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

Some suggested changes to the HTTP draft

From: Jacob Palme <jpalme@dsv.su.se>
Date: Sat, 17 Jan 1998 13:50:53 +0100
Message-Id: <v03110700b0e6302257c3@[130.237.150.138]>
To: http-wg@cuckoo.hpl.hp.com
Cc: Jim Gettys <jg@pa.dec.com>, Nick Shelness <shelness@lotus.com>, IETF working group on HTML in e-mail <mhtml@segate.sunet.se>
The HTTP draft says:

   If a cache receives a successful response whose Content-Location field
   matches that of an existing cache entry for the same Request-URI, 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.

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.

Later on, the HTTP draft says:

   The Content-Location entity-header field MAY be used to supply the
   resource location for the entity enclosed in the message when that
   entity is accessible from a location separate from the requested
   resource's URI. In the case where a resource has multiple entities
   associated with it, and those entities actually have separate
   locations by which they might be individually accessed, the server
   should provide a Content-Location for the particular variant which
   is returned. In addition, a server SHOULD provide a
   Content-Location for the resource corresponding to the response
   entity.

Suggested change:

   The Content-Location entity-header field, in the outermost HTTP
   heading of a response, MAY be used to supply the resource location
   for the entity enclosed in the message when that entity is
   accessible from a location separate from the requested
   resource's URI. In the case where a resource has multiple entities
   associated with it, and those entities actually have separate
   locations by which they might be individually accessed, the server
   should provide a Content-Location for the particular variant which
   is returned. In addition, a server SHOULD provide a
   Content-Location for the resource corresponding to the response
   entity.

   The Content-Location header field in a body part inside a returned
   multipart MIME structure is used as defined in [46].

   [46] Palme, J., Hopmann, A., Shelness, N.: MIME Encapsulation of
   Aggregate Documents, such as HTML (MHTML), March 1997.

Reason: To avoid the risk of unintended discrepancies between the HTTP
and the MHTML standards.

------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Received on Saturday, 17 January 1998 04:57:37 EST

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