leejo / cgi.pm Goto Github PK
View Code? Open in Web Editor NEWThe CGI.pm perl module
License: Artistic License 2.0
The CGI.pm perl module
License: Artistic License 2.0
https://rt.cpan.org/Ticket/Display.html?id=22737
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.
Check existing test coverage with Devel::Cover, et al, and increase where necessary. I would like to make sure we have a good level of test coverage, this can be done as a rolling task when addressing other issues.
https://rt.cpan.org/Ticket/Display.html?id=15065
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.
https://rt.cpan.org/Ticket/Display.html?id=70609
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.
https://rt.cpan.org/Ticket/Display.html?id=67666
CGI.pm lets you set a parameter value as
param('p', $v);
It would be slightly nicer if you could say
param('p') = $v;
https://rt.cpan.org/Ticket/Display.html?id=53628
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.
https://rt.cpan.org/Ticket/Display.html?id=15065
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.
https://rt.cpan.org/Ticket/Display.html?id=38100
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.
https://rt.cpan.org/Ticket/Display.html?id=65492
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.
https://rt.cpan.org/Ticket/Display.html?id=23823
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]
https://rt.cpan.org/Ticket/Display.html?id=35354
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)
https://rt.cpan.org/Ticket/Display.html?id=54055
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
https://rt.cpan.org/Ticket/Display.html?id=81935
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'.
https://rt.cpan.org/Ticket/Display.html?id=71799
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 !-)
https://rt.cpan.org/Ticket/Display.html?id=30057
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
https://rt.cpan.org/Ticket/Display.html?id=70284
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 ;
}
https://rt.cpan.org/Ticket/Display.html?id=53966
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:-)
https://rt.cpan.org/Ticket/Display.html?id=53628
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.
Point bugtracker at github
Migrate RT tickets to github:
https://rt.cpan.org/Ticket/Display.html?id=49690
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
To remove the dependency on FCGI from CGI.pm, this is a blocker for removing CGI.pm from core. Those wishing to install/upgrade CGI.pm when it is removed from core may have problems due to the FCGI dependency.
Suggest creating a new dist, cgi-fast, cloning CGI.pm repo then changing remotes. Thus preserving entire history in the new dist.
https://rt.cpan.org/Ticket/Display.html?id=15065
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.
https://rt.cpan.org/Ticket/Display.html?id=83365
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>
https://rt.cpan.org/Ticket/Display.html?id=61396
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.
https://rt.cpan.org/Ticket/Display.html?id=85595
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
https://rt.cpan.org/Ticket/Display.html?id=36312
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;
}
https://rt.cpan.org/Ticket/Display.html?id=57524
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.
https://rt.cpan.org/Ticket/Display.html?id=53701
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......
https://rt.cpan.org/Ticket/Display.html?id=54487
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.
https://rt.cpan.org/Ticket/Display.html?id=54511
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
Update and cleanup of perldoc and suggest alternatives to CGI.pm for developers new to perl
https://rt.cpan.org/Ticket/Display.html?id=65924
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.
https://rt.cpan.org/Ticket/Display.html?id=30940
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.
There's a Wikipedia page about CGI.pm:
http://en.wikipedia.org/wiki/CGI.pm
It could use a review for potential updates. I see that the "current version" there is out of date, although that doesn't seem important to maintain there. Perhaps that part can just be removed.
https://rt.cpan.org/Ticket/Display.html?id=82364
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?
https://rt.cpan.org/Ticket/Display.html?id=85595
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
https://rt.cpan.org/Ticket/Display.html?id=30057
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
https://rt.cpan.org/Ticket/Display.html?id=22737
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.
https://rt.cpan.org/Ticket/Display.html?id=54055
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
https://rt.cpan.org/Ticket/Display.html?id=55166
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.
https://rt.cpan.org/Ticket/Display.html?id=23823
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]
https://rt.cpan.org/Ticket/Display.html?id=75628
$ 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.
https://rt.cpan.org/Ticket/Display.html?id=65492
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.
https://rt.cpan.org/Ticket/Display.html?id=50576
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.
https://rt.cpan.org/Ticket/Display.html?id=51020
my $params = $cgi->Vars;
my $value = delete $params->{'value'};
$value is undef even if $params->{'value'} is not undef.
Use perlbrew for testing against all perls and add script (if necessary) for easy testing against all available perls. It is highly likely that people are still using CGI.pm with old old old perls.
https://rt.cpan.org/Ticket/Display.html?id=76189
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.
https://rt.cpan.org/Ticket/Display.html?id=51021
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.)
https://rt.cpan.org/Ticket/Display.html?id=79102
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
https://rt.cpan.org/Ticket/Display.html?id=52469
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.