Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 10008: The new HTTP Query Method

rfc-editor.org

Post reply on HN
Print view View original

131–140 of 189 posts

Re: RFC 10008: The new HTTP Query Method

#131

Post by drdexebtjl »

ralferoo wrote: post #70
cryptonym wrote: post #50

Earlier quoted context omitted.

You are guessing wrong. Thanks, I know specific implementation will come with their limits. This will equally apply to QUERY body size and caching strategy. Are we seriously ok with linking the RFC as source while providing a statement that doesn't match? RFC does matter.

The RFC does say "It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements." One can infer from the RFC that you can reasonably expect many implementations to fail beyond 8000 characters, and that there are no guarantees up to that either. True, the RFC doesn't specify a limit, but it does clearly indicate that it's not unbounded, nor should you ex…

This RFC (10008) does not require caching to be implemented at all, so it would make no sense to make a recommendation here for what is a reasonable limit to expect caching to work.

Re: RFC 10008: The new HTTP Query Method

#132

Post by drdexebtjl »

ralferoo wrote: post #129
inigyou wrote: post #85

Earlier quoted context omitted.

POST/QUERY data can be in any format. Who are you to say order doesn't matter? Are you sure you can even parse it? Mine is in DES-encrypted (with key "password") base85 DER, you really gonna implement that in your proxy?

Maybe my knowledge is out of date in terms of how people generally use POST nowadays, but AFAIK multipart/form-data is still the most common encoding for data and occasionally application/x-www-form-urlencoded. Both of these, the key values can be in any order with the same interpretation. That's kind of a moot point for POST method, because they should never be cached anyway, but for the new QUERY method it'd be rea…

This RFC does not require caching to be implemented at all, so it wouldn’t be reasonable to expect a cache hit, no. But if your implementation does that, cool :)

Re: RFC 10008: The new HTTP Query Method

#133

Post by Joker_vD »

spockz wrote: post #130
OvervCW wrote: post #58

Earlier quoted context omitted.

There is: your browser or other type of client does not know it can repeat a POST request if it fails, whereas a QUERY request can be freely repeated in case of errors.

Not freely. It is idempotent, not safe. So it still can have serious load consequences.

    Unlike POST, however, the method is explicitly safe and idempotent, allowing
    functions like caching and automatic retries to operate.

Re: RFC 10008: The new HTTP Query Method

#134

Post by CodesInChaos »

acabal wrote: post #93
CodesInChaos wrote: post #17

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.

Supporting more than GET/POST in HTML forms has been my dream for decades. There's a WHATWG proposal to do just that if you want to add your voice: https://github.com/whatwg/html/pull/11347

I'm not convinced of the benefit of allowing PUT/PATCH/DELETE in forms. But QUERY sounds more useful, and its lack of side-effects (plus the lack of legacy code using it) would avoid the need for CORS preflight requests.

There is a separate issue for QUERY: https://github.com/whatwg/html/issues/12594

Re: RFC 10008: The new HTTP Query Method

#135

Post by schoen »

rhplus wrote: post #11
pwdisswordfishq wrote: post #4

Wait, it's already past 10 thousand?

Someone has an ambiguous bet predicting when RFC 10000 will be published, but the numbers went straight from 9998 to 10008. No-one wins! https://manifold.markets/CollectedOverSpread/when-will-rfc-1...

Is anyone formulating prediction market questions asking AIs to brainstorm about edge cases in order to leave fewer of them uncovered by the market definition?

We do have humans brainstorming about such things, but this feels like something LLMs might be good at.

Re: RFC 10008: The new HTTP Query Method

#136

Post by nfw2 »

drdexebtjl wrote: post #128
afavour wrote: post #57

Earlier quoted context omitted.

Is caching not the primary reason to use this over POST? You should never want to cache POST requests.

No. Being idempotent, it also lets the browser/client/reverse proxy retry it if it fails.

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

Re: RFC 10008: The new HTTP Query Method

#138

Post by [deleted] »

piterrro wrote: post #44

> 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

[deleted]

Re: RFC 10008: The new HTTP Query Method

#139

Post by nfw2 »

stymaar wrote: post #105
mholt wrote: post #104

Earlier quoted context omitted.

Too many servers ignore/drop/reject body in GET requests. RFC 9110 does allow it, but is only recommended if server documentation states that it is supported.

These servers will likely also reject the QUERY request though…

Yeah those servers need to be updated anyway to support the new standard

Also, anyone using these servers is not currently putting params in GET body because doing so wouldn't work.

Those that oversee evolving standards seem to take extreme cautious to not rock the boat, and so more and more gotchas for the sake of backwards-compatibility keep getting added to the mountain of random details new devs have to learn. Which will soon include the difference between a GET and a QUERY I guess.

Re: RFC 10008: The new HTTP Query Method

#140

Post by nfw2 »

brookst wrote: post #33
CodesInChaos wrote: post #7

Earlier quoted context omitted.

QUERY is GET with a request body. So it must be safe , not just idempotent . Where safe means it has no significant side-effects. Typically servers will not keep any state for QUERY requests. There is one interesting variant though, which uses state: The client sends a QUERY containing the full query, and the server returns a url usable with GET with which this query can be triggered in the future. Similar to prepare…

Thanks for the explanation! I still don’t get how idempotency can typically be ensured without state. It very much depends on data model and application design. Even side effects like using a user’s lookup quota need to be handled at a higher layer than HTTP (I think?).

HTTP can't ensure what happens in the application layer is safe or idempotent. It is up to the developer to ensure that the implications communicated by their api design are in fact true.
Post reply on HN