-
Notifications
You must be signed in to change notification settings - Fork 265
include.js cannot be cached (Cache-Control: public, max-age=0) #3035
Comments
To discuss on list.... |
Also noted in GH-2549 |
Posted the 10 min proposal to the list: https://groups.google.com/d/topic/mozilla.dev.identity/jXhDsQsO-fQ/discussion |
Also related: #3119 |
can the application cache file be of use here ? u can add an additional script to look for push changes to ur repo and on the respone download the new manifest file ,which wld download the updated include.js on the next run. still cant figure a way make it async.. |
If we have ETags, why is deployment trickier after unblocking caching? |
@djc if we use time-based expires/cache-control headers, and the time period hasn't elapsed, then the browser will not check the ETag, it'll just use the locally-cached version of the file. check out the dev-identity conversation francois linked for more discussion. |
Hi! To help us better focus, I'm "closing" all issues that have been open for more than six months. These have been tagged "cleanup-2014" so that we can go back and review them in the future. For more information, check out this thread: http://thread.gmane.org/gmane.comp.mozilla.identity.devel/7394 If you believe this bug is still a major issue for you, please comment, submit a pull request, or discuss it on our mailing list: https://lists.mozilla.org/listinfo/dev-identity Sorry for GitHub notification spam! |
include.js
is currently exposing aCache-Control
header withmax-age=0
which means that sites that include from every page will cause browsers to do an extra HTTPS request every time.Letting browsers cache this file makes deploying a new version trickier, but it's really worth it from a performance point of view.
The text was updated successfully, but these errors were encountered: