Comment by nonethewiser | Hacker News Reader

Comment by nonethewiser | Hacker News Reader

Parent Full thread

But doesn't this beg the question: why not GET with query params?

I'm not necessarily against it - I've had the urge to send a body on a GET request before (cant recall or justify the use-case, however).

Reasons I can think of:

- browsers limit url (and therefore) query param size

- general dev ergonomics

The practical limits (ie, not standard specified limits) on query param size seems fair but its worth mentioning there are practical limits to body size as well introduced by web servers, proxies, cloud api gateways, etc or ultimately hardware. From what I can see this is something like 2kb for query params in the lower end case (Chrome's 2083 char limit) and 10-100mb (but highly variable and potentially only hardware bound) for body size.

In both cases it's worth stating that the spec is being informed by practical realities outside of the spec. In terms of the spec itself, there is no limit to either body size or query param length. How much should the spec be determined by particular implementation details of browsers, cloud services, etc.?

With a request body you can also rely on all the other standard semantics that request bodies afford, such as different content-types, content encoding. Query parameters are also often considered less secure for things like PII and (less important these days) query parameters don't really define character encoding.

But generally the most important reason is that you can take advantage of the full range of mimetypes, and yes practicality speaking there's a limit on how much you should stuff in a query parameter.

This has resulted in tons of protocols using POST, such as GraphQL. This is a nice middle ground.

Servers have to limit header size as well, since content-length isn't available. Without a bounded header size the client can just send indefinitely.

Also just impossible to read, and url encoding is full of parser alignment issues. I have to imagine that QUERY would support a json request body.

Size can be a very practical concern if your query parameter is e.g. a picture.

Not showing the URL in various logs can be a concern if your query parameters are sensitive.

A picture as an input for a GET seems like a very strange use-case. Can you elaborate?

I do agree on the quirkiness of encoding a bunch of data in the URL. Its nice to decouple the endpoint from the input at a more fundamental level.

Use cases like reverse image search come to mind

Reasons:

  - URI length limits (not just
    browsers, but also things
    like Jersey)
  
  - q-params are ugly and limiting
    by comparison to an arbitrarily
    large and complex request body
    with a MIME type

However, q-params are super convenient because the query is then part of the URI, which you can then cut-n-paste around. Of course, a convenient middle of the road is to use a QUERY which returns not just query results but also a URI with the query expressed as q-params so you can cut-n-paste it.

Query params are also extremely commonly logged all over the place and so putting sensitive information in them is almost always a bad idea.

Of course. The security considerations section does mention this as a feature of `QUERY`, saying that the `Location:` returned by the server should not encode all the details of the request.

However it's also true that q-params effectively form part of the UI. I'm certain you've edited URIs before -- I have, and I know not-so-knowledgeable people who do it too.

Striking a balance here is not easy. With `QUERY` the server can decide how much of the query to encode into the `Location:`, if any of it at all. The server might use knowledge of the "schema" that the query refers to, or it might use the syntax of the query (if it supports indicating sensitive portions), or it might only "link-shorten" the whole query.

This avoid changing the definition of GET. Who knows how many middle boxes would mess with things if you did that because they “know” what GET means and so their thing is “safe”.

Until GET changes.

People aren’t using QUERY yet so that problem doesn’t exist.

Reply on news.ycombinator.com