tentative patch for browser-cache problem
-
What do you think of the following change to the “Disk-Enhanced” page-caching code?
In Generic.php, function _read(), in the return statement (line 163 in trunk):
//'time' => null, // BEFORE 'time' => @filemtime($path), // AFTER
Explanation: Currently, the code always returns a null timestamp for cached files. With a null time-value, if the site has “Browser Caching” enabled with the “Last-Modified” option, then the “Last Modified” response header will always be set to January 1, 1970 (i.e. the beginning of Unix time, sometimes seen when evaluating an uninitialized/null date variable). When a user revisits the page with this “Last-Modified” value, his browser will usually try to send this 1/1/70 date in the “If-Modified-Since” request header, unless he does a force-refresh. This value will always match the null-date in <b>_check_modified_since()</b> in PgCache.php. As a result, a 304 (not modified) response will always be returned, even if the cached file has been updated.
With the above change, the “Last-Modified” header should instead get the cached file’s timestamp, which the user’s browser may later send in the “If-Modified-Since” header. In response, a 304 will be sent only if the cached file has the same timestamp. Otherwise, presumably the cached file has been updated (following publish or cache purge), so the new content should be sent instead, with a new Last-Modified date.
Does this analysis make sense? (Apologies in advance: the poster is not a WordPress or W3TC expert, nor has he investigated other possible consequences of this change.)
Thanks for your time.
- The topic ‘tentative patch for browser-cache problem’ is closed to new replies.