Skip to content
This repository has been archived by the owner on May 10, 2019. It is now read-only.

include.js cannot be cached (Cache-Control: public, max-age=0) #3035

Closed
fmarier opened this issue Feb 22, 2013 · 8 comments
Closed

include.js cannot be cached (Cache-Control: public, max-age=0) #3035

fmarier opened this issue Feb 22, 2013 · 8 comments

Comments

@fmarier
Copy link
Contributor

fmarier commented Feb 22, 2013

include.js is currently exposing a Cache-Control header with max-age=0 which means that sites that include from every page will cause browsers to do an extra HTTPS request every time.

$ curl --head https://login.persona.org/include.js
HTTP/1.1 200 OK
Vary: Accept-Encoding,Accept-Language
Cache-Control: public, max-age=0
Content-Type: application/javascript
Strict-Transport-Security: max-age=2592000; includeSubdomains
Date: Fri, 22 Feb 2013 05:38:42 GMT
Access-Control-Allow-Origin: https://login.persona.org
ETag: "15578-1360955616000"
Connection: keep-alive
X-Frame-Options: DENY
Content-Length: 15578

Letting browsers cache this file makes deploying a new version trickier, but it's really worth it from a performance point of view.

@callahad
Copy link
Contributor

To discuss on list....

@jrgm
Copy link
Contributor

jrgm commented Feb 26, 2013

Also noted in GH-2549

@fmarier
Copy link
Contributor Author

fmarier commented Feb 26, 2013

Posted the 10 min proposal to the list: https://groups.google.com/d/topic/mozilla.dev.identity/jXhDsQsO-fQ/discussion

@fmarier
Copy link
Contributor Author

fmarier commented Apr 24, 2013

Also related: #3119

@deepak1556
Copy link

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..

@djc
Copy link
Member

djc commented Oct 1, 2013

If we have ETags, why is deployment trickier after unblocking caching?

@jaredhirsch
Copy link
Member

@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.

@callahad
Copy link
Contributor

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!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants