Re: HTTP: T-T-T-Talking about MIME Generation
Daniel W. Connolly (connolly@hal.com)
Thu, 15 Dec 1994 18:58:50 -0600
In message <ab169307050210042c52@[192.190.111.20]>, Mitra writes:
>>In message <ab1685b2030210040a79@[192.190.111.98]>, Mitra writes:
>>>One thing to consider (not that i think this is a bad idea) is that often
>>>the objects being sent along are images leading to two non-optimisations.
>>>
>>>1) Mime encoding is going to roughly double the number of bytes sent
>
>At 4:18 PM 12/15/94, Daniel W. Connolly wrote:
>>Hello? Mime encoding adds a few bytes between objects for the boundary.
>>HTTP is 8-bit clean, after all. No base64 needed.
>
>Hmm - maybe I'm missing something, but I dont think you can put the file in
>WITHOUT encoding, if you are looking for a boundary, what if the file
>contained the wrong bytes and got interpreted as the boundary.
"Don't do that." :-)
Seriously: you're supposed to pick a boundary so that this doesn't happen.
I've seen two approaches:
(1) scan the data to be sure your boundary doesn't appear in
the data
(2) pick a true-random number of say, 64 bits and base64 encode
that as the boundary. Supposedly the chances of a collision
using this algorithm are less than the chance that a stray photon
will cause your computer to malfunction. I haven't boned up
on statistics and probability enough to follow the arguments
exactly, though.
The boundary mechanism is compatible with all three
content-transfer-encodings, not just 7-bit.
Dan