4 ms·

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

by tosti 4mo ago

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

jbverschoor 4mo ago
Yeah, query seems just GET with a body. No difference in protocol nor behavior
- ComodoHacker 4mo ago
  Except compatibility. If you're using classic GET and it's enough for you, you aren't affected.
  - 4gotunameagain 4mo ago
    What is compatible with a QUERY but not with a GET ?
    - dotancohen 4mo ago
      Intermediate proxies, caches, CDNs, firewalls, and load balancers.
      - 4gotunameagain 4mo ago
        That is only in the case of GET with a body though.
        dotancohen 4mo ago
        Yes. That is the issue under discussion, e.g. not "classic GET".
- gl-prod 4mo ago
  The difference is the method. Query you're saying I can use body. GET you should never use body.
  - locknitpicker 4mo ago
    > The difference is the method. Query you're saying I can use body. GET you should never use body. The biggest win is how intermediary boxes now have concrete guidance that a specific HTTP request is both safe, idempotent, and carries a request body. Up until now none of this existed, and at best developers could use unsafe methods to carry request bodies (see GraphQL and how it uses POST for queries)
- _flux 4mo ago
  There is the Accept-Query header https://www.rfc-editor.org/info/rfc10008/#appendix-A.3 https://www.rfc-editor.org/info/rfc10008/#appendix-A.3 that tells you can use QUERY. That's a bit different.
jy14898 4mo ago
405 Method Not Allowed is trivial to fall back to POST. How do you know the GET request behaved incorrectly?
- tosti 4mo ago
  That's assuming the corporate proxy is well-behaved.
  - jagged-chisel 4mo 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.
    - tosti 4mo ago
      We can HTTP and all bets are still off, probably. Do you test with a proxy? I know I don't, and if I would it'd be the latest version of squid. Some of those non-conforming middle boxes could be unattended black boxes in the back of a closet somewhere on the 3rd floor. Who knows. Some customers would consider alternatives to your offering because it doesn't work, others would file a support ticket and there becomes an incentive not to use the new and shiny. The broken middle black box vendor can't be bothered and keeps selling broken boxes. Shit like this is why we can't have nice things.
flanked-evergl 4mo ago
The fact that some infrastructure is poorly maintained is not a reason against evolving protocols, it's a reason to maintain infrastructure better. It's really not that difficult to do.

by tosti 4mo ago

jbverschoor 4mo ago

Yeah, query seems just GET with a body. No difference in protocol nor behavior

ComodoHacker 4mo ago
Except compatibility. If you're using classic GET and it's enough for you, you aren't affected.
- 4gotunameagain 4mo ago
  What is compatible with a QUERY but not with a GET ?
  - dotancohen 4mo ago
    Intermediate proxies, caches, CDNs, firewalls, and load balancers.
    - 4gotunameagain 4mo ago
      That is only in the case of GET with a body though.
      - dotancohen 4mo ago
        Yes. That is the issue under discussion, e.g. not "classic GET".
gl-prod 4mo ago
The difference is the method. Query you're saying I can use body. GET you should never use body.
- locknitpicker 4mo ago
  > The difference is the method. Query you're saying I can use body. GET you should never use body. The biggest win is how intermediary boxes now have concrete guidance that a specific HTTP request is both safe, idempotent, and carries a request body. Up until now none of this existed, and at best developers could use unsafe methods to carry request bodies (see GraphQL and how it uses POST for queries)
_flux 4mo ago
There is the Accept-Query header https://www.rfc-editor.org/info/rfc10008/#appendix-A.3 https://www.rfc-editor.org/info/rfc10008/#appendix-A.3 that tells you can use QUERY. That's a bit different.

jy14898 4mo ago

405 Method Not Allowed is trivial to fall back to POST. How do you know the GET request behaved incorrectly?

tosti 4mo ago
That's assuming the corporate proxy is well-behaved.
- jagged-chisel 4mo 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.
  - tosti 4mo ago
    We can HTTP and all bets are still off, probably. Do you test with a proxy? I know I don't, and if I would it'd be the latest version of squid. Some of those non-conforming middle boxes could be unattended black boxes in the back of a closet somewhere on the 3rd floor. Who knows. Some customers would consider alternatives to your offering because it doesn't work, others would file a support ticket and there becomes an incentive not to use the new and shiny. The broken middle black box vendor can't be bothered and keeps selling broken boxes. Shit like this is why we can't have nice things.

flanked-evergl 4mo ago

The fact that some infrastructure is poorly maintained is not a reason against evolving protocols, it's a reason to maintain infrastructure better. It's really not that difficult to do.