nocache_headers fail to prevent aggressive caching in Chrome

[andy]

In Chrome 22, a response with a valid Last-Modified header will be cached despite Cache-Control and Expires headers. So even though the user is logged in, the resource is cached and the browser sends If-Modified-Since with subsequent requests. This can result in a strange, partially-logged out experience with batcache under certain conditions.

In wp_get_nocache_headers(), the Last-Modified header is set to the current time. Setting its value to the empty string resolves the issue.

I will post two patches: one which only empties the Last-Modified header in the array, another which also removes the header when the header_remove() function is defined (PHP >= 5.3).

[andy]

Empty Last-Modified

[andy]

Empty Last-Modified and remove header if PHP >= 5.3

[barry]

The same thing happens in Safari 6.0.1 as well.

[SergeyBiryukov]

Related: #21745

[nacin]

Looks good. Goes nicely with #21745.

[nacin]

Because there are filters in both wp_get_nocache_headers() and WP::send_headers(), here is an alternative patch.

[andy]

Replying to nacin:

Because there are filters in both wp_get_nocache_headers() and WP::send_headers(), here is an alternative patch.

I endorse this patch.

[nacin]

Only side effect of 22258.3.diff​ is it could remove a valid Last-Modified header that is not set by WP or via the wp_headers filter. I don't think this is an issue, but in the interest of CYA, two possibilities: the extra send_headers() logic andy has, or 22258.4.diff​.

[nacin]

RFC2616 doesn't say much about this, but some reading: ​http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-13#page-10. If the Date and Last-Modified headers are within 60 seconds (and they would be here, barring a server misconfiguration), it is considered a weak validator, because of potential timing inconsistencies; they are also considered weak for being only accurate to the second.

[nacin]

In [22283]:

Do not issue a Last-Modified header when issuing no-cache headers to avoid aggressive (webkit) caching. Serve a blank header when header_remove() is not available (PHP < 5.3). props andy. fixes #22258.

[ryan]

Do we want to silence header_remove() like we do header() to avoid "Cannot modify header information - headers already sent by..." messages? These are popping up all over the unit tests.

[andy]

Good catch, but the @-bandage wastes more dev time than a clean fix would. I would rather see core functions with header() calls do something smart like check headers_sent() and trigger_error().

[nacin]

Would probably be easiest if we just checked headers_sent() at the start of nocache_headers(), and in WP::send_headers(). There's no reason to error-suppress header() a half-dozen times when we can bypass it all together.

[nacin]

Though, @ isn't as bad, because if someone is using xdebug.scream or a custom error handler (including the Debug Bar), it doesn't get masked in the way headers_sent() would. At least it is consistent with our use of @header(), and we can possibly make changes later.

[sirzooro]

Replying to ryan:

Do we want to silence header_remove() like we do header() to avoid "Cannot modify header information - headers already sent by..." messages? These are popping up all over the unit tests.

Maybe it is good time to reconsider #21282 ?

[nacin]

In [22303]:

Avoid 'headers already sent' messages for header_remove() the same way we currently do with header(). props ryan. fixes #22258.

[slene]

In php5.2 the Last-Modified header always blank !!!

A response with a blank Last-Modified header will be set to "Thu, 01 Jan 1970 00:00:00 GMT" in some server. The browser will be always send a If-Modified-Since header "Thu, 01 Jan 1970 00:00:00 GMT". and the server response a 304 status code. Make the browser can not refresh cache.

sorry my bad english...

[SergeyBiryukov]

This ticket was closed on a completed milestone. If you believe there's a problem, please open a new one. That sounds like server misconfiguration though.