Re: Worries about content-length

Briefly, let me describe some work we have done in this area. We have
developed a product using a session maintaining extension to HTTP which is
similar to the "keep-alive" that other people have done. I have now written
it up and you can check it out at:

Let me share some implementation experience.

Our extension requries us to know the exact length of the Entity-Body so
that we can maintain an ongoing connection between the client and the server.

We have two ways that we do this. When we know the length of the Entity-Body
before we start transmitting it we use a "content-length" field, because it
has been our experience that scanning for a multipart boundary does
represent a slight performance hit. For CGI-like objects (which are VERY
common in our application) we use the multipart boundaries to signel the end
of our Entity-Body.

A couple of details:
1) You can expect to generate a multipart boundary before you start sending
a message and not worry about it conflicting with the text of the message.
If your multipart boundary is 32 characters for instance and your average
document is about 100 lines, you will only have a problem once every:
26^32/100 times. Not something I'm going to really worry about.
2) It works. It IS tricky to get it to work correctly. Plan on spending some
time getting the details right.
3) We ONLY use the content-length when we are communicating with servers
using the session extension. Previous implementations did it wrong enough of
the time that we never attempt to rely on them.
4) When we are proxying a document from an untrusted server and it is a
single part MIME-entity, we encapsulate it inside a multipart entity. This
appears to work fine, and is easy to do on the fly.

Alex Hopmann
ResNova Software, Inc.

Received on Monday, 8 May 1995 14:41:52 UTC