Alternates, 300 responses, and cache keys

Koen writes:
    Roy T. Fielding:
    >[Jeff Mogul:]
    >> One question: how does a cache decide if 300 response with an
    >> Alternates header can be returned in reply to a subsequent
    >> request (a more precise way of saying "is cachable")?  Is this
    >> 
    >>     1. Always
    >>     
    >>     2. Only if the new request looks like [fill in the blank]
    >> 
    >>     3. Never
    >
    >Always, unless otherwise indicated by a Cache-control or Expires
    >in the 300 response.  This is (was?) in the description of 300.
    
    No. In the 1.1 draft, it is (3.) Never, unless otherwise indicated by a
    Cache-control or Expires in the 300 response.  Only 200 and 206
    responses can be cached by default.

In draft-ietf-http-v11-spec-01.txt, it is as Roy says.  In Jim's current
draft, 300 is "reserved for future use", and its cachability is not
explicitly discussed.  I suggest that it would be a good idea to
review this part of Jim's draft.

I do like Koen's suggestion that only 200 and 206 responses are
cachable with an explicit expiration time (Expires: or max-age:);
it simplifies part of the caching design that I hadn't gotten around
to writing (because I wasn't sure how to deal with it).  Here's what
I plan to include:

13.14.1 Caching and status codes
   A response received with a status code of 200 or 206 may be stored by
   a cache and used in reply to a subsequent request, subject to the
   expiration mechanism, unless a Cache-control directive prohibits
   caching.

   A response received with any other status code MUST not be returned
   in a reply to a subsequent request unless it carries at least one of
   the following:

      - an Expires: header

      - a max-age Cache-control directive

      - a must-revalidate Cache-control directive

If anyone wants to object to this, please suggest an alternative rule
and justify it.
    
    The content negotiation draft we will change this `never' into a
    `always, but this is sub-optimal if [fill in the blank].

So this is what I plan to say about what a cache should do if
it receives an Alternates header:

   If a cache receives an Alternates header in a response from the
   origin server, it should act as if the response carried a "Vary:
   {accept-headers}" header.  This means that the response may be
   returned in reply to a subsequent request with Accept-* headers
   identical to those in the current request.

      Note that section 13.14.1 prevents caching of 300 (Multiple
      choices) responses unless this is explicitly allowed by an
      Expires or Cache-control header.

Roy, Koen, does this capture what you intend?

Roy writes:
    >[Jeff]:
    > I guess I'd be happier if someone could tell me what a Content-Location
    > looked like.
    
    Just like Location, except with "Content-" in front.  I edited the
    description directly into Jim's copy, since the changes from URI 
    covered many different areas.

I guess I'm still confused.  I understand (perhaps wrongly) that
an Alternates header may describe more than one alternate, but the
Content-Location header only includes a single URI.

Would someone please explain (perhaps with an example) how Alternates
and Content-Location are supposed to work together?

Koen writes:
    >[Jeff]
    >> I would rephrase that as: The variant-ID is used as part of the cache
    >> key only if the Request-URI is not sufficient to determine a specific
    >> entity.  (And then only for conditional requests and for replacing 
    >> existing cache entries.)
    
    No, change that to `the request URI and the contents of a
    Content-Location header (if present)'.

And Dan DuBois says:
    From this context I'd say "yes or no" depending on whether the
    server used Vary or Alternates.  For Vary the cache key would be
    Request-URI + Variant-ID:, and for Alternates: the cache key would
    be Request-URI and Content-Location:.  So you're both right(?)

I guess there is still some confusion.  A cache needs a key at several
different times:
	(1) when creating or replacing a cache entry, because a
		response has just been received.
	(2) when finding a cache entry to (potentially) use, because
		a request has just been received.

I think these cases have to be discussed separately, and each
have several sub-cases.  (I'll use the symbol "vary-hdrs" to
mean "the values of the request headers specified in a Vary
header", and "cont-loc-URI" to mean "the absoluteURI specified
in a Content-Location header".)

Case 1:
	(a) Response has none of {Vary, Alternates, Content-Location}
	    nor a variant-ID:
			entry-Key = (Request-URI, null, null, null)

	(b) Response includes a variant-ID (and so presumably Vary)
			entry-Key = (Request-URI, variant-ID, null, vary-hdrs)

	(c) Response includes Content-Location:
			entry-Key = (Request-URI, null, cont-loc-URI, null)

	or do you guys mean that there are really two different keys
	for the entry, like so?
			entry-Key1 = (Request-URI, null, null)
			entry-Key2 = (content-location-URI, null, null)

Case 2:
	(x) Request has no variant-ID
			lookup-Key = (Request-URI, null, req-hdrs)
	(y) Request has a variant-ID
			lookup-Key = (Request-URI, variant-ID, req-hdrs)

and if I understand things, the matching function applied during a
lookup is something like:
	(I) The first field of the lookup-Key must matche either
	the first or third field of the entry-Key.
	(II) The second field of both keys must match.
	(III) if the fourth field of the entry-Key is not null, all
	of the headers present there must match the corresponding
	headers in req-hdrs, according to the rules that Koen described.

This almost makes sense to me, but I'm still not sure about Case 1(c).

In other words, I'm pretty sure this is wrong, but since I have to
provide something specific to Jim, someone else will have to provide
a definite algorithm as soon as possible.  Otherwise, this algorithm
goes into his draft, and we can fix it later.

-Jeff

Received on Thursday, 18 April 1996 00:58:39 UTC