Re: NEW ISSUE: The role of Warning and Semantic Transparency in Caching

Now #138; http://trac.tools.ietf.org/wg/httpbis/trac/ticket/138


On 14/11/2008, at 6:46 PM, Mark Nottingham wrote:

>
> Part 6 (Caching) makes warning one of the pivotal features that  
> provide semantic transparency in HTTP caching;
>
>> Requirements for performance, availability, and disconnected  
>> operation require us to be able to relax the goal of semantic
>> transparency. The HTTP/1.1 protocol allows origin servers, caches,  
>> and clients to explicitly reduce transparency when necessary.  
>> However, because non-transparent operation may confuse non-expert  
>> users, and might be incompatible with certain server applications  
>> (such as those for ordering merchandise), the protocol requires  
>> that transparency be relaxed
>>
>>      - only by an explicit protocol-level request when relaxed by  
>> client or origin server
>>
>>      - only with an explicit warning to the end user when relaxed  
>> by cache or client
>
> In particular, any of several conditions (e.g., transforming  
> content, using stale responses, failure to revalidate) invokes a  
> requirement upon caches to generate a Warning header. User-Agents  
> are then required to make these Warnings apparent to the end user.  
> Additionally, there are some places where direct notifications to  
> the end user are required, as well as relaxation of MUST-level  
> requirements, upon the condition that the end user is warned  
> (leading to situations where 2616 allows a strongly-stated MUST NOT  
> to be violated; e.g., must-revalidate).
>
> The issue is that very few cache and intermediary implementations  
> (approaching zero) generate Warning headers, and very few user-agent  
> implementations (again, approaching if not at zero) display warnings  
> to users.
>
> As a side note, Warning headers carry very little unique information  
> that's relevant to end users; if the response is stale, this can be  
> determined from examining expiry and Age headers; likewise if a  
> heuristic freshness algorithm is used. While the information that  
> the cache is disconnected or that revalidation failed is potentially  
> interesting to automated agents, it is seldom useful to end users.
>
> Furthermore, "Semantic Transparency" muddles together the roles of  
> intermediaries and caches; while primarily defined in the caching  
> section of the specification, it is more appropriate to discuss it  
> in the context of intermediaries only. Cache-specific transparency  
> is adequately covered by existing requirements.
>
> Therefore, I propose that:
>
> 1) Text regarding displaying warnings to end users be removed, and
> 2) Requirements for generating Warning headers be relaxed, *except*  
> those around transformation, and
> 3) Requirements that relax other requirements if the end user is  
> informed (such as that for must-revalidate) be removed, and
> 4) Adding a requirement that caches SHOULD NOT serve stale content  
> except when explicitly allowed, or disconnected, and
> 5) The concept of 'semantic transparency' be re-specified as  
> applying to intermediaries, not caches.
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>


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

Received on Saturday, 15 November 2008 21:35:04 UTC