> 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