W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 2000

Re: Question for HTTP/1.1 cache implementors (both proxy & client caches)

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Wed, 19 Apr 2000 16:02:33 -0700
To: Jeffrey Mogul <mogul@pa.dec.com>
cc: http-wg@hplb.hpl.hp.com
Message-ID: <200004191602.aa19350@gremlin-relay.ics.uci.edu>
>Finally, when RFC2616 is revised to move from Draft Standard
>to Full Standard, would anyone object to clarifying the language
>in 14.9.3?  For example, replacing:
>
>   The max-age directive on a response implies that the
>   response is cacheable (i.e., "public") unless some other, more
>   restrictive cache directive is also present.
>
>with
>
>   The max-age directive on a response implies that the
>   response is cacheable (i.e., "public") unless some other, more
>   restrictive cache directive is also present.  If a more
>   restrictive cache directive (such as "no-cache" or "no-store")
>   is present, the cache MUST ignore the max-age directive;
>   this supports extensibility using the mechanism described
>   in section 14.9.6.
>
>and perhaps also, under "s-maxage":
>
>   If a more restrictive cache directive is present, the cache
>   MUST ignore the s-maxage directive.
>
>for the same reason.

Wouldn't that become a contradiction with the extension scheme?
In other words, that requirement along with your example of

      Cache-Control: no-store, community="UCI", max-age=30

would require that the recipient ignore max-age even if it did
understand the community extension.  I think that is why we decided
to use relative constraints rather than absolute constraints in the
language above.

....Roy
Received on Thursday, 20 April 2000 00:03:59 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:36 EDT