Last modified: 2013-06-18 15:07:23 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 T27744, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 25744 - Figure out why Firefox disobeys caching headers from RL, test cacheability of RL responses in other browsers
Figure out why Firefox disobeys caching headers from RL, test cacheability of...
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
All All
: High enhancement (vote)
: ---
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-01 20:43 UTC by Roan Kattouw
Modified: 2013-06-18 15:07 UTC (History)
4 users (show)

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


Attachments

Description Roan Kattouw 2010-11-01 20:43:10 UTC
Per summary
Comment 1 Mark A. Hershberger 2011-02-09 01:30:31 UTC
Trevor? Roan? anything to do here?
Comment 2 Laurence 'GreenReaper' Parry 2011-03-27 01:46:15 UTC
I found I had to add this to LocalSettings.php because the main skin CSS and the startup script didn't have a version on:

# Force ResourceLoader to serve unversioned resources for 30 days as well (normally 5 min)
$wgResourceLoaderMaxage['unversioned'] = array('server' => 30 * 24 * 60 * 60, 'client' => 30 * 24 * 60 * 60);

Without it Firefox 4 was attempting to retrieve them every time. They're still not sent with a content-length, which seems wrong, but at least it doesn't do that.
Comment 3 Roan Kattouw 2011-03-27 13:59:56 UTC
(In reply to comment #2)
> I found I had to add this to LocalSettings.php because the main skin CSS and
> the startup script didn't have a version on:
> 
> # Force ResourceLoader to serve unversioned resources for 30 days as well
> (normally 5 min)
> $wgResourceLoaderMaxage['unversioned'] = array('server' => 30 * 24 * 60 * 60,
> 'client' => 30 * 24 * 60 * 60);
> 
> Without it Firefox 4 was attempting to retrieve them every time. They're still
> not sent with a content-length, which seems wrong, but at least it doesn't do
> that.
That's not a proper fix, as it will make invalidations (updates to JS/CSS) take unreasonably long.

(In reply to comment #1)
> Trevor? Roan? anything to do here?
I logged this as a TODO a long time ago to investigate caching behavior, but I don't think I'm gonna get to it soon.
Comment 4 Laurence 'GreenReaper' Parry 2011-03-27 18:05:18 UTC
> That's not a proper fix, as it will make invalidations (updates to JS/CSS)
> take unreasonably long.

Well, if they can change, why are they being sent without a version or date in the first place? :-)
Comment 5 Roan Kattouw 2011-03-27 18:21:29 UTC
(In reply to comment #4)
> > That's not a proper fix, as it will make invalidations (updates to JS/CSS)
> > take unreasonably long.
> 
> Well, if they can change, why are they being sent without a version or date in
> the first place? :-)
Because the version parameter would be embedded in HTML and be cached in Squid otherwise.

The version parameter has two uses. First, its presence indicates that the request can be cached for 30 days (5 minutes if absent). Second, changing its value will cause a cache miss (since the URL is different). The idea here is that the startup module lists the last-changed timestamps for each module, which we then use to build the versioned URLs. This way, the startup module is refreshed every 5 minutes and the other modules are only refreshed when they've changed (or after 30 days).
Comment 6 Roan Kattouw 2011-08-13 09:08:19 UTC
This seems fine now, I'm no longer seeing any caching weirdness in Firefox.

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


Navigation
Links