diff options
author | Timo Tijhof <krinklemail@gmail.com> | 2016-09-02 15:44:59 -0700 |
---|---|---|
committer | Krinkle <krinklemail@gmail.com> | 2016-09-02 23:07:12 +0000 |
commit | 6fa1e56daa33273f3fba97a70be79f7d151c8470 (patch) | |
tree | 8f0b0994a2cd77c70ebfe26023ad82cc68101f98 /tests/phpunit/includes/filerepo/file/FileTest.php | |
parent | a0c9fb59a934a3e7d9f31f249ab0b2b923f49db7 (diff) | |
download | mediawikicore-6fa1e56daa33273f3fba97a70be79f7d151c8470.tar.gz mediawikicore-6fa1e56daa33273f3fba97a70be79f7d151c8470.zip |
resourceloader: Shorten cache expiry if 'version' query doesn't match
Versioned load.php requests (load.php?modules=..&version=..) are highly
cacheable due to being versioned. When a module changes, the startup module
delivers new metadata to the client which naturally results in a cache miss
by producing a different url.
However, during upgrades and other deployments it was possible for a
multi-server installation to pollute edge caches with outdated content
in the following scenario:
* Deployment starts for an upgrade from version A to version B.
* Server 1 (on version B) gets a request for the startup manifest.
Client receives new manifest with version B information
and makes a versioned request for version B.
* Server 2 (still on version A) responds to this request with the
version it has (which is version A).
* Edge cache will store version A under the new url for version B.
This commit changes the last point by setting a low max-age when a request
has a 'version' hash mismatch.
Test plan:
* Look for a request in your browser like:
'/load.php?..modules=jquery%2Cmediawiki..&version=..'
* Verify it has a high Cache-Control max-age.
* Manipulate the 'version' parameter and verify it gets a low max-age.
Bug: T117587
Change-Id: Iba89c09b7b71d9fd2a8ff3ebe2618e26ea9daddf
Diffstat (limited to 'tests/phpunit/includes/filerepo/file/FileTest.php')
0 files changed, 0 insertions, 0 deletions