git bisect says that this regression was caused by commit c89077713915f605eb5d716545f182c8d0bf5581
This makes little sense to me, since that commit doesn't touch anything even slightly related. As far as I can tell, the proximate issue is that PATCH is not a "well-known method" to HAproxy, despite being in RFC 5789. find_http_meth is returning HTTP_METH_OTHER (silently) for it, and there's something hinky with how the method ACL matcher handles HTTP_METH_OTHER. I tried to poke the pat_match_meth function with a debugger, but it's not even being called in v2.2.3 (it *is* being called in v2.2.2). Did something break in how custom matchers are called? On Thu, Sep 17, 2020 at 3:48 PM James Brown <[email protected]> wrote: > One of our configurations includes the following snippet: > > acl allowed_method method HEAD GET POST PUT PATCH DELETE OPTIONS > ttp-request deny if !allowed_method > > In HAproxy 2.2.2 and below, this correctly blocks all requests that are > not HEAD, GET, PUT, POST, PATCH, DELETE, or OPTIONS. > > In HAproxy 2.2.3, this blocks PATCH requests. It seems to *only* be > broken for PATCH requests. > > The word "PATCH" does not occur in the diff between 2.2.2 and 2.2.3, which > is concerning. > > -- > James Brown > Engineer > -- James Brown Engineer
