[wp-trac] [WordPress Trac] #23021: Last-Modified header always set to 1970... when it is blank. Make browser cannot refresh cache.

[WordPress Trac]

#23021: Last-Modified header always set to 1970... when it is blank. Make browser
cannot refresh cache.
--------------------------+--------------------
 Reporter:  slene         |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.5.1
Component:  General       |     Version:  3.5
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |
--------------------------+--------------------

Comment (by nacin):

 [attachment:23021.4.diff] is the direction I think I want to go, after a
 long conversation with andy (who contributed #22258 and knows far more
 than I about insane caching setups).

 It is basically [attachment:23021.5.diff] but it does some extra effort to
 verify that absolutely no Last-Modified header is sent. Basically, it
 revokes a Last-Modified header if it is sent by other means (a plugin, for
 example). In 5.3, that's easy with header_remove().

 In 5.2, we would continue to use `header('Last-Modified:')` as it is the
 best option, if imperfect. It is better than letting a Last-Modified
 header sneak through (intended for a cached resource, presumably). It is
 better than the current time based on Chrome's aggressive caching as
 reported in #22258. And, I think problems in Chrome outweigh problems on
 certain server setups, especially when updating to PHP 5.3 fixes it.

 In WP 3.4, we always sent (and replaced) the Last-Modified header, which
 is what I think we should continue to do. In 3.5, we always sent an empty
 Last-Modified header in PHP 5.2. With the patch, we'll now only send an
 empty Last-Modified header to override an existing Last-Modified header,
 as a last resort.

 I think this is good for 3.5.1. Thoughts?

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23021#comment:10>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software