https://bugzilla.wikimedia.org/show_bug.cgi?id=51283
Web browser: ---
Bug ID: 51283
Summary: 304 response sent without Expires (and other) headers
Product: MediaWiki
Version: 1.22-git
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: Unprioritized
Component: ResourceLoader
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected]
Classification: Unclassified
Mobile Platform: ---
There are two code paths that can lead to ResourceLoader.php calling
tryRespondLastModified:
ResourceLoader::respond
if ( $wgUseFileCache )
ResourceLoader::tryRespondFromFileCache
ResourceLoader::sendResponseHeaders
ResourceLoader::tryRespondLastModified
or
ResourceLoader::respond
tryRespondLastModified
Only one of these paths calls ResourceLoader::sendResponseHeaders.
The other path will set a HTTP 304 status and Status: 304 header, but no other
headers. The lack of the Expires header in particular causes a variety of odd
problems when using (at least) mod_proxy/mod_disk_cache as an apache-based
caching reverse proxy.
Using mod_proxy and mod_disk_cache from apache2 pre-2.2.18, this leads to the
proxy returning erroneous 304 responses to clients who sent unconditional
requests (see https://issues.apache.org/bugzilla/show_bug.cgi?id=45341).
After the fix/workaround added in 2.2.18, mod_proxy will now correctly send the
cached content back to the client, but will then immediately purge the page
from the cache, which is not ideal.
I fixed this locally by moving the call to sendResponseHeaders from the first
call path after the call to tryRespondLastModified, then adding a call to
sendResponseHeaders in tryRespondLastModified itself.
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
