Re: LAST CALL on MAX-AGE issue
Roy T. Fielding (fielding@kiwi.ics.uci.edu)
Sat, 19 Jul 1997 09:44:44 -0700
Looks good to me.
....Roy
In message <9707190116.AA23026@acetes.pa.dec.com>, Jeffrey Mogul writes:
>(1) I think this note (in Roy's proposal)
>
> Note: An origin server wishing to use a relatively new HTTP cache
> control feature, such as the "private" directive, on a network
> that includes older caches which do not understand that feature,
> will need to combine the new feature with an old Expires value
> in order to prevent the older caches from caching the response.
>
>could be made slightly clearer:
>
> Note: An origin server wishing 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, 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.
>
>(2) I think it would be a good idea to include after the last
>paragraph of this section (14.9.3):
>
> If a cache returns a stale response, either because of a max-stale
> directive on a request, or because the cache is configured to
> override the expiration time of a response, the cache MUST attach a
> Warning header to the stale response, using Warning 10 (Response is
> stale).
>
>the following note:
>
> Note: A cache may be configured to return stale responses
> without validation, but only if this does not conflict with any
> MUST-level requirements concerning cache validation (e.g., a
> "must-revalidate" Cache-control directive).
>
>In a private email discussion during March, Roy pointed out that
>this is said elsewhere in the specification. However, I'm concerned
>that some implementors may misconstrue the discussion in 14.9.3
>without such a reminder.
>
>-Jeff
>