It would be a potentially breaking change so out of an abundance of caution likely would require (or need to wait for) a new version of HTTP like HTTP/4.0. On the other hand, adding an entirely new Method potentially can be applied across HTTP versions. It's possible for an HTTP/1.1 server to accept QUERY today under this RFC, it doesn't need to wait for and upgrade to HTTP/4.0 service, whatever that would entail. (Especially in the Postel's Law world where HTTP/1.1, HTTP/2.0, and HTTP/3.0 are all living side-by-side and are very different protocols under the hood.)
There's countless proxies in the wild that would not behave correctly with an RFC-defined GET-with-body, and there's no way for a client to know if that's the case.
QUERY has the advantage of getting default behaviour from most proxies (which at least is well behaved even if inefficient). If there are any proxies that just drop QUERY requests, at least they won't silently mangle the request.
This is the same way that instead of improving how HTTP 301 was specified, HTTP 308 was created. It's a pragmatic move.
i actually agree with you, i don't comprehend why we're adding anything to HTTP like this, it is basically already deprecated. The modern API is WebTransport, if you want to make caching better for WebTransport, do it there.
If we're going to play the "should" game, whatever originated the body "shouldn't" have because the spec says that's illegal.
Although we could also go with, a proxy shouldn't delete the body, it "should" reject the request outright as ill-formed.
The meta-point I'm making here, which I'm sure will be missed if I don't spell it out, is that if we're going to talk about what "should" be done when it is explicily out of the scope of a standard, there's no way around the fact that there are multiple completely sensible ways to extend the standard and there's every reason to expect that in the real world people aren't going to agree. Sometimes they manage to, but even then often quite imperfectly. Our human intuitions that standards are something that are "built" is perhaps not wrong, but you can also productively look at standards as taking the raw material of all possible things two systems could send to each other and removing possibilities. If you reach into a space that has been explicitly removed, you can't expect everyone else to do so in exactly the same way you will.
For a very long time, the spec did not say it's illegal. In fact, RFC 2616 (that has been defining the HTTP/1.1 for 15 years) says that
A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests. A server SHOULD
read and forward a message-body on any request; if the request method
does not include defined semantics for an entity-body, then the
message-body SHOULD be ignored when handling the request.
but if you go into the section that describes the semantics of a GET request, well — that section says nothing at all whether a GET request is allowed or not to have a message-body. So it's not prohibited, and the servers should simply ignore it when processing it (and proxies should forward it up).
The HTTP standard does not define a body for GET requests. Therefore, proxy implementations will typically only copy the data from the request header when sending it off to its next destination. They don’t technically “delete” anything. This saves compute (and possibly bandwidth, if the request happened to have a body, although the whole point is that one can safely assume a GET request does not have a body per the standard).
It would be a potentially breaking change so out of an abundance of caution likely would require (or need to wait for) a new version of HTTP like HTTP/4.0. On the other hand, adding an entirely new Method potentially can be applied across HTTP versions. It's possible for an HTTP/1.1 server to accept QUERY today under this RFC, it doesn't need to wait for and upgrade to HTTP/4.0 service, whatever that would entail. (Especially in the Postel's Law world where HTTP/1.1, HTTP/2.0, and HTTP/3.0 are all living side-by-side and are very different protocols under the hood.)
There's countless proxies in the wild that would not behave correctly with an RFC-defined GET-with-body, and there's no way for a client to know if that's the case.
QUERY has the advantage of getting default behaviour from most proxies (which at least is well behaved even if inefficient). If there are any proxies that just drop QUERY requests, at least they won't silently mangle the request.
This is the same way that instead of improving how HTTP 301 was specified, HTTP 308 was created. It's a pragmatic move.
Proxies often delete it
They could be updated to not delete it, like they would require for this new method anyway.
"Checkmate, IETF."
i actually agree with you, i don't comprehend why we're adding anything to HTTP like this, it is basically already deprecated. The modern API is WebTransport, if you want to make caching better for WebTransport, do it there.
Agree.
They should not delete the body in the first place.
If we're going to play the "should" game, whatever originated the body "shouldn't" have because the spec says that's illegal.
Although we could also go with, a proxy shouldn't delete the body, it "should" reject the request outright as ill-formed.
The meta-point I'm making here, which I'm sure will be missed if I don't spell it out, is that if we're going to talk about what "should" be done when it is explicily out of the scope of a standard, there's no way around the fact that there are multiple completely sensible ways to extend the standard and there's every reason to expect that in the real world people aren't going to agree. Sometimes they manage to, but even then often quite imperfectly. Our human intuitions that standards are something that are "built" is perhaps not wrong, but you can also productively look at standards as taking the raw material of all possible things two systems could send to each other and removing possibilities. If you reach into a space that has been explicitly removed, you can't expect everyone else to do so in exactly the same way you will.
> the spec says that's illegal.
For a very long time, the spec did not say it's illegal. In fact, RFC 2616 (that has been defining the HTTP/1.1 for 15 years) says that
but if you go into the section that describes the semantics of a GET request, well — that section says nothing at all whether a GET request is allowed or not to have a message-body. So it's not prohibited, and the servers should simply ignore it when processing it (and proxies should forward it up).The HTTP standard does not define a body for GET requests. Therefore, proxy implementations will typically only copy the data from the request header when sending it off to its next destination. They don’t technically “delete” anything. This saves compute (and possibly bandwidth, if the request happened to have a body, although the whole point is that one can safely assume a GET request does not have a body per the standard).