It's worth flagging up that part of what makes WhiteNoise good for serving static files in production also makes it not quite as good for using in development.
Most file servers work by taking the requested URL, constructing a local path from it, and then checking whether a file exists at that particular path. WhiteNoise on the other hand, searches for all available static files on startup and then builds a dictionary of files which it assumes won't change until the code is reloaded. This has a couple of big advantages: one is security -- there's a whole class of path-traversal vulnerabilities that I don't have to worry about because I never have to generate a path from a user-supplied URL. The other is that WhiteNoise can serve files from arbitrary URLs, rather than just within a fixed prefix like `/static/`, without adding an extra hit on the filesystem for every single request that comes in. While this works well in production, it breaks down in development where the static files change without causing a reload of the server. I've started getting bug reports from users who are trying to use WhiteNoise in development and are getting confused by this. So, while I'd obviously be delighted to see some of WhiteNoise's features merged into core I think there will need to be a slightly different approach for serving files in development. Dave On Saturday, 29 November 2014 23:07:05 UTC, 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 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/a4efc639-ee61-4c6b-88b4-2866f86bdc24%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
