Re: HTTP/2 in 2.1.x behaves different than in 2.0.x

2020-07-06 Thread Christian Ruppert

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:
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

forms.

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,
Willy


--
Regards,
Christian Ruppert



Re: HTTP/2 in 2.1.x behaves different than in 2.0.x

2020-07-03 Thread Willy Tarreau
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
forms.

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,
Willy



Re: HTTP/2 in 2.1.x behaves different than in 2.0.x

2020-07-03 Thread Jerome Magnin
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

-- 
Jérôme



HTTP/2 in 2.1.x behaves different than in 2.0.x

2020-07-03 Thread Christian Ruppert

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.

Steps to reproduce:
HAProxy 2.1.x
A simple http frontend, including h2 + logging

tail -f /var/log/haproxy.log|grep curl

curl -s https://example.com -o /dev/null --http1.1
curl -s https://example.com -o /dev/null --http2

Notice the difference:
test_https~ backend_test/testsrv1 1/0/0/2/3 200 4075 - -  1/1/0/0/0 
0/0 {example.com|curl/7.69.1|} "GET / HTTP/1.1"
test_https~ backend_test/testsrv1 0/0/0/3/3 200 4075 - -  1/1/0/0/0 
0/0 {example.com|curl/7.69.1|} "GET https://example.com/ HTTP/2.0"


Now the same with HAProxy 2.0.14:
test_https~ backend_test/testsrv1 1/0/0/2/3 200 4075 - -  1/1/0/0/0 
0/0 {example.com|curl/7.69.1|} "GET / HTTP/1.1"
test_https~ backend_test/testsrv1 0/0/0/3/3 200 4075 - -  1/1/0/0/0 
0/0 {example.com|curl/7.69.1|} "GET / HTTP/2.0"


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).


--
Regards,
Christian Ruppert