Hi.
On 2023-08-07 (Mo.) 18:35, Nick Wood wrote:
Hello all,
I'm not sure if anything further happened with this, but after upgrading
from 2.6 to 2.8.1, custom pages are now broken by default over HTTP/2.
Please can you specific more deeper what you mean with "broken by default".
What does not work anymore?
what's your config?
Is the custom page also broken when you activate H2 on 2.6?
Has HTTP/2 support been enabled by default? If so how would one turn it
off so we don't have to downgrade back to v2.6?
In the Announcement of 1.8 is described how to deactivate the H2.
https://www.mail-archive.com/haproxy@formilux.org/msg43600.html
```
- HTTP/2 is advertised by default in ALPN on TLS listeners. It was about
time, 5 years have passed since it was introduced, it's been enabled by
default in clear text as an HTTP/1 upgrade for 4 years, yet some users
do not know how to enable it. From now on, ALPN defaults to "h2,http/1.1"
on TCP and "h3" on QUIC so that these protocol versions work by default.
It's still possible to set/reset the ALPN to disable them of course. The
old concern some users were having about window sizes was addressed by
having a setting for each side (front vs back).
```
That the doc link to the alpn keyword.
http://docs.haproxy.org/2.8/configuration.html#5.1-alpn
Thanks,
Nick
Regards
Alex
On 17/04/2023 15:09, Aleksandar Lazic wrote:
On 17.04.23 15:08, Willy Tarreau wrote:
On Mon, Apr 17, 2023 at 03:04:05PM +0200, Lukas Tribus wrote:
On Sat, 15 Apr 2023 at 23:08, Willy Tarreau <w...@1wt.eu> wrote:
On Sat, Apr 15, 2023 at 10:59:42PM +0200, Willy Tarreau wrote:
Hi Nick,
On Sat, Apr 15, 2023 at 09:44:32PM +0100, Nick Wood wrote:
And here is my configuration - I've slimmed it down to the
absolute minimum
to reproduce the problem:
If the back end is down, the custom 503.http page should be served.
This works on HTTP/1.1 but not over HTTP/2:
Very useful, thank you. In fact it's irrelevant to the errorfile but
it's the 503 that is not produced in this case. I suspect that it's
interpreted on the server side as only a retryable connection error
and that if the HTTP/1 client had faced it on its second request it
would have been the same (in H1 there's a special case for the first
request on a connection, that is not automatically retryable, but
after the first one we have the luxry of closing silently to force
the client to retry, something that H2 supports natively).
I'm still trying to figure when this problem appeared, and it looks
like even 2.4.0 did behave like this. I'm still digging.
And indeed, this issue appeared with this commit in 1.9-dev10 4
years ago:
746fb772f ("MEDIUM: mux_h2: Always set CS_FL_NOT_FIRST for new
conn_streams.")
So it makes h2 behave like the second and more H1 requests which
are silent
about this. We overlooked this specificity, it would need to be
rethought a
little bit I guess.
Even though we had this issue for a long time and nobody noticed, we
should probably not enable H2 on a massive scale with new 2.8 defaults
before this is fixed to avoid silently breaking this error condition.
I totally agree ;-)
Well, I would prefer to keep on the line so that such bugs could be
found much earlier :-).
Jm2c
Willy
