Hacker News

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

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 all usage scenarios are the public internet, and something doesn't have to be useful on the public internet to be standardized.

Realistically, systems for the public internet will use a secure hash as the cache key so it'll always be the same size. The cache key already includes a URL that can be very long, and an arbitrary set of header values.

One example - I'm building an MCP server at the moment for a database I'm working on. In ChatGPT I want to do dry-run posts first that roll back before committing - both are POST requests with a property - and it loves to trigger the safety layer in the tools (for various reasons, it's hard to debug exact causes)

But I think this would make it better - QUERY before POST means different request types, not just the same with a safety flag.

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.

> Why even bother trying to capture this in a generic way?

I guess it's about resolving the odd semantics of using POST which is not idempotent and thus allowing easier control flow of caches and retrys.

Your perspective is 100% correct if you think at the application-layer, but with a dedicated method, you can have that behaviour out-of-the-box out of your HTTP infrastructure (whether it's at your hyperscaler's router or your apache/nginx/browser whatever) and stop implementing yourself the post-as-a-query edge case.

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

I would use a hash of the body content (the query) as a URL parameter

/?hash=123456789

If you control the full stack then the functionality described here can be implemented with POST. The only way this comes into play is if some second party client of your service is trying to impose rules on how your backend works. My answer to that is no. I will be defining the contract by which my services operate.

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

This is better solved with the post redirect get pattern.

See https://github.com/whatwg/html/issues/12594.

One oddity of forms: the result of a form POST is a page that has a location (the URL) but that cannot loaded via that location. As far as I know, the fact that the page is a POST and not a GET is not stored anywhere visible to the user or to JS. And refresh works oddly.

If method=QUERY were added, there would be a new variety of this weirdness.

Depends whether your form submission should expect side effects or not. Most forms submissions have side effects. If the effect is truly idempotent, wouldn't PUT be a better verb? That is also supposed to be idempotent.

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

Now HN’s UX can finally be decent.

The team will have to wait for a new header and textarea specs to fix the rest of the jank.

This site is so awful lol. Why don’t they update it?

I'll forever love a long, totally plain text document like this. So many good times with video game FAQs as a kid. It really is a superior form of information in a lot of ways (not all).

beautiful formatting. I should crib this style template for internal work memos, it's timeless.

Apparently some load balancers drop the body.

> I've been sending request body along GET method for years now

Generally not a great idea. With some http implementations this is not even possible (for example, fetch)

https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

> You cannot include a body with GET requests

And transparent caching might result in weird issues.

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.

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

Probably won't. Probably will replace whenever POST is currently used for a query.

Yeah, and it doesn't even have to be a query, it could be an idempotent effect. I think they'd be better off calling it IPOST (for idempotent post).

Edit: ah, they declare QUERY as "safe" meaning no side effects, for cacheability. My mistake.

> the term 'query' is already used to refer to http requests in general

In what circles is this the case? I sometimes colloquially refer to a GET request as a query, but definitely not so on a POST, PUT or DELETE.

The standards have always been a bit more abstract than you use in practice. Common practice prior to this would be /catsearch?sleep=20&sunbeams=yes&breakfast=0300 where the "resource" is /catsearch and the rest are query parameters, but you could also use /catsearch/sleep/20/sunbeams/yes/breakfast/0300 which looks like a "resource", but nobody is actually enforcing that it is a "resource".

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.

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

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 prepared statements in SQL databases.

Using QUERY for GraphQL queries (not mutations) would be a good match. These only read data, but are sometimes bigger than the url length limit.

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

Nah, you need the 405 Method Not Allowed to be returned by legacy systems and proxies along the way to your bleeding edge server rather than silently failing whilst dropping the params in the request body.