- 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
> 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 http://www.ics.uci.edu/~fielding/
Received on Thursday, 29 February 1996 13:45:00 UTC