W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: MIME multipart/* vs HTTP

From: Keith Moore <moore@cs.utk.edu>
Date: Thu, 01 May 1997 02:55:26 -0400
Message-Id: <199705010655.CAA04062@spot.cs.utk.edu>
To: Michael Giroux <mgiroux@worldnet.att.net>
Cc: 'Dave Kristol' <dmk@bell-labs.com>, Scott Lawrence <lawrence@agranat.com>, "ipp@pwg.org" <ipp@pwg.org>, "http-wg@cuckoo.hpl.hp.com" <http-wg@cuckoo.hpl.hp.com>, moore@cs.utk.edu
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3189
> Content-Length is not a very efficient mechanism for high volume 
> (tens of thousands of concurrent connections, at 200+ TPS) servers.
> It requires that the server cache the entire message in order to 
> determine the final length, then send the content.  This will generally
> require that the data is processed at least twice.  First to cache it,
> and again to send it.

Correct, and this is one of the main reasons why content-length
mechanisms were not chosen for delimiting multipart boundaries
in MIME messages.  The other reason was differences in the 
representation of text messages on different platforms.
HTTP doesn't have the latter problem to the same degree as MIME
email does, but it does have the former problem.  Content-Length
is almost as undesirable for HTTP as it is for MIME email.

(Not to mention that mixing the protocol-level framing in with 
the description of the payload causes all sorts of confusion.)

> It would be better if these protocols used a scheme that breaks the
> message into multiple messages.  Each message would start with
> a length field.  In this way, it would be easy to add a boundry marker
> as defined by a zero length part at end. 

Exactly the solution adopted for SMTP chunking.

Received on Wednesday, 30 April 1997 23:57:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC