Hi Jerome, Willy,

thanks! Yeah, it only affected url, not path. I've fixed all cases were we wrongly assumed that url is like path.
Thanks for clarifying!

On 2020-07-03 19:59, Willy Tarreau wrote:
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:

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,

Christian Ruppert

Reply via email to