W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

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

From: Daniel W. Connolly <connolly@hal.com>
Date: Thu, 15 Dec 1994 18:58:50 -0600
Message-Id: <9412160058.AA06869@ulua.hal.com>
To: Mitra <mitra@path.net>
Cc: Marc Salomon <marc@library.ucsf.edu>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In message <ab169307050210042c52@[]>, Mitra writes:
>>In message <ab1685b2030210040a79@[]>, 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.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:10 UTC