Multiple values for single name in multipart/form-data for MMS service HTTP POST

 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.o
rg/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: giulio.hardingmnetcorporation.com

http://www.mnetcorpora
tion.com



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

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.




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.o
rg/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: giulio.hardingmnetcorporation.com
>
> http://www.mnetcorpora
tion.com
>
>
> _______________________________________________
> Devel mailing list
> Develmbuni.org
> http://
lists.mbuni.org/mailman/listinfo/devel


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

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.o
rg/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: giulio.hardingmnetcorporation.com
>>
>> http://www.mnetcorpora
tion.com
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Develmbuni.org
>> http://
lists.mbuni.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Develmbuni.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: giulio.hardingmnetcorporation.com

http://www.mnetcorpora
tion.com



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

We support unique names, we simply don't guarantee that they
are  
unique, if the message contains multiple parts of the same
type and/or  
the http-post-parameters is constructed in such a way as not
to ensure  
they are unique.

PHP is certainly not the ideal poster boy of Web languages I
agree,  
but it is common and so we are stuck with it. To be sure we
did not  
base this on what PHP does, rather we found that since a
number of  
engines support this seamlessly (see Python, Perl, and so
on), and  
your typical web clients (firefox, IE, etc) are perfectly
happy  
sending multiple fields with the same name, then there is no
reason  
for us to hard-code field generation in a way that might not
be  
flexible for the end-user (programmer). And we think Python,
PHP et al  
take the right view that it is better to be liberal in what
you  
accept. The resulting code on the client side is also
typically  
cleaner than what one might have dealing with many different
names.

In short, I am open to suggestions, but really in this case
I am not  
convinced that Oreilly/Jakarta guys took the best position!

P.

On Apr 29, 2008, at 10:04, Giulio Harding wrote:

> 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.o
rg/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: giulio.hardingmnetcorporation.com
>>>
>>> http://www.mnetcorpora
tion.com
>>>
>>>
>>>
_______________________________________________
>>> Devel mailing list
>>> Develmbuni.org
>>> http://
lists.mbuni.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> Devel mailing list
>> Develmbuni.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: giulio.hardingmnetcorporation.com
>
> http://www.mnetcorpora
tion.com
>
>

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