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