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.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
___
Devel mailing list
Devel@mbuni.org
