runserver serve static files cached in debug

[TZanke]

Hello,

right now i experience a problem with runserver and serving static files.

1) open chrome
2) open F12 debug tools
2) start runserver (Debug True)
3) open django site with a js/css required in head
4) have a look at a js/css file in network tab of debugger. At first the css/js file is loaded with status code 200, on F5 press maybe chrome just checks again an gets a 304. Fine. But sometime (at least 80% of the time) chrome does not check the server file again. I dont know why chrome does not refreshes the file every time when 'just' F5 is pressed. CTRL+F5 will fix the issue, but i think runserver with Debug=True should care about this problem itself to allow fast and easy development of js/css.

Possible fix: Add add_never_cache_headers to the static.py serve method

Right now i am not able to check the problem and fix on the latest version of Django, is there any simple way to setup a Django Environment with master branch to revalidate this issue?

Merge request on github: ​https://github.com/django/django/pull/14571

Right now i am not aware of all your django related requirements for submitting a code change / pull request / commit message / tests so please be gentle and take my pull request just as a possible example how to fix the issue. I know there is a lot more work to do.

Best regards
Tobias

[Carlton Gibson]

Hi Tobias — Welcome aboard!

Possible fix: Add add_never_cache_headers to the static.py serve method

I don't think this is the right approach. As far as I can see the browser behaviour is correct and as desired, serving static assets from the browser cache when possible.

When working on a file this behaviour can be undesired. For that all the browsers allow disabling the caches (at least while the dev tools are open) by accessing the settings (normally via the little cog or hamburger menu on in the dev tools, or via the Develop menu in Safari). If you check this static assets are fetched on each request.

If you really wanted to add no cache headers you could do so in a middleware, but I don't think it's appropriate for projects in general.

I hope that makes sense.

[TZanke]

Hello Carlton,

my (and my coworkers) expected behavior, with DEBUG=True, was a non-cached js/css file. So while developing, new colleges always struggle debugging, cause "my files does not get refreshed, but debug is on! Help me!". Yeah no problem, we always use the "disable browser cache" but maybe we are not alone with this problem, and this could easily be fixed. Cause static.py serve only is used in Debug mode by Django.

But we will respect the decision made.

If you really wanted to add no cache headers you could do so in a middleware, but I don't think it's appropriate for projects in general.

I've tried, but its not working. static.py serve is called within the 'StaticFilesHandler', skipping the Middlewares from BaseHandler.
See: ​https://github.com/django/django/blob/main/django/contrib/staticfiles/handlers.py#L53
No super call, no Middleware execution.

But keep in mind, i am not able to test with a new Django version right now. Maybe i am wrong 'just lookin at github'. But in Django 1.11 Middlewares are skipped.
(And yees, we are are nearly finished with Python3 conversion, so Django 2/3 is coming...soon ;)

Best regards
Tobias

[Carlton Gibson]

Hi Tobias.

... is called within the 'StaticFilesHandler'...

Yes, of course. (Doh.)

In that case using the browser dev tools to disable caching is the way to go.
Thanks.

[Dan Swain]

I would like to revisit this issue and make a distinction between static assets held by the Django site vs CDN-delivered content. Using the Disable cache option in the Network tab of developer tools DOES accomplish reloading static assets, BUT it causes ALL static assets to be reloaded including CDN-delivered content. I like to set up libraries to be delivered via CDN, even in development mode. Therefore, I would like to see runserver deliver new versions of ONLY the static assets that are housed in the Django project but NOT the CDN-delivered content. This behavior would allow development to continue even if an Internet connection is interrupted since CDN-delivered content would always be pulled from the cache. If this behavior is not the desired default for runserver (though I can't see why it wouldn't be), then perhaps a flag such as --always-refresh-static would be in order to trigger this behavior.

Finally, I know that I could use a bundler such as Vite or Snowpack to do hot reloading of static files, but I'm not currently using a bundler and so would like to see the above-described behavior included with runserver.

[Mariusz Felisiak]

I appreciate you'd like to reopen the ticket, but please ​follow the triaging guidelines with regards to wontfix tickets and take this to DevelopersMailingList.

[Ole Laursen]

I just ran into this ticket - I have the reverse problem, I'd like the static serve to send out a cache forever header, since I have a cache buster in place (it appends ?_=[timestamp of file] to all references to static assets). So it would be nice if I could get rid of the HTTP spam from the 304s.

Perhaps a compromise could be a relatively easy way of setting the static cache headers? Like:

    re_path(r'^static/(?P<path>.*)$', django.views.static.serve, {'document_root': settings.STATIC_ROOT, 'cache_control': {'no_store':True, 'max_age': 0}}),

I'm currently using a wrapper like this:

def static_serve_with_forever_cache(request, *args, **kwargs):
    response = django.views.static.serve(request, *args, **kwargs)
    if '_' in request.GET:
        patch_cache_control(response, public=True, max_age=365 * 24 * 60 * 60, immutable=True)
    return response

So it's not a big deal. But it is somewhat of a foot gun, so explicit support with a little note in the documentation might be useful?

[Mariusz Felisiak]

#33148 was marked as a duplicate of this ticket.

[Carlton Gibson]

Same topic was also in #27572. There's a simple wrapper for static.serve in https://code.djangoproject.com/ticket/27572#comment:4

[Kevin Christopher Henry]

This issue is being discussed in the ​Django Forum.