a first, incomplete draft of my caching proposal

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