Hi All, I'm pretty interested in getting secure and _somewhat_ efficient static file serving in Django.
Quick history: 2005 - Jacob commits #428: a "static pages" view. Note that this view should only be used for testing!" 2010 - Jannis adds staticfiles. Serving via django is considered "grossly inefficient and probably insecure". 2011 - Graham Dumpleton adds wsgi.file_wrapper to Gunicorn. 2012 - Aymeric adds StreamingHttpResponse and now files are read in chunks rather than reading the entire file into memory. (No longer grossly inefficient IMHO.) I propose: - Deprecate the "show_indexes" parameter of static.serve() (unless people actually use it). - Have people report security issues to secur...@djangoproject.com (like always) - Audit the code and possibly add more security checks and tests. - add wsgi.file_wrapper support to responses (5-line proof of concept: https://github.com/django/django/pull/3650 ) - support serving static files in production, but still recommend nginx/apache or a cdn for performance. - make serving static files in production an opt-in, but put the view in project_template/project_name/urls.py I think it's a huge win for low-traffic sites or sites in the "just trying to deploy and get something live" phase. You can always optimize later by serving via nginx or cdn. We already have the views, api, and logic around for finding and serving the correct files. We can be just as efficient and secure as static/dj-static without needing to make people install and configure wsgi middleware to the application. We could have staticfiles classes implement more complicated features like giving cache recommendations, and serving pre-gzipped files. Is this a good idea? I realize it's not totally thought through. I'm fine with waiting until 1.9 if needed. Collin On Saturday, November 29, 2014 6:07:05 PM UTC-5, Collin Anderson wrote: > > Hi All, > > I think doing something here is really good idea. I'm happy with any of > the solutions mentioned so far. > > My question is: what does static/dj-static do that our built-in code > doesn't do? What makes it more secure? It seems to me we're only missing is > wsgi.file_wrapper and maybe a few more security checks. Why don't we just > make our own code secure and start supporting it? > Here's basic wsgi.file_wrapper support: > https://github.com/django/django/pull/3650 > > We could then, over time, start supporting more extensions ourselves: > ranges, pre-gziped files, urls with never-changing content, etc. That way > we get very, very deep django integration. It seems to me this is a piece > that a web framework should be able to support itself. > > Collin > > > On Friday, November 28, 2014 9:15:03 AM UTC-5, Tim Graham wrote: >> >> Berker has worked on integrating gunicorn with runserver >> <https://github.com/django/django/pull/3461> so that we might be able to >> deprecate our own homegrown webserver. Windows support for gunicorn is >> supposedly coming soon <https://github.com/benoitc/gunicorn/issues/524>which >> may actually make the idea feasible. This way we provide a more secure >> solution out of the box (anecdotes indicate that runserver is widely used >> in production despite our documentation warnings against doing so). >> >> On the pull request, Anssi had an idea to use dj-static >> <https://github.com/kennethreitz/dj-static> to serve static/media files. >> My understanding is that we would basically integrate the code for >> dj-static into Django and then add a dependency on static >> <https://pypi.python.org/pypi/static>. It could be an optional >> dependency since you might want to serve static files differently in >> production, but it would likely be more or less universally used in >> development. We could then say that django.views.static.serve (and its >> counterpart in staticfiles) is okay to use in production (and I guess >> people are already using them in production despite our warnings that they >> are not hardened for production use). >> >> What do you think of this plan? >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bfc1eb0d-8b69-4450-bfe0-7147ef729317%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
