session_cache_control('none') was meant to read session_cache_limiter('none'). Sorry.

The default value 'nocache' means that the page should not be cached at all. Have a look at php.ini-dist, you probably want  to set session.cache_limiter to 'private'.

There seems to be a misunderstanding:

Using session_cache_limiter("private") will create the malformed Expires headers mentioned in my bug report.

I did use "private", but this causes incorrect Expires headers as described. That's why I switched to "none" and created the headers myself.

Also see my detailed comment on bug #5415
http://bugs.php.net/bug.php?id=5415

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.

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.

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."

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!