- From: Keith Moore <moore@cs.utk.edu>
- Date: Thu, 01 May 1997 22:05:00 -0400
- To: "Phillip M. Hallam-Baker" <hallam@ai.mit.edu>
- Cc: Robert Herriot <Robert.Herriot@eng.sun.com>, Larry Masinter <masinter@parc.xerox.com>, rdebry@us.ibm.com, lawrence@agranat.com, ipp@pwg.org, http-wg@cuckoo.hpl.hp.com, moore@cs.utk.edu
> 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. 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
Received on Thursday, 1 May 1997 19:06:52 UTC