Re: Multiple Content-Location headers

At 08.34 -0800 98-01-15, Jim Gettys wrote:
> Now, to go further in this discussion, we need to be convinced that the
> proposal won't break deployed code. The burden of proof is on you at this
> point, as the one proposing the change.  So as I see it, either show that
> 1) the change won't break running deployed HTTP code, or 2) change the name
> to something else, so it won't break deployed code, and therefore HTTP might
> be able to implement it.

Most implementors I have communicated with use the same code to display
aggregate HTML whether this HTML arrives via e-mail or via HTTP. So their
code is not broken, but aided by having the same format for aggregate
HTML objects, independent of transport protocol.

Assuming that we define a new header Content-Alternate or something
like that, what existing code would be broken by MHTML and in what way?
I do not think that even the MHTML group original proposal would break
any existing code, but if the HTTP group so wants, we are willing to
define Content-Alternate to avoid multiple Content-Location headers.

Can you give an example of what would break existing code in what way?
 Of course HTTP clients which are not capable of handling multipart
MIME objects may have problems, but you cannot stop all development
of new features just because old implementations will have problems
handling new features. The common method in HTML browsers to handle
new features is just to ignore the HTML elements they cannot understand.
This would work rather well in our case; the effect would be that
if a document contained the same picture in several places, the
rendering with such HTML browser would show the picture only in
one of the places, and that is not very unreasonable, is it?

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



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

Received on Thursday, 15 January 1998 12:20:48 UTC