- From: Keith Moore <moore@cs.utk.edu>
- Date: Thu, 01 May 1997 02:55:26 -0400
- 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
> 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. Keith
Received on Wednesday, 30 April 1997 23:57:18 UTC