Last modified: 2008-05-05 03:34:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T14775, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 12775 - Changes in global CSS/JS do not apply - unable to purge site CSS/JS
Changes in global CSS/JS do not apply - unable to purge site CSS/JS
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: High major with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: testme
Depends on:
Blocks: javascript css
  Show dependency treegraph
 
Reported: 2008-01-24 13:30 UTC by Danny B.
Modified: 2008-05-05 03:34 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Danny B. 2008-01-24 13:30:36 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.
Comment 1 Splarka 2008-01-24 13:39:39 UTC
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.
Comment 2 Splarka 2008-01-24 13:41:04 UTC
> This is due to r27456 (linky)
Comment 3 Splarka 2008-05-05 03:34:18 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links