W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: MIME multipart/* vs HTTP

From: Scott Lawrence <lawrence@agranat.com>
Date: Wed, 30 Apr 1997 14:35:25 -0400
Message-Id: <199704301835.OAA29625@devnix.agranat.com>
To: Hallam-Baker <hallam@ai.mit.edu>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3172

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC