desiderantes commented on PR #499: URL: https://github.com/apache/httpcomponents-core/pull/499#issuecomment-2424189940
> > I do not understand the argument about inconsistencies of GET with bodies, this is a different method, services would either support it or not. I think that's the main point of this new method, to have a clean way to handle GET-like requests with body, without having to guess if any part of the infrastructure assumes GET don't have bodies (like a proxy stripping them) and having surprising results and failures. > > Your point is understood, but the problem remains fundamentally the same. > > The fact that QUERY is technically a different method doesn't eliminate the inconsistencies; it just shifts them. Introducing QUERY as a workaround for the issues with GET bodies assumes the entire HTTP ecosystem will uniformly recognize and support it. In reality, infrastructure like proxies, caching layers, and older servers are unlikely to know what to do with QUERY requests. This could lead to dropped requests, unexpected stripping of bodies, or flat-out rejections, similar to the problems you're trying to avoid with GET and a body. Simply put, anything that doesn’t explicitly recognize QUERY may mishandle it. An explicit failure mode (not supporting unknown/custom HTTP methods) is substantially better than mishandled request bodies, so I'd say it is not a shift, but an enforcement, either the method is supported/allowed to pass (and the server ends up getting the request) or it is not, and the request fails. No middle ground, no inconsistent behaviour, other than caching proxies not caching responses (which would just be a matter of the server having a misconfigured cache). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
