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

See <http://www.w3.org/mid/A248E415-4DA9-494F-AC1B-427C3CE028F3@mnot.net>. Defining cacheability for each individual status code is not a simple thing.


On 09/03/2010, at 2:33 AM, Brian Smith wrote:

> 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
> 


--
Mark Nottingham     http://www.mnot.net/

Received on Tuesday, 9 March 2010 09:31:55 UTC