Re: Worries about content-length

> > > > 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?
> > >
> > > You can guarantee (with adequate probability) that the end string is
> > > unique without parsing the data, by using a sufficiently good random
> > > number generator.
> > >
> > > I guarantee it.
> 
> > Yes, but it's still a hack.  A simpler solution is to just pick a constant
> > byte value (020 springs to mind :-) and use that as an escape code.  It
> > doesn't fit into the MIME scheme of things, but it's 100% solid and simpler
> > to build than mime/multipart
> 
> Actually, I see it the other way around, with byte stuffing being the hack and
> unique boundaries as the cleanest way to do it. I also disagree about it being
> simpler -- byte stuffing requires that you diddle the stream as it is sent,
> which complicates your inner processing loop where you spend your time.
> Boundaries keep that loop nice and simple.

One can make algorithmic arguments on both sides fairly persuasively: I
believe they end up being very close in the limit.   For example, I
would implement byte-stuffing on the server side by having the files in
the cache be pre-stuffed.  Since my server has a RAM cache, it's
particularly easy.  Then I just do a single firehose write to the socket.
(Of course, the pre-computation technique can be used in the random
delimiter case to guarantee 100% safety)

The "hack" aspect, in my opinion, to the random delimiter scheme comes
from being less than 100% solid.  Admittedly, the probability of a
false match can be pushed arbitrarily small, but it cannot be made 0.
Given a good random number generator, I wouldn't worry about it too
much, except that it really feels like a bug waiting for a place to
happen.

Received on Monday, 8 May 1995 15:10:17 UTC