W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

FW: "Value" caches (was Can proxies rewrite Date:?)

From: Paul Leach <paulle@microsoft.com>
Date: Mon, 11 Mar 96 11:32:18 PST
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: red-16-msg960311192504MTP[01.52.00]000000b1-139778
Resend -- mail problem:

] From: Jeffrey Mogul  <mogul@pa.dec.com>
] Date: Friday, March 08, 1996 11:16AM
]
] In the "caches hold responses" model, therefore, the cache
] needs to create a new response R3 that is some combination
] of R1 and R2.  Presumably, it does this by taking the union
] of the two responses, and using R2's values for any field that
] is present in both R1 and R2.
]
] In the "caches hold values" model, the cache constructs a new
] "value" out of the pieces provided by R1 and R2 (using essentially
] the same algorithm), and then returns this new value as R3
] to client B.
]
] Either way, the cache needs to perform a function
] 	R3 = F(R1, R2)
] or
] 	newvalue = G(R2, oldvalue)
] that ensures that a consistent set of entity headers remains attached
] to the entity body.

Warning!!! Philosophy!!!

I think that what Jeff says about the "caches hold values" (CHV) model 
doesn't capture the essence of that model.  What I think the model 
means is that the responses R aren't atomic, that we can look at them 
and see a finer structure:
	R = (C, V)
i.e, that a response has some "communications stuff" (basically, 
response and general headers) and some "value stuff" (Date, entity 
headers and entity-body). Using this elaborated CHV model, we can 
therefor rewrite Jeff's response function as
	newvalue = G(V, oldvalue)
where G takes each of the subparts of V (individual headers or 
entity-body ranges) and replaces the corresponding subpart of oldvalue 
to create newvalue; whereas
the communications stuff is synthesized anew on each response.

This elaborated CHV model isn't a complete explanation.  It doesn't 
account for Location headers, for example. In fact, it doesn't account 
for content negotiation (CN) at all, really, because CN deals with 
"virtual" entities, which by definition can't be cached.  A fuller 
explanation would say that the cache has two kinds of entries:
	mappings from virtual entities to real entities
	real entities
Only the latter fit the CHV model, but they form the "reality 
grounding" function on top of which one can build virtual entities.

This fits nicely in with the observation at the WG meeting about 
Location. A particular variant ( a real entity) always has to have 
either a URI or a URI and a variant ID if it wants to be cached,

It fits nicely with Vary -- Vary specifies how to construct a mapping 
from certain request headers toa real entity that might be in the cache.

It also fits nicely with issues of caching POST and GETs with "?" in 
the URI.  When they are cacheable,  they are a mapping  that includes 
the query string or the POST entity-body.

Paul
Received on Monday, 11 March 1996 11:33:32 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:48 EDT