You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm switching an app from hosting static files on S3 to serving them from Django via WhiteNoise, behind the CloudFront CDN. WhiteNoise uses a middleware to intercept requests to STATIC_URL, and returns a file response. This is all relatively straightforward to set up.
Expected behaviour
Hashed static files served via WhiteNoise should have a far-future Cache-Control header
More broadly, Django CMS shouldn't set a "never cache" header for responses that don't include a toolbar
Actual behaviour
During testing I discovered that the Cache-Control header was still being set to "never cache" for static files. A dive through PDB led me to the ToolbarMiddleware and the behavior of using the cache-disabledEmptyToolbar while processing the response for non-CMS pages.
One possible workaround is to set CMS_TOOLBAR_HIDE = True, which short-circuits ToolbarMiddleware processing. However, this causes problems for us because we have views that have toolbar-related functionality, but aren't CMS pages. As a workaround for that, I subclassed ToolbarMiddleware to override is_cms_request to recognize the additional views.
Environment
Python version: 2.7.15
Django version: 1.11.18
django CMS version: 3.4.5
The text was updated successfully, but these errors were encountered:
Summary
I'm switching an app from hosting static files on S3 to serving them from Django via WhiteNoise, behind the CloudFront CDN. WhiteNoise uses a middleware to intercept requests to
STATIC_URL
, and returns a file response. This is all relatively straightforward to set up.Expected behaviour
Cache-Control
headerActual behaviour
During testing I discovered that the
Cache-Control
header was still being set to "never cache" for static files. A dive through PDB led me to theToolbarMiddleware
and the behavior of using the cache-disabledEmptyToolbar
while processing the response for non-CMS pages.One possible workaround is to set
CMS_TOOLBAR_HIDE = True
, which short-circuitsToolbarMiddleware
processing. However, this causes problems for us because we have views that have toolbar-related functionality, but aren't CMS pages. As a workaround for that, I subclassedToolbarMiddleware
to overrideis_cms_request
to recognize the additional views.Environment
The text was updated successfully, but these errors were encountered: