Hello Dominik, On Thu, May 05, 2022 at 07:55:06AM +0000, Froehlich, Dominik wrote: > Hello everyone, > > We recently bumped our HAproxy deployment to 2.5 and are now getting hit by > this fix: > > MEDIUM: mux-h1: Reject HTTP/1.0 GET/HEAD/DELETE requests with a payload > > > http://git.haproxy.org/?p=haproxy-2.5.git;a=blob_plain;f=CHANGELOG > > The issue is we have many legacy customers using very old systems and we > can't tell all of them to rewrite their clients to http/1.1.
Of course... Do you have an idea how they ended up sending a body with such requests ? Maybe adding a comment on the issue below for posterity could be useful for future versions of the HTTP spec: https://github.com/httpwg/http-core/issues/904 > I get the security fix to prevent request smuggling where some servers ignore > the body and treat it as another request, I'm not arguing that. > > However, I was wondering if it was possible to intercept HTTP/1.0 client > requests and upgrade them to HTTP/1.1 without hitting the rejection code of > the commit here: > https://github.com/haproxy/haproxy/commit/e136bd12a32970bc90d862d5fe09ea1952b62974 "Upgrading" the version must really never ever be done, as a lot of HTTP semantics changed between 1.0 and 1.1, and by telling a server that the client is 1.1, the server will be allowed to use chunking, trailers, 100-continue and a lot of other stuff that 1.0 clients are unable to understand. For your use case, I guess the best solution would be to add an option (possibly a global one) to relax that rule. It's self-contained inside an "if" statement so it should be quite easy to add such an option and be done with it, because when you need it, you definitely know that you need it, you'll find the keyword in the doc and the accompanying warning about the security impacts. Also the HTTP spec now says "unless support is indicated via other means", so the intent clearly is to make this configurable on a case-by-case basis. > This way we would not have to downgrade to HAproxy 2.4 again - which would be > very unfortunate as we need many of the nice features of 2.5. We'll discuss this with Christopher tomorrow, but I'm not worried about this for now. Thanks! Willy
