Changes between Initial Version and Version 4 of Ticket #27572


Ignore:
Timestamp:
Jan 30, 2023, 8:20:22 AM (15 months ago)
Author:
Mateusz Kurowski
Comment:

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)

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #27572

    • Property Resolution → wontfix
    • Property Status new → closed

  • Ticket #27572 – Description

    initial v4  
    1 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.
    2 
    3 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.
    4 
    5 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.
Back to Top