[Resolved] $_GET element limit??

[Cailean]

I have a dynamically generated HTML form which structured as shown below. It appears that the form freezes (buttons do nothing) whenever the user enters values for X and Y whose product exceeds 100. Is the $_GET array limited to 100 elements?

I have already determined that it is not a character limit on the generated URL...

<?php
$X=$_GET['X']; 
$Y=$_GET['Y']; 
$Z=$_GET['Z']; 
echo '<form action="'.$PHP_SELF.'" method="get">';
echo 'Number of Classrooms:<input type="text" size="3" name="X" value="'.$X.'"><br />';
echo 'Number of Students per room:<input type="text" size="3" name="Y" value="'.$Y.'">';
echo '<br /><br />';
echo '<input type="submit" name="submit" value="Submit">';
echo '<input type="submit" name="reset" value="Reset"><br />';
for($xcounter=1; $xcounter<=$X; $xcounter++){
	echo '<br />Classroom #'.$xcounter.':<br />';
	for($ycounter=1; $ycounter<=$Y; $ycounter++){
		echo 'Student #'.$ycounter.'<input type="text" size="15" name="Z['.$xcounter.']['.$ycounter.']" value="'.$Z[$xcounter][$ycounter].'"><br />'; 
	} 
}
echo '</form>';
?>

Any thoughts on how I can get more than 100 students would be appreciated.

[Weedpacket]

use POST for your method instead of GET.

[Roger_Ramjet]

I don't know of any limit in the URL per se, but most proxies will limit the maximun size of a http request, ie if it more than 3Kb forget it. So you have a practical limit of @3000 chars.

[Weedpacket]

Originally posted by Roger Ramjet
I don't know of any limit in the URL per se, but most proxies will limit the maximun size of a http request, ie if it more than 3Kb forget it. So you have a practical limit of @3000 chars.

That must really screw up file uploads.

[Cailean]

Originally posted by Roger Ramjet
I don't know of any limit in the URL per se, but most proxies will limit the maximun size of a http request, ie if it more than 3Kb forget it. So you have a practical limit of @3000 chars.

I've successfully run it with URLs in the 1800 character range with about 50 variables, but it'll break with 100 variables even if they're empty... actually it won't even try to send the $_GET array, it builds the large form and then quits, not allowing the user to click submit...

let me get the above code working properly, and you'll see what I mean....

EDIT: I've posted the fixed code in the first post... if you run it (even with no data) you will see that with any combo of X and Y that multiplies to more than 112 causes it to break... example: 2 rooms of 50 works fine, 2 rooms of 60 breaks.

[tsinka]

Hi,

try this one:

<?PHP
  if (isset($_POST['submit'])) {
    $X=isset($_POST['X']) ? $_POST['X'] : 0;
    $Y=isset($_POST['Y']) ? $_POST['Y'] : 0;
    $Z=isset($_POST['Z']) ? $_POST['Z'] : array();
  } else {
    $X=0;
    $Y=0;
    $Z=array();
  }
?>

<form action="<?PHP echo $_SERVER['PHP_SELF']; ?>" method="post">
Number of Classrooms:<input type="text" size="3" name="X" value="<?PHP echo $X; ?>">
Number of Students:<input type="text" size="3" name="Y" value="<?PHP echo $Y; ?>">
<br />
<br />
<?PHP
    for($xcounter=1; $xcounter<=$X; $xcounter++){
      echo "Classroom #{$xcounter}:&nbsp;\n";
      for($ycounter=1; $ycounter<=$Y; $ycounter++){
        $zvalue = isset($Z[$xcounter][$ycounter]) ? $Z[$xcounter][$ycounter] : "";
        echo "<input type=\"text\" size=\"3\" name=\"Z[{$xcounter}][{$ycounter}]\" value=\"{$zvalue}\">\n";
      }
      echo "<br />\n";
    }
?>    

    <input type="submit" name="submit" value="Submit">
    <input type="submit" name="reset" value="Reset">

</form>

Thomas

[Weedpacket]

Originally posted by Cailean
I've successfully run it with URLs in the 1800 character range with about 50 variables, but it'll break with 100 variables even if they're empty... actually it won't even try to send the $_GET array, it builds the large form and then quits, not allowing the user to click submit...

That sounds more like a limitation in the browser you're using - what is it? I had no trouble testing your code in Mozilla (with X=Y=Z=50, giving 2500 text fields).

Of course, if your form is that big, maybe you should consider some other way of presenting it - spread it over several pages, perhaps.

[tsinka]

Most IE versions have a (rather low) limit regarding the length of a GET string. Using POST instead of GET should solve the problem.

Thomas

[Cailean]

Hmmm, I hadn't considered a browser limitation -- silly me!

I would use POST if I could, but what we need is a way for users to 'save' their data without using a server-side DB... Crazy-long URLs seem to be the answer...

Breaking it into pages was/is my next move... the drawback is that changing data 'on the fly' becomes more cumbersome...

[tsinka]

What exactly do you mean with "save" ?

Thomas

[Cailean]

'save'=being able to see what you entered yesterday without having to type it in again today.

[tsinka]

What does that application exactly do ?

Thomas

[Cailean]

The classroom/student thing is just an analogy... the actual app is a work in progress that calculates multi-district voting results via various forms of proportional representation formulas...

It's intended audience is academics, etc. and it will be hosted, eventually, on a university server which is why there were concerns about data accumulation in a DB. Also, the GET method means that no-one else can see your data unless you send them the URL... browser histories being the exception... This aspect satisfies some intellectual property concerns...

[Roger_Ramjet]

Originally posted by Cailean
Also, the GET method means that no-one else can see your data unless you send them the URL... browser histories being the exception... This aspect satisfies some intellectual property concerns...

WRONG, the GET method means that EVERYONE can see your data on every proxy and relay server the http request passes through, if they really wanted to. Always use POST where possible, or sensible (ie filling a table with a form in every cell would make for rather a large page, so I use a dynamic link with the data in the URL). I don't know of any situation where a POST will not work if a GET will. Perhaps an HTML guru can enlighten us.

[Roger_Ramjet]

Originally posted by Weedpacket
That must really screw up file uploads.

Is that sarcasm I detect weedpacket? Since I have a great deal of trouble with file uploads I can only say "Yes, it does". But then I am behind a winroute proxy/firewall, which is where I got the 3Kb limit on http requests. I'm sure other proxy software and proxy servers can be even more restrictive.

[Cailean]

Originally posted by Roger Ramjet
WRONG, the GET method means that EVERYONE can see your data on every proxy and relay server the http request passes through, if they really wanted to. Always use POST where possible, or sensible (ie filling a table with a form in every cell would make for rather a large page, so I use a dynamic link with the data in the URL). I don't know of any situation where a POST will not work if a GET will. Perhaps an HTML guru can enlighten us.

Sorry, I guess I wasn't clear... it's not about security, it's about where the data is stored once it's all been entered. The folks who will be using this thing would be wary about their carefully designed and inputted (is that a word?) electoral systems residing on someone else's server... in a DB, for example. The POST method doesn't work because they need to be able to go back to the data later. The way it is now, all the data is saved in the URL so it can be reused and transported. In most cases, it will simply be by way of browser bookmarks which even makes the size of the URLs irrelevant. Once they have the data entered and various variables set the way they want, they simply bookmark the page and it's theirs forever - more or less. In other words, yes, POST will work, but it doesn't provide the stable URL that I'm after.

[Weedpacket]

Originally posted by Roger Ramjet
Is that sarcasm I detect weedpacket? Since I have a great deal of trouble with file uploads I can only say "Yes, it does". But then I am behind a winroute proxy/firewall, which is where I got the 3Kb limit on http requests. I'm sure other proxy software and proxy servers can be even more restrictive.

To be honest, I've never had to deal with such a braindead limitation - and would make a noise if someone expected me to. This page I'm typing into now is 57kB. Ye Gods, my avatar is bigger than your limit! I've typed posts on this board that are bigger than that!

The server's limits are more relevant in my opinion: for Apache 2 the defaults are that no line of a request may be more than 8190 bytes long (that's 8kB less two characters for the end-of-line marker). That includes the first line of the header, which contains the entire URL being requested (including the query string).

Also by default, there is no limit on the size of the body of a request - which is where the contents of a form are put when POST is used as the request method. Since the web server itself does nothing about interpreting the body of a request, overall size is the only limitation that it imposes.

[Weedpacket]

Originally posted by Cailean
Sorry, I guess I wasn't clear... it's not about security, it's about where the data is stored once it's all been entered. The folks who will be using this thing would be wary about their carefully designed and inputted (is that a word?) electoral systems residing on someone else's server... in a DB, for example. The POST method doesn't work because they need to be able to go back to the data later.

Basically, you're saying that they want to be able to store the data without storing the data. It seems totally bizarre to me and a hilariously slack-happy approach to something like voting results, but I kind of expect that from academics. They can often be charmingly naïve about matters outside their discipline.

Have you considered using mail() to email the results to, say, the returning officer?

[Roger_Ramjet]

You mistook me weedpacket. It is not a limit on the size of the page, or anything like that, just on the size of the request going out.

Now, as it happens I am the person responsible for all things IT here, so I could change the limit. But, we have had such problems with trojans and worms over the past few months that I changed from a 'permissive' to a 'fascist' mode. Deny Everything and Limit Everything to the bare minimum needed to function.

I'm actually sitting here all evening rebuilding workstations from scratch, debug on the disks and everything, to make sure I've finally killed the beast. Sticking to the 'best practice' recommendations from Kerio and McAfee is the best I can do; at least untill I have absorbed the full documentation that comes with our upgraded versions of their software.

PS we used to use Symantec antivirus products - TOTAL CRAP. I got one little nasty bug on my gateway and bang, in came viruses and worms galore, and Symantex Systemworks did not spot one of them, some being as old as 2002. So a word to the wise everyone, Ditch Symantec and Norton's.

[Weedpacket]

Originally posted by Roger Ramjet
You mistook me weedpacket. It is not a limit on the size of the page, or anything like that, just on the size of the request going out.

I realise that; I had to upload my avatar, and like I (just edited the post to mention), I can type more than 3kB in a single post.[/b][/quote]

But, we have had such problems with trojans and worms over the past few months that I changed from a 'permissive' to a 'fascist' mode.

Let me guess, you're using IIS on a Windows system.