Re: Multiple Content-Location headers

    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!
    
I have been having discussions with some of the people behind
the "DRP" protocol proposal
	http://www.w3.org/TR/NOTE-drp-19970825.html
about how to extend HTTP to support "duplicate suppression".
Using multiple Content-Location headers is an interesting approach,
but it might not entirely solve the problem.  (For example, some
things, such as the Netscape logo, are duplicated thousands of
times in the Web; one could not list these all in a Content-Location
header).

At any rate, I suggest that this is an important issue to solve,
but we are not ready to embed any specific solution in the HTTP/1.1
standard.  And the solution(s) for MIME and HTTP might be different,
since these are very different protocols.  (MIME, for example, 
does not have to worry about interactions with proxy caches,
partial retrievals, etc.)

    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

HTTP is not MIME.  The MHTML working group shouldn't be thinking
about "modifying the HTTP spec", especially since we are trying
very hard to push HTTP/1.1 to Proposed Standard status ASAP.  We
can make changes to HTTP/1.1 that are required to satisfy the IESG
that it actually works as advertised; we can't keep making changes
to keep track of new features being discussed in other working groups.

-Jeff

Received on Monday, 12 January 1998 12:10:06 UTC