Re: Multiple Content-Location headers

At 08.52 -0500 98-01-13, Scott Lawrence wrote:
> I don't believe that this should
> be changed at this late date, so I'd be carefull about assuming that
> changes proposed by MHTML will apply to HTTP usage.

The next MHTML draft will say that MHTML applies to the formatting
of MIME composite objects for sending through e-mail, netnews or
HTTP. I think it is obvious that the format of MIME composite
objects should be the same, independent of how they are sent.

> You describe the motivation for this as being a multipart message
> containing multiple different references to the same entity.  For example,
> message contains A, B, and C where A refers to C and B refers to D but D
> is really another name for C.  Rather than adding an attribute to C to
> give it the additional name (from the HTTP point of view overloading the
> semantics of Content-Location), why not add another part to the message
> that provides the equivalent of an HTTP redirect.  Something like (for
> D):
>
> Content-Type: mime/alternate-name
> Location: C

A simpler solution might be to have two headers:
Content-Location: .. one single primary location ..
Alternate-Locations: .. list of other locations with the same content ..

> The usage of Content-Location within HTTP is specifically to allow the
> specification of which one of some number of alternate versions of an
> entity is in this response.

I do not quite understand how you are able to designate one location
as the primary one, if you are sending two copies of exactly the
same object, referenced in two different ways. In the case you
describe, how can you say that C is primary and D is secondary?

------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme

Received on Tuesday, 13 January 1998 08:50:23 UTC