304 page caching

Heya,

Super Cache does not seem to be returning HTTP403 Not Modified when the page has not been modified

Request Headers

GET /a/b/c/ HTTP/1.1
Host: www.XXX.local
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://XXX.local/a/b/c/
Cookie: _ga=GA1.2.2009775145.1461832283; _gat=1
Connection: keep-alive
If-Modified-Since: Thu, 28 Apr 2016 09:02:02 GMT

Response Headers

HTTP/1.1 200 OK
Date: Thu, 28 Apr 2016 09:02:31 GMT
Server: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.4.16
Vary: Accept-Encoding,Cookie
X-Powered-By: PHP/5.4.16
Cache-Control: max-age=3, must-revalidate
WP-Super-Cache: Served supercache file from PHP
Content-Encoding: gzip
Content-Length: 12430
Last-Modified: Thu, 28 Apr 2016 09:02:02 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

Scenario: The client has a browser-cached version of the page. The client requests a copy of the same page, and lets the server know that it has got a locally cached copy of the file. The page has not been updated, so the locally cached version is still valid. (dated “Thu, 28 Apr 2016 09:02:02 GMT”)

Expected: The page was last modified on that same date, so the WP Super Cache returns a HTTP304 without payload., forcing the client to re-use its browser-cached version.
Actual: WP Super Cache returns a HTTP200, bypassing the browser-cache.

I’ve disabled all other plugins and themes, and I’m running the latest version of the plugin to date (1.4.8)

I’ve dug into the plug-in code and found the line that’s causing the issue:

website/wp-content/plugins/wp-super-cache/wp-cache-phase1.php:242
The below line needs to changed:
FROM
if ( $remote_mod_time != 0 && $remote_mod_time == $local_mod_time ) {
TO
if ( $remote_mod_time && $remote_mod_time == $local_mod_time ) {

This ensures $remote_mod_time is set, and does not cast it to int (read more about casting here: https://stackoverflow.com/questions/6843030/why-does-php-consider-0-to-be-equal-to-a-string)

Is there any chance we could have this fix included in the next release?

Thanks
Laurent