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
