On 12/04/2014 10:33 PM, Collin Anderson wrote: > 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 [email protected] (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.
I also think this is a good plan. It certainly makes sense to look at "static" and "whitenoise" for ideas and compare their code to ours to see where we could be more efficient or secure, but it's much less churn for Django users if we simply improve our existing code rather than pull in something wholly new. Carl -- 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 [email protected]. To post to this group, send email to [email protected]. 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/548203D3.5070809%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
