- From: Koen Holtman <koen@win.tue.nl>
- Date: Wed, 17 Apr 1996 22:29:36 +0200 (MET DST)
- To: fielding@avron.ICS.UCI.EDU (Roy T. Fielding)
- Cc: mogul@pa.dec.com, http-caching@pa.dec.com
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. The content negotiation draft we will change this `never' into a `always, but this is sub-optimal if [fill in the blank]. >> 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. > >> It might also be nice if someone could explain how an >> origin server decides whether to use opaque negotiation or transparent >> negotiation. However, I think from the point of view of caching, I >> don't need to know. Allowing reactive negotiation does not require special caching rules in 1.1, so you are correct that you do not have to know. >It would normally be done via server configuration (in practice, >on a directory-by-directory basis or using .meta/.multi files). No. With transparently negotiated resources, the choice to use preemptive or reactive depends on the contents of the accept* headers you are getting. If you add an opaque part, it will indeed probably involve server configuration files. >> ... >> 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.) > >Yep. No, change that to `the request URI and the contents of a Content-Location header (if present)'. >......Roy Koen.
Received on Wednesday, 17 April 1996 20:52:58 UTC