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