W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

Re: On transparency

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Sun, 25 Feb 1996 03:09:10 -0800
To: Koen Holtman <koen@win.tue.nl>
Cc: http-caching@pa.dec.com
Message-Id: <9602250309.aa14050@paris.ics.uci.edu>
> Only "never check" would be non-compliant.  And the state management
> subgroup _needs_ it to be non-compliant with HTTP/1.1, because you
> can't reliably use cookies to build stateful services under the `never
> check' behavior.

It is certainly true that cookies may get messed up when any recipient
is in "never check" mode.  However, making "never check" non-compliant
would not make cookies any more reliable, because the "never check" mode
is more important than HTTP compliance.  The only thing we can do is
make it clear to the user when semantic transparency is necessary for
correct behavior.

> Actually, you _can_ reliably use cookies under the `never check'
> behavior, by using various `cache busting' techniques that have a
> disastrous impact on the efficiency of all caches.  Anyway, I've said
> this many times before.

Assuming the server is still using cache-control, this has no more
impact on "all caches" than does using cookies.

> As someone who implements stateful services, I could live with `never
> check' being allowed under HTTP/1.1, _but only_ if the user agent
> signals this to my server, so that I can give the user an appropriate
> warning message:
> 
>  `Please enable document verification in your browser caching setup,
>   as the correct working of this service depends on it'.

So you want something from the client, like max-stale.

>>Shel is wrong.  The problem is in his own application assuming that
>>the user will always want a stateful session.
> 
> His application can assume that the user wants a stateful session,
> because his application is about filling a shopping basket with books,
> which is inherently stateful.

No, his application is about selling books; it is only stateful because
that is how he wants the user to interact with the site.  It is not true
that all possible ways to interact with a site must be equally supported
by all users of HTTP.  A user that doesn't want stateful interaction
should be given that choice.

> OK, now for a constructive proposal.
> 
> If you insist that HTTP/1.1 must make it legal for user agents and
> proxy caches to ignore a Cache-Control response header, then I insist
> that user agents and proxies always warn origin servers about doing so
> by including a particular header in every request:

Nope -- it would just be abused by service providers.  Besides, the user
may change settings after the request is made.  Why not just send a
Warning header in a response to any request containing max-stale?

NOTE TO JEFF:

   I do not believe that any change to the name "max-age" is acceptable,
   given that it DOES mean the exact same thing on both request and response.
   That means that "fresh-min", "fresh-life", whatever is NOT acceptable
   to me.

   Likewise, "stale-max" is backwards -- it should be "max-stale",
   with no =NN meaning infinity (i.e., "never check").  That would meet
   my criteria for not requiring HTTP applications to be non-compliant.


 ...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 Sunday, 25 February 1996 11:27:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC