4 ms·

"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, theref

"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

dotancohen 4mo 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!
- nixon_why69 4mo ago
  It's possible that the slogan "There's one obvious way to do it" as a riposte to "There's more than one way to do it" was more responsible for Python's first wave of success than anything else.
- ivanhoe 4mo ago
  Hey, remember what Larry said, there's more than one way to do things ;P
ronbenton 4mo ago
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
- pdpi 4mo 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 4mo ago
  Is the stripper service in question already implementing it?
- tgv 4mo 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."
cryo32 4mo 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.
EnnEmmEss 4mo 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. QUERY is meant to address these limitations. [1]: https://github.com/whatwg/fetch/issues/551 https://github.com/whatwg/fetch/issues/551
- nesarkvechnep 4mo ago
  There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.
  - darig 4mo ago
    [dead]
  - EnnEmmEss 4mo ago
    To clarify, by REST spec I meant the state of access defined by https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/....
    - nesarkvechnep 4mo ago
      This is just HTTP. The definitive guide to REST is "Architectural Styles and the Design of Network-based Software Architectures" by Roy Fielding.
- krackers 4mo ago
  >Additionally, a lot of existing web servers by default ignore GET requests with a body. I think the point made is that _all_ existing web servers have no idea what a "QUERY" is anyway, so changes need to be made anyhow.
Bombthecat 4mo ago
Some security/ API gateway block requests when it's a GET with a body.
locknitpicker 4mo ago
> "Using GET with a Body works" Except it doesn't. Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded. It sounds like most people with the "just use GET" nonsense are far from having any experience in cloud computing.
- topham 4mo ago
  QUERY won't be supported by them either. So, change is required. Just change GET to allow for body and move on. Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is. QUERY will likely need firmware updates, core engine updates, etc. Meanwhile, tweaking GET is a rule change.
  - akersten 4mo ago
    Yeah I really don't understand the anti-GET-body argument. "Using GET with a body isn't in the spec, WAFs and webservers that haven't been updated might reject it!" Ok, QUERY wasn't in the spec when those were written either. What do you expect those appliances to do with a totally unknown verb? It's a welcome addition but the new method is pure marketing. There's no reason the update couldn't have been to expand GET instead of add support for QUERY.
    - WorldMaker 4mo ago
      > What do you expect those appliances to do with a totally unknown verb? 405 Method Not Allowed We have existing standards for unsupported methods.
    - locknitpicker 4mo ago
      > Using GET with a body isn't in the spec, It's exactly the opposite. The HTTP spec does cover GET with bodies. However, what you fail to account is that the spec specifies they are invalid and a GET with body is meaningless, and represents a potential attack.
  - WorldMaker 4mo ago
jefc1111 4mo ago
Yep. We had to change our app when we took on a client with a strictly configured WAF which rejected GET with body. I know I have come across multiple points where I have used POST when I know it is wrong, or GET with a body, when I know it is wrong. So I welcome QUERY!
- entuno 4mo ago
  AWS CloudFront blocks GET requests with a body, so it doesn't even have to be a particularly strict setup or an explicit WAF.
maxloh 4mo ago
It sounds like GET with a body is just undefined behavior. Why not just standardize it? It seems to be a better way than adding a new method.
- Vosporos 4mo ago
  A lot of un-updateable software out there that strip the body. Especially when the companies behind it doesn't provide support anymore.
  - earthdeity 4mo ago
    will those support QUERY?
- WorldMaker 4mo ago
  1) Changes to how GET works likely require a new HTTP version to assure maximum breaking change awareness. We're already in a Postel's Law state where we have HTTP/1.1, HTTP/2, and HTTP/3 all running side-by-side for reasons that all three are very different under the hood at even the transport layers. Do we really want to add HTTP/1.2, HTTP/2.1, and HTTP/3.1 to that list? An entirely new method is easier to apply horizontally to all three versions, because the HTTP standard already allows that as an extension mechanism. (There's an IANA registry for HTTP methods and HTTP methods such as WebDAV's have always been their own standards outside of HTTP RFCs.) 2) A plain separation between GET should only accept query string parameters and QUERY should only accept body parameters potentially reduces attack surface of attackers trying to mix and match the two to find potential order of precedence attacks.
stymaar 4mo ago
You're missing the point. Using GET with a body is currently unspecified, so of course you're not supposed to do it (though you're not forbidden to either). But specifying this behavior would get you in the same situation as adding a new method: everything not up to date with the spec will keep behaving poorly but newer system would work. The only benefit of adding a new method is for marketing/awareness: it may end up getting support faster than the alternative because it sounds as a sexy new thing to implement. This kind of benefit should not be overlooked, but we should also acknowledge its limits: most of enterprise stuff (WAF, frameworks, etc.) are not going to work overnight just because it's a new method instead of a spec change.
bellowsgulch 4mo ago
So a POST with explicit caching semantics?
- em-bee 4mo ago
  no, a POST that is idempotent. caching is an optional side benefit.
  - bellowsgulch 4mo ago
    Isn't that just a PUT minus the inferred semantics?
    - em-bee 4mo ago
      yeah good catch, my response was incomplete. QUERY is a POST that is not only idempotent but also safe (it does not change anything at all on the server) (and it's cacheable of course) PUT is idempotent but not safe.
      - bellowsgulch 4mo ago
        Good point.
somekindaguy 4mo ago
Why not just add an optional body to the spec for GET

dotancohen 4mo 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!

nixon_why69 4mo ago
It's possible that the slogan "There's one obvious way to do it" as a riposte to "There's more than one way to do it" was more responsible for Python's first wave of success than anything else.
ivanhoe 4mo ago
Hey, remember what Larry said, there's more than one way to do things ;P

ronbenton 4mo ago

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

pdpi 4mo 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 4mo ago
Is the stripper service in question already implementing it?
tgv 4mo 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."

cryo32 4mo 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.

EnnEmmEss 4mo 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. QUERY is meant to address these limitations. [1]: https://github.com/whatwg/fetch/issues/551 https://github.com/whatwg/fetch/issues/551

nesarkvechnep 4mo ago
There's no such thing as REST spec. The closes mechanism to actual REST is to create a resource using POST and then query it using GET. You have the added benefit of the resource being cacheable.
- darig 4mo ago
  [dead]
- EnnEmmEss 4mo ago
  To clarify, by REST spec I meant the state of access defined by https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/....
  - nesarkvechnep 4mo ago
    This is just HTTP. The definitive guide to REST is "Architectural Styles and the Design of Network-based Software Architectures" by Roy Fielding.
krackers 4mo ago
>Additionally, a lot of existing web servers by default ignore GET requests with a body. I think the point made is that _all_ existing web servers have no idea what a "QUERY" is anyway, so changes need to be made anyhow.

Bombthecat 4mo ago

Some security/ API gateway block requests when it's a GET with a body.

locknitpicker 4mo ago

> "Using GET with a Body works" Except it doesn't. Some API gateways outright strip request bodies from GET requests to prevent them from being forwarded. It sounds like most people with the "just use GET" nonsense are far from having any experience in cloud computing.

topham 4mo ago
QUERY won't be supported by them either. So, change is required. Just change GET to allow for body and move on. Most of the systems that are blocking GET/body could be easily tweaked to allow it. Today. As is. QUERY will likely need firmware updates, core engine updates, etc. Meanwhile, tweaking GET is a rule change.
- akersten 4mo ago
  Yeah I really don't understand the anti-GET-body argument. "Using GET with a body isn't in the spec, WAFs and webservers that haven't been updated might reject it!" Ok, QUERY wasn't in the spec when those were written either. What do you expect those appliances to do with a totally unknown verb? It's a welcome addition but the new method is pure marketing. There's no reason the update couldn't have been to expand GET instead of add support for QUERY.
  - WorldMaker 4mo ago
    > What do you expect those appliances to do with a totally unknown verb? 405 Method Not Allowed We have existing standards for unsupported methods.
  - locknitpicker 4mo ago
    > Using GET with a body isn't in the spec, It's exactly the opposite. The HTTP spec does cover GET with bodies. However, what you fail to account is that the spec specifies they are invalid and a GET with body is meaningless, and represents a potential attack.
- WorldMaker 4mo ago

jefc1111 4mo ago

Yep. We had to change our app when we took on a client with a strictly configured WAF which rejected GET with body. I know I have come across multiple points where I have used POST when I know it is wrong, or GET with a body, when I know it is wrong. So I welcome QUERY!

entuno 4mo ago
AWS CloudFront blocks GET requests with a body, so it doesn't even have to be a particularly strict setup or an explicit WAF.

maxloh 4mo ago

It sounds like GET with a body is just undefined behavior. Why not just standardize it? It seems to be a better way than adding a new method.

Vosporos 4mo ago
A lot of un-updateable software out there that strip the body. Especially when the companies behind it doesn't provide support anymore.
- earthdeity 4mo ago
  will those support QUERY?
WorldMaker 4mo ago
1) Changes to how GET works likely require a new HTTP version to assure maximum breaking change awareness. We're already in a Postel's Law state where we have HTTP/1.1, HTTP/2, and HTTP/3 all running side-by-side for reasons that all three are very different under the hood at even the transport layers. Do we really want to add HTTP/1.2, HTTP/2.1, and HTTP/3.1 to that list? An entirely new method is easier to apply horizontally to all three versions, because the HTTP standard already allows that as an extension mechanism. (There's an IANA registry for HTTP methods and HTTP methods such as WebDAV's have always been their own standards outside of HTTP RFCs.) 2) A plain separation between GET should only accept query string parameters and QUERY should only accept body parameters potentially reduces attack surface of attackers trying to mix and match the two to find potential order of precedence attacks.

stymaar 4mo ago

You're missing the point. Using GET with a body is currently unspecified, so of course you're not supposed to do it (though you're not forbidden to either). But specifying this behavior would get you in the same situation as adding a new method: everything not up to date with the spec will keep behaving poorly but newer system would work. The only benefit of adding a new method is for marketing/awareness: it may end up getting support faster than the alternative because it sounds as a sexy new thing to implement. This kind of benefit should not be overlooked, but we should also acknowledge its limits: most of enterprise stuff (WAF, frameworks, etc.) are not going to work overnight just because it's a new method instead of a spec change.

bellowsgulch 4mo ago

So a POST with explicit caching semantics?

em-bee 4mo ago
no, a POST that is idempotent. caching is an optional side benefit.
- bellowsgulch 4mo ago
  Isn't that just a PUT minus the inferred semantics?
  - em-bee 4mo ago
    yeah good catch, my response was incomplete. QUERY is a POST that is not only idempotent but also safe (it does not change anything at all on the server) (and it's cacheable of course) PUT is idempotent but not safe.
    - bellowsgulch 4mo ago
      Good point.

somekindaguy 4mo ago

Why not just add an optional body to the spec for GET