Re: What are "appropriate Cache-Control or Expires header fields"

Mark Nottingham wrote:
> I haven't heard any more feedback about this. AFAICT the only thing remaining in this issue<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/199>  is to adjust the language in p2-semantics that originally brought this up.
>
> I think we should:
>
> 1) Remove all reference to caching from the status code definitions in p2 (e.g., most of the 3xx, 410), relying on it to be covered by p6, and
> 2) Move the text that associates heuristic freshness with individual status codes out of p6 into the appropriate status code definitions in p2, and
> 3) Allow future status codes to identify themselves as allowing heuristic freshness (the current requirement in p6 is IMO too strict of a reading of 2616, looking at it again).
>
> Thoughts?
>    
The change you made in changeset 721 (adding "the response status is 
understood by the cache and defined as being cacheable") was good 
because every cacheable status code would be explicitly marked so. But, 
then changeset 737 made things really unclear--if a status code doesn't 
say anything about its cacheability, then is it cacheable or not? The 
added concept of "understanding" from Changeset 737 could (and should) 
be replaced by simple, explicit statements in the definition of each 
status code stating exactly what a cache is allowed to do with a 
response of that code--for example, "This is a cacheable-if-fresh status 
code" and "This is a heuristically-cacheable status code," and with the 
language in part 6 can be changed to "the status code is defined as 
being cacheable-if-fresh and the cached response is fresh [ref to 
standard freshness definintion], or the status code is defined as being 
hearistically-cacheable and the cached response is fresh according to 
the hueristic freshness calculation [ref to it]." These are the kinds of 
statements that implementors can directly use to create code without any 
potential for misunderstanding or disagreement amonst readers of the spec.

I will spend some time in the next day or two to create a proposal that 
uses this explicit approach if you are open to it.

Regards,
Brian

Received on Monday, 8 March 2010 15:34:19 UTC