Hacker News Reader

Comment by newscracker | Hacker News Reader

A couple of quick observations and comments after skimming through this (some of these are mentioned or hinted at in the RFC).

With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY.

One of the advantages of GET is the direct visibility, which makes modifications simple and easy for almost anyone (end users, testers, etc.).

The larger question I have is who will choose to adopt it sooner, with web servers, web application frameworks and web browsers in the mix.

View on HN

The situations where I've wished for GET to be able to have a (typically JSON) body were all in situations where the request isn't "user visible" in the first place. That is: API calls, SPA apps, ajax requests, that sort of thing. Not something people are really supposed to bookmark or call directly.

If today you're doing some JS-fu to make an ajax GET request then you already need to do something to have permalinks (if desired).

Completely worth bringing up and thinking about, but unless I'm missing something I don't think a QUERY verb will change all that much here?

> unless I'm missing something I don't think a QUERY verb will change all that much here?

The semantics are important. GET APIs are expected to be safe, idempotent, and cache-friendly. When you are unable to use GET for technical reasons and move to POST, suddenly none of the infrastructure (like routers, gateways, or generic http libs) can make these assumptions about your API. For example, many tools will not attempt to put retry logic around POST calls, because they cannot be sure that retrying is safe.

Having the QUERY verb allows us to overcome the technical limitations of GET without having to drop the safety expectations.

I like the safety aspect of QUERY. Having CDNs cache based off the semantics of the content might be a hard ask. I wonder if this might lead to a standards based query language being designed and a push for CDNs to support it. Otherwise you probably need to implement your own edge processing of the request and cache handling for any content type you care to handle.

Yes, I understand that. I'm just commenting on the "bookmarkable" aspect here, obviously.

You can just use body with GET. QUERY is redundant.

You can, and that is mentioned in RFC 9110... along with the cons for doing so.

> Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain.

QUERY is a new option to help avoid some of those downsides.

https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3.1

Just release change to this RFC and adjust GET body semantics. Much easier than introducing a whole new verb and already supported in a lot of software.

> With HTTPS used almost everywhere, using this QUERY method (when standardized) could prevent bookmarking specific “GET” URLs if the developers thoughtlessly replace GET everywhere with QUERY.

You're bothering about non-issues. Bookmarks support GET requests, not any other verb. Like it has always been, if you need to support bookmarks then you implement bookmarkeable URLs to be used with GET requests.

Also, your far-fetched example failed to account for the fact that nowadays POST requests are used to query.

Reply on news.ycombinator.com