Rendered at 10:38:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
ramon156 1 hours ago [-]
"QUERY is just GET"
"Using GET with a Body works"
Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense.
Just because it works, doesn't mean its the right way
EnnEmmEss 27 minutes ago [-]
Using GET with a Body doesn't work if you try using it in the browser with JS fetch for example[1]. Additionally, a lot of existing web servers by default ignore GET requests with a body.
The use case of QUERY is because POST conveys non-safe, non-idempotent requests which can potentially modify stuff according to the REST spec. GET requests on the other hand convey retrieval of a resource. However, due to GET requests not having a body, there's a limit to the amount of data you can put in the URL and you also cannot put sensitive data in it.
Additionally, GET requests are meant to be highly cacheable by default while a lot of the QUERY type requests are usually meant more for one-shot access.
I’ve seen a framework strip body content off GET requests, so doing hacky things doesn’t even always work. The QUERY method is a welcome addition
tgv 5 minutes ago [-]
I'd say it's the framework doing the hacky thing. It should be optional. AFAIK, the HTTP spec allows for it, under certain conditions. "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."
pdpi 36 minutes ago [-]
Insofar as I'm concerned, a GET request with a body is an attack-shaped aberration. E.g. Somebody who's trying to get me to mix up validating query string parameters and request body parameters.
Hacky things not working is a feature, not a bug.
psychoslave 35 minutes ago [-]
Is the stripper service in question already implementing it?
cryo32 43 minutes ago [-]
The whole stack is a pile of badly designed hacks. Not much point in fixing it now. I mean they can’t even spell referrer correctly.
dotancohen 1 hours ago [-]
> Just because it works, doesn't mean its the right way
Tell that to anybody in the business long enough to decipher someone else's Perl!
Asmod4n 35 minutes ago [-]
Slightly off topic Funfact: you can buy a several thousand dollars expensive ssl intercepting proxy appliance which doesn’t support anything beyond http/1.1.
Will be fun when those see a whole new http verb, I bet that leads to at least DoS by the track record of that company.
Stitch4223 12 minutes ago [-]
Not mentioning the vendor… means your comment is true for every vendor :)
Asmod4n 8 minutes ago [-]
That would be lancom. Good routers, the rest not so much.
ktpsns 4 hours ago [-]
HTTP QUERY was discussed many times in the past here:
> using HTTP GET with a request body is a bad idea, as for example users behind a corporate firewall or a different browser may be unable to use your website.
So is using QUERY requests for quite some time from now.
jy14898 2 hours ago [-]
405 Method Not Allowed is trivial to fall back to POST. How do you know the GET request behaved incorrectly?
tosti 2 hours ago [-]
That's assuming the corporate proxy is well-behaved.
jagged-chisel 53 minutes ago [-]
Then all bets are off, and I guess we just can’t HTTP ever again because a proxy can misbehave.
One should adhere to Best Practices since one cannot control every device between the app and the user. Best Practice says “GET has no body. QUERY can have a body. If QUERY fails (405), use POST with the body.” And eventually, enough proxies will behave well enough that at least the HTTP bit of the app has a chance of working.
jbverschoor 2 hours ago [-]
Yeah, query seems just GET with a body. No difference in protocol nor behavior
gl-prod 1 hours ago [-]
The difference is the method. Query you're saying I can use body. GET you should never use body.
Except compatibility. If you're using classic GET and it's enough for you, you aren't affected.
4gotunameagain 1 hours ago [-]
What is compatible with a QUERY but not with a GET ?
dotancohen 1 hours ago [-]
Intermediate proxies, caches, CDNs, firewalls, and load balancers.
haburka 9 minutes ago [-]
This is awesome and very much needed. Sending massive get requests always felt like shit and support for body parsing of GET was all over the place. I hope it will be adopted quickly.
8-prime 3 hours ago [-]
It's interesting to see additions to HTTP methods as it much feels like the existing ones are set in stone. At least for the time that I have been a developer.
I'm curious to see how fast the adoption/support for HTTP QUERY will be. I've had my fair share of situations where I wished for something like HTTP QUERY.
PunchyHamster 2 hours ago [-]
zero. Many libs will/can just request method as a string so you can start coding now
> I've had my fair share of situations where I wished for something like HTTP QUERY.
Using POST instead comes with no drawbacks
rezonant 1 hours ago [-]
I think the article summarizes pretty well what the drawbacks of POST are: unclear idempotency (well it's actually pretty damned clear: they are not cacheable). That complicates caching logic, and that's not just for the application server itself, but any reverse proxies in front of it as well as the user agent itself.
I'm not sure QUERY is a great solution, because in the context of a web application absolutely no one enjoys using a page that does not keep its state on refresh, so that really limits where QUERY makes sense, but if you have a case that is not driven by navigation, great.
hparadiz 2 hours ago [-]
I can implement it in about 10 minutes. Not even kidding.
echoangle 2 hours ago [-]
In what role? As a user writing client code or when implementing the caching middleware or the Webserver?
hparadiz 2 hours ago [-]
In my CRUD controller that I already have.
mi_lk 38 minutes ago [-]
OK, but stop trying to make fetch happen.
waweic 2 hours ago [-]
I wonder what the drawbacks of standardizing a GET body would have been. CoAP already has it (which creates friction in building CoAP<->HTTP proxies).
All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?
braiamp 50 minutes ago [-]
A absolute swats of middle boxes that will not get addressed ever. As industry, it's preferable to create something that is a hard break and makes players upgrade and give people a feature to argue for said upgrade
_alphageek 54 minutes ago [-]
>> QUERY request can be cached
I have a weird feeling. Query body is encrypted by https. So CDN will not be able to cache results.
In order to make it work right - whole topology of the internet should be redone. Caching on the backend server will not give any real gains for large scale apps.
CodesInChaos 48 minutes ago [-]
The whole connection is encrypted by https, the request body is treated the same as the url, the headers or the response. The only unencrypted parts are the IP addresses/ports and the domain name (if SNI without ECH is used).
CDNs already terminate TLS connections so they can cache GET requests.
rileymat2 7 minutes ago [-]
I think a lot of people don’t know the http/1.x protocol from url (header) to body is a stream of text* separated by \r\n.
* the body may be compressed.
doctor_phil 2 hours ago [-]
Nice, not having bodies on GET has been a pet peeve of mine for a long time. It would be nice to allow bodies on DELETE as well, but that is less of a problem in most cases.
ralferoo 18 minutes ago [-]
If you're doing anything complicated enough to need so much data that it'd be better to send the data in a body, it's probably not a DELETE and so POST would be more appropriate anyway.
DELETE is intended to delete one specific object, pointed to by a unique URL, not to delete arbitrary objects matching some criteria.
koolala 3 hours ago [-]
What do you think people will make the Query request body? Most everything will use this for JSON but it could be anything so what other interesting things do you think will go in there? Query 1 + 1 and get 2?
pmontra 26 minutes ago [-]
We might start using QUERY for the search requests from our web app to our server, if nothing in the stack in between the app and our server side code does not drop the body. A JSON body beats the spaghetti arguments of most filters.
miggol 2 hours ago [-]
Considering the guideline that QUERY should be idempotent and cacheable, file querying requests come to mind. Reverse image search, for example.
CommonGuy 58 minutes ago [-]
GraphQL implementations could switch to this
dreambigwrkhard 3 hours ago [-]
I'm curious too. Unless the developer is really passionate about this I don't think a dev will risk (potential) compatibility issues or unexpected footguns to use this when the workarounds do seem to work quite well already. I just dont see the benefit but maybe it's because I am just not aware of a real world use case; happy to be corrected.
unilynx 2 hours ago [-]
Elastic/Opensearch uses GET requests with a body for search, which is complicated or forbidden (not exactly sure) with the HTTP spec. Not all HTTP clients are willing to submit a body with a GET.
So opensearch also allows you to POST search requests, but those are uncacheable
QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.
Rapzid 2 hours ago [-]
Body is already optional with GET. Proxies aren't supposed to touch it or assign meaning to it; it's between the client and the end server.
A whole new method whose semantics don't really fit with the others is.. An odd way forward.
CommonGuy 1 hours ago [-]
Proxies are allowed to drop bodies of HTTP GET requests.
RFC 9110 states:
> [..] content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request [..]
> A client SHOULD NOT generate content in a GET request [..]
magicalhippo 27 minutes ago [-]
Even HTTP 1.0 RFC[11] is fairly clear on this, although it doesn't explicitly spell it out like RFC 9110. GET requests should only consider the Request-URI and request bodies should only be included if the method calls for it.
Yeah I always disliked that there's this idea that you can't put a body on a GET request.
Iirc openapi generators goes out of its way to not support that which has lead to me writing a small rant into an API specification before to explain why the get_xyz uses POST...
thewisenerd 1 hours ago [-]
semantics become extremely relevant when "proxies" start caching.
grugdev42 2 hours ago [-]
We should have just added optional body support for GET requests.
So much simpler...
tumetab1 9 minutes ago [-]
The only valid argument against HTTP GET with a body is that it has privacy/security risks.
Exist stuff (caches, CDN, etc.) could serve private information because the HTTP GET is cached without checking the request contents. The new standard can avoid this because old stuff does not know about HTTP QUERY.
ComodoHacker 2 hours ago [-]
More complex actually
IshKebab 1 hours ago [-]
What are the chances sites start using this to prevent sharing links...
restful2 54 minutes ago [-]
This breaks rest/crud.
tumetab1 8 minutes ago [-]
It can actually improve because the semantics which currently are weird, GET is used for Search (Query), listing and also Get resources.
UnfitFootprint 50 minutes ago [-]
Is it not just READ? As for rest, why?
bazoom42 44 minutes ago [-]
How so?
johnnyevert 43 minutes ago [-]
Will this be compatible with graphql?
acimen101 2 hours ago [-]
[flagged]
hparadiz 4 hours ago [-]
[flagged]
flanked-evergl 3 hours ago [-]
No, it does not feel like that.
hparadiz 3 hours ago [-]
My framework is already two decade old prior art and you still haven't actually convinced me that this RFC solves a problem.
rmunn 2 hours ago [-]
1. Sometimes you need a request body.
2. POST cannot be guaranteed to be safe if re-sent.
3. This is GET with a request body, guaranteed* to be safe if re-sent.
* With the caveat that it's only guaranteed if the server is following the RFC correctly.
LaGrange 2 hours ago [-]
I will keep using POST and not some weird thing that isn’t supported by a proxy living in the basement of a shoe store in Wageningen or whatever.
PunchyHamster 2 hours ago [-]
> POST cannot be guaranteed to be safe if re-sent.
It can absolutely be guaranteed. What it can't be is communicated to be safe so browser gonna ask its silly question
broken-kebab 41 minutes ago [-]
You can guarantee it to yourself, sure, but the talk is about different guarantees, those which are implied by people who has no idea about your plans and opinions but whose software may interact with yours.
hparadiz 2 hours ago [-]
I read the RFC front to back. It is lazy. To the point where I'd be embarrassed to even show it to people.
For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechanism but no they don't bother to define ANYTHING like that. Instead and I will quote this for completeness because it's honestly one of the funniest things I've ever read in an RFC.
> 4. Security Considerations
> It can be used as an alternative to passing request information in the URI (e.g., in the query component). This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content. In other cases, where the query contains sensitive information, the potential for logging of the URI might motivate the use of QUERY over GET.
This. This is just plain baffling to me. The argument is that QUERY replaces GET (it doesn't) so let's shove data into the same place that POST already does because it MAY MAY be logged. Bro the people doing the logging are logging the entire damn thing URI, Header, and Body. What even is this.
And again if they knew their shit they would know that GET has a soft cap of 2,083 characters from the internet explorer days so no one shoves more than that into a url for compatibility and if they do they risk losing data so they use POST anyway. Heck my framework even does JSON post bodies in the POST. And again if you are writing an RFC do your research and use this technical fact as an advantage. Define your own limits and explain why based on existing methodology. It would actually give your RFC some weight.
It doesn't even bother to address query feedback errors like what if the disk says no and writes are locked.
Frankly...... I miss the old days when RFCs where measured in pounds of paper.
antiloper 44 minutes ago [-]
Yes servers have to validate input data... This isn't new...
flanked-evergl 2 hours ago [-]
> For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it.
Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.
hparadiz 2 hours ago [-]
[flagged]
flanked-evergl 53 minutes ago [-]
What does "some random third party" have to do with any of it? An SQL server can expose HTTP directly. SQL is not the only query language that exists.
SPARQL's standard protocol for sending Queries uses HTTP[1], and yes, of course it allows clients to define the query that it sends over HTTP. HTTP QUERY would be ideal for SPARQL queries. There are also many unprotected SPARQL endpoints that you can use without any authentication [2][3].
This thread is for an RFC that is less than 3 pages and solves no problems that exist. I'm tired of having to pretend like every idea on the internet is a good one.
xxkcd 51 minutes ago [-]
Don’t add new stuff (query). Instead fix the broken shit that’s already added (get). Sigh. Xkcd standards.
marc_vuit 1 hours ago [-]
nice man
nokeya 2 hours ago [-]
If it needs so much explanation and discussion, maybe it is not a great idea after all?
flyingshelf 1 hours ago [-]
Arguably the only explanation you need is that "QUERY is the same as GET plus a body". The article just explains what GET is and isn't, but that can be implied.
reddalo 2 hours ago [-]
The article describes the current situation first. The whole explanation is quite simple: QUERY requests are the same as GET, but they have a body.
someguynamedq 2 hours ago [-]
So just add an optional body to get
dxdm 35 minutes ago [-]
The article also addresses why this is not the chosen solution. It's pretty much the first one you'd think of: all kinds of existing software (that can be between client and server and out of their control) already handle GET bodies in all kinds of incompatible ways, because the existing standard says they're meaningless and "shouldn't" be included. The idea is to not break people's stuff, so they don't rugpull the established standard.
There's usually a reason why the simplest solution that pops into one's head is not "just" used by the people who put a lot more thought into it. Not always, but it can be useful to try to come up with it.
IshKebab 1 hours ago [-]
It doesn't really need that much explanation though. TL;DR: It's GET but with bodies officially supported.
"Using GET with a Body works"
Seems like this is going everyone's head. You're not supposed to use GET with a Body, this is a hack, therefore having an explicit method makes sense.
Just because it works, doesn't mean its the right way
The use case of QUERY is because POST conveys non-safe, non-idempotent requests which can potentially modify stuff according to the REST spec. GET requests on the other hand convey retrieval of a resource. However, due to GET requests not having a body, there's a limit to the amount of data you can put in the URL and you also cannot put sensitive data in it.
Additionally, GET requests are meant to be highly cacheable by default while a lot of the QUERY type requests are usually meant more for one-shot access.
QUERY is meant to address these limitations.
[1]: https://github.com/whatwg/fetch/issues/551
Hacky things not working is a feature, not a bug.
Will be fun when those see a whole new http verb, I bet that leads to at least DoS by the track record of that company.
https://news.ycombinator.com/item?id=48568502 (4d ago, 173 comments)
https://news.ycombinator.com/item?id=29794838 (4y ago, 125 comments)
So is using QUERY requests for quite some time from now.
One should adhere to Best Practices since one cannot control every device between the app and the user. Best Practice says “GET has no body. QUERY can have a body. If QUERY fails (405), use POST with the body.” And eventually, enough proxies will behave well enough that at least the HTTP bit of the app has a chance of working.
> I've had my fair share of situations where I wished for something like HTTP QUERY.
Using POST instead comes with no drawbacks
I'm not sure QUERY is a great solution, because in the context of a web application absolutely no one enjoys using a page that does not keep its state on refresh, so that really limits where QUERY makes sense, but if you have a case that is not driven by navigation, great.
All in all, I dislike the overall focus on the HTTP method when designing "RESTful" interfaces. If all we're building is, effectively, an RPC, why would the cacheability meta-information be the first thing we specify?
I have a weird feeling. Query body is encrypted by https. So CDN will not be able to cache results. In order to make it work right - whole topology of the internet should be redone. Caching on the backend server will not give any real gains for large scale apps.
CDNs already terminate TLS connections so they can cache GET requests.
* the body may be compressed.
DELETE is intended to delete one specific object, pointed to by a unique URL, not to delete arbitrary objects matching some criteria.
So opensearch also allows you to POST search requests, but those are uncacheable
QUERY would fit here perfectly - it's probably trivial for opensearch to add but it will take some time for clients to catch up.
A whole new method whose semantics don't really fit with the others is.. An odd way forward.
RFC 9110 states:
> [..] content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request [..]
> A client SHOULD NOT generate content in a GET request [..]
[1]: https://www.rfc-editor.org/info/rfc1945/
So much simpler...
Exist stuff (caches, CDN, etc.) could serve private information because the HTTP GET is cached without checking the request contents. The new standard can avoid this because old stuff does not know about HTTP QUERY.
* With the caveat that it's only guaranteed if the server is following the RFC correctly.
It can absolutely be guaranteed. What it can't be is communicated to be safe so browser gonna ask its silly question
For one you would never allow a client to dictate the query. That is a security and validation problem. So you have to deconstruct the query anyway and then rebuild it. That's HTTP APIs 101. Now if the authors of this RFC knew what they were doing they could enforce trust with some sort of JWT like trust mechanism but no they don't bother to define ANYTHING like that. Instead and I will quote this for completeness because it's honestly one of the funniest things I've ever read in an RFC.
> 4. Security Considerations
> It can be used as an alternative to passing request information in the URI (e.g., in the query component). This is preferred in some cases, as the URI is more likely to be logged or otherwise processed by intermediaries than the request content. In other cases, where the query contains sensitive information, the potential for logging of the URI might motivate the use of QUERY over GET.
This. This is just plain baffling to me. The argument is that QUERY replaces GET (it doesn't) so let's shove data into the same place that POST already does because it MAY MAY be logged. Bro the people doing the logging are logging the entire damn thing URI, Header, and Body. What even is this.
And again if they knew their shit they would know that GET has a soft cap of 2,083 characters from the internet explorer days so no one shoves more than that into a url for compatibility and if they do they risk losing data so they use POST anyway. Heck my framework even does JSON post bodies in the POST. And again if you are writing an RFC do your research and use this technical fact as an advantage. Define your own limits and explain why based on existing methodology. It would actually give your RFC some weight.
It doesn't even bother to address query feedback errors like what if the disk says no and writes are locked.
Frankly...... I miss the old days when RFCs where measured in pounds of paper.
Every single SQL server allows a client to dictate the query. Furthermore, not all queries are SQL queries.
SPARQL's standard protocol for sending Queries uses HTTP[1], and yes, of course it allows clients to define the query that it sends over HTTP. HTTP QUERY would be ideal for SPARQL queries. There are also many unprotected SPARQL endpoints that you can use without any authentication [2][3].
[1]: https://www.w3.org/TR/sparql11-protocol/#query-operation
[2]: https://sparql.dblp.org/
[3]: https://data.europa.eu/en/about/sparql
There's usually a reason why the simplest solution that pops into one's head is not "just" used by the people who put a lot more thought into it. Not always, but it can be useful to try to come up with it.