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

Re: Some suggested changes to the HTTP draft

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>
Message-Id: <Pine.LNX.3.96.980117081802.6507B-100000@hopf.math.nwu.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5209
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
Received on Saturday, 17 January 1998 06:30:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC