- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 18 Apr 1996 11:37:52 +0200 (MET DST)
- To: mogul@pa.dec.com (Jeffrey Mogul)
- Cc: http-caching@pa.dec.com
Jeffrey Mogul:
>
>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.
Actually, I wrote this 300 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:);
Note that this was not meant as a new suggestion, I remember that we
agreed on default a month or so ago.
>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.
Yes. Note that I already have sentences that imply this for responses
from varying resources in the Vary header section.
> 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.
This works for me. I have text with the same meaning in the
Alternates header description for the 1.1 draft. You can add the
sentence
This is covered in depth in Sections 10.53 (Alternates) and
10.52 (Vary).
after your last sentence above.
> 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?
It does for me.
>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.
Yes, and this single URI is one of those in the Alternates header; it
is the URI under which the actual entity returned in the response is
also available.
>Would someone please explain (perhaps with an example) how Alternates
>and Content-Location are supposed to work together?
I believe I sent such an example in my second-to-last message. The
exact interaction of them will be defined in the content negotiation
draft, this is not something that plain 1.1 caches have to worry
about.
>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.
Yes. See my 1.1 draft text about cache replacement. I call the cache
key a `replacement key' there.
> (2) when finding a cache entry to (potentially) use, because
> a request has just been received.
Such finding cannot be done with a replacement key, it will have to be
done by matching new request headers to the request headers which
`generated' the cached entries.
So the (1) and (2) cache keys are not the same (certainly not not for
opaque negotiation, for transparent negotiation they can be, but that
is not defined in plain 1.1).
My opaque negotiation text (included in the Vary header section for
1.1) carefully avoids defining a key other than a sequence of request
headers for (2) above.
>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)
Yes. Note that there is only one entity, so this is just HTTP/1.0
replacement.
>
> (b) Response includes a variant-ID (and so presumably Vary)
> entry-Key = (Request-URI, variant-ID, null, vary-hdrs)
No, As the replacement key, I defined
entry-Key = (Request-URI, variant-ID, null)
here. The vary-hdrs are not needed for replacement; in fact inclusion
of them in the key would make replacement much less efficient.
>
> (c) Response includes Content-Location:
> entry-Key = (Request-URI, null, cont-loc-URI, null)
Yes.
> 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)
entry-Key1 above would cause replacement much too often. entry-Key2
is an excellent replacement key, but this it will be defined in the
content negotiation draft, not the plain 1.1 draft, because entry-Key2
brings spoofing problems with it.
Also note that there is a fourth case, though I do not expect this to
happen much:
(d) Response includes a variant-ID
AND Response includes Content-Location:
entry-Key = (Request-URI, variant-id, cont-loc-URI, null)
Generalizing, I defined in my text for the 1.1 draft:
HTTP/1.1 allows the authors of varying resources to guide cache
replacement by the inclusion of elements of so-called replacement keys
in the responses of these resources. The replacement key of a varying
response consists of two elements, both of which may be empty strings,
separated by a semicolon:
replacement-key = variant-id ";" absoluteURI
The variant-id element of the replacement key is the variant-id value
in the Cval header of the response, if a Cval header which such a
value is present, and an empty string otherwise. The absoluteURI
element of the replacement key is the absolute URI given in, or
derived from, the Content-Location header of the response if present,
and an empty string if no Content-Location header is present.
>Case 2:
> (x) Request has no variant-ID
^^^^^^^
Huh? Don't you mean `cached response under consideration for return
has a variant-id?'? Or do you mean that there is a variant-ID in the
If-Invalid header of the request? I assume you mean the latter.
> lookup-Key = (Request-URI, null, req-hdrs)
Yes.
> (y) Request has a variant-ID
> lookup-Key = (Request-URI, variant-ID, req-hdrs)
No, still
lookup-Key = (Request-URI, null, req-hdrs)
you use this lookup key, and if you find the Cval: header value of
this response in the If-Invalid header, you know that you can send a
not-modified response instead of a complete entity.
>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).
You lost me here. Which lookup are you talking about?
>
>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.
A definite algorithm that says when caches may return responses from
varying resources is already in the draft, it is in my Vary section.
A definite algorithm for cache replacement of varying resources is
also already in the draft, it is in my `Cache replacement for varying
resources' section.
As far as I can see, that covers all definite algorithms which do not
also apply to non-varying resources.
> Otherwise, this algorithm
>goes into his draft, and we can fix it later.
I strongly suggest that you do not put the any algorithms based on
your case analysis above in the draft, as they are likely to either
duplicate or contradict the algorithms I put in. This way, we can see
later if any algorithm is left out.
Please, do not wait submitting text to Jim until you understand all
the selection and replacement algorithms connected to Vary and
Alternates. I gave these algorithms to Jim already. Just get this
draft out of the door, we can see if anything is left out later.
>-Jeff
Koen.
Received on Thursday, 18 April 1996 10:19:20 UTC