> On 28 Nov 2014, at 15:15, Tim Graham <[email protected]> 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?
I don't think using dj-static is a good idea (after having fixed a few things myself in it). If we'd want to do some form of "simpler" file serving we should be going with whitenoise (http://whitenoise.evans.io/) because: - it has a deeper integration with Django (e.g. knows about the manifest storage backend in staticfiles) - has a more flexible API than the Cling based dj-static for custom paths like file uploads and more - works great with CDN/load balancer backed deployments via far-future cache headers for content that doesn't change - supports serving gzipped content when wanted To me this is currently the one-stop-solution when using staticfiles and I would be stoked to see it or its techniques be adopted. Jannis -- 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/9B11AB1B-2850-401D-97BA-FB7C73268672%40gmail.com. For more options, visit https://groups.google.com/d/optout.
