+1 to this: I'm all in favour of supporting production-adequate static file handling in core. A couple of small points:
We already have the views, api, and logic around for finding and serving > the correct files. One question that needs to be thought through is the role of `collectstatic` and `STATIC_ROOT`. The existing static.serve view just ignores `STATIC_ROOT` completely and uses the configured StaticFileFinders to locate files. This means if you use the ManifestStaticFilesStorage backend -- or anything that uses the `post_process` hook -- it won't find your processed files at all. Probably the simplest thing is to switch on DEBUG, and serve files from `STATIC_ROOT` (falling back to using the finders) when DEBUG is False, and use the existing behaviour otherwise. We could have staticfiles classes implement more complicated features like > giving cache recommendations, and serving pre-gzipped files. Definitely +1 to using classes (CBVs, presumably) to handle this. The existing views don't easily support customising behaviour. Regards, Dave On 5 December 2014 at 05:33, Collin Anderson <cmawebs...@gmail.com> 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 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 a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/N0KbgDeLuUE/unsubscribe > . > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/django-developers/bfc1eb0d-8b69-4450-bfe0-7147ef729317%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 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/CAHbVmPynOBLUR4zSs8C4Uka2i3ug_F%3D%2B4%3Dx2gC7cKbEiKvs4vg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
