On Sat, 15 Apr 2023 at 23:08, Willy Tarreau <[email protected]> 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. Lukas
