leejo / cgi.pm Goto Github PK

This is a design bug that will have to be fixed in a manner that allows
for backward compatibility (by providing an option to control which of
the two behaviors are used).

The labels for at least checkbox() and _box_group() should not have
their HTML escaped.  It is extremely useful (and, of course, valid) to
use HTML to style the labels of radio buttons and check-boxes.  It makes
little sense to escape the HTML of these labels.

When you create a popup_menu with CGI.pm (ex: print my_popup_menu(-
name=>'selection_serverlist',-default=>'' ,-multiple=>'true',-
values=>\@ep, -labels=>\%serverlist);) and you use multiple=>'true' 
you can select multiple items in the list and post them.

The problem in CGI.pm is that when you rebuild you page your selection 
is lost.
The CGI.pm module doesn't work with the hash that's being returned.
It only uses the first item in the has.

As a quick-fix I changed the following:

foreach (@values) {
    if (/<optgroup/) {
        foreach (split(/\n/)) {
            my $selectit = $XHTML ? 'selected="selected"' : 'selected';
            s/(value="$selected")/$selectit $1/ if defined $selected;
            $result .= "$_\n";
        }
    }
    else {
    my $temp_value = $_;
        for ( $self->param($name)) {
        if ($temp_value eq $_)  {
            $selected = $_;
        }
    }
        my $attribs = $self->_set_attributes($_, $attributes);
    my($selectit) = defined($selected) ? $self->_selected
($selected eq $_) : '';
    my($label) = $_;
    $label = $labels->{$_} if defined($labels) && defined($labels->
{$_});
    my($value) = $self->escapeHTML($_);
    $label=$self->escapeHTML($label,1);
        $result .= "<option${attribs} ${selectit}
value=\"$value\">$label</option>\n";
    }
}

The first 6 lines of the else are mine. They fix my problem with the 
multiple select.

Kind regards,
Tom

Fix (some) podchecker warnings:

*** WARNING: line containing nothing but whitespace in paragraph at line
267 in file lib/CGI/Carp.pm
*** WARNING: =item type mismatch ('definition' vs. 'number') at line
6992 in file lib/CGI.pm

Patched against 3.52 which rt.cpan.org doesn't seem to recognise.

I was recently investigating a bug in the development Bugzilla, and
discovered the problem was caused by CGI.pm's multipart_start() not
accepting a -charset parameter. This meant that is was impossible to
specify a UTF-8 multipart (without putting the charset in the content type).

So, I provided a patch to Bugzilla to modify their
Bugzilla::CGI::multipart_start() to accept -charset. This was provided
in https://bugzilla.mozilla.org/show_bug.cgi?id=357526 and subsequently
checked in: 
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/webtools/bugzilla/Bugzilla&command=DIFF_FRAMESET&file=CGI.pm&rev1=1.29&rev2=1.30&root=/cvsroot

It was suggested that this bug was reported upstream, so here it is...

Cheers,

John.

Not sure if it is worth to file a bug report, but I like it to have a
"clean" error_log to quickly detect relevant things:

calling url_param() with a query string like www.example.com?p1=1&&p2=2

cause an error:

Use of uninitialized value in hash element at (eval 109) line 14.
 at (eval 109) line 14

I assume, adding:

          my($param,$value);
          for (@pairs) {
+         next unless defined($_);
          ($param,$value) = split('=',$_,2);

into the url_param() will fix it.

Cheers
Heiko

I am seeing it running 3.05, but the source for 3.25 looks
the same.  Content-Disposition: header parsing is requiring
quotes around the values of parameters like name= and filename=
which is not what the RFC calls for.  Those can be quoted
strings or tokens (aka strings that do not require quoting.)

William Bardwell
[email protected]

CGI.pm lets you set a parameter value as

    param('p', $v);

It would be slightly nicer if you could say

    param('p') = $v;

I have noticed that a change was applied to perl (maint-5.12) in Jan
2011 which modified CGI.pm itself and added two new test scripts:
headers.t and multipart_init.t:

http://perl5.git.perl.org/perl.git/commit/b7fa2aca51

The first two changes do seem to have found their way back to the CGI.pm
CPAN distro, but the latter change -- the addition of multipart_init.t
-- appears to have been missed.

I've checked through every CPAN release from 3.48 through 3.59 and don't
see it anywhere, despite the Changes file for 3.52 claiming to have
fixed a logic error in it!

The current bleadperl version is attached. Could you please consider
including it (or a later version if you have one, perhaps including
whatever fixes 3.52's Changes file was referring to?) in future releases.

Summary

This ticket suggests a patch to read input not only from STDIN but from
an arbitrary handle.


Description:

CGI.pm is used to read input from STDIN. This works perfectly
when the script is running under web server control. For proxy
solutions, the situation is different as input and output of the final
CGI script are received (and written) via a socket.

 client <===> web server
        <===> STDIN/STDOUT | cgi-bin/proxy-script
        <===> socket | script using CGI.pm

For this to work for GET *and* POST requests it is required to pass the
socket as a parameter to CGI.pm. So, I'd like to suggest a patch that
adds this feature.

The constructor allows to pass a handle parameter already, but (as I
understand) this is meant for initialization in order to restore
sessions, or to read CGI parameters provided in Boulderio format, not to
process client data. So, I added another (optional) constructor
parameter. To allow further extensions it is a reference to a hash
containing "configuration settings", and is used like so:

 my $cgi = new CGI(undef, {client_handle => $handle});

The client_handle setting takes a handle to read input from. If this
setting is omitted the module should fall back to STDIN as usual.

This way, there should be no need to touch existing scripts - existing
features should be preserved and initialization via the first parameter
should continue to work.

Please see the attached patch against CGI.pm 3.48 that adds this
functionality.

The patched module passes all tests of the original distribution 3.48
and works successfully in a real project (using perl v5.10.0 built for
i686-pc-linux-gnu-64int, on Linux 2.6.30.9-64).

Would it be possible to add this feature to the distribution?

Thank you in advance

               Jochen

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 ;
    }

inspired by http://stackoverflow.com/questions/11343663
use CGI -utf8; would/could corrupt PUTDATA/POSTDATA -- fixed
I also add -putdata_upload to tread param('PUTDATA') same as file
uploads for lower memory footprint

postdata-CGI.pm-3.60.diff

Summary

This ticket suggests a patch to read input not only from STDIN but from
an arbitrary handle.


Description:

CGI.pm is used to read input from STDIN. This works perfectly
when the script is running under web server control. For proxy
solutions, the situation is different as input and output of the final
CGI script are received (and written) via a socket.

 client <===> web server
        <===> STDIN/STDOUT | cgi-bin/proxy-script
        <===> socket | script using CGI.pm

For this to work for GET *and* POST requests it is required to pass the
socket as a parameter to CGI.pm. So, I'd like to suggest a patch that
adds this feature.

The constructor allows to pass a handle parameter already, but (as I
understand) this is meant for initialization in order to restore
sessions, or to read CGI parameters provided in Boulderio format, not to
process client data. So, I added another (optional) constructor
parameter. To allow further extensions it is a reference to a hash
containing "configuration settings", and is used like so:

 my $cgi = new CGI(undef, {client_handle => $handle});

The client_handle setting takes a handle to read input from. If this
setting is omitted the module should fall back to STDIN as usual.

This way, there should be no need to touch existing scripts - existing
features should be preserved and initialization via the first parameter
should continue to work.

Please see the attached patch against CGI.pm 3.48 that adds this
functionality.

The patched module passes all tests of the original distribution 3.48
and works successfully in a real project (using perl v5.10.0 built for
i686-pc-linux-gnu-64int, on Linux 2.6.30.9-64).

Would it be possible to add this feature to the distribution?

Thank you in advance

               Jochen

$ perl -MCGI -E'say CGI->VERSION'
3.59

When POSTing a request with Content-Type: application/xml, the method 
param('POSTDATA') returns undef, instead the data end up under the 
undocumented parameter 'XForms:Model'. I expect param('POSTDATA') to 
always return the raw request body.

Older CGI.pm versions had the following code in the find_tempdir sub:

if( $CGI::OS eq 'WINDOWS' ){
    unshift @TEMP,
        $ENV{TEMP},
        $ENV{TMP},
        $ENV{WINDIR} . $SL . 'TEMP';
}

This was problematic because it could put 'undef' values onto the @TEMP
array.  This is fixed in 3.55 (and before) via the following:

# PeterH: These vars may not exist if this is invoked...
unshift(@TEMP,$ENV{TEMP}) if defined $ENV{TEMP};
unshift(@TEMP,$ENV{TMP}) if defined $ENV{TMP};
unshift(@TEMP,$ENV{WINDIR} . $SL . 'TEMP') if defined $ENV{WINDIR};

HOWEVER, this new code puts entries onto @TEMP in the opposite order of
the original code.  The result is that C:\WINDOWS\TEMP will be preferred
over the settings from the environment variables, which is *not* what
most people will want.  The order of the above three lines should be
reversed:

unshift(@TEMP,$ENV{WINDIR} . $SL . 'TEMP') if defined $ENV{WINDIR};
unshift(@TEMP,$ENV{TMP}) if defined $ENV{TMP};
unshift(@TEMP,$ENV{TEMP}) if defined $ENV{TEMP};

-----

An alternative fix would be to restore the old code and remove the other
'if defined' check that appears, and then change the line inside the loop:

 for (@TEMP) {
   do {$TMPDIRECTORY = $_; last} if -d $_ && -w _;
 }

to

   do {$TMPDIRECTORY = $_; last} if defined($_) && -d $_ && -w _;

Thanks!
-Jeff

PS: Yes, I am kind of ashamed of myself for using Perl with ms-win, but
I have no choice, I tellya, they've got my kids and won't release them
unless I cooperate !-)

From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64308:

Conforming to RFC2109, the 'Expires' field is deprecated in favour of
'Max-Age'. Please provide both fields to conform both "old"
specification and "modern" one.

E.g. this one should have also 'Max-Age' "field".

$ perl -MCGI::Cookie -le '$a=CGI::Cookie->new(q{-name} => 'ID',
q{-expires} => "+3M"); print $a->as_string()'
ID=; path=/; expires=Thu, 14-Jan-2010 19:51:06 GMT


Perl version: 5.10.1.
OS: Debian.

Currently, 'CGI::read_from_stdin()' contains this code:

        if ( $MOD_PERL ) {
        $res = $self->r->read($tempbuf, $bufsiz, 0)
    }
    else {
        $res = read(\*STDIN, $tempbuf, $bufsiz);
    }

###

Then CGI::PSGI came along and wanted to read from a source other than 
these two. So, it overloads 'read_from_stdin()' to essentially change 
one line:

  $res = $self->{psgi_env}{'psgi.input'}->read($tempbuf, $bufsiz, 0);


But now we've found a bug in 'read_from_stdin()', so we have some 
changes to it in 'git' (currently just in Yanick's branch), Once 
released, CGI::PSGI will need to be patched as well (and any other 
module that takes the same approach).

My proposal is to to make a routine that encapsulates the if/else logic 
above.

Then, CGI::PSGI could override just that. Also, it's step towards 
further isolating mod_perl-specific logic in CGI.pm. 

File upload methods like UploadInfo show that they need a filename as 
argument.

Everything is fine with the sample using ->param to get this filename, 
but if you use ->Vars to get all arguments as a hash (ref) and then use 
UploadInfo on the correct hash value, it doesn't work.

It maybe a subject for the wishlist but i think that it's more important

my @styles = ( { -src => 'styles/mystyle.css', -title => 'default'} );
print header(-type=>'application/xhtml+xml',
             -charset=>'utf-8'),
    start_html(-encoding => 'utf-8',
               -style=>\@styles,
               -declare_xml => 'true');

As it is documented, -declare_xml will outputs this:
<?xml version="1.0" encoding="utf-8"?>
and later, start_html outputs this
<link rel="stylesheet" type="text/css" href="styles/mystyle.css"
title="default"/>

Then, my XHTML when loaded (i did test with firefox) doesn't load my CSS.

Here is what it has to be:
<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/css" href="mystyle.css"?>                  



Documentation:
(http://www.w3schools.com/xml/xml_display.asp)

So in init there is this code:

      # If method is GET or HEAD, fetch the query from
      # the environment.
      if ($meth=~/^(GET|HEAD)$/) {
          if ($MOD_PERL) {
            $query_string = $self->r->args;
          } else {
              $query_string = $ENV{'QUERY_STRING'} if defined
$ENV{'QUERY_STRING'};
              $query_string ||= $ENV{'REDIRECT_QUERY_STRING'} if defined
$ENV{'REDIRECT_QUERY_STRING'};
          }
          last METHOD;
      }

Due to internal redirects I was losing the form in mod_perl.  I created
an override library for myself this has this change which fixed the issue:

      # If method is GET or HEAD, fetch the query from
      # the environment.
      if ($meth=~/^(GET|HEAD)$/) {
          if ($MOD_PERL) {
            $query_string = $self->r->args;
            $query_string ||= $ENV{'REDIRECT_QUERY_STRING'} if defined
$ENV{'REDIRECT_QUERY_STRING'} && $query_string eq '';
          } else {
              $query_string = $ENV{'QUERY_STRING'} if defined
$ENV{'QUERY_STRING'};
              $query_string ||= $ENV{'REDIRECT_QUERY_STRING'} if defined
$ENV{'REDIRECT_QUERY_STRING'};
          }
          last METHOD;
      }

Patch is to add preliminary support (& documentation) for conditional
comments around style sheets.  With the patch, the -style option accepts
a -cond argument.  For example,
  print start_html(-style => {
    -media => 'all',
    -cond => ['.foo {color: navy;}', '/style/1_IE.css', 
          [5, '/style/IE5.css'],
          {-src => ['/style/2_IE.css', '/style/3_IE.css'], 
           -code => '.bar {padding: 1em;}'}, 
          ['/style/4.css'],
          ['!', '/style/notIE.css'],
          {-expr => '((>=7)|(! 5)&IE',
           -src => '/style/complex_IE.css',
           -code => '.foo, .bar { border: #800;}'}
    ]
    }
  );
produces
  <!--[if IE]>
  <style type="text/css">
  .foo {color: navy;}
  </style>
  <link rel="stylesheet" type="text/css" href="/style/1_IE.css" media="all">
  <link rel="stylesheet" type="text/css" href="/style/2_IE.css" media="all">
  <link rel="stylesheet" type="text/css" href="/style/3_IE.css" media="all">
  <style type="text/css">
  <!-- 
  .bar {padding: 1em;}
   -->
  </style>
  <![endif]-->
  <!--[if  IE 5]>
  <link rel="stylesheet" type="text/css" href="/style/IE5.css" media="all">
  <![endif]-->
  <!--[if IE]>
  <link rel="stylesheet" type="text/css" href="/style/4.css" media="all">
  <![endif]-->
  <![if ! IE]>
  <link rel="stylesheet" type="text/css" href="/style/notIE.css" >
  <![endif]>
  <!--[if ((gte IE 7)|(! IE 5)&IE]>
  <link rel="stylesheet" type="text/css" href="/style/complex_IE.css"
media="all">
  <style type="text/css">
  <!-- 
  .foo, .bar { border: #800;}
   -->
  </style>
  <![endif]-->

Coming eventually: conditional comments for scripts and arbitrary header
elements.

When using mod_perl with CGI::Cookie, the recommended way to set cookies is:

$r->headers_out->set('Set-Cookie' => $c);

but when running as a cgi script the recommended way to set cookies is:

print header(-cookie=>$c);

So here's the problem: when running as a cgi script using a mod_perl emulator (such as HTML::Mason::FakeApache or Apache::Emulator) we would like to use the mod_perl recommended method, so we can switch transparently between mod_perl and cgi.  However, using the 'Set-Cookie' header does not work with *multiple* cookies, because CGI.pm only looks for multiple cookies under the 'Cookie' or 'Cookies' headers.

According to the POD, CGI::Fast honors the environment variables
FCGI_SOCKET_PATH and FCGI_LISTEN_QUEUE. However, experimentally these
variables only take effect if assigned in a BEGIN block prior to loading
CGI::Fast. Without this, invoking the program causes it to simply run
once and exit. eg.

#!perl
use CGI::Fast;

local $ENV{FCGI_SOCKET_PATH} = ":9000";
local $ENV{FCGI_LISTEN_QUEUE} = 20;

while ($q = CGI::Fast->new) {
    print $q->header;
    print "<html><body>The foo input is ", $q->param('foo'),
"</body></html>";
}

prints 

Content-Type: text/html; charset=ISO-8859-1

<html><body>The foo input is </body></html>


on STDOUT and exits immediately. To fix this you have to change the code
as follows:

BEGIN {
    $ENV{FCGI_SOCKET_PATH} = ":9000";
    $ENV{FCGI_LISTEN_QUEUE} = 20;
}
use CGI::Fast;

I can't say whether this is a code or POD bug since I'm not sure what
the original intent was, but it's definitely one or the other.

The distname being CGI.pm breaks a number of things, and in doing so goes against a 
convention used by nearly every other dist on CPAN.

Fix: change the distname to be 'CGI'.

In one of my scripts, before I load CGI.pm, I have an encoding() layer 
set on STDOUT. Simply calling "use CGI;" will remove that layer, because 
CGI.pm does this:

if ($needs_binmode) {
    $CGI::DefaultClass->binmode(\*main::STDOUT);
    $CGI::DefaultClass->binmode(\*main::STDIN);
    $CGI::DefaultClass->binmode(\*main::STDERR);
}

  Thus clearing any already-pushed IO layer.

When using mod_perl with CGI::Cookie, the recommended way to set cookies is:

$r->headers_out->set('Set-Cookie' => $c);

but when running as a cgi script the recommended way to set cookies is:

print header(-cookie=>$c);

So here's the problem: when running as a cgi script using a mod_perl emulator (such as HTML::Mason::FakeApache or Apache::Emulator) we would like to use the mod_perl recommended method, so we can switch transparently between mod_perl and cgi.  However, using the 'Set-Cookie' header does not work with *multiple* cookies, because CGI.pm only looks for multiple cookies under the 'Cookie' or 'Cookies' headers.

The first request to a CGI::Fast daemon is recording certain environment 
variables, and later requests are getting these as defaults if none are 
defined.

The two which have affected me are HTTP_COOKIE, and PATH_INFO.

If the first request has no value, then all subsequent requests are 
fine. However, if the first request has values, then these become 
defaults for future requests which otherwise would have no value.

I've tested it both with dynamically starting FastCGIs, and with pre-
initialised ones via FastCGIServer, and both exhibit the same behaviour.

I've attached a test FastCGI script (test1) which illustrates the 
problem. If you access it from a browser which has a cookie within the 
path, or use an extra path, and then access it from a different browser 
with no cookie/path, you get the cookie/path showing up.

This is a pretty big problem for apps which use a cookie to track a 
session for authentication. If a pre-existing user accesses the app, 
then their session cookie gets saved as the default, and subsequent 
anonymous requests show up as authenticated to that user.

There may also be other env vars suffering the same issue, but these 
were the two key ones that are impacting my apps.

As some further tests, I tested using just FCGI by itself (see test2). 
It did not show the problem.

I then used a FCGI main loop, but using CGI internally (ie; not using 
CGI::Fast) (see test3), and it also did not show the problem.

I copied CGI/Fast.pm, and found that if I added:
  $Ext_Request = FCGI::Request();
...to BEGIN, if there's no FCGI_SOCKET_PATH, then using CGI::Fast works 
fine.

ie;

BEGIN {
   # ...
   if ($ENV{FCGI_SOCKET_PATH}) {
   # ...
   }
   else
   {
      $Ext_Request = FCGI::Request();
   }
}

It seems that using one request, rather than just calling 
FCGI::accept(), works properly.

Before I pinpointed the issue, I updated my CGI perl libs from CPAN, so 
am using 3.52. The FCGI lib is 0.7.1. The server runs Debian Linux 
5.0.6, with kernel 2.6.31.5. Perl is version 5.10.0.

CGI::Util's escape and unescape methods are useful outside of just the internals of CGI.pm.  
Because of this, it would be nice if these methods had exposure in the documentation so that 
they would be more accessible to developers.

When you create a popup_menu with CGI.pm (ex: print my_popup_menu(-
name=>'selection_serverlist',-default=>'' ,-multiple=>'true',-
values=>\@ep, -labels=>\%serverlist);) and you use multiple=>'true' 
you can select multiple items in the list and post them.

The problem in CGI.pm is that when you rebuild you page your selection 
is lost.
The CGI.pm module doesn't work with the hash that's being returned.
It only uses the first item in the has.

As a quick-fix I changed the following:

foreach (@values) {
    if (/<optgroup/) {
        foreach (split(/\n/)) {
            my $selectit = $XHTML ? 'selected="selected"' : 'selected';
            s/(value="$selected")/$selectit $1/ if defined $selected;
            $result .= "$_\n";
        }
    }
    else {
    my $temp_value = $_;
        for ( $self->param($name)) {
        if ($temp_value eq $_)  {
            $selected = $_;
        }
    }
        my $attribs = $self->_set_attributes($_, $attributes);
    my($selectit) = defined($selected) ? $self->_selected
($selected eq $_) : '';
    my($label) = $_;
    $label = $labels->{$_} if defined($labels) && defined($labels->
{$_});
    my($value) = $self->escapeHTML($_);
    $label=$self->escapeHTML($label,1);
        $result .= "<option${attribs} ${selectit}
value=\"$value\">$label</option>\n";
    }
}

The first 6 lines of the else are mine. They fix my problem with the 
multiple select.

Kind regards,
Tom

CGI::cookie() does not persist the utf8_on() flag of cookie names and 
values. This leads to different bugs, for example, Bugzilla bug tracker 
does not remember selected "Version" if its value is not latin1.

A fixed implementation could look like... (see attach)

?

-----------------------------------------------------------------

---
Flags:
    category=library
    severity=medium

---
Site configuration information for perl 5.10.0:

Configured by Debian Project at Sun Aug 16 22:37:28 UTC 2009.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.6.26-2-amd64, archname=i486-linux-gnu-thread-
multi
    uname='linux puccini 2.6.26-2-amd64 #1 smp fri aug 14 07:12:04 utc 
2009 i686 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -
Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/
usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -
Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/
usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/
lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/
man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/
man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -
Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -
Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-
aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -
pipe -I/usr/local/include'
    ccversion='', gccversion='4.3.4', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/lib64
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.9.so, so=so, useshrplib=true, 
libperl=libperl.so.5.10.0
    gnulibc_version='2.9'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'

Locally applied patches:


---
@INC for perl 5.10.0:
    /etc/perl
    /usr/local/lib/perl/5.10.0
    /usr/local/share/perl/5.10.0
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.10
    /usr/share/perl/5.10
    /usr/local/lib/site_perl
    .

---
Environment for perl 5.10.0:
    HOME=/home/vitali
    LANG=ru_RU.UTF-8
    LANGUAGE=
    LD_LIBRARY_PATH=:/usr/lib/oracle/xe/app/oracle/product/10.2.0/
client/lib:/usr/lib/oracle/xe/app/oracle/product/10.2.0/client/lib
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/oracle/xe/app/
oracle/product/10.2.0/client/bin:/usr/lib/oracle/xe/app/oracle/
product/10.2.0/client/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

A PUT HTTP request with no body and no Content-Length or Content-Type
headers seems to freeze up CGI->new(). I found this while trying to
install Test::WWW::Mechanize, whose t/put_ok.t script fails under CGI
versions 3.44, 3.45, and 3.48. 3.43 works fine, as does 3.29; I haven't
tested any others.

Steps to reproduce:
1. install CGI 3.44 or later
2. get Test::WWW::Mechanize (I'm using 1.24 but I don't think it matters)
3. unpack T::WWW::M
4. in the T::WWW::M directory, call "perl Makefile.PL" and "make" to set
up the blib/ directory
5. in the T::WWW::M directory, call "prove -bv t/put_ok.t". The HTTP PUT
requests will time out.

I have narrowed the path of execution down to this:
* T::WWW::M's test t/put_ok.t calls the testserver in t/TestServer.pm
* TestServer subclasses HTTP::Server::Simple::CGI
* The method HTTP::Server::Simple::CGI::handler calls CGI->new()
* CGI->new() calls CGI->init()
* CGI->init() calls CGI->read_from_stdin() around line 651
* CGI->read_from_stdin() never returns

It's difficult to say that this is invalid behaviour, since the utility
of an empty PUT request is questionable. However there's nothing in the
RFC I can see which explicitly forbids an empty PUT request, and if
there's no Content-Length header then it's certainly possible that
there's no body to the HTTP request.

In any case, even if you think an empty HTTP PUT request is invalid, CGI
should probably fail gracefully rather than getting stuck.

I had previously raised this issue with T::WWW::M before finding out
that CGI is probably responsible. The previous discussion can be viewed
here:
http://code.google.com/p/www-mechanize/issues/detail?id=127

There is problem in method rearrange, when is last or any value
empty(undef). If is value undefined that can be printed in this format:

<form method="post" action="/index.pl" id> 

I was recently investigating a bug in the development Bugzilla, and
discovered the problem was caused by CGI.pm's multipart_start() not
accepting a -charset parameter. This meant that is was impossible to
specify a UTF-8 multipart (without putting the charset in the content type).

So, I provided a patch to Bugzilla to modify their
Bugzilla::CGI::multipart_start() to accept -charset. This was provided
in https://bugzilla.mozilla.org/show_bug.cgi?id=357526 and subsequently
checked in: 
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/webtools/bugzilla/Bugzilla&command=DIFF_FRAMESET&file=CGI.pm&rev1=1.29&rev2=1.30&root=/cvsroot

It was suggested that this bug was reported upstream, so here it is...

Cheers,

John.

When using mod_perl with CGI::Cookie, the recommended way to set cookies is:

$r->headers_out->set('Set-Cookie' => $c);

but when running as a cgi script the recommended way to set cookies is:

print header(-cookie=>$c);

So here's the problem: when running as a cgi script using a mod_perl emulator (such as HTML::Mason::FakeApache or Apache::Emulator) we would like to use the mod_perl recommended method, so we can switch transparently between mod_perl and cgi.  However, using the 'Set-Cookie' header does not work with *multiple* cookies, because CGI.pm only looks for multiple cookies under the 'Cookie' or 'Cookies' headers.

I am seeing it running 3.05, but the source for 3.25 looks
the same.  Content-Disposition: header parsing is requiring
quotes around the values of parameters like name= and filename=
which is not what the RFC calls for.  Those can be quoted
strings or tokens (aka strings that do not require quoting.)

William Bardwell
[email protected]

Currently, 'CGI::read_from_stdin()' contains this code:

        if ( $MOD_PERL ) {
        $res = $self->r->read($tempbuf, $bufsiz, 0)
    }
    else {
        $res = read(\*STDIN, $tempbuf, $bufsiz);
    }

###

Then CGI::PSGI came along and wanted to read from a source other than 
these two. So, it overloads 'read_from_stdin()' to essentially change 
one line:

  $res = $self->{psgi_env}{'psgi.input'}->read($tempbuf, $bufsiz, 0);


But now we've found a bug in 'read_from_stdin()', so we have some 
changes to it in 'git' (currently just in Yanick's branch), Once 
released, CGI::PSGI will need to be patched as well (and any other 
module that takes the same approach).

My proposal is to to make a routine that encapsulates the if/else logic 
above.

Then, CGI::PSGI could override just that. Also, it's step towards 
further isolating mod_perl-specific logic in CGI.pm. 

Right now, STORE in the TIEHASH interface does this:

    my @vals = index($vals,"\0")!=-1 ? split("\0",$vals) : $vals;

But if $vals is an arrayref, it should really just store the arrayref.
(This would allow me to use the Vars tiehash interface interchangeably
with other hashes that might be passed into a method.)

Core perl ships CGI.pm but not FCGI.  Everything works fine.

Users cannot upgrade CGI later, though, because FCGI will be required, even for the same version.  This makes it difficult to consider dropping CGI.pm from the core perl distribution, because it becomes much more difficult to install CGI outside core.

Clearly CGI.pm can operate without FCGI.  Please make FCGI a recommendation or option, rather than a hard requirement when installed from the CPAN distribution.

Thank you.

-- 
rjbs

The CGI.pm HTML generator produces an empty anchor tag:

------------------------------------
lizard:~5.10$ pwd
/usr/share/perl/5.10
lizard:~5.10$ perl -e 'use CGI ":standard";
                       print a({-name=>"my-anchor"}), "\n";'
<a name="my-anchor" />
lizard:~5.10$ 
-----------------------------------

This isn't a valid tag in xhtml (check the DTD for xhtml 1.0 strict or
transitional) and in particular, causes problems with firefox and safari
(which is how I came to investigate this).
The correct representation should be:
<a name="my-anchor"></a>

This seems like something that would be easy to fix......

Sometimes it is useful for CGI::Carp not to add a timestamp to error
messages.  The web server may add its own timestamp anyway, and you may
prefer that any error output from the script should be identical from
one run to the next.  This patch adds a new 'noTimestamp' option or
$NO_TIMESTAMP package variable.  Please could you consider this feature
for inclusion in the next version?

I found a problem with upload of attachments using apache2, mod_perl2
and bugzilla running on Windows.
If I run apache as a service, CGItemp# files are correctly created and
read in c:\windows\temp, but if I run apache from the command
line/terminal, upload of attachments doesn't work (PS: only when using
mod_perl): now it (CGI.pm) (tries to) reads CGItemp# files from
C:\DOCUME~1\monster\LOCALS~1\Temp folder (the folder exists, no
problem), but it never creates/writes the temp files!? (found out using
Sysinternals FileMonitor).

Workaround was to set fixed temp dir:
$CGITempFile::TMPDIRECTORY = 'c:/temp';
It took a long time for me to figure this out.

Please fix so the next guy doesn't won't have to figure out:-)
Bug exists in at least 3.41 and 3.48.
I can assist if you need me:-)

my $params = $cgi->Vars;
my $value = delete $params->{'value'};

$value is undef even if $params->{'value'} is not undef.

The first request to a CGI::Fast daemon is recording certain environment 
variables, and later requests are getting these as defaults if none are 
defined.

The two which have affected me are HTTP_COOKIE, and PATH_INFO.

If the first request has no value, then all subsequent requests are 
fine. However, if the first request has values, then these become 
defaults for future requests which otherwise would have no value.

I've tested it both with dynamically starting FastCGIs, and with pre-
initialised ones via FastCGIServer, and both exhibit the same behaviour.

I've attached a test FastCGI script (test1) which illustrates the 
problem. If you access it from a browser which has a cookie within the 
path, or use an extra path, and then access it from a different browser 
with no cookie/path, you get the cookie/path showing up.

This is a pretty big problem for apps which use a cookie to track a 
session for authentication. If a pre-existing user accesses the app, 
then their session cookie gets saved as the default, and subsequent 
anonymous requests show up as authenticated to that user.

There may also be other env vars suffering the same issue, but these 
were the two key ones that are impacting my apps.

As some further tests, I tested using just FCGI by itself (see test2). 
It did not show the problem.

I then used a FCGI main loop, but using CGI internally (ie; not using 
CGI::Fast) (see test3), and it also did not show the problem.

I copied CGI/Fast.pm, and found that if I added:
  $Ext_Request = FCGI::Request();
...to BEGIN, if there's no FCGI_SOCKET_PATH, then using CGI::Fast works 
fine.

ie;

BEGIN {
   # ...
   if ($ENV{FCGI_SOCKET_PATH}) {
   # ...
   }
   else
   {
      $Ext_Request = FCGI::Request();
   }
}

It seems that using one request, rather than just calling 
FCGI::accept(), works properly.

Before I pinpointed the issue, I updated my CGI perl libs from CPAN, so 
am using 3.52. The FCGI lib is 0.7.1. The server runs Debian Linux 
5.0.6, with kernel 2.6.31.5. Perl is version 5.10.0.

Core perl ships CGI.pm but not FCGI.  Everything works fine.

Users cannot upgrade CGI later, though, because FCGI will be required, even for the same version.  This makes it difficult to consider dropping CGI.pm from the core perl distribution, because it becomes much more difficult to install CGI outside core.

Clearly CGI.pm can operate without FCGI.  Please make FCGI a recommendation or option, rather than a hard requirement when installed from the CPAN distribution.

Thank you.

-- 
rjbs

The url() method in CGI.pm examines the X-Forwarded-Host header to
determine the vhost name, but does not cater for this header containing
a comma-separated list (which can happen if the request has passed
through multiple reverse proxies).

The apache documentation
<http://httpd.apache.org/docs/2.2/mod/mod_proxy.html> says:

"Be careful when using these headers on the origin server, since they
will contain more than one (comma-separated) value if the original
request already contained one of these headers."

The Catalyst code caters for this by taking the last value in the list.
The attached patch makes CGI.pm follow the same behaviour.