I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of sense.
-- Loïc > On Dec 5, 2014, at 12:33 PM, Collin Anderson <[email protected]> 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. > > 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 so that we might be > able to deprecate our own homegrown webserver. Windows support for gunicorn > is supposedly coming soon 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 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. 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 [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/bfc1eb0d-8b69-4450-bfe0-7147ef729317%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/1603744A-A45A-4FDE-B5D6-3814CE589692%40gmail.com. For more options, visit https://groups.google.com/d/optout.
