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 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/e3be33a3-3675-4397-b017-e0565bda84fb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
