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
20819,`staticfiles.views.serve` should return 404 response instead of raising `ImproperlyConfigured`,Tai Lee,nobody,"I use this view to serve static files without having to `collectstatic` all the time during development, but I don't want to have code like this to create my root urlconf:
{{{
urlpatterns = patterns('',
# urls
)
if 'runserver' in sys.argv:
urlpatterns += patterns('',
url(r'^static/(.*)', 'django.contrib.staticfiles.views.serve', name='static'),
)
urlpatterns += patterns('',
# more urls. e.g. a catch-all that includes the URLs of another app at the root level.
url(r'^', include('myapp.urls')),
)
}}}
The above example also means that the `static` URL cannot be reversed by name, because it's only present during development. In some cases it can be convenient to simply reverse a URL name like this directly from a template or Python code.
If I leave the URL in my root urlconf and deploy to production to avoid these issues, and I forget to `collectstatic` after an update or if visitors request a static file that really doesn't exist, I get an HTTP 500 error emailed to me.
This view shouldn't do anything in production, but I think it should be sufficient to simply return a 404 error instead of raising `ImproperlyConfigured`. This is still an accurate error (static files that do exist will be served by the front-end server), and developers should know that a 404 for static media in production means they need to run `collectstatic`.
I discussed this briefly with jezdez on IRC who seemed OK with this idea, as long as the documentation was clear that this view would return a 404 and not return static files if used in production.
",Cleanup/optimization,closed,contrib.staticfiles,master,Normal,fixed,staticfiles serve ImproperlyConfigured,,Accepted,1,0,0,0,0,0