Re: MIME multipart/* vs HTTP

> DK> In my ignorance of MIME, I've been puzzled about this boundary
> DK> business.  Assuming each multipart contains a Content-Length header,
> DK> does it matter what the boundary is?  Can't the recipient just eat the
> DK> number of content bytes before looking for the next boundary?  If so,
> DK> the boundary strings don't have to be particularly clever, do they?


OK I'll admit it. Content-Length is not actually valid MIME. It was added to
the HTTP spec after I discovered a problem with the original POST and PUT
method - the spec stated that closing the connection was used to indicate
the end of object which was kinda a lose on POST (think about it).

So I went off to talk it over with Tim and he agreed with me that we
needed a length specifier. We spent a while looking through the MIME specs
looking for it but didn't find it. Finally we punted and decided that it
must be in there and that the only logical name was "Content-Length".
We added it to the HTTP spec as a header incorporated from MIME.

A while later we discovered that not only was there no MIME content length
header but its absence was an anathema to the MIME people. I had a long
argument with Nat B. about this at WWW2. There was absolutely no way I
was going to corrupt the HTTP spec with stupid and unnecessary boundary
markers. Introducing probabalistic fudges when there is an analytic
solution is something I dislike intensely. Besides searching for the
boundary marker was very expensive computationally, every byte had to be
examnined.

Against this the MIME argument was that you might want to gate HTTP to mail.
The idea that the gateway should handle the convbersion was not acceptable.

I was keen to keep the HTTP spec clean because I wanted to support a 
hyperterminal like "streaming mode" where the server sent a continuously 
extending page at the client. This is what I believe the so called push
technologies are doing although I don't regard that as "true push". For 
that I would want to make the browser a client/server. To push content onto 
the browser you would execute a PUT or POST to a URL specified by the 
browser.  There would have to be some hailing protocol but I don't think 
that is too complex. If the job was done properly there would be no need
for all these quite bizare plugins to do chat.

So if people are wondering why the specs don't agree the answer is simple. 
I was right, they were persuing a theological point and I didn't really
want to call attention to the dispute at the time :-)

Mind you, those guys did win on Content-MD5 :-(

	Phill

Received on Wednesday, 30 April 1997 10:16:06 UTC