Solution to 304's not working with version 1.4.6
-
When running supercache 1.4.6, I was not getting 304 responses even though I had that option selected.
wp-cache-phase1.php uses a default int value of zero for $remote_mod_time on line 240
line 243 contains this test (potentially comparing a string to an int):
$remote_mod_time != 0Since php tries to turn the $remote_mod_time string into an int (and in this case into a zero), I was never getting the 304 header.
I worked around this by changing the default 0 into a string ‘0’ by wrapping it with single quotes.
So line 240 becomes:
$remote_mod_time = ‘0’;
And line 243 becomes:
if ( $remote_mod_time != ‘0’ && $remote_mod_time == $local_mod_time ) {With that in place, the server began responding with 304’s when the browser had an up to date client cached copy of a super cached file.
But Fiddler Tool then reported a protocol violation as the 304 response had a zero sized body (good) and a non-zero Content-Length header (violation)
So I added a new line 245 to set the content-length header to zero when the response was a 304. The section of code now looks like this:
243 if ( $remote_mod_time != '0' && $remote_mod_time == $local_mod_time ) { 244 header("HTTP/1.0 304 Not Modified"); 245 header( 'Content-Length: 0'); //304's are always zero length 246 exit();
Hopefully this will help anybody noticing the same behavior and maybe make it into the next release/version.
- The topic ‘Solution to 304's not working with version 1.4.6’ is closed to new replies.