- 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
> 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