Re: Multiple Content-Location headers
Jacob Palme (jpalme@dsv.su.se)
Thu, 15 Jan 1998 20:55:42 +0100
At 17.21 +0000 98-01-15, Nick_Shelness@motorcity2.lotus.com wrote:
> Could I suggest that to break this impasse, that MHTML switches to a new
> header field Content-Label to replace its use of Content-Location. This
> would better capture the MHTML role of the header field, and would also
> allow the simplifications I argued for last week on the MHTML list to
> proceed. I.e., Content-Label could only specify an absolute URI, and would
> not establish a base.
I am not very happy with changing an existing and already implemented
IETF proposed standard in such a radical way. But maybe it is necessary.
Let us examine the differences between how MHTML and HTTP uses Content-
Location to see if they really need to be split into two different
header fields.
HTTP 1.1 spec says MHTML spec says (I have removed
the controversial text allowing
multiple Content-Location headers,
since we all agree to remove
this.)
In HTTP, multipart body-parts MAY A Content-Location header
contain header fields which are specifies an URI that labels the
significant to the meaning of that content of a body part in whose
part. A Content-Location header heading it is placed. Its value
field SHOULD be included in the CAN be an absolute or a relative
body-part of each enclosed entity URI.
that can be identified by a URL.
A Content-Location header field is
allowed in any message or content
heading, in addition to one
Content-ID header (as specified in
[MIME1]) and, in Message headings,
one Message-ID (as specified in
[RFC822])
The Content-Location entity-header An URI in a Content-Location
field MAY be used to supply the header need not refer to an
resource location for the entity resource which is globally
enclosed in the message when that available for retrieval using this
entity is accessible from a URI (after resolution of relative
location separate from the URIs). However, URI-s in
requested resource's URI. Content-Location headers (if
absolute, or resolvable to
absolute URIs) SHOULD still be
globally unique.
A cache cannot assume that an When processing (rendering) a
entity with a Content-Location text/html body part in an MHTML
different from the URI used to multipart/related structure, all
retrieve it can be used to respond URIs in that text/html body part
to later requests on that Content- which reference subsidiary
Location URI. However, the Content- resources within the same
Location can be used to multipart/related structure SHALL
differentiate between multiple be satisfied by those resources
entities retrieved from a single and not by resources from any
requested resource, as described another local or remote source.
in section Caching Negotiated
Responses. Therefore, If a sender wishes a
recipient to always retrieve an
... URI referenced resource from its
source, an URI labeled copy of
If a single server supports that resource MUST NOT be included
multiple organizations that do not in the same multipart/related
trust one another, then it must structure.
check the values of Location and
Content-Location headers in In addition, since the source of a
responses that are generated under resource received in
control of said organizations to multipart/related structure can be
make sure that they do not attempt misrepresented (see 12.1 above),
to invalidate resources over which if a resource received in
they have no authority. multipart/related structure is
stored in a cache, it MUST NOT be
retrieved from that cache other
than by a reference contained in a
body part of the same
multipart/related structure.
Failure to honor this directive
will allow a multipart/related
structure to be employed as a
Trojan Horse. For example, to
inject bogus resources (i.e. a
misrepresentation of a
competitor's Web site) into a
recipient's generally accessible
Web cache.
My feeling is that the use of Content-Location as defined in the HTTP
and MHTML spec is not so different as to require us to use different
headers. But could the HTTP people please examine the quotes above
and check what you feel about this.
------------------------------------------------------------------------
Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme