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

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

On Sat, 15 Nov 2008, Mark Nottingham wrote:

>
> 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 Sunday, 16 November 2008 04:14:58 UTC