Page MenuHomePhabricator

ResourceLoader should not respond with HTTP 304 without Expires (and other) headers
Closed, ResolvedPublic


Author: davidt-mediawiki-bugz

There are two code paths that can lead to ResourceLoader.php calling tryRespondLastModified:


if ( $wgUseFileCache )




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

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.

See Also:



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:51 AM
bzimport set Reference to bz51283.
bzimport added a subscriber: Unknown Object (MLST).

Change 74400 had a related patch set uploaded by Catrope:
Always send headers with a 304 response in ResourceLoader

Could this be the root cause of bug 51766 as well?

Krinkle updated the task description. (Show Details)
Krinkle added a project: Performance Issue.
Krinkle set Security to None.
Krinkle moved this task from Inbox to Assigned on the MediaWiki-ResourceLoader board.
Krinkle removed a subscriber: Unknown Object (MLST).