On Wed, Nov 28, 2012 at 4:21 PM, Chad innocentkiller@gmail.com wrote:
On Wed, Nov 28, 2012 at 6:48 PM, Luke Welling lwelling@wikimedia.org wrote:
Is there a reason not to use the Yahoo championed approach of embedding a version number in all static file names so you can set a very long cache expires time and just add new versions to the CDN when a change is made?
That's what we used to do for CSS/JS--but we don't serve individual files like that anymore--they're all served together via the resource loader.
ResourceLoader actually uses a somewhat more advanced version of the
version-number-in-filename approach: it dynamically computes the last modified timestamp of the collection of resources it's requesting, and puts that timestamp in the query string. If the timestamp is not available dynamically, we omit the timestamp, and RL automatically serves the resource with a short cache timeout (5 min) in that case.
Also, it wouldn't have helped much in this case--the problem was that the HTML/CSS output changed in an incompatible way and we had old (or new, during the rollback) versions of the HTML still being served via Squid (they're cached for 30 days, unless something purges them like an edit).
"Don't change the HTML in incompatible ways" is probably a good general rule to live by--but having an easy way to say "start purging all pages on $theseWikis from Squid/Varnish" would also be nice.
Yes, the HTML and CSS changed in incompatible ways. The CSS cache
invalidated quickly (5-10 mins probably), but the HTML cache didn't. Platonides probably misspoke when he said "cached (skin) CSS had <h5>"; I'd imagine it was the Squid-cached HTML instead.
Either way, the CSS should be backwards-compatible with the old HTML, and in this case it wasn't. That's the core of the problem.
Roan