Well, we're constrained to Java for our applications. The Java parsers we've tried including COS (com.oreilly.servlet) and Jakarta Commons fileupload do not support multiple identical names. Given that the RFC says that the names should be unique, I'd say that the PHP parser is not the best basis for mbuni's design/functionality.

Why not support unique names as the RFC suggests, and thus allow the use of other (stricter) parsers?

On 29/04/2008, at 3:12 PM, P. A. Bagyenda wrote:
Giulio,

 Yes and no.

Most CGI processors accept multiple parameters with the same name, and process them based on whatever rules they impose. For instance PHP converts the parameter into an array if the parameter name(s) are of the form name[]. Other languages do different things. Try the attached PHP file as a simple example.

Mbuni for that reason also uses the same name for different parts as found.

<t.php>

On Apr 29, 2008, at 08:15, Giulio Harding wrote:

From the mbuni documentation (http://www.mbuni.org/ 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 (http://www.ietf.org/rfc/rfc2388.txt):

"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
MSN: [EMAIL PROTECTED]

http://www.mnetcorporation.com


_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel

_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel

--
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
MSN: [EMAIL PROTECTED]

http://www.mnetcorporation.com


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

_______________________________________________
Devel mailing list
Devel@mbuni.org
http://lists.mbuni.org/mailman/listinfo/devel

Reply via email to