- From: John Franks <john@math.nwu.edu>
- Date: Sat, 17 Jan 1998 08:27:38 -0600 (CST)
- To: Jacob Palme <jpalme@dsv.su.se>
- Cc: http-wg@cuckoo.hpl.hp.com, Jim Gettys <jg@pa.dec.com>, Nick Shelness <shelness@lotus.com>, IETF working group on HTML in e-mail <mhtml@segate.sunet.se>
On Sat, 17 Jan 1998, Jacob Palme wrote: > > I suggest this is changed to: > > If a cache receives a successful response where the Content-Location > field in the *outermost* HTTP heading matches that of an existing cache > entry for the same Request-URI, and whose entity-tag differs from that > of the existing entry, and whose Date is more recent than that of the > existing entry, the existing entry SHOULD NOT be returned in response > to future requests and should be deleted from the cache. > > Reason: I think this is what you really mean. To use Content-Locations > in headings inside MIME Multipart objects for cache matching can be > dangerous. With a couple of minor well specified exceptions HTTP does not deal with Multipart objects as multipart, but as a single object. There are no outer vs inner headers; only one set of headers. What you might call inner headers are just part of the data to HTTP. The content of a MIME Multipart object is no different than the content of a binary file to HTTP. An HTTP cache should be no more likely to use a heading inside a MIME Multipart object than to use a string inside an object of type application/octet-stream. John Franks john@math.nwu.edu
Received on Saturday, 17 January 1998 06:30:30 UTC