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
Without cache directives in the response headers from the Contents API, Chrome appears to cache fetch responses for a duration proportional to the time since the reported last modification of the content. This prevents fetches from seeing updated contents when contents (on first fetch) haven't seen recent modifications.
From the server's root dir (same cwd as previous command) make a dir to list contents from. Pretend it was created a few months ago (but using just a few hours ago repros as well):
mkdir some_dir
touch -t 202301010000 some_dir
In an incognito Chrome window, clear browser cache, then navigate to the server root url (http://127.0.0.1:8892/). Be welcomed by "A Jupyter Server is running.".
In the Developer Tools console, exercise the Contents API for the created dir:
Run the fetch again and notice the response is obtained from disk cache.
Make a modification to the directory:
touch some_dir/a
Run the fetch again and notice the response is obtained from disk cache, and hence doesn't include some_dir/a. Repeatable for minutes.
Expected behavior
A fetch with default options should show the new directory entry. (Caching this for a few seconds seems acceptable, but not 10m+.)
The problem can be avoided by specifying cache use behavior in the fetch options (e.g. no-store). I don't know if it is expected to have to specify this in the frontend, vs. having the server control the caching behavior better. I found fe730a6 which disables caching for unversioned static files and suggests server-side handling was at least preferred there.
Trying a simple version of that:
diff --git a/jupyter_server/services/contents/handlers.py b/jupyter_server/services/contents/handlers.py
index 50e7703db..b193eb0d0 100644
--- a/jupyter_server/services/contents/handlers.py
+++ b/jupyter_server/services/contents/handlers.py
@@ -89,6 +89,9 @@ class ContentsHandler(ContentsAPIHandler):
self.set_header("Location", location)
self.set_header("Last-Modified", model["last_modified"])
self.set_header("Content-Type", "application/json")
+ # disable browser caching, rely in 304 replies for savings
+ if "v" not in self.request.arguments:
+ self.add_header("Cache-Control", "no-cache")
self.finish(json.dumps(model, default=json_default))
@web.authenticated
, conditional requests are performed for every fetch, problem no longer observed. IDK enough about browser caching to know if this is the right fix though.
I haven't seen this Chrome behavior with page loads, only fetches.
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋
Description
Without cache directives in the response headers from the Contents API, Chrome appears to cache fetch responses for a duration proportional to the time since the reported last modification of the content. This prevents fetches from seeing updated contents when contents (on first fetch) haven't seen recent modifications.
Reproduce
Start the server:
From the server's root dir (same cwd as previous command) make a dir to list contents from. Pretend it was created a few months ago (but using just a few hours ago repros as well):
In an incognito Chrome window, clear browser cache, then navigate to the server root url (http://127.0.0.1:8892/). Be welcomed by "A Jupyter Server is running.".
In the Developer Tools console, exercise the Contents API for the created dir:
Response headers should look like:
Run the
fetch
again and notice the response is obtained from disk cache.Make a modification to the directory:
Run the
fetch
again and notice the response is obtained from disk cache, and hence doesn't includesome_dir/a
. Repeatable for minutes.Expected behavior
A
fetch
with default options should show the new directory entry. (Caching this for a few seconds seems acceptable, but not 10m+.)The problem can be avoided by specifying cache use behavior in the fetch options (e.g.
no-store
). I don't know if it is expected to have to specify this in the frontend, vs. having the server control the caching behavior better. I found fe730a6 which disables caching for unversioned static files and suggests server-side handling was at least preferred there.Trying a simple version of that:
, conditional requests are performed for every fetch, problem no longer observed. IDK enough about browser caching to know if this is the right fix though.
I haven't seen this Chrome behavior with page loads, only fetches.
Context
Troubleshoot Output
The text was updated successfully, but these errors were encountered: