Last modified: 2013-08-14 12:09:43 UTC
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.
Change 74400 had a related patch set uploaded by Catrope: Always send headers with a 304 response in ResourceLoader https://gerrit.wikimedia.org/r/74400
Could this be the root cause of bug 51766 as well?