3 ms·

Despite the spec, a lot of clients, load balancers, and server libraries can't handle GET with a body.

by lozenge 3y ago

silverwind 3y ago
They won't support a new method either.
- derefr 3y ago
  But it being an unsupported method will hopefully at least cause the middlebox to generate a 405 error, rather than undefined behavior.
  - water9 3y ago
    Rather than a 400 error?
    - derefr 3y ago
      No, rather than the body being silently ignored in the caching (or even proxying!) logic of some middleboxes, because "since GET will never have a body, for efficiency, we won't bother to check for one."
bruce511 3y ago
Which is somewhat surprising given that it is common enough that I've come across it several times in the wild. So much so that I added support for it to my own server and client libraries. Which means that adding support for QUERY will be trivial (yay!) As an aside, I also support DELETE with a body.
sarthak-ag 3y ago
Yet, given enough demand, and a explicit recommending nod from the spec, these will comply. It's not really as big as problem as everyone seems to think. And it's literally the same amount of work of adding a new verb.
- Lex-2008 3y ago
  Things might've changed since then, but back in 2009 it was Chromium who disabled bzip2 compression after some ISPs were borking bzip2-compressed pages[1] (although it's mot entirely clear if it was indeed the reason for dropping bzip2), not the other way around. Later in 2016 this was mentioned as being the reason for limiting brotli compression to HTTPS only[2]. [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=14801 https://bugs.chromium.org/p/chromium/issues/detail?id=14801 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=452335#c86 https://bugs.chromium.org/p/chromium/issues/detail?id=452335... So while I agree that it would be nice if everyone respected a "living standard", my hopes for middleboxes to comply are not high.
deleted 3y ago
[deleted]

Despite the spec, a lot of clients, load balancers, and server libraries can't handle GET with a body.

silverwind 3y ago

They won't support a new method either.

derefr 3y ago
But it being an unsupported method will hopefully at least cause the middlebox to generate a 405 error, rather than undefined behavior.
- water9 3y ago
  Rather than a 400 error?
  - derefr 3y ago
    No, rather than the body being silently ignored in the caching (or even proxying!) logic of some middleboxes, because "since GET will never have a body, for efficiency, we won't bother to check for one."

bruce511 3y ago

Which is somewhat surprising given that it is common enough that I've come across it several times in the wild. So much so that I added support for it to my own server and client libraries. Which means that adding support for QUERY will be trivial (yay!) As an aside, I also support DELETE with a body.

sarthak-ag 3y ago

Yet, given enough demand, and a explicit recommending nod from the spec, these will comply. It's not really as big as problem as everyone seems to think. And it's literally the same amount of work of adding a new verb.

Lex-2008 3y ago
Things might've changed since then, but back in 2009 it was Chromium who disabled bzip2 compression after some ISPs were borking bzip2-compressed pages[1] (although it's mot entirely clear if it was indeed the reason for dropping bzip2), not the other way around. Later in 2016 this was mentioned as being the reason for limiting brotli compression to HTTPS only[2]. [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=14801 https://bugs.chromium.org/p/chromium/issues/detail?id=14801 [2]: https://bugs.chromium.org/p/chromium/issues/detail?id=452335#c86 https://bugs.chromium.org/p/chromium/issues/detail?id=452335... So while I agree that it would be nice if everyone respected a "living standard", my hopes for middleboxes to comply are not high.

deleted 3y ago

[deleted]