[Django] #27572: Static files served in development should prevent caching
Django
-------------------------------------+-------------------------------------
Reporter: Kevin | Owner: nobody
Christopher Henry |
Type: | Status: new
Cleanup/optimization |
Component: | Version: 1.10
contrib.staticfiles |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Currently, when Django serves static files in development with `runserver`
and `django.contrib.staticfiles` it doesn't provide any cache headers. In
their absence, user agents are free to cache the resources
[https://tools.ietf.org/html/rfc7234#section-4.2.2 however they like].
That means that when the developer updates a static resource they can't
predict whether or not they will see the new version or the older cached
version.
Dealing with this on the user agent side isn't always easy. For example,
if you're using an embedded browser in a native app you'll probably have
to create a remote debugging connection to the app and use platform-
specific development tools to manipulate or disable the cache.
Since caching is a performance optimization that makes development more
difficult and less predictable, I think it makes sense to disable it (via
the appropriate HTTP headers) for static resources served in development.
--
Ticket URL: <https://code.djangoproject.com/ticket/27572>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Henry |
Type: | Status: new
Cleanup/optimization |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Tim Graham):
We've [https://groups.google.com/d/topic/django-
developers/N0KbgDeLuUE/discussion been thinking about] replacing our own
staticfile serving code with something like
[https://github.com/evansd/whitenoise whitenoise]. Do you know if it has a
suitable option?
--
Ticket URL: <https://code.djangoproject.com/ticket/27572#comment:1>
Django
-------------------------------------+-------------------------------------
Henry |
Type: | Status: new
Cleanup/optimization |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Kevin Christopher Henry):
I haven't used `whitenoise` before, but based on the
[http://whitenoise.evans.io/en/stable/django.html#WHITENOISE_MAX_AGE
documentation] it looks like it's already doing what I proposed above:
{{{
WHITENOISE_MAX_AGE
Default: 60 if not settings.DEBUG else 0
Time (in seconds) for which browsers and proxies should cache non-
versioned files.
}}}
So, yes, a switch to `whitenoise` should solve this problem! I don't know
how imminent that is, so I'll leave it up to you whether this is worth
fixing in the meantime.
--
Ticket URL: <https://code.djangoproject.com/ticket/27572#comment:2>
Django
-------------------------------------+-------------------------------------
Henry |
Cleanup/optimization |
Component: contrib.staticfiles | Version: 1.10
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
Great, I don't see much value in duplicating work then.
--
Ticket URL: <https://code.djangoproject.com/ticket/27572#comment:3>
Django
-------------------------------------+-------------------------------------
Henry |
Type: | Status: closed
Cleanup/optimization |
Component: contrib.staticfiles | Version: 1.10
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
> Currently, when Django serves static files in development with
> `runserver` and `django.contrib.staticfiles` it doesn't provide any cache
> headers. In their absence, user agents are free to cache the resources
> [https://tools.ietf.org/html/rfc7234#section-4.2.2 however they like].
> That means that when the developer updates a static resource they can't
> predict whether or not they will see the new version or the older cached
> version.
>
> Dealing with this on the user agent side isn't always easy. For example,
> if you're using an embedded browser in a native app you'll probably have
> to create a remote debugging connection to the app and use platform-
> specific development tools to manipulate or disable the cache.
>
> Since caching is a performance optimization that makes development more
> difficult and less predictable, I think it makes sense to disable it (via
> the appropriate HTTP headers) for static resources served in development.
New description:
--
Comment (by Mateusz Kurowski):
For future reference here is a monkey patch that works for me in
development:
{{{
from functools import wraps
import django.http
import django.views.static
def no_cache_static(f):
@wraps(f)
def static(*a, **kw):
response: django.http.response.HttpResponse = f(*a, **kw)
response.headers["Cache-Control"] = "no-cache"
return response
return static
django.views.static.serve = no_cache_static(django.views.static.serve)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/27572#comment:4>
Django
-------------------------------------+-------------------------------------
Henry |
Type: | Status: closed
Cleanup/optimization |
Component: contrib.staticfiles | Version: 1.10
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Old description:
New description:
Currently, when Django serves static files in development with `runserver`
and `django.contrib.staticfiles` it doesn't provide any cache headers. In
their absence, user agents are free to cache the resources
[https://tools.ietf.org/html/rfc7234#section-4.2.2 however they like].
That means that when the developer updates a static resource they can't
predict whether or not they will see the new version or the older cached
version.
Dealing with this on the user agent side isn't always easy. For example,
if you're using an embedded browser in a native app you'll probably have
to create a remote debugging connection to the app and use platform-
specific development tools to manipulate or disable the cache.
Since caching is a performance optimization that makes development more
difficult and less predictable, I think it makes sense to disable it (via
the appropriate HTTP headers) for static resources served in development.
--
Comment (by Kevin Christopher Henry):
(I added the description back in since it was wiped out by the last edit.)
It looks like the idea of integrating whitenoise hasn't gone anywhere
since it was [https://groups.google.com/g/django-
developers/c/N0KbgDeLuUE/m/LXlLqYOWBAAJ last mentioned] in 2017, so I'm
not sure the resolution makes sense anymnore.
--
Ticket URL: <https://code.djangoproject.com/ticket/27572#comment:5>
Django
-------------------------------------+-------------------------------------
Henry |
Type: | Status: closed
Cleanup/optimization |
Component: contrib.staticfiles | Version: 1.10
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson):
This was raised again in #32891.
Closed as wontfix with ≈: 1) We **want** to see the caching correctly set,
and 2) "Disable caching on the client" if you don't want it. 2 there is in
contrast to "Dealing with this on the user agent side isn't always easy" —
but I think these latter days it pretty much is... 🤷♀️ (Either way, the
wrapper around `static.serve` seems pretty lightweight.)
--
Ticket URL: <https://code.djangoproject.com/ticket/27572#comment:6>
Django
-------------------------------------+-------------------------------------
Henry |
Type: | Status: closed
Cleanup/optimization |
Component: contrib.staticfiles | Version: 1.10
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Kevin Christopher Henry):
This issue is being discussed in the [https://forum.djangoproject.com/t
/static-files-served-in-development-should-not-be-cached/18579 Django
Forum].
--
Ticket URL: <https://code.djangoproject.com/ticket/27572#comment:7>