I've just pushed a simple middleware wrapper that lets you install 
WhiteNoise by adding:

MIDDLEWARE_CLASSES = (
   ...
    'whitenoise.middleware.StaticFilesMiddleware',
   ...
)


See: https://github.com/evansd/whitenoise/blob/master/whitenoise/middleware.py

No messing with wsgi.py!

This approach will be marginally less efficient than handling things at the 
WSGI layer, but the integration is much cleaner.

On Tuesday, 29 December 2015 17:31:02 UTC, David Evans wrote:
>
> I'd be very happy to help with this. Two things to mention:
>
> 1. When I first wrote WhiteNoise the FileResponse class didn't exist and 
> so the only way I could access `wsgi.file_wrapper` was by wrapping the wsgi 
> application directly and bypassing Django. Now we have the FileResponse 
> class it would be possible to implement WhiteNoise as standard Django 
> middleware without having to edit wsgi.py. I think this would be a much 
> cleaner approach, and I don't think it will be too much work to implement. 
> I should have time to look at this next week.
>
> 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?
>>
>

-- 
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/e24d4590-e8e7-437d-a441-b1ba51e1f535%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to