POSTDATA [rt.cpan.org #70284] about cgi.pm HOT 3 CLOSED

[email protected] - 2011-08-16 14:30:12

Unfortunately, the code below demands a content type of some kind
or the script parses the content regardless. Unfortunately, recent
builds of Chrome have resulted in a version of the file uploader which
has no content value

We are most concerned with following standards, rather than specific
browsers. What do the standards stay about this case?

Links to specific RFC passages are helpful.

Mark

from cgi.pm.

http://cgfirecoral.myopenid.com/ - 2011-08-16 14:59:36

We are most concerned with following standards, rather than specific
browsers. What do the standards stay about this case?

Links to specific RFC passages are helpful.

Mark

Standards seem to be unclear about this. RFC 1867 covers
multipart/form-data in detail for file uploads and the code
handles this well. What isn't really discussed is what to
do when another non-form content type is passed (say image/jpeg).

I think this is a little late in the flow for standards to come
into play. CGI.pm attempts to provide the request in a useable
condition: either parsed parameters or as a single POSTDATA
parameter.

The content is parsed in the following situations:
content-type: application/x-www-form-urlencoded
content-type: multipart/form-data
content-type: none

It is not parsed in all other cases. The attempt to parse
when you have no content-type is directly contradictory to
the CGI.pm documentation for non-urlencoded arguments:

If POSTed data is not of type application/x-www-form-urlencoded or
multipart/form-data, then the POSTed data will not be processed, but
instead be returned as-is in a parameter named POSTDATA.

I would argue that it is a mistake to process content that
does match either of the encoded content-types.

from cgi.pm.

[email protected] - 2011-08-16 15:22:40

Thanks for spelling out the situation clearly. I'll give the proposal
due consideration.

from cgi.pm.