Opened 3 years ago

Closed 2 years ago

#18336 closed Bug (fixed)

Static files randomly fail to load in Google Chrome

Reported by: anonymous Owned by: nobody
Component: HTTP handling Version: master
Severity: Normal Keywords:
Cc: robgolding63 Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I've noticed while using Google Chrome that frequently (once every 2 or 3 refresh) some of my static files fail to load, it can be anything: an image, a .js file, etc. Opening that file directly always work, reloading the page usually work as well. I couldn't reproduce this behavior with Firefox.

This is happening with the default options for the runserver of django.contrib.staticfiles.

I figured this probably had to do with either a timeout or the size of the request queue, possibly both. I tried setting request_queue_size to 10 (default is 5) as demonstrated in the attached file and it completely solve the issue. I the tried setting it to 1 and it makes the issue systematic.

I tried to find how many concurrent requests chrome does and found the following:

Unless I'm missing something, Chrome actually use less concurrent requests than Firefox. A value of 10 for request_queue_size does seem to solve my problem completely, but I wouldn't know what should be the actual best value.

Attachments (1) (555 bytes) - added by anonymous 3 years ago.

Download all attachments as: .zip

Change History (17)

Changed 3 years ago by anonymous

comment:1 Changed 3 years ago by jezdez

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Wow, what a weird bug, accepting in general, but have to look into this further.

comment:2 Changed 3 years ago by aaugustin

This reminds me of #16099, but it appears to be a different bug.

comment:3 Changed 3 years ago by anonymous

I made a test project to demonstrate the behavior, here with a request_queue_size of 1, each refresh seems to load a different set of pictures.

comment:4 Changed 3 years ago by chipx86

I'm curious if this has still been a problem for anyone. I've been noticing this lately with recent versions of Chrome, and can confirm that the attached patch solves it (though, it feels like a bandaid to me).

I can reliably reproduce this, so if there's anything I can do to help in debugging this, please let me know.

comment:5 Changed 3 years ago by yesimon

Yes this is a problem for me as well with Chrome 23 on OS X Mountain Lion when there are a lot of concurrent staticfiles requests.

comment:6 Changed 3 years ago by jtiai

I had the same problem. It happened exactly at the spesific location and only with Chrome. I managed to get runserver working by adjusting request_queue_size.

It's not a problem for other browsers.

comment:7 Changed 3 years ago by ramiro

Can the users that are experimenting this issue report their OS?. Maybe it's a MAC OS X-specific thing?

Version 0, edited 3 years ago by ramiro (next)

comment:8 Changed 3 years ago by anonymous

OP here, I'm indeed running OS X.

comment:9 Changed 3 years ago by yesimon

comment:10 Changed 3 years ago by chipx86

I'm also on MacOS X.

To do any actual development, I have to patch every time I upgrade Django, in each virtualenv. If there were a way to at least override this in some form globally, I could live with it, but for the moment, it's a complete pain and leads to odd, sometimes very subtle bugs.

comment:11 Changed 3 years ago by robgolding63

  • Cc robgolding63 added

comment:12 Changed 3 years ago by gansos

I've also been experiencing this (Django 1.5, Mac OS 10.8, Chrome 25). In some cases it completely locks up Chrome (tab dies). Other times random static files fail to load. In addition, I've seen very similar behavior in AppEngine's dev_appserver (also based on Python's SocketServer module) , and I'm inclined to think request_queue_size is the culprit.

comment:13 Changed 3 years ago by yesimon

BTW I got this fix merged into django-devserver, which is a drop in replacement for runserver in dev.

This bug is probably going to be a WontFix on both Chrome and Django ends.

comment:14 Changed 3 years ago by loic84

For anyone looking for a quick fix that doesn't require patching Django or installing a third party app: you can monkey patch WSGIServer from

A queue size of 10 has worked really well for me since I opened this ticket, but with this in you can easily increase the value to match your needs.

from django.core.servers.basehttp import WSGIServer
WSGIServer.request_queue_size = 10
Last edited 2 years ago by loic84 (previous) (diff)

comment:15 Changed 2 years ago by aaugustin

I could eventually reproduce this, on OS X.8 with Chrome, with the test project provided by Loic in comment 3 and WSGIServer.request_queue_size set to 1.

I'm not sure why the original path and devserver resort to monkey-patching instead of simply defining request_queue_size on WSGIServer.

comment:16 Changed 2 years ago by Aymeric Augustin <aymeric.augustin@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 4ff682c1ba1cd051243842bbd2feb19e75b559f3:

Fixed #18336 -- Doubled request_queue_size.

This reduces random failures to load static files with Google Chrome.

Note: See TracTickets for help on using tickets.
Back to Top