Multiple Content-Location headers

The MHTML group has decided to allow more than one Content-Location
in the same message heading. This can be used, for example, if the
same object can be located by several different URLs, and you want
to specify all of them. A particular case is the following

-- border --

-- border --
<img src="">

-- border --
<img src="">

-- border --

Supposes a.gif and images/a.gif actually refer to the same image.
And suppose the two HTML objects above have digital seals on them.
Then, if you did not allow multiple Content-Location headers in
the first body part, you would have to send the image twice, or
you would have to modify the HTML invalidating the digital seals!

The reason I am sending this message to the http working group
mailing list, is that this decision in the MHTML working group
may modify the HTTP spec, which presently says

  14.15	Content-Location

  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.

The MHTML group further has decided, that if there is more than one
Content-Location in the same message heading, then neither of them can
be used to establish a base (unless both specify the same base).

I suggest that the editors of the HTTP draft go through all cases where
Content-Location is mentioned in the HTTP draft to check that it agrees
with the above decisions in the MHTML group.

Please do not send replies to this message only to the mailing list, since I will not
then get them, I am not a member of that mailing list.

Jacob Palme <> (Stockholm University and KTH)
for more info see URL:

Received on Monday, 12 January 1998 08:35:04 UTC