multipart/form-data

[GoogleCodeExporter]

In order to correctly handle POST and PUT of text, binary, and BLOB
columns, mod_ndb needs to support requet bodies with content type
multipart/form-data.

Original issue reported on code.google.com by john.david.duncan on 28 Mar 2007 at 12:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

See http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2

Original comment by john.david.duncan on 23 Aug 2007 at 11:12

[GoogleCodeExporter]

Content-transfer encoding can safely be ignored:
---------------

RFC 2045, Section 6, on Content-Transfer-Encoding:
6.1.  Content-Transfer-Encoding Syntax

   The Content-Transfer-Encoding field's value is a single token
   specifying the type of encoding, as enumerated below.  Formally:

     encoding := "Content-Transfer-Encoding" ":" mechanism

     mechanism := "7bit" / "8bit" / "binary" /
                  "quoted-printable" / "base64" /
                  ietf-token / x-token

   These values are not case sensitive -- Base64 and BASE64 and bAsE64   are all equivalent.  An encoding 
type of 7BIT requires that the body   is already in a 7bit mail-ready 
representation.  This is the default  value 
-- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the  
Content-Transfer-Encoding header field is 
not present.

6.2:

The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all mean that 
the identity (i.e. NO) encoding 
transformation has been   performed.  As such, they serve simply as indicators 
of the domain of  the body 
data, and provide useful information about the sort of   encoding that might be 
needed for transmission in a 
given transport   system.... 

 Certain Content-Transfer-Encoding values may only be used on certain media types.  In particular, it is 
EXPRESSLY FORBIDDEN to use any encodings other than "7bit", "8bit", or "binary" 
with any composite media 
type, i.e. one that recursively includes other Content-Type fields.  Currently 
the only composite media types 
are "multipart" and "message". 

Original comment by john.david.duncan on 24 Aug 2007 at 2:59

[GoogleCodeExporter]

   Content-Type: multipart/form-data; boundary=AaB03x

   --AaB03x
   Content-Disposition: form-data; name="submit-name"

   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"
   Content-Type: multipart/mixed; boundary=BbC04y

   --BbC04y
   Content-Disposition: file; filename="file1.txt"
   Content-Type: text/plain

   ... contents of file1.txt ...
   --BbC04y
   Content-Disposition: file; filename="file2.gif"
   Content-Type: image/gif
   Content-Transfer-Encoding: binary

   ...contents of file2.gif...
   --BbC04y--
   --AaB03x--

Original comment by john.david.duncan on 24 Aug 2007 at 3:01

[GoogleCodeExporter]

mulipart/form-data itself is defined in RFC 2388.  
http://www.ietf.org/rfc/rfc2388.txt

Original comment by john.david.duncan on 24 Aug 2007 at 3:06

[GoogleCodeExporter]

Add a global "max-upload-size" configuration variable.
Read the whole multipart/form-data request into a buffer. 
Refer to the individual items in the buffer with <name, pointer, length>.
Usuallly most of the buffer will be a BLOB, and you can pass the pointer and 
length into NdbBlob::setValue().
When the request ends, Apache will free the buffer.

Original comment by john.david.duncan on 24 Aug 2007 at 8:06

[GoogleCodeExporter]

If the request body is larger than max-upload-size, return 412 Request Entity 
Too Large.

Original comment by john.david.duncan on 24 Aug 2007 at 8:13

[GoogleCodeExporter]

Ref. to the mechanics of this in Apache is Stein & MacEachern pp. 545 - 553.
Note that the current read_http_post.cc does not support "chunked" encoding.

Original comment by john.david.duncan on 24 Aug 2007 at 8:24

[GoogleCodeExporter]

Original comment by john.david.duncan on 1 Sep 2007 at 12:55

• Added labels: Milestone-1.2
• Removed labels: Milestone-2.0