Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CGI CPAN distribution.

Report information
The Basics
Id: 70284
Status: rejected
Priority: 0/
Queue: CGI

People
Owner: Nobody in particular
Requestors: perl [...] firecoral.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Subject: POSTDATA
The documentation says that POSTDATA (or PUTDATA) will be used if the content type is not: application/x-www-form-urlencoded multipart/form-data 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, so CGI.pm can't obtain the uploaded file information. Starting around line 700: # YL: Begin Change for XML handler 10/19/2001 if (!$is_xforms && ($meth eq 'POST' || $meth eq 'PUT') && defined($ENV{'CONTENT_TYPE'}) && $ENV{'CONTENT_TYPE'} !~ m|^application/x-www-form-urlencoded| && $ENV{'CONTENT_TYPE'} !~ m|^multipart/form-data| ) { my($param) = $meth . 'DATA' ; $self->add_parameter($param) ; push (@{$self->{param}{$param}},$query_string); undef $query_string ; } # YL: End Change for XML handler 10/19/2001 ----------------------------------- The following code is a potential (albeit ugly) fix: if (!$is_xforms && ($meth eq 'POST' || $meth eq 'PUT') && (!defined($ENV{'CONTENT_TYPE'}) || (defined($ENV{'CONTENT_TYPE'}) && $ENV{'CONTENT_TYPE'} !~ m|^application/x-www-form-urlencoded| && $ENV{'CONTENT_TYPE'} !~ m|^multipart/form-data| ))) { my($param) = $meth . 'DATA' ; $self->add_parameter($param) ; push (@{$self->{param}{$param}},$query_string); undef $query_string ; }
Subject: Re: [rt.cpan.org #70284] POSTDATA
Date: Tue, 16 Aug 2011 08:43:15 -0400
To: bug-CGI.pm [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Show quoted text
> 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
Show quoted text
> 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.
CC: undisclosed-recipients:;, "http://cgfirecoral.myopenid.com/ via RT" <bug-cgi.pm [...] rt.cpan.org>
Subject: Re: [rt.cpan.org #70284] POSTDATA
Date: Tue, 16 Aug 2011 11:22:32 -0400
To: bug-CGI.pm [...] rt.cpan.org
From: Mark Stosberg <mark [...] summersault.com>
Thanks for spelling out the situation clearly. I'll give the proposal due consideration.
This issue has been copied to: https://github.com/leejo/CGI.pm/issues/88 please take all future correspondence there. This ticket will remain open but please do not reply here. This ticket will be closed when the github issue is dealt with.
On Tue Aug 16 10:59:36 2011, http://cgfirecoral.myopenid.com/ wrote: Show quoted text
> > 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.
So what's the fix here? I have committed the below change in rt/70284 (see github), but this is likely to break backwards compatibility. It is also causing a few tests to fail. commit 9a24603b6fa32e6dba69a0aff9944114587b754d Author: Lee Johnson <lee@givengain.ch> Date: Fri Jul 25 16:54:13 2014 +0200 resolve #88 [rt.cpan.org #70284] - POSTDATA parsing tweaks this also includes a resolution for #87 [rt.cpan.org #69958] TODO: fix tests and squash merge to another branch for peer-review tweaks are to make POSTDATA/PUTDATA set when the CONTENT_TYPE env variable is empty (brings inline with the documentation) - this is to prevent the module trying to parse data such as binary content into params, which is never going to work. the important step is the call to undef the $query_string variable, after setting the POSTDATA/PUTDATA, which has now been commented arguably it is a mistake to process content that doesn't match the application/x-www-form-urlencoded or multipart/form-data, however the change to enter the logic to set POSTDATA/PUTDATA when there is no CONTENT_TYPE could be a backward incompatible change, hence it will sit here in a branch until i have looked into this some more Changes | 3 +++ lib/CGI.pm | 35 +++++++++++++++++++++++++++++------ t/delete.t | 19 +++++++++++++------ t/request.t | 3 ++- 4 files changed, 47 insertions(+), 13 deletions(-)
Closing, no response in close to a year and the fix breaks backward compat. Not going to spend anymore time on this.