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

From: Mark Nottingham <[email-masked]>
Date: Fri, 14 Nov 2008 18:46:52 -0800

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/

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 15 Nov 2008 13:34:22 -0800

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

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

>> (such as those for ordering merchandise), the protocol requires  
>> that transparency be relaxed
>>
> 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).
>
> heuristic freshness algorithm is used. While the information that  
> the cache is disconnected or that revalidation failed is potentially  
> 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.
>
> 5) The concept of 'semantic transparency' be re-specified as  
> applying to intermediaries, not caches.
>
>
> --

---

From: David Morris <[email-masked]>
Date: Sat, 15 Nov 2008 20:13:46 -0800 (PST)

I'm opposed to any proposal to remove a requirement for making warnings
available to end users. I don't want to turn this into a GUI design
exercise. My choice of the phrase "making warnings available" was chosen
to indicate that it is the user agent's designers choice as to how this
is accomplished.

I have spent way to many hours debugging web based applications where most
of that time was spent finding a tool which would let me see what was
really happening. Removing the requirement for providing potentially
useful diagnostic information goes against all of my long held beliefs
related to the design of robust systems. In some future effort, I'd
love to see a comprehensive system for reporting errors back to origin
servers with enough context information that the server owner might
actually be able to identify and fix the problem.

Dave Morris