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 ;-)
Willy
