Re: HTTP: T-T-T-Talking about MIME Generation

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

Received on Thursday, 15 December 1994 17:06:55 UTC