Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP Query Method

ietf.org

Post reply on HN
Print view View original

71–80 of 136 posts

Re: The HTTP Query Method

#71

Post by locknitpicker »

newscracker wrote: post #8

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…

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

Re: The HTTP Query Method

#72

Post by gaigalas »

themafia wrote: post #67
gaigalas wrote: post #51

Earlier quoted context omitted.

GET: I want to see stuff. POST: I want to change stuff. I don't know how this style cannot match cleanly any architecture. It's not supposed to be a map to CRUD, it's a bunch of building blocks for manipulating state over a network.

PATCH: I want to change stuff.

PATCH: I want to change stuff in a predictable way.

--

PUT: I want to replace stuff.

DELETE: I don't want anyone to GET that stuff anymore.

HEAD: I want to peak at how stuff is shown.

OPTIONS: I want to know what I can do with stuff.

--

COPY: I want to copy stuff (WebDav)

MOVE: I want to move stuff (WebDav)

MKCOL: I want a new sublevel of stuff (WebDav)

PROPFIND: I want to list stuff (WebDav)

PROPPATCH: I want to mass change stuff (WebDav)

LOCK: I want to control who METHODs stuff.

UNLOCK: I want to remove control over who METHODs stuff.

--

All of those are actually optional. It is okay to use POST[0]. GET and POST with proper hypermedia (media types and links) is all 99% of apps need.

[0]: https://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post

Re: The HTTP Query Method

#73

Post by locknitpicker »

leloctai wrote: post #31

As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration. More than one I've seen some sites with UI so bad, that manually editing the url is the easiest way to get it to do what i want.

> As inefficient as encoding everything into the URI is, I really enjoy being able to bookmark and share specific filter configuration.

That is perfectly fine. Sites that support path- and query-based filters are already designed specifically to have filters embedded in links, which are GET requests. The QUERY method is something more in line of a GraphQL style of query that isn't held back by the semantics of a POST request. GraphQL didn't invented this API style. If GraphQL-style APIs didn't affected how WebApps implemented links, QUERY methods won't.

Re: The HTTP Query Method

#74

Post by chrisandchris »

gridlocdev wrote: post #17

I can’t wait for QUERY to become an official RFC. It's felt quite awkward to tiptoe around the existing spec when building features that retrieve data; we've had to either use POST to keep sensitive filter criteria out of http logs or just create a usually massive URL-encoded query string.

There's nothing holding you back implementing the QUERY method right now - HTTP methods are standardized, but not limited to the standard. Obsviously it depends how proxies/servers/etc. might handle uncommon methods.

Re: The HTTP Query Method

#75

Post by locknitpicker »

chronicler wrote: post #2

Making GET requests have bodies as the norm would also handle this

> Making GET requests have bodies as the norm would also handle this

The RFC is pretty clear that no participant in a HTTP request is expected to even allow a GET request through. RFC 9110 even states quite clearly that it's even a potential request smuggling attack. Some major cloud providers provide API Gateway implementations that outright strip request bodies from GET requests.

I think you are missing the whole point of proposing a new HTTP verb. Changing the semantics of a GET request is not an option because of both the security risks it presents and the fact that the infrastructure of the whole internet either is designed to reject these requests or outright breaks. See how GET requests are cached and how cache implementations don't discriminate GET requests based on it's request body.

Re: The HTTP Query Method

#76

Post by locknitpicker »

cortesoft wrote: post #18
platzhirsch wrote: post #3

Earlier quoted context omitted.

I might be misunderstanding something, but it seems the issue isn't really about whether GET can technically carry a body. The deeper concern is that HTTP methods have specific meanings, and mixing those signals can causes confusion and it's nice to have this semantic separation.

If you look at the summary table, the only difference between a GET and a QUERY is that the query can have a body. Other than that, they have the exact same characteristics and purpose, so there isn’t really a need to semantically separate them.

> If you look at the summary table, the only difference between a GET and a QUERY is that the query can have a body. Other than that, they have the exact same characteristics and purpose, so there isn’t really a need to semantically separate them.

This is outright false. RFC9110, which clarifies semantics of things like GET requests, is clear on how GET requests should not have request bodies because it both poses security issues and breaks how the web works.

Just because your homemade HTTP API expects a GET request packs a request body, that does not mean any of the servers it hits between your client and your server will. Think about proxies, API gateways, load balancers, firewalls, etc. Some cloud providers outright strip request bodies from requests.

The internet should not break just because someone didn't bothered to learn how HTTP works. The wise course of action is to create a new method with specific semantics that are clear and actionable without breaking the world.

Re: The HTTP Query Method

#77

Post by vbezhenar »

flakes wrote: post #36
arp242 wrote: post #12

Earlier quoted context omitted.

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…

> 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 attem…

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

Re: The HTTP Query Method

#79

Post by virtue3 »

bruce511 wrote: post #37
resonious wrote: post #26

Earlier quoted context omitted.

Very timely as I just recently ended up with a URL query string so big that CloudFront rejected the request before it even hit my server.. Ended up switching that endpoint to POST. Would've liked QUERY for that!

I have come across systems that use GET but with a payload like POST. This allows the GET to bypass the 4k URL limit. It's not a common pattern, and QUERY is a nice way to differentiate it (and, I suspect will be more compatible with Middleware). I have a suspicion that quite a few servers support this pattern (as does my own) but not many programmers are aware of it, so it's very infrequently used.

I think graphQL as a byproduct of some serious shenanigans.

"Your GraphQL HTTP server must handle the HTTP POST method for query and mutation operations, and may also accept the GET method for query operations."

Supporting body in the get request was an odd requirement for something I had to code up with another engineer.

Re: The HTTP Query Method

#80

Post by Hackbraten »

zzq1015 wrote: post #64

PSA: When posting an RFC or (especially) an RFC-draft, please use the IETF Datatracker URL. For example, this one is: https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-met... The best way to view an RFC, IMHO, is to use the "htmlized" format: you can view and compare different versions, view errata for a formal RFC, and go back to Datatracker at any time. Also, the Datatracker URL is version-insensitive, so un…

> please use the IETF Datatracker URL.

On my phone, your Datatracker link results in an unreadable mess of a page due to the hard-coded line breaks in the plaintext rendition of the RFC text (making it unreadable in portrait mode) and the huge sticky page nav (causing the content viewport to shrink vertically to almost zero in landscape mode). The HTML page behind OP's link reads just fine.

> The best way to view an RFC, IMHO, is to use the "htmlized" format

I don't see any choices of format such as HTML behind your link. There's a sticky nav, then a couple of pages of metadata, followed by a plaintext rendering of the RFC. What am I missing?

Post reply on HN