Re: HTTP/1.1 Issue: max-age in responses not defined

>>   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-cachable in order to retain compatibility with HTTP/1.0 servers.
>    ^^^^^^^^^^^^
>
>Eek!  This is a completely new SHOULD as far as I can see.

Actually, it is an old SHOULD that was discarded when the big caching
changes were made to Expires.  It reflects what was in HTTP/1.0.

>I oppose adding this SHOULD because it leads to sub-optimal caching.  I
>don't see any need to be compatible with the `Many HTTP/1.0 cache
>implementations' the paragraph talks about.  I consider these `many
>implementations' to be sub-optimal, because they should be using I-M-S to
>revalidate the stale entry instead of just throwing it away.

The only way to obtain optimal caching is to use Cache-Control, or no
Expires at all.  This paragraph would only apply when it is clear that
an older, RFC 1945-compliant origin server is attempting to force proxies
not to cache a message.  The changes to Expires from RFC 1945 to 2068
removed those semantics, but in so doing created an incompatibility between
HTTP/1.0 and HTTP/1.1, which by definition is an error in the new protocol.

The only significant effect on HTTP/1.1 caching will be the prevention of
caching messages from HTTP/1.0 servers that are clearly intended to not be
cachable.

>Also, this new SHOULD contradicts the Expires section:

That would be changed as well.

.....Roy