Re: Worries about content-length

> > The boundary-marker method used by MIME multipart is the only way I've
> > seen of getting (nearly) reliable determination of the end of the data
> > without using content-length.
> >
> > I wonder if there might be some way to employ this method in HTTP for
> > single-part data being sent back over HTTP when content-length can't
> > be easily precomputed (CGI or what have you).
> >
> > Implementation is easy: the server would compute a random string,
> > include it in the HTTP header; at the end of the transmission (e.g.,
> > when the CGI returns without error) it would add the terminating
> > header.

> Hmm, is it that much easier? In order for the server to guarantee that the
> `random' string is unique it must parse the stream before it can generate
> one and then it might as well calculate the content-length?

Why on earth would you bother to parse the stream? All you have to do is
generate a pseudorandom string (truly random would be better, but the hardware
to generate true random strings isn't widely available yet) and use it. No
parsing is needed. The chances of a properly generated random 128 bit string
(use 256 bits if you're paranoid) occurring in data are millions of times less
than the chances of an undetectable bit error occurring on most modern
transmission mediums, and the results of such an error in either case are
basically equivalent.

I've been using this technique for years now with MIME email and it works
extremely well.

				Ned

Received on Monday, 8 May 1995 14:01:29 UTC