- From: Al Gilman <asgilman@access.digex.net>
- Date: Tue, 2 Sep 1997 17:00:20 -0400 (EDT)
- To: jpalme@dsv.su.se (Jacob Palme)
- Cc: mhtml@SEGATE.SUNET.SE, uri@bunyip.com
to follow up on what Jacob Palme said: > > The MHTML standard says that if there is both a Content-Base > and a Content-Location header in the same content heading, the > Content-Base has precedence over the Content-Location. Is there > any problem with this? Clearly, the standard must specify which > has precedence, good standard should not leave things like > this undefined. "undefined" in my opinion is an ugly word > in standards documents. > Some more loose talk from this end -- I haven't done the homework implied: I suspect that HTTP is willing to trust that header fields are received in the order sent, and give precedence to the textually last header field within a [single message header, or by extension the headers of a single MIME part]. Since in the email context you may not wish to trust that header fields are received in the order that they were sent, you may have a good reason not use that as the basis for resolving conflicts. Personally, I see some virtue to a policy which would make the presence of both a Content-Base and Content-Location header field within the same header block an error [leaving BASE undefined] if they do not agree as to the implied BASE. But I do see the choice whether to fix this quietly, fix it with a warning, or not fix it as a judgement call without an iron-clad case for any one choice. Particularly, if the same Content-Base + Content-Location value pair are at risk of being interpreted one way when transmitted in MIME and another way when transmitted via HTTP I see this as a likely source of trouble and too arcane for prime time. -- Al Gilman
Received on Tuesday, 2 September 1997 17:00:30 UTC