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

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/

Received on Saturday, 15 November 2008 02:47:31 UTC