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

Roy T. Fielding:
>   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.

Koen Holtman:
    Eek!  This is a completely new SHOULD as far as I can see.

    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.
    
One goal for HTTP/1.1 is that it not break any HTTP/1.0 implementations.
The HTTP/1.0 not-quite-specification (RFC1945) says, for "Expires"

	Applications must not cache this entity beyond the date given.

I.e., the HTTP/1.0 interpretation here is a MUST, and we are actually
relaxing it by saying "SHOULD".

Lest one think that this is some newfangled thing in RFC1945, I
went back to earlier texts for "Expires".  Back in March, 1995,
draft-ietf-http-v10-spec-00.txt said 

   Caching clients (including proxies) 
   must not cache this copy of the resource beyond the date given, 
   unless its status has been updated by a later check of the origin 
   server.

(which is probably clearer than the RFC1945 wording).  Going back
even further, to November 1993, draft-ietf-iiir-http-00.txt said
that "Expires"

   Gives the date after which the information given ceases to be valid
   and should be retrieved again.

(whether this "should" is a SHOULD or a MUST isn't clear, since
the term "should" is often used in this document in places where
we would almost certainly use MUST today.)

Aside from that, this probably does not pose a serious threat
to cache performance.  On the other hand, it could probably
be worded better.  How about something like this:
    Many HTTP/1.0 servers expect caches to 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 NOT use the response in
    reply to a subsequent query without first revalidating it.

I.e., while "max-age=0" does not imply "must-revalidate", "expires now"
does.

    Also, this new SHOULD contradicts the Expires section (14.21):

    The Expires entity-header field gives the date/time after which the
    response should be considered stale. A stale cache entry may not
    normally be returned by a cache (either a proxy cache or an user
    agent cache) unless it is first validated with the origin server [...]
    
Not as I reworded it.  Note that the word "cachable" is used a little
too informally in HTTP/1.1 (RFC2068).  The definition is

   cachable
      A response is cachable if a cache is allowed to store a copy of
      the response message for use in answering subsequent requests. The
      rules for determining the cachability of HTTP responses are
      defined in section 13. Even if a resource is cachable, there may
      be additional constraints on whether a cache can use the cached
      copy for a particular request.

I believe what Roy meant by "non-cachable" is "not usable without
revalidation", not "not storable".

-Jeff

Received on Monday, 31 March 1997 16:49:36 UTC