- From: Daniel DuBois <ddubois@spyglass.com>
- Date: Thu, 18 Apr 1996 04:10:37 -0500
- To: koen@win.tue.nl (Koen Holtman), fielding@avron.ICS.UCI.EDU (Roy T. Fielding)
- Cc: mogul@pa.dec.com, http-caching@pa.dec.com
At 10:29 PM 4/17/96 +0200, Koen Holtman wrote:
>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
>>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].
Have to agree with Koen here. The determination of whether or not to send a
300 depends on transparent negotiation algorithms not defined in HTTP/1.1.
>>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.
This thread seems to be getting awfully confrontational.
It would likely involve both. The .meta files would likely indicate, for
instance, 1) the other possible variants, 2) if the file is the root of a
variable resource, 3) the source quality, and/or 4) Content-* information.
Server configuration for the Spyglass Server lets it be known which
extensions correspond to which mime types, languages, etc. Content
negotiation, reactive or otherwise, can't occur without this configuration
information.
Naturally, the Accept headers come into play as well. One's an
implementation issue, the other's a protocol issue.
-----
the Programmer formerly known as Dan
http://www.spyglass.com/~ddubois/
Received on Wednesday, 17 April 1996 21:52:56 UTC