Transparency vs. Performance: survey of opinion

An issue that has been debated with vigor in the caching subgroup is
one of of "transparency vs performance".

Jeff Mogul summarized the sense of the subgroup as:

> 	Applications in which HTTP is used span a wide space
> 	of interaction styles.  For some of those applications,
> 	the origin server needs to impose strict controls on
> 	when and where values are cached, or else the application
> 	simply fails to work properly.  We referred to these
> 	as the "corner cases".  In (perhaps) most other cases,
> 	on the other hand, caching does not interfere with the
> 	application semantics.  We call this the "common case".
> 	
> 	Caching in HTTP should provide the best possible
> 	performance in the common case, but the HTTP protocol MUST
> 	entirely support the semantics of the corner cases, and in
> 	particular an origin server MUST be able to defeat caching
> 	in such a way that any attempt to override this decision
> 	cannot be made without an explicit understanding that in
> 	doing so the proxy or client is going to suffer from
> 	incorrect behavior.  In other words, if the origin server
> 	says "do not cache" and you decide to cache anyway, you
> 	have to do the equivalent of signing a waiver form.
> 
> 	We explicitly reject an approach in which the protocol
> 	is designed to maximize performance for the common case
> 	by making the corner cases fail to work correctly.

To which Roy Fielding replied:

>   Let me again say that I adamantly oppose this decision.  It doesn't
>   reflect any of the applications that currently use HTTP, it is a
>   mythical invention of the subgroup that such a thing is even
>   desirable in all cases, and does a poor job of satisfying the
>   user's needs.

>   The reason that user agents are not always semantically transparent
>   is because the user does not always want them to be semantically
>   transparent.  No matter what is in the protocol, no decision by the
>   WG will ever change this fact of life.  It is therefore WRONG to
>   require in the protocol what cannot be achieved by any application
>   -- all you are doing is requiring applications to be
>    non-compliant.

>   What you want is to enable the protocol to say "this is what you
>   have to do to remain semantically transparent" and then require
>   that applications default to semantic transparency mode.  The
>   former is what Cache-control does, and the latter can be added to
>   the text.

>   What we cannot do is control the user's application of HTTP
>   technology; attempting to do so is foolish and contrary to the
>   design of the Web.  Requiring a visible/noticeable warning be
>   presented when semantic transparency is disabled is reasonable,
>   provided that it does not actively interfere with people's work.


The discussion has been wide-ranging, but I believe that those present
at the Caching subgroup meeting and subsequently on the mailing list, 
Shel Kaplan, Koen Holtman (and, for that matter, myself) agreed with
Jeff's summary and disagreed with Roy's point of view.

Rather than continuing to go back and forth on this issue in
http-caching, I thought perhaps we could just get this out into the
full HTTP-WG and see if there is anyone other than Roy who support's
Roy's point of view here.

This seems to be a fundamental issue which affects many other parts of
the HTTP protocol with regard to caching, and unless we get beyond
this, we'll have trouble.

Those who want to follow the argument in more detail can check the
caching subgroup mail archive at:

	http://www.roads.lut.ac.uk/lists/http-caching

and in particular the thread starting

	http://weeble.lut.ac.uk/lists/http-caching/0342.html

Received on Sunday, 25 February 1996 18:52:07 UTC