Hi Maxim,

> It turns out no browsers implement HTTP/2 GOAWAY handling properly, and
> large enough number of resources on a page results in failures to load
> some resources. In particular, Chrome seems to experience errors if
> loading of all resources requires more than 1 connection (while it
> is usually able to retry requests at least once, even with 2 connections
> there are occasional failures for some reason), Safari if loading requires
> more than 3 connections, and Firefox if loading requires more than 10
> connections (can be configured with network.http.request.max-attempts,
> defaults to 10).
>
> It does not seem to be possible to resolve this on nginx side, even strict
> limiting of maximum concurrency does not help, and loading issues seems to
> be triggered by merely queueing of a request for a particular connection.
> The only available mitigation seems to use higher keepalive_requests value.

Instead of blaming browsers, did you consider implementing graceful shutdown
using 2-stage GOAWAY? The process is clearly described in RFC7540, sec. 6.8:

[...] A server that is attempting to gracefully shut down a
connection SHOULD send an initial GOAWAY frame with the last stream
identifier set to 2^31-1 and a NO_ERROR code. This signals to the
client that a shutdown is imminent and that initiating further
requests is prohibited. After allowing time for any in-flight stream
creation (at least one round-trip time), the server can send another
GOAWAY frame with an updated last stream identifier. This ensures
that a connection can be cleanly shut down without losing requests.

This is a solved problem, and the solution was pointed out years ago:
http://mailman.nginx.org/pipermail/nginx-devel/2017-August/010439.html
http://mailman.nginx.org/pipermail/nginx-devel/2018-March/010930.html

Best regards,
Piotr Sikora
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel