A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing
implementations to reject the request.
Right. The HTTP RFCs have been backing off gently from the initial position that implementations should not sent bodies with GETs and that the semantics of the GET request were defined purely in the request URI.
But presumably no-one is brave/foolhardy enough actually to redefine GET as having a semantic body because a bazillion different implementations (clients, servers and middle boxes) probably become non-compliant.
>redefine GET as having a semantic body because a bazillion different implementations (clients, servers and middle boxes) probably become non-compliant.
So what actually?
apps that didnt use GET Body, will not care anyway
apps that will use HTTP GET Body will be checked anyway
So, unless somebody downgrades HTTP Server then what could be the problem?
Aside from how much easier it is to identify whether a component supports QUERY than which forms of GET it supports, GET and QUERY (like PUT and DELETE) have similar guarantees have different meaning and are sometimes (but not always) useful against the same resource for different purposes. OPTIONS lets you tell the availability of that of they are different methods, but not if one is GET w/o body and the other is GET w/body.