3

When I use Firefox to access one of my sites with a lot of CSS files, periodically, not all the CSS files are downloaded

Looking in the Developer Control Panel in Firefox (F12), I see that, when the problem occurs, that the files have Status = 0, almost like the request was never sent to the server, but looking at the server the request is there.

I've tried to simplify the problem as much as I can, and I've manged to reduce it to an html file which gets 100 CSS files, and some javascript which will automatically detect when the problem occurs

This in an attempt to make it easier for people to test on their own installations, and to try and prove that I'm not just crazy

Test parameters:

Fresh debian 9 on GCP (Also tested on centOS)

nginx 1.10.3 (but it also happens on latest stable and mainline)

HTTPS/SSL enabled (Tested with self-signed, Let's encrypt and commercial SSL)

HTTP2 enabled

Firefox 66 (Also tested with Firefox 65)

Now when I access my test HTML, the javascript will reload the page until the error occurs, and then display an alert. This can take anywhere from a few seconds to five minutes, it usually happens within the first minute

Firefox will download the first few CSS files and then either seem to skip the rest, or skip 20-30-40 files and then try again, skipped files will have status 0 nginx access log will say that it responded with either status 200 or 304, but firefox will never display that information

The html/css test package can be downloaded here: html test package

I'm not 100 % sure who/what is at fault here

It could easily be me, but if that's the case no one should be able to reproduce my results, and several people have already

It could be Firefox or it could be nginx, or a combination of the two

Any help would be greatly appreciated, been banging my head against the wall for the past two days

Edit / clarification:

I realise that I should never/ever "force" a user to have to download 100 CSS files on a production server :)

100 was just the number where the results were very easy and fast to reproduce, and so I went with 100 for the test package, to make it easier/faster for you guys to reproduce the problem for yourselves

noir04
  • 41
  • 5
  • 2
    Did you say 100 CSS files?! That's pretty strange itself. – Michael Hampton Mar 22 '19 at 14:59
  • 1
    You're right, 100 is a lot, but I'm pretty sure the browser/server should be able to handle it, consistently – noir04 Mar 22 '19 at 16:57
  • Probably so, but even if they load successfully that's going to slow down your site significantly from the user perspective as the browser has to re-render the page after every one. This is one of many reasons why you should serve as few CSS files as possible (and minify them). – Michael Hampton Mar 23 '19 at 00:19
  • I'm not at all disagreeing with you, and on my production side I also combine CSS files into one big file, and minify'ing that file - However, is this really the expected behaviour of the browser/server when asked to serve up 100 CSS files? Intermittent silent fails? – noir04 Mar 23 '19 at 05:09

1 Answers1

1

Due to no answers and a slight derail ( no hard feelings Michael Hampton, I hope :) ), I ended up filing a bug with the Firefox team: https://bugzilla.mozilla.org/show_bug.cgi?id=1538978

The bug turned out to be a duplicate of some other bugs, all of that can be seen on bugzilla.

But in short, nginx sends a "goaway" when it reaches its http2_max_requests limit.

Firefox doesn't handle that, that well, and thus produces some problems

Chrome handles it a little better, it seems to wait a little and then retry

Who's at "fault", I don't really know, but a way to significantly reduce the problem is to set http2_max_requests to a very high number, say 500.000, the default is 1000

http2_max_requests 500000;

I've been running like this for a few weeks now, without any problems. So.. Problem "solved"

noir04
  • 41
  • 5