RE: MIME multipart/* vs HTTP

-----Original Message-----
From:	Scott Lawrence [SMTP:lawrence@agranat.com]
Sent:	Wednesday, April 30, 1997 11:35 AM
To:	Hallam-Baker
Cc:	http-wg@cuckoo.hpl.hp.com
Subject:	Re: MIME multipart/* vs HTTP


PH-B> OK I'll admit it. Content-Length is not actually valid MIME. It
PH-B> was added to the HTTP spec after I discovered a problem with the
PH-B> original POST and PUT method [...]

PH-B> [...] There was absolutely no way I was going to corrupt the
PH-B> HTTP spec with stupid and unnecessary boundary
PH-B> markers. Introducing probabalistic fudges when there is an
PH-B> analytic solution is something I dislike intensely. Besides
PH-B> searching for the boundary marker was very expensive
PH-B> computationally, every byte had to be examnined.

  Hear hear.

  If the intent is/was that Content-Length should be used in each part
  of a multipart/* body part rather than boundary markers, then I
  believe that the spec needs some clarification on this point.  While
  I expect that others may disagree, I believe that such a change
  would be a big improvement.

It seems that this would be an improvement, but what about the case where you are not sure in advance what the Content-Length will be ? I also dislike the Multipart boundaries, but don't see another way around the problem if you don't know the content-length.

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

  A gateway would also have to do work to change the HTTP 8-bit data
  to some Content-Transfer-Encoding anyway, wouldn't it?  Adding a
  boundary marker (or the Content-Length in the other direction) in
  the process hardly seems an extraordinary requirement.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Nick

Received on Wednesday, 30 April 1997 11:59:28 UTC