On Fri, Jul 03, 2020 at 02:25:33PM +0200, Jerome Magnin wrote:
> Hi Christian,
> On Fri, Jul 03, 2020 at 11:02:48AM +0200, Christian Ruppert wrote:
> > Hi List,
> > 
> > we've just noticed and confirmed some strange change in behavior, depending
> > on whether the request is made with HTTP 1.x or 2.x.
> > [...] 
> > That also affects ACLs like url*/path* and probably others.
> > I don't think that is intended, isn't it?
> > That looks like a regression to me. If that is a bug/regression, than it
> > might be good if it's possible to catch that one via test case (regtest).
> >
> This change is intentional and not a regression, it was introduced by
> this commit:
> http://git.haproxy.org/?p=haproxy.git;a=commit;h=30ee1efe676e8264af16bab833c621d60a72a4d7

Yep, it's the only way not to break end-to-end transmission, which is
even harder when H1 is used first and H2 behind.

Also please note that "path" is *not* broken because it's already taken
from the right place. "url" will see changes when comparing with the
previous version which would see a path in H2, or either a path or a uri
in H1. Because if you're using "url", in H1 you can already have the two

Now what haproxy does is to preserve each URL component intact. If you
change the scheme it only changes it. If you call "set-path" it will only
change the path, if you use "replace-uri" it will replace the whole uri.

I'd say that HTTP/2 with the :authority header was made very browser-centric
and went back to the origins of the URIs. It's certain that for all of us
working more on the server side it looks unusual but for those on the client
side it's more natural. Regardless, what it does was already supported by
HTTP/1 agents and even used to communicate with proxies, so it's not a
fundamental breakage, it just emphasizes something that people were not
often thinking about.

Hoping this helps,

Reply via email to