Allow client caching of include.js

[kevinoid]

I started this discussion on the dev-identity mailing list and didn't receive any objections. Francois Marier suggested I file a bug about it here. The text that follows is mostly taken from the email:

I contend that browsers should be allowed to cache include.js (which is currently sent with "Cache-Control: public, max-age=0").

The documentation suggests that https://login.persona.org/include.js should be included on every page in a web application in order to support automatic login and allow logout, and that the file should not be self-hosted. On my test machine, this typically adds between 150 and 600ms to the load time of every page (Note: My RTT to login.persona.org, from tcptrace, is ~75ms.). The experience is improved on some browsers by deferring the script, but it's clearly not a panacea.

I realize that the desire for caching is counter-balanced by the desire to be able to deploy fixes quickly (particularly for security issues). However, if the script were cached for a matter of hours it would be a noticeable improvement for users visiting multiple pages with Persona during that time, which, particularly if Persona increases in popularity, could be substantial. I would also expect it to lower resistance to adoption among developers concerned about page load-times.

Thanks for your consideration,
Kevin

[callahad]

I'm +1 on caching for several hours. Somewhere between 2-6 hours feels "right" in terms of reducing burden while preserving agility. @kevinoid, how long are you thinking would be good?

[kevinoid]

The big tradeoffs that I see are between the expected bug severity, acceptability of down/broken time (for a given severity), and expected turnaround time for code fixes weighed against latency and resource usage in the typical use case. I don't know much about how you might weigh those, but 2-6 hours sounds pretty reasonable to me.

[callahad]

The make-us-fast-crew will take responsibility for this. The big concern is a botched deployment that requires a rollback: we don't want users to be stuck for 2-6 hours.

Initial idea: 2-6 hours of caching normally. Drop to no-cache the day of a deploy. Once we're happy with stability, reinstate 2-6 hours of caching. This will require coordination / codevelopment with ops, so it may take us a few cycles before this is actually resolved.

[lloyd]

/cc @Gene @zach

On Oct 11, 2012, at 11:24 AM, Dan Callahan notifications@github.com wrote:

The make-us-fast-crew will take responsibility for this. The big concern is a botched deployment that requires a rollback: we don't want users to be stuck for 2-6 hours.

Initial idea: 2-6 hours of caching normally. Drop to no-cache the day of a deploy. Once we're happy with stability, reinstate 2-6 hours of caching. This will require coordination / codevelopment with ops, so it may take us a few cycles before this is actually resolved.

—
Reply to this email directly or view it on GitHub.

[callahad]

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!