You are free to use what your PaaS provider supplies, but if you are using heroku (and many others) you do not have a choice. If AWS allows you to use apache 2.4 in event mode, then by all means use it! But there are plenty of platforms out there where you cannot easily serve static files and/or performance does not matter too much. So in the end it boils down if we can remove code from Django, if yes it is a win, even if it is just used for the development server.
On Thursday, December 31, 2015 at 1:00:13 AM UTC+1, Cristiano Coelho wrote: > > Just curious, about PaaS, I know AWS (Amazon) deploys python/django on > apache (which is quite decent), and apache also serves static files > decently. What would be wrong with this? > The idea of having Python serving static files (and potentially gziping > it), when python is one of the slowest languages out there, I don't think > it is really a good idea. You should be really serving static files with > something implemented in C/C++ or similar high performant language (read > nginx or apache). How wrong am I? > > El viernes, 5 de diciembre de 2014, 5:19:45 (UTC-3), Aymeric Augustin > escribió: >> >> Yes, I support this plan. >> >> "Serve your files with nginx!" doesn't fly in the age of PaaS. >> >> Serving static files with Django and having a CDN cache them is a >> reasonable setup as far as I know. >> >> I don't know if the "probably insecure" argument still holds. Are there >> some specific security risks in serving files that don't exist in serving >> dynamic content? I'd say dynamic content is more difficult. This main >> problem I can imagine when serving files is directory traversal. We already >> have protections against this class of attacks in several features. (Usual >> disclaimer: my background is security is mostly theoretical.) >> >> -- >> Aymeric. >> >> >> 2014-12-05 6:33 GMT+01:00 Collin Anderson <cmawe...@gmail.com>: >> >>> 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. >>> >>> Collin >>> >>> On Saturday, November 29, 2014 6:07:05 PM UTC-5, 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 django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/bfc1eb0d-8b69-4450-bfe0-7147ef729317%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/bfc1eb0d-8b69-4450-bfe0-7147ef729317%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> Aymeric. >> > -- 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/ca72a482-50cd-43d9-b6ea-7d3bf74b5823%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
