Subject: Re: IPP>PRO - http comments

From: "Phillip M. Hallam-Baker" <[email-masked]>
Date: Thu, 1 May 1997 12:24:06 -0400

--->> It would be good to get a definitive answer as to whether
>> Content-Length takes priority over the boundary string in a
>> multipart/*.  At a recent IETF meeting I asked such a question to
some
>> knowledgeable person who said that Content-Length was ignored in
this
>> context and that the boundary string was the only way to determine
the
>> end of a part in a multipart/*. I would prefer that Content-Length
>> take priority if it is present.
>
>My take:
>
>It is illegal to send content where the content-length and the
boundary
>string disagree. So one doesn't take priority over the other. A
>recipient
>should signal an error if it detects that they are different.

I agree with the first part but not the second.

If you see a content length the obvious thing to do is to avoid the
computationaly intensive check of each byte (yes O(1) is less than
anything Boyer-Moore can do and that is not subjective). You
hop straight to the boundary.

If you see a boundary marker ther, then its OK other wise you signal
an error.

Note that if there are additional boundaries within the content length
delimited block you don't see them. 

So content length should take priority but you may in some cases be 
able to detect an error.

>Senders that are at all uncertain about the length of the data should
>omit content-length and rely on the boundary alone.

Yep

Phill.

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 May 1997 22:05:00 -0400

> So content length should take priority but you may in some cases be 

Content-Length fields do sometimes appear in MIME message bodyparts.
Such Content-Length fields are often incorrect, but are generally
ignored by MIME user agents because they're nonstandard.  Those same
messages can and do get returned in HTTP responses as message/rfc822
objects.  (this is actually a nice way to provide HTTP access to a
mail archive, since the client will format it as if it would an email
message.)

Should the HTTP server then scan the internals of a message/rfc822 or
multipart/* message that it's returning, and correct or remove every
Content-Length header field, just so the HTTP client doesn't have to
scan for the boundary marker?  This doesn't make any sense to me.  Not
only does it require the server to alter message content, it also puts
the computational burden in the wrong place.

(The following is with my AD hat on:)

Otherwise: Content-Length is part of the HTTP protocol, not part of
the MIME specification.  Content-Length is valid for an HTTP entity
header, but not valid for the header of a component of a multipart.

This needs to be clarified in the next verison of the HTTP protocol
specification.  In general, it is not acceptable for HTTP multipart to
have a inconsistent definition from MIME multipart.  If exceptions are
needed for backward compatibility, the specification needs to say
exactly when those exceptions apply -- but not for all multipart
variants regardless of how they are transmitted.

Keith