id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux
19295,Document that runserver --insecure doesn't work with DEBUG False and CachedStaticFilesStorage,Apreche,kedmiston,"How to reproduce:
Enable the CachedStaticFilesStorage in your settings and turn DEBUG off.
{{{
DEBUG = False
STATICFILES_STORAGE = 'django.contrib.staticfiles.storage.CachedStaticFilesStorage'
}}}
Turn on the runserver with the insecure flag
{{{ $ python manage.py runserver --insecure }}}
Visit your runserver in your browser, and the static files will not load. When using the default django.contrib.staticfiles.storage.StaticFilesStorage the static files will load.
The reason is because of this section in contrib/staticfiles.storage.py
{{{
100 def url(self, name, force=false):
101 """"""
102 Returns the real URL in DEBUG mode.
103 """"""
104 if settings.DEBUG and not force:
105 hashed_name, fragment = name, ''
106 else:
}}}
When DEBUG is False, the automatic static file serving in runserver is disabled. But using runserver with --insecure will re-enable it. Because the CachedStaticFilesStorage only looks at the DEBUG flag, it will not work properly in this scenario. Perhaps that force parameter could be set to True when the --insecure flag is passed to runserver?
Yes, this is an extremely rare and low-priority edge case, but still a bug.
It's also not clear what the expected behavior is when both the --nostatic and --insecure flags are passed to runserver simultaneously. They sort of cancel each other out. Personally I feel the nostatic should take priority.",Cleanup/optimization,closed,Documentation,1.4,Normal,fixed,,,Accepted,0,0,0,0,1,0