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

141–150 of 189 posts

Re: RFC 10008: The new HTTP Query Method

#141

Post by ralferoo »

drdexebtjl wrote: post #132
ralferoo wrote: post #129

Earlier quoted context omitted.

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 :)

An RFC would never mandate caching. But the table in the article says "cacheable: yes" for GET and QUERY. There is no "my implementation" because this is a proposal that has only just been proposed and there is currently "no implementations". I'm simply saying that QUERY will be harder to get caching correct compared to GET, and I'm almost certain there will be end up being CVEs resulting from its implementation.

Re: RFC 10008: The new HTTP Query Method

#142

Post by dagss »

ralferoo wrote: post #65
CodesInChaos wrote: post #36

Earlier quoted context omitted.

The browser can simply store a collision resistant hash (e.g. SHA-256) of the body, if it wants a smaller cache key. I can't really think of any caching related attacks that don't equally apply to a query parameter. Generating a unique 30 character query parameter is just as easy as generating a 30 MB request body, if you want to flood the cache.

Not necessarily that simple, as you'd have sort all the input parameters to maintain a useable cache key. Not especially difficult, but if the data is large and so re-allocation and sorting is required, then you're starting to open up the attack surface where bugs might have been introduced.

Do you have to? Is it common to treat ?a=1&b=2 the same as ?b=2&a=1 in browser/CDNs/etc?

Seems the spec puts this as a MAY. I think I doubt it will be implemented in generic ways, except perhaps for urlencoded payloads. After all you cannot normalize in general without knowing the query language. At the backend it does not matter, may as well cache one level deeper based on the parsed input irrespective of QUERY or not.

Re: RFC 10008: The new HTTP Query Method

#143

Post by angrybards »

barbazoo wrote: post #91

> GET: Content (body) "no defined semantics" I thought it wouldn't be a terrible idea to open up the GET method to contain a body but according to the original spec the GET body is to be ignored completely. There's also caching which would break because the important bit of the request would live in the stripped body.

GET with only a URI has the semantics of retrieving the current representation of the resource. This is the most basic form of hyperlinking and quite important to how the web works. Adding a body parameter to GET would break that constraints of the method as you couldn't treat two requests using the same URI as referencing the same thing.

Re: RFC 10008: The new HTTP Query Method

#144

Post by drdexebtjl »

ralferoo wrote: post #141
drdexebtjl wrote: post #132

Earlier quoted context omitted.

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 :)

An RFC would never mandate caching. But the table in the article says "cacheable: yes" for GET and QUERY. There is no "my implementation" because this is a proposal that has only just been proposed and there is currently "no implementations". I'm simply saying that QUERY will be harder to get caching correct compared to GET, and I'm almost certain there will be end up being CVEs resulting from its implementation.

It’s been an IETF Internet-Draft for a few years at this point, so there are some implementations already in the wild.

What I mean is that implementations are free to choose do something as complex as what you suggest, but also something as simple as hashing the body as a blob, and they can even bail on caching completely (for example if the payload is too large).

All of those options would be correct behavior per the RFC.

Of course we may still see CVEs from this, but they will be self-inflicted, not caused by a complex standard.

Re: RFC 10008: The new HTTP Query Method

#145

Post by cosmotic »

advisedwang wrote: post #88
cosmotic wrote: post #78

Why not just define the semantics of a GET request body?

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…

Would those same proxies work with the new method?

Re: RFC 10008: The new HTTP Query Method

#146

Post by gamache »

nfw2 wrote: post #136
drdexebtjl wrote: post #128

Earlier quoted context omitted.

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

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.

Re: RFC 10008: The new HTTP Query Method

#147

Post by ralferoo »

dagss wrote: post #142
ralferoo wrote: post #65

Earlier quoted context omitted.

Not necessarily that simple, as you'd have sort all the input parameters to maintain a useable cache key. Not especially difficult, but if the data is large and so re-allocation and sorting is required, then you're starting to open up the attack surface where bugs might have been introduced.

Do you have to? Is it common to treat ?a=1&b=2 the same as ?b=2&a=1 in browser/CDNs/etc? Seems the spec puts this as a MAY. I think I doubt it will be implemented in generic ways, except perhaps for urlencoded payloads. After all you cannot normalize in general without knowing the query language. At the backend it does not matter, may as well cache one level deeper based on the parsed input irrespective of QUERY or n…

No, that was my point. In a GET request, a caching proxy cannot assume the URL is URL encoded parameters, because the URL can contain data encoded in any form. So, you could only cache a GET on an exact URL.

But for a QUERY that explicitly marked the data as multipart or url-encoded, then semantically the order of parameters no longer matters.

That said, it's hypothetical because the only thing that uses those at the moment is POST and that explicitly should never be cached.

But there's another reply above to my comment that points out that a caching implementation is free to do what it likes, and if it fails to cache when parameters are in a different order, then it would still be correct, which is a fair point. That comment was https://news.ycombinator.com/item?id=48578024

Re: RFC 10008: The new HTTP Query Method

#148

Post by acabal »

MBCook wrote: post #122
acabal wrote: post #93

Earlier quoted context omitted.

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

What’s the use case for that?

Because if HTTP is the language of the web, then HTML forms are how humans speak that language to computers. Right now we humans can only speak GET and POST.

In other words, right now if a human wants to DELETE a widget, the human has click on an HTML form to `POST /widgets/123/delete` - i.e. use an incorrect verb on an incorrect URL/object - or use some other workaround like smuggling a special `_method=DELETE` variable. This is unnatural and semantically incorrect, resulting in ugly hacks that break HTTP-level expectations like idempotency; and it also requires additional app-level logic to process.

Meanwhile a machine is allowed to simply `DELETE /widgets/123` because their interface to HTTP is not clicking on HTML forms.

We humans could converse with websites in semantically correct HTTP, have clean URLs in which both REST APIs and human-facing URLs are identical without hacks, and require no extra app/framework logic, if HTML forms simply allowed all (human-relevant) HTTP verbs.

Re: RFC 10008: The new HTTP Query Method

#149

Post by brookst »

Joker_vD wrote: post #37
brookst wrote: post #33

Earlier quoted context omitted.

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

> I still don’t get how idempotency can typically be ensured without state. Well, how is "GET /index.html HTTP/1.1" made idempotent in practice without (additional) state?

Ah, QUERY is explicitly scoped to be read-only, unlike PUT, POST, DELETE, etc. I had missed that part.

Re: RFC 10008: The new HTTP Query Method

#150

Post by pseudohadamard »

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

It does seem like a boil-the-ocean "fix". The entire planet has been kludging this with GET or POST as appropriate for the entire lifetime of HTTP, and now there's a proposal to do something that looks identical to POST but with slightly different semantics? So in exchange for solving a problem that's been dealt with (if not perfectly) forever you'd need to convince the entire world to adopt a new, incompatible mechanism? I'll give this one as much of a chance as BEEP.

You've never heard of BEEP? Well, that's why.

Post reply on HN