151–160 of 189 posts
> GET request with a body was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method. The decision to create a distinct method came down to historical interoperability issues and strict compliance with the core architectural definitions of HTTP. I've been sending request body along GET method for years now
If this is actually going to replace GET requests w/ query strings in the wild, Im very much hoping for browser bookmarks to support keeping request parameters.
> GET request with a body was heavily considered by the IETF working group, but it was ultimately rejected in favor of creating the new QUERY method. The decision to create a distinct method came down to historical interoperability issues and strict compliance with the core architectural definitions of HTTP. I've been sending request body along GET method for years now
you can do all kinds of nonstandard stuff if you control the server, the client, and any steps in between. the point of standards is for when you don't control it all.
put your server behind a managed load balancer or a caching proxy, and your get requests with bodies aren't going to do so well anymore.
Just curious, was it Google/Facebook that sponsored this?
Edit: refute or agree, please.
I wonder if HTML forms will add support for QUERY: This would avoid the annoying re-submission warnings you're getting if you refresh a page that was returned by a POST form submission, since QUERY is required to be idempotent.
This whole thing is non sense. It basically mixes technical constraints (body or not body) with a functional requirement that arises from people that are tied to semantics of the protocol. HTTP is transfer protocol. It should not ever imply anything at the business level. Yes REST made it's worst mistake out if it by giving a meaning to the verb. Yes proxies rule how the body is re-interpreted in spite of the will of…
Yes this, yes that, yes the other, because proxies are in agreement with patterns are in agreement with the HTTP spec that methods exist and have semantic and functional requirements. Your 'should' seems to be discussing a hypothetical technology that is not HTTP, because HTTP has worked this way since 1997.
What I meant was a tangent: the HTTP was designed with a strong assumption that the application implementing it (the web server) would be the one providing the logic. Hence all the RFC terminology "should", "must", targeted at the implementor.
But very quickly, the logic was deferred to a layer on top (PHP,...) which would focus on the business aspect. The wiring was strong but the contract intent is loose (the requirements on the transport do not apply to the function).
Different layers, different people involved. What survived are the more or less conventions about it, which for the ease and limitations imposed by the protocol layer, led to infinite discussions about GET having a body or not.
The whole question arises because there is this clash between transport and logic that is wired on top, not built-in.
So while indeed, introducing QUERY solves a protocol gap, the people designing the business method never cared (or even knew) about that gap in the first place. This was another people's job to try to reconcile the two.
That's why I'm saying that digging into the initial assumption that the implementor of the HTTP is bound to business-level contraints is not reflecting the reality that has been going on since the early days of the dynamic web.
Earlier quoted context omitted.
Technically a put or a patch is also idempotent. The benefits are idempotent and safe (and semantically appropriate). Post (generally) communicates something is changing whereas a query doesn't
PUT is idempotent, PATCH is not always. The semantics of a PATCH payload are up to the server and standards like JSON Patch (RFC 6902, https://datatracker.ietf.org/doc/html/rfc6902 ) allow non-idempotent operations like adding an item to a list.
Earlier quoted context omitted.
Your link doesn't say URIs are length-limited
They are in the sense that the recommended supported length is only 8000 bytes. There are no such specified length recommendations for HTTP body size.
Of course I don't advocate oversize URLs. That's a point of RFC10008.
Let's say we build a service for image transformation or image information extraction. Get isn't practical. QUERY with image as body could be a valid usage, regardless of caching. It conveys information that request is idempotent and can be retried with no impact on data, contrary to POST. If your http client is configured to support this, it can potentially improve reliability.