Re: On transparency

Jeff wrote:
> Caches exist to improve performance, and it's not zero-sum game.
> Users, servers, and intermediaries (such as Netcom or similar) can all
> benefit from caching, if it is done right.
> 
> However (and this is the point where you are manifestly wrong), caches
> do not exist independently of semantics.  Otherwise, I could write
> a cache that returns, say, a Dilbert cartoon, no matter what URL
> was requested.  That's obviously an extreme breakdown in semantics,
> but to say that the "user's needs" define the semantics of an HTTP
> interaction is so ill-defined as to be entirely useless.

That is nonsense.  If the user's needs are to see a Dilbert cartoon
every time, then the cache is acting correctly if it gives them a
Dilbert cartoon every time.  Naturally, you don't see that option
on many cache configuration menus, but I'm sure we could get Lou
to add one given an adequate number of good beers.  :-)

You do see, on EVERY caching browser known to me, the options
to "check once per session" and "never check".  Your summary of the
meeting consensus would make both those options non-compliant with HTTP/1.1.

At the same time, there is no reason why "semantic transparency" can't
be another caching option.

> Users DO have needs for things such as performance, availability,
> clarity of the UI, etc.  But these are entirely orthogonal to whether
> the semantics of a request-response interaction are those intended
> by the origin server or not.  In this respect, the user's primary
> "need" is that when he or she makes a request, the response has some
> semantically appropriate meaning.

That depends on the user's context.  When I make a request from home,
I want the minimum amount of network bandwidth to be consumed while
sustaining semantic transparency.  When I make the same request from work,
bandwidth is less of an issue. If I were to make the same request from my
cousin's house in Whangamata, then the number of network requests is
critical and thus never check is the only correct behavior.  If I make
the same request during a canned presentation in front of a huge audience,
then you can bet that I will have preloaded the cache and, again,
never check is the only correct behavior.

> If the Web were simply composed of static (or slowly changing) documents,
> then the semantics of HTTP interactions would be trivial and one could
> easily let the user decide exactly what to do.  But this is manifestly
> not the only thing the Web is used for, and probably no longer even the
> most prevalent.  At the meeting on Feb. 2, for example, Shel Kaphan made
> it quite clear that the worst problem he faced in implementing his
> book-ordering service was the plethora of user-agent and cache
> implementations that blithely assumed they could decide when and
> when not to use a cached copy of some response.

Shel is wrong.  The problem is in his own application assuming that
the user will always want a stateful session.  There is nothing that the
working group can do to change the needs of people who use HTTP, and one
of those needs is to cache responses regardless of the nature of those
responses.  You may indeed define semantic transparency, and even require
that semantic transparency be the default behavior for caching applications,
but you cannot require that HTTP applications ignore the user's needs.

The reason why this is a problem today is because cache's have to guess
about what the origin server wants.  The Cache-control header field
removes the need to guess, and thus will result in more reliable behavior
under normal circumstances.  Note, however, that normal circumstances are
always defined by the user.  The most that the protocol can do is carry
the information necessary for the cache to make the right decision about
how best to serve the user.

> I defy you to explain, for example, how Shel Kaphan can make his
> book-ordering server work in your user-wins model.

That's easy -- give the user an option at the outset regarding how
they would like to proceed.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Thursday, 22 February 1996 07:26:34 UTC