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: 49674
Status: resolved
Priority: 0/
Queue: CGI

People
Owner: Nobody in particular
Requestors: cbbs70a [...] hotmail.com
Cc:
AdminCc:

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



Subject: Error passing a large number of named parameters
Download (untitled) / with headers
text/plain 256b
I seemed to have hit a limit on the number of parameters I can pass to a cgi script. Using @values = $query->param, values stop being read somewhere around 400 values. However, for a smaller number of parameters, I have no problem. Is this a bug in CGI.pm?
Subject: Re: [rt.cpan.org #49674] Error passing a large number of named parameters
Date: Sun, 13 Sep 2009 17:18:38 -0400
To: bug-CGI.pm [...] rt.cpan.org
From: Yanick Champoux <yanick [...] babyl.dyndns.org>
Download (untitled) / with headers
text/plain 746b
FSD via RT wrote: Show quoted text
> I seemed to have hit a limit on the number of parameters I can pass to a > cgi script. Using @values = $query->param, values stop being read > somewhere around 400 values. However, for a smaller number of > parameters, I have no problem. Is this a bug in CGI.pm?
It is more likely that you are hitting some limit of your browser or web server. Are the parameters passed via POST or GET? In the latter case, urls begin to get iffy for certain browsers/servers when they reach 2,000 characters. With 400 parameters, I'd suspect your not too far from that limit. In all cases, can you give us details of your setting (web server, browser used to submit the request) to give us more insight at your particular case?
From: frank [...] digennaro.com
Download (untitled) / with headers
text/plain 1.3k
On Sun Sep 13 17:16:16 2009, yanick@babyl.dyndns.org wrote: Show quoted text
> FSD via RT wrote:
> > I seemed to have hit a limit on the number of parameters I can pass to a > > cgi script. Using @values = $query->param, values stop being read > > somewhere around 400 values. However, for a smaller number of > > parameters, I have no problem. Is this a bug in CGI.pm?
> > It is more likely that you are hitting some limit of your browser or > web server. Are the parameters passed via POST or GET? In the latter > case, urls begin to get iffy for certain browsers/servers when they > reach 2,000 characters. With 400 parameters, I'd suspect your not too > far from that limit. > > > In all cases, can you give us details of your setting (web server, > browser used to submit the request) to give us more insight at your > particular case?
I am using Webmin version 1.480 as the web server and Firefox 3.5.3. The method is post and I am not sending the parameters via the query string in the url. I am reading them like this in a loop. $value = $query-> param($var). All is well for awhile, but before it is finished, the data stops being read, usually halfway through the read. if $value = $query-> param($var400), and $value should equal "john doe", I can get $value = "joh" and thats it. All other values after that are missing.
Download (untitled) / with headers
text/plain 626b
On Mon Sep 14 10:29:16 2009, cbbs70a wrote: Show quoted text
> I am using Webmin version 1.480 as the web server
Unless I'm mistaken, Webmin is an administrative interface, not the web server itself. I'm attaching a small form and cgi that I've quickly put together to see if I can reproduce your problem. The form has 500 elements and the cgi prints them all. I'm using Apache 2 and Firefox, and don't have any issue with it. In all case, CGI.pm doesn't have any limit on the number/size of parameters, the bottleneck is how many can the browser/server can deal with. Chances are this is where you're hitting your snag. Joy, `/anick
Download print-500.zip
application/zip 6.8k

Message body not shown because it is not plain text.

From: cbbs70a [...] hotmail.com
Download (untitled) / with headers
text/plain 622b
On Mon Sep 14 21:20:29 2009, YANICK wrote: Show quoted text
> On Mon Sep 14 10:29:16 2009, cbbs70a wrote:
> > I am using Webmin version 1.480 as the web server
> > Unless I'm mistaken, Webmin is an administrative interface, not the web > server itself. > > I'm attaching a small form and cgi that I've quickly put together to see > if I can reproduce your problem. The form has 500 elements and the cgi
Actually, Webmin has a small web server written in PERL called miniserv.pl. The thing for me to do is move the scripts and try them under Apache and see what happens. That will tell me alot, hopefully enough to know whats wrong.
From: cbbs70a [...] hotmail.com
Download (untitled) / with headers
text/plain 169b
Ok, I was able to verify that reading in 1,000 parameters under Apache worked, however, it did not work under Webmin/miniserv.pl. My mistake. This should be closed out.
Subject: Re: [rt.cpan.org #49674] Error passing a large number of named parameters
Date: Thu, 17 Sep 2009 19:15:47 -0400
To: bug-CGI.pm [...] rt.cpan.org
From: Yanick Champoux <yanick [...] babyl.dyndns.org>
Download (untitled) / with headers
text/plain 684b
FSD via RT wrote: Show quoted text
> Tue Sep 15 09:55:43 2009: Request 49674 was acted upon. > Transaction: Correspondence added by cbbs70a > Queue: CGI.pm > Subject: Error passing a large number of named parameters > Broken in: (no value) > Severity: Important > Owner: Nobody > Requestors: cbbs70a@hotmail.com > Status: open > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=49674 > > > > Ok, I was able to verify that reading in 1,000 parameters under Apache > worked, however, it did not work under Webmin/miniserv.pl. My mistake. > This should be closed out
Okay. It will. Thanks for your input, and good luck in your bug hunting! Joy, `/anick
Download (untitled) / with headers
text/plain 195b
Thanks for the help triaging this Yanick. In a case like this I would be interested to check the $CGI::POST_MAX value, although that turned out not to be the issue here. Marking as resolved.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.