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
It looks like cache problem, so I'm going to investigate step by step...
...damned, opening the Firefox console solved the issue (the no-cache were ticked), so we have a browser cache issue: users with the old theme in their local cache may get what I got.
I unticked the Firefox network console "disable cache" and tried all other translations to try to reproduce, and was able to reproduce it once:
Also the size is too low to contain the whole css, so it looks like the network connection has started, bytes has been received, but the cache won the race and the network connection was interrupted.
Which I find strange is that when I refresh, all other components are requested by my browser, which all properly receive a "304 not modified" answer, but not the CSS itself:
This is a cache issue, and it is solved by using a hard refresh (or visiting from an incognito tab).
Usually, this is solved for me by the JS build tools :) We could manually add a version number/uuid or something like that to the name of the css file when we build the theme, so that the new version is loaded each time a theme is updated. GitHub, for example, has CSS filenames like github-230a1a8c439e974d9e793a2132759a84.css
A stored response is considered "fresh", as defined in
Section 4.2, if the response can be reused without "validation"
then in 4.3.3:
A 304 (Not Modified) response status code indicates that the
stored response can be updated and reused; see Section 4.3.4.
So if we add an s-maxage=60 header for example, the intermediate caches (Fastly here) will still be able to HIT on every request, only revalidating once per minute, and the browsers will have to re-validate the CSS on almost every pageloads (and most of the time getting a 304 answer), instead of being allowed to use one from their cache.
So validation means more HTTP requests, but many with no response body (it takes 11ms on my laptop to get a 304 on a docs.python.org CSS) but no maintenance.
On the other hand, fingerprinting means less HTTP requests (we could even explicitly set s-maxage=31536000), but would require a modification of the CSS filename and the HTML, either at release time, either at build time.
An easy way to fingerprint would be to append the version in the stylesheet variable in theme.conf: python_docs_theme/theme.conf:stylesheet = pydoctheme.css?v=2021.5.
Activity
JulienPalard commentedon May 11, 2021
see: https://bugs.python.org/issue44103
obulat commentedon May 12, 2021
This is a cache issue, and it is solved by using a hard refresh (or visiting from an incognito tab).
Usually, this is solved for me by the JS build tools :) We could manually add a version number/uuid or something like that to the name of the css file when we build the theme, so that the new version is loaded each time a theme is updated. GitHub, for example, has CSS filenames like
github-230a1a8c439e974d9e793a2132759a84.cssobulat commentedon May 12, 2021
Where would we add that? Build scripts?
JulienPalard commentedon May 12, 2021
I'm wondering if it's better to use validation instead of fingerprinting.
From RFC 7234:
then in 4.3.3:
So if we add an
s-maxage=60header for example, the intermediate caches (Fastly here) will still be able to HIT on every request, only revalidating once per minute, and the browsers will have to re-validate the CSS on almost every pageloads (and most of the time getting a304answer), instead of being allowed to use one from their cache.So validation means more HTTP requests, but many with no response body (it takes 11ms on my laptop to get a 304 on a docs.python.org CSS) but no maintenance.
On the other hand, fingerprinting means less HTTP requests (we could even explicitly set
s-maxage=31536000), but would require a modification of the CSS filename and the HTML, either at release time, either at build time.An easy way to fingerprint would be to append the version in the stylesheet variable in
theme.conf:python_docs_theme/theme.conf:stylesheet = pydoctheme.css?v=2021.5.hugovk commentedon Feb 16, 2023
Please see PR #108.