#19768 [Csd]: Expires header incorrectly set, cannot be overwritten

ID: 19768 User updated by: php at savignano dot de Reported By: php at savignano dot de Status: Closed Bug Type: Session related Operating System: Win32, Unix PHP Version: 4.2.1 New Comment: Very well explained, shiflett@php.net - I see your point, and I have to admit that now this behaviour seems correct to me, too. Thank you! Previous Comments: ------------------------------------------------------------------------ [2003-04-07 13:36:47] shiflett@php.net I do not think it has been explained very well yet, but PHP's behavior appears to be correct. The use of an Expires header with an expired date is to ensure backwards compatibility with HTTP/1.0 agents. Since Cache-Control is new, changing the value from nocache to private (or anything else) makes no difference with older agents that ignore it completely. However, for HTTP/1.1 agents, the Cache-Control directives override the Expires header, so that fine-tuned caching is possible. For more information, look at section 14.9.3 of RFC 2616. Here is the most relevant part: "If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks. "Many HTTP/1.0 cache implementations will treat an Expires value that is less than or equal to the response Date value as being equivalent to the Cache-Control response directive "no-cache". If an HTTP/1.1 cache receives such a response, and the response does not include a Cache-Control header field, it SHOULD consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers. "Note: An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network including older caches that do not understand that feature. The origin server will need to combine the new feature with an Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching the response." ------------------------------------------------------------------------ [2002-11-01 09:26:36] php at savignano dot de Judging from http://www.w3.org/Protocols/HTTP/1.0/spec.html#Expires the Expires header was the intended header in HTTP/1.0 for cache control. I do not understand why you say, a past header should be sent instead of a correct date. header() doesn't enable me to replace an Expires header, as stated in my original report. ------------------------------------------------------------------------ [2002-10-28 23:23:03] yohgaki@php.net Since HTTP/1.0 lacks cache control feature can be found in HTTP/1.1, past date expire header should be sent. It's not a bug, but a intended behavior for HTTP/1.0 clients. See also header() manual page to replace header, but add new one. ------------------------------------------------------------------------ [2002-10-26 11:23:15] php at savignano dot de Also see my detailed comment on bug #5415 http://bugs.php.net/bug.php?id=5415 ------------------------------------------------------------------------ [2002-10-26 11:08:26] php at savignano dot de I did use "private", but this causes incorrect Expires headers as described. That's why I switched to "none" and created the headers myself. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/19768 -- Edit this bug report at http://bugs.php.net/?id=19768&edit=1