- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 04 Jan 96 18:47:04 PST
- To: http-caching@pa.dec.com
I've been trying to put together a coherent caching proposal for HTTP/1.1, and making slower progress than I had hoped. (Life is like that.) Anyway, it's nowhere near done, it has bugs that I know about, and I'm sure it will change a lot (I've rewritten it three times this week), but it's far enough along that the rest of you might want to read it. Please feel free to send comments to me or to the list. I've been fairly willing to rewrite pieces in response to comments I've received from the few people who have seen earlier drafts. You'll be able to tell where pieces are missing (look for TBS, or for notes marked with "XXX"). PLEASE DO NOT CIRCULATE THIS document. It's not ready, it doesn't represent anyone's opinion (except for mine, and only until the next time I change my mind), and it would only cause confusion if it got out. To give you some idea of what this thing says, here's an overview of my proposal: The caching model has these major design elements: 1. The basic protocol provides a way to enforce strict correctness; if servers, caches, and clients follow these rules, then users will never see something other than what the server intends. Note: the proposal includes techniques to preserve compability with HTTP/1.0 systems, without significantly changing the way that they work today. Please don't flame me about this before reading it! 2. The protocol provides ways for the servers, caches, and clients to loosen the strictness rules. In effect, the server grants permission for a cache to behave loosely. The amount of looseness is explicitly bounded by the participants, and user agents are always aware if a response may be the result of a loosening of the rules. Currently, loosening is done by bounding the amount of time that an invalid cached response can be used. Done using a "Fresh-until:" header, and some Cache-control: directives. 3. A cache can check if a cached value is correct by checking with a server, and only reloading the value if the cached version may be invalid. This is done using ``conditional'' HTTP methods, whose operation depends on the validity check. Done using opaque cache validators and a few new headers. 4. The protocol includes an explicit Cache-control mechanism that allows servers or clients to directly control aspects of caching. I'm suggesting some revisions to Roy's Cache-control: directives 5. The protocol includes a warning mechanism to transmit indications of possibly incorrect caching. Using a new Warning: header, which is designed so that if Warning: values are cached by HTTP/1.0 proxies, everything still works. URL: http://ftp.digital.com/%7emogul/cachedraft.txt -Jeff
Received on Friday, 5 January 1996 02:53:12 UTC