-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add hash to webpack requests to enable caching #9776
Conversation
Thanks for making a pull request to JupyterLab! To try out this branch on binder, follow this link: |
I'm confused. I think we want caching - that's why we have the content hash in the filename, so caching would work. But your comment seems to indicate that we do not want caching. |
First, it does seem that this improves the current situation. A couple of thoughts:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this does make things better with the existing Jupyter Server conventions, +1 to merging (with my suggested comment change, if my comment change is correct), though I think in the long run it's better to make Jupyter Server have better caching conventions.
I've made a Jupyter Server issue for tweaking the default (or at least handler-level) caching behavior at jupyter-server/jupyter_server#413 |
Arguably, we should also set the |
Answering this: the change to not use etags was made in jupyter/notebook@7ea4db6. Min decided there that we would use last-modified time to control caching, rather than explicitly compute a sha1 hash etag (which apparently is Tornado's default behavior). I think this is fine, and certainly is cheaper, and does not mess up cache validation. |
Co-authored-by: Jason Grout <jasongrout@users.noreply.github.com>
@meeseeksdev please backport to 3.0.x |
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon! If these instruction are inaccurate, feel free to suggest an improvement. |
Yes. I was seeing a "304" response. |
…g for 1.2.x Same fix as [jupyterlab#9776](jupyterlab#9776)
Hello! Got the same issue with Jupyterlab 1.2.7 |
References
Related to #9762. cc @zhamujun
Code changes
Add a version argument to generated webpack output for both the main build and prebuilt extensions when in production mode.
This is needed because the server is deciding whether to cache static files based on the existence of this argument, which is also the behavior of tornado's
StaticFileHandler
. This same behavior exists when running using the classic notebook server.The files generated by webpack are of the form
3341.cf37a29a49e9bc70ba18.js
(with no argument), but the requests it makes include the version argument, allowing the caching behavior to work.User-facing changes
JupyterLab will load faster when built in production mode (after the files are cached).
Backwards-incompatible changes
N/A