- From: Koen Holtman <koen@win.tue.nl>
- Date: Wed, 15 May 1996 10:33:56 +0200 (MET DST)
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter: > >> We worked out the following simplification: >> - adopt a model in which generic resources bind to other resources >> (called variant resources below), not to resource entities >> - thus, for a single resource, at most one response can be cached. >> A resource only has one expiration time associated with it. A >> generic resource is nothing but a `portal' through which variant >> resources are accessed. > >I think that there is another view of how content negotiation and >caching might interact, where a single resource might have several >(fresh) entities associated with it in a cache, each corresponding to >different request headers as distinguished by vary parameters, and >where expiration times (freshness) is associated with entities and not >with resources. I agree. This other view you describe is the view recorded in the current 03 draft. >I think these differing models of how caching of negotiated resources >might work are both self-consistent but not compatible and will >require different protocol. As far as caching algorithms (storing of multiple responses for one request-URI, header matching, conditional requests) are concerned, the two models are not very different. The main difference is in the way these caching algorithms are described. Additional small differences exist in header syntax and use. >Larry Koen.
Received on Wednesday, 15 May 1996 01:34:06 UTC