Also consider the media files could number into the millions (or bajizillions?). Particularly for, say, a image hosting application. Clearly it would not be feasible to enumerate all the files, and there would clearly be regular additions. It might be that this use case is simply "beyond the scope" of a django-supplied static files server, and the developer should instead use nginx, lighttpd or something similar.
On Tuesday, December 29, 2015 at 9:31:02 AM UTC-8, David Evans wrote: > > 2. Serving media files is a slightly different case. WhiteNoise was > designed around the assumption that it's serving a set of > developer-supplied, public files which remain unchanged during the lifetime > of the process. This simplifies a lot of performance and security concerns > that come with serving mutable, user-supplied files. At present, if you use > `add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL)` as you > suggested then WhiteNoise won't pick up any files that were uploaded after > the application was started -- at least, not unless you enable the > "autorefresh" setting which I explicitly don't recommend for production. > > Obviously it's possible to support this if we decide this is an important > goal but it will need more thought and will definitely be more work than > just supporting static files. > > On Tuesday, 29 December 2015 00:36:06 UTC, Tim Graham wrote: >> >> I'd like to work together with Dave to develop a proof of concept that >> integrates whitenoise into Django. I spent about an hour looking through >> whitenoise and our own static file serving code, and I think integrating >> whitenoise will yield a simpler user experience with about the same amount >> of code as have now. >> >> Essentially, we'd recommend adding something like this to existing >> wsgi.py files (it would be in the default startproject template) >> >> from whitenoise.django import DjangoWhiteNoise >> application = DjangoWhiteNoise(application) >> application.add_files(settings.MEDIA_ROOT, prefix=settings.MEDIA_URL) >> >> which would have the benefit of working out of the box in production too, >> I think. Of course, you could disable that based on settings.DEBUG or some >> other toggle. >> >> We could then deprecate: >> >> * django/contrib/staticfiles/views.py >> * django/contrib/staticfiles/management/commands/runserver.py >> * django/contrib/staticfiles/handlers.py >> * django/views/static.py >> >> Any objections to doing further investigation in this area? >> >> On Saturday, June 20, 2015 at 8:09:11 AM UTC-4, David Evans wrote: >>> >>> On Friday, 5 December 2014 19:14:29 UTC, Carl Meyer wrote: >>>> >>>> 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 secu...@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. >>>> >>>> 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 >>>> >>>> >>>> >>> Sorry to revive an old thread here, but I just wanted to add that v2.0 >>> of WhiteNoise now supports serving development files, providing the same >>> behaviour as runserver currently does in DEBUG mode. (There were enough >>> people wanting to do their development using gunicorn rather than runserver >>> to make this worthwhile.) >>> >>> This means that WhiteNoise is now a one-stop-shop for static file >>> handling in Django. If there's still an appetite for integrating it, or >>> something equivalent, into core I'd be happy to help out. >>> >>> Dave >>> >> -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/29a7a6dd-07c1-41e1-8de3-7acda64a6017%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
