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.

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/

Received on Wednesday, 30 April 1997 11:56:33 UTC