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: Thu, 29 Feb 1996 04:40:11 -0800
To: Koen Holtman <koen@win.tue.nl>
Cc: http-caching@pa.dec.com
Message-Id: <9602290440.aa28311@paris.ics.uci.edu>
> My proposed header is basically a refined version of max-stale.  
> I would be happy with max-stale
>  1) if it can express any kind of `never check' mode we can imagine
>     now

I think it can, provided that no =NN means infinity.

>  2) if clients are required to send it if they may be planning to 
>     weaken caching rules.

"may be planning" is too weak -- it would apply to all browsers
all the time (and thus be useless).  Requiring that it be sent when
the client is in the "not semantically transparent" mode is okay.

> I don't know if both these requirements are met by max-stale, that is
> why I made a new header definition.

Any value for max-stale implies that the client (or an outbound
client) is operating in a "not semantically transparent" mode, since
it is asking for a stale response in preference to one that would
require a request on the next inbound server.

> |Authors of stateful services have the need to protect users who use
> |software with weakened caching restrictions from shooting themselves
> |in the foot.  For commercial stateful services, both the law and the
> |marketplace demand that this protection is provided by service
> |authors.
> You seem to be saying that the end user's need for control is so
> important that it prevents us from satisfying any other needs.  This
> is a ridiculous position.

Well, I didn't say that.  I said that the server may need to change its
method of servicing the user in order to satisfy the user's needs
AND provide that protection.  Any commercial service which depends upon
Cookies in order to ensure such protection is already broken, since
cookies will still be cached by HTTP/1.0 clients and proxies.

Cookies are a poor design for implementing market-basket functionality
in an HTTP client/server environment.  The correct design is to maintain
the market basket within the client state, and to simply POST that
basket to the cashier's URI when the user wishes to perform the actual
purchase transaction.  This is so easy to do that it sometimes makes
me scream whenever this topic resurfaces in the various www-related
mailing lists.

Unfortunately, I can't correct the mistakes of browser designers; the best
that I can do is add things to the protocol that limit the damage.
There does not exist any complete solution to the unreliability of
state in the header fields, since any stateful interaction across the
wire is contrary to the original design of HTTP as a stateless protocol,
and thus contrary to the way applications want to behave.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
Received on Thursday, 29 February 1996 13:45:00 UTC

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