From the mbuni documentation ( userguide.shtml#mms_service):

"Note that the parameter name/value is repeated as many times in the POST data as there are matching parts in the message. That is, if there are three images in the MM and http-post-parameters is image=%i then the parameter image will be passed thrice, with different values. (The CGI script used must therefore be prepared to handle multiple parameters with the same name.)"

So; given multiple images, there would be multiple parameter/value pairs with 'name=image' in the mulitpart/form-data in the HTTP POST body.

However, from RFC 2388 - Returning Values from Forms: multipart/form- data (

"3. Definition of multipart/form-data

The media-type multipart/form-data follows the rules of all multipart
   MIME data streams as outlined in [RFC 2046].  In forms, there are a
   series of fields to be supplied by the user who fills out the form.
   Each field has a name. Within a given form, the names are unique.


   "multipart/form-data" contains a series of parts. Each part is
expected to contain a content-disposition header [RFC 2183] where the
   disposition type is "form-data", and where the disposition contains
   an (additional) parameter of "name", where the value of that
   parameter is the original field name in the form."

So; it looks like mbuni's behaviour violates the RFC for multipart/ form-data, in that within it's given 'form', the names are NOT unique.

Aside from RFC compliance (which could be debatable?), it turns out that pretty much every multipart/form-data parser we've come across does not support multiple values for a single name.

We'd like to avoid hacking one of these parsers to support multiple values for a single name - wouldn't it be better for mbuni to enumerate the names somehow (to make them unique) when handling multiple pieces of the same type of content?

Giulio Harding
Systems Administrator

m.Net Corporation
Level 2, 8 Leigh Street
Adelaide SA 5000, Australia

Tel: +61 8 8210 2041
Fax: +61 8 8211 9620
Mobile: 0432 876 733
Yahoo: giulio.harding

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Devel mailing list

Reply via email to