Last modified: 2008-05-05 03:34:18 UTC
If any change done to site CSS or JS it does not apply at all. I've tried to do all the purge methods I know, cleared all caches, tried in 10 different browsers, nothing worked. So far I seen on #mediawiki, #wikimedia-tech and some other channels, other users have similar problems as well. This is pretty big problem because it causes users can't use new CSS/JS features, which is really way so annoying. It used to be able just to simply reload the CSS/JS page to load the new script and it was available at the moment.
This is due to 27456 forcing a server-side cache (set to 5 minutes on Wikimedia) to all raw pages (all User/Site Css/JS). This was apparently done by domas so that anonymous users who shift-reload pages all the time (why??) would not re-request all the raw pages from the apache back-ends every time. Due to this, it is impossible to reload a squid-cached URL before it expires, and it also cannot be purged. The only way to guarantee a cache miss is by changing the URL. I've seen a dozen user complaints about this already, and personally experienced a frustrating edit session of my user/monobook.js, taking 5 minutes to load each change. This should be reverted until a solution is found to address the agressive caching of user and site-wide css/js. Perhaps a dummy URL parameter reflecting the last edit of the page, or a squid parameter fragment like &purgeme that would purge the preceeding URL minus the fragment, or a rawpurge=true sent via POST.
> This is due to r27456 (linky)
Someone did something sometime in February that pretty much fixed this bug at the squid level (tim, brion or domas IIRC). The problem was in a hack that prevented the servers recognizing "Pragma: No-cache" headers from clients, making all pages hard-cached for up to 5 minutes. Or something.
