Front-side HTTP caches can be essential at giant scale. First they help with naturally-static content, then you can design to maximize the amount that can be HT

Front-side HTTP caches can be essential at giant scale. First they help with naturally-static content, then you can design to maximize the amount that can be HTTP-cached. I would like to see this better recognized as a usual and desirable production setup in the Django community, so as to eventually change the traditional doctrine around static resources. Currently, there's the assumption that every serious production deployment moves static file-serving out of python/Django, to a dedicated side server. So, the interaction of the 'staticfiles' component changes awkwardly around the DEBUG setting, and the docs contain hand-wavey warnings about how using Django to serve static resources is "grossly inefficient and probably insecure". Well, once you've committed to having a front-side HTTP cache, it's pretty damn efficient - one request per resource for an arbitrarily long cache-lifetime period. It requires fewer deployment steps and standalone processes than the assumed ('collectstatic'-and-upload-elsewhere) model. And if the staticfiles app is truly "insecure", that needs fixing: many people run their dev/prototype code in an internet-accessible way, so any known security risks here should get the same attention they get elsewhere. (Disabling the code entirely when DEBUG is true is a dodge.) I'd love a future version of Django to embrace the idea: "staticfiles is a wonderful way to serve static resources, if you run a front-side HTTP cache, which most large projects will".