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

21–30 of 189 posts

Re: RFC 10008: The new HTTP Query Method

#21

Post by n_e »

CodesInChaos wrote: post #7
brookst wrote: post #3

Wouldn’t just putting an etag on POST requests accomplish the same thing? If I’m understanding it the server has to maintain state to ensure idempotency.

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…

Interestingly, despite the QUERY request being safe, the RFC says it's subject to preflight requests:

> A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see [FETCH]).

Re: RFC 10008: The new HTTP Query Method

#22

Post by cryptonym »

100ms wrote: post #10

Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting. Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningf…

Sure you can provide an image as request body, but you could already do it with b64 query parameter. If you try hard enough, you can poorly use any proposed standard. GET with query parameters already is opaque and makes cache busting trivial.

Re: RFC 10008: The new HTTP Query Method

#23

Post by networked »

Imustaskforhelp wrote: post #12
rhplus wrote: post #11

Earlier quoted context omitted.

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...

Everytime I think that prediction markets bets can't get worse, they do, all in weird ways. I never expected someone betting over when RFC 10,000 will be published but somehow its fits just about right for prediction markets. just wow, people seem to be having too much money it seems for them to bet over when RFC's are gonna get released. This isn't even one of the worst offenders on prediction market or even compara…

People aren't betting real money on this. Manifold uses "mana" points similar to HN karma, which is why you get more for-fun silly bets. I don't see anything inherently wrong with it. Disclosure: my mana net worth is 75k; I haven't been active on Manifold.

Re: RFC 10008: The new HTTP Query Method

#24

Post by 100ms »

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.

Forms, HTTP implementations, public API surfaces, and all for what exactly. Introducing a new verb for this feels profoundly misplaced

Re: RFC 10008: The new HTTP Query Method

#25

Post by friendzis »

100ms wrote: post #10

Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting. Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningf…

> It also implies an unbounded and user-controlled cache key.

While the concern is valid, caching is entirely optional at query level, therefore it is totally valid to cache only certain "filters".

Re: RFC 10008: The new HTTP Query Method

#26

Post by CodesInChaos »

n_e wrote: post #21
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…

Interestingly, despite the QUERY request being safe, the RFC says it's subject to preflight requests: > A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see [FETCH]).

That paragraph merely describes how existing browsers behave, it doesn't specify how future browsers must behave. After all, a HTTP RFC isn't really the right place to specify browser specific behavior like CORS, that belongs in a W3C/WHATWG specification.

Re: RFC 10008: The new HTTP Query Method

#28

Post by giancarlostoro »

Joker_vD wrote: post #19
100ms wrote: post #10

Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting. Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningf…

> It also implies an unbounded and user-controlled cache key, The query part of GET's URI is also barely bounded in practice and user-controlled, and is indeed used as part of the cache key (because it's a part of URI), so I am not sure why you raise this objection at all.

> and user-controlled

I've found some sites that tack on a session ID and if you try to tamper with the URL in any way, it sends you back to "Page 1" really annoys me lol at that point let me skip to any page with your web UI.

Re: RFC 10008: The new HTTP Query Method

#29

Post by layer8 »

cryptonym wrote: post #22
100ms wrote: post #10

Including a strong motivating example might have helped sell this, using an example that could trivially be expressed as a GET is extremely distracting. Even imagining a QUERY with a large JSON filtering structure, or say an image input as request body, it feels extremely odd to include the request body as part of the cache key. It also implies an unbounded and user-controlled cache key, with the only really meaningf…

Sure you can provide an image as request body, but you could already do it with b64 query parameter. If you try hard enough, you can poorly use any proposed standard. GET with query parameters already is opaque and makes cache busting trivial.

Query parameters are length-limited, because HTTP URIs are: https://www.rfc-editor.org/info/rfc9110/#section-4.1-5. There is no expectation for arbitrarily long HTTP URLs to be functioning.

Re: RFC 10008: The new HTTP Query Method

#30

Post by CodesInChaos »

ctdinjeu7 wrote: post #27
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.

[flagged]

Where does HN use POST for safe operations? I can't think of any.

Comment submission isn't safe, so QUERY can't be used there. And it doesn't suffer from the problem anyways, since HN returns a 3XX on successful submission, so refreshing doesn't show a warning.

Post reply on HN