URGENT HELP - form submit stops working when so many check boxes checked - Why?

[Dave Smithz]

Hi there,

A PHP application I built has a section which lists a number of members to a
club whose names each appear with a check box beside them that can be
ticked.

These check boxes are part of a form which amongst other submit buttons has
a one particular submit button that if checked will send the form data
(using GET) to a script that will email all the checked members.

The client today phoned to say that when the check a few members on the form
(only about 10 actually) and pressed the submit button it done nothing (In
fact all submit buttons on form stop working). A can verify this behaviour
and also note that if I reduce the amount of checked members I can then make
the submit button work again!

This is bizarre. My initial thoughts are this may be something to do with it
being a GET post and there being a maximum length, but really I moved the
form to a GET method because I wanted the users to be able to use the back
button on the browser to come back to the page (I had trouble doing this
other ways).
Also I thought I would post this right away in case this is a recognised
scenario with an easy fix.

Please help and thanks in advance for any advice.

Dave

 

[chotiwallah]

Hi there,

A PHP application I built has a section which lists a number of members to a
club whose names each appear with a check box beside them that can be
ticked.

These check boxes are part of a form which amongst other submit buttons has
a one particular submit button that if checked will send the form data
(using GET) to a script that will email all the checked members.

The client today phoned to say that when the check a few members on the form
(only about 10 actually) and pressed the submit button it done nothing (In
fact all submit buttons on form stop working). A can verify this behaviour
and also note that if I reduce the amount of checked members I can then make
the submit button work again!

This is bizarre. My initial thoughts are this may be something to do with it
being a GET post and there being a maximum length, but really I moved the
form to a GET method because I wanted the users to be able to use the back
button on the browser to come back to the page (I had trouble doing this
other ways).
Also I thought I would post this right away in case this is a recognised
scenario with an easy fix.

Please help and thanks in advance for any advice.

Dave

doesn't look like a php problem, but anyway:

a couple of ideas come to mind:

1. check the html generated by your php script

2. try different browsers to check wether this is a browser problem

3. try using POST to check wether your form works at all

4. check/disable any javascript that might interfere with posting

this will hopefully bring you a bit closer to the error.

micha

 

[Travis Newbury]

A PHP application I built has a section which lists a number of members to a
club whose names each appear with a check box beside them that can be
ticked...

I created a webpage that solves your problem. But I, like you, will
not list the URL in the message...

 

[Dave Smithz]

I created a webpage that solves your problem. But I, like you, will
not list the URL in the message...

I'm not sure I understand. I cannot list the URL because it requires
password access and has confidential data protected by data protection act
etc.
If you had the same problem, what was causing it and how did you solve it?

Thanks

 

[rf]

Dave Smithz

I'm not sure I understand. I cannot list the URL because it requires
password access and has confidential data protected by data protection act
etc.

My car is broken. What is wrong?

If you had the same problem, what was causing it and how did you solve it?

I showed the car bloke at the garage my bloody car!

Cheers
Richard.

 

[Travis Newbury]

I'm not sure I understand. I cannot list the URL because it requires
password access and has confidential data protected by data protection act
etc.

No one can know if they have the same problem becuase when we make such
a page it works. We don't know what you did to make it not work.

Take your code and make a dummy page that displays the problem.
Chances are, when you make that dummy page the solution will be obvious
to you. If not, then we will at least be able to see what you did.

 

[Peter van Schie]

A PHP application I built has a section which lists a number of members to a
club whose names each appear with a check box beside them that can be
ticked.

These check boxes are part of a form which amongst other submit buttons has
a one particular submit button that if checked will send the form data
(using GET) to a script that will email all the checked members.

Hi Dave,

If it only happens when quite some data is being sent through a GET
request (i.e. many checkboxes), it might be that the limit of size of
the GET request is being exceeded.
As chotiwallah already suggested; try it with POST to be sure.

 

[Berislav Lopac]

Hi there,

A PHP application I built has a section which lists a number of
members to a club whose names each appear with a check box beside
them that can be ticked.

These check boxes are part of a form which amongst other submit
buttons has a one particular submit button that if checked will send
the form data (using GET) to a script that will email all the checked
members.
The client today phoned to say that when the check a few members on
the form (only about 10 actually) and pressed the submit button it
done nothing (In fact all submit buttons on form stop working). A can
verify this behaviour and also note that if I reduce the amount of
checked members I can then make the submit button work again!

This is bizarre. My initial thoughts are this may be something to do
with it being a GET post and there being a maximum length, but really
I moved the form to a GET method because I wanted the users to be
able to use the back button on the browser to come back to the page
(I had trouble doing this other ways).

This is exactly what I thought. Have you even tried it with POST? Also, why
would there be a problem with POST?

Berislav

 

[Dave Smithz]

Dave Smithz wrote

OK been a busy day, but looks like (although not thoroughly tested it)
changing to POST solved it. However, when I was choosing the GET method, I
did query whether there would be a limit and it was not clear.

I am sure this sort of behaviour would have been well documented and well
known about.

In summary, if I create a webpage with many submit buttons with all slightly
different names (so I can work out which one has been pressed) and it also
has many check boxes, when I check over a certain number of these check
boxes all submit buttons stop working. I can then literally uncheck some
until I get to a point where the submit buttons will work again.

This seems to be a general case for me. I thought this would type of
limitation would be common knowledge to experts, or maybe I am still doing
something wrong.

I will carry on my investigations and report any interesting findings. the
problem with the post method is that my clients like to use the back button
and post does not work as well as get when it comes to actually seeing what
you had on the page before when you press the back button.

Kind regards

Dave

 

[Peter van Schie]

I will carry on my investigations and report any interesting findings. the
problem with the post method is that my clients like to use the back button
and post does not work as well as get when it comes to actually seeing what
you had on the page before when you pres

Dave,

The GET limitation *is* common knowledge.
About the back button: my guess is your clients are using IE 6 if I read
your comment on the Back button behaviour.
That's a common bug in IE6, but you can easily solve this by adding:

header("Cache-control: private");

at the top of your script.

 

[Berislav Lopac]

This seems to be a general case for me. I thought this would type of
limitation would be common knowledge to experts, or maybe I am still
doing something wrong.

As Peter said, it is common knowledge. The thing is that, IIRC, Web server
(e.g. Apache or IIS) can set this limit in a configuration, so there is no
telling what is the limit in any single case.

Berislav

 

[John Dunlop]

About the back button: my guess is your clients are using IE 6 if I read
your comment on the Back button behaviour.
That's a common bug in IE6, but you can easily solve this by adding:

header("Cache-control: private");

Do you think that's a good workaround?

 

[Peter van Schie]

Do you think that's a good workaround?

I'm not sure where you want to go with this question, but yes it is a
workaround that works. From a user's perspective it's a tedious job
having to fill out a form again with the same information after using
the Back button.

 

[John Dunlop]

John Dunlop wrote:

[Peter van Schie wrote:]

About the back button: my guess is your clients are using IE 6 if I read
your comment on the Back button behaviour.
That's a common bug in IE6, but you can easily solve this by adding:

header("Cache-control: private");

Do you think that's a good workaround?

I'm not sure where you want to go with this question,

anywhere you like, and I'll follow.

but yes it is a workaround that works.

Ok, if there's compelling arguments *for* that caching
directive - excluding working around IE6's bug - and less
compelling ones, if any, *against* it, why aren't you sending
it in the first place? If, on the other hand, the arguments
lead you to decide on a different value, say 'public', which
one influences you more: those arguments, or IE6's bug? (I'm
not looking for answers here, since I could care less about
individual situations; just suggesting things to think about.)

From a user's perspective it's a tedious job having to fill out a form
again with the same information after using the Back button.

Yes.

[By a strict interpretation of RFC2616, they'd have to fill
the form in again anyway. But I find that isn't always the
case in reality]

 

[Peter van Schie]

Ok, if there's compelling arguments *for* that caching
directive - excluding working around IE6's bug -

That depends on the application.

and less
compelling ones, if any, *against* it

Not that I know of, so I don't see any reason to not use it.
If there are major drawbacks I'd be glad to be informed about them.

, why aren't you sending
it in the first place?

But I do.
I only suggested it to Dave to circumvent the "Back button problem".

If, on the other hand, the arguments
lead you to decide on a different value, say 'public', which
one influences you more: those arguments, or IE6's bug? (I'm
not looking for answers here, since I could care less about
individual situations; just suggesting things to think about.)

As you already said; that's an individual situation issue. I can't
remember any case in which I needed both.
Besides that there are multiple ways that lead to Rome.

 

[Neredbojias]

I'm not sure I understand. I cannot list the URL because it requires
password access and has confidential data protected by data protection act
etc.
If you had the same problem, what was causing it and how did you solve it?

I think what he's saying is that the problem and your description of the
problem are not the same thing.

 

[John Dunlop]

I only suggested it to Dave to circumvent the "Back button problem".

Ok, let me put it another way. If 'Cache-Control: private' is
appropriate and you send it, the problem you speak of won't
arise; but if it's inappropriate, should you* send it at all?


* generic 'you'.

 

[JDS]

As Peter said, it is common knowledge. The thing is that, IIRC, Web server
(e.g. Apache or IIS) can set this limit in a configuration, so there is no
telling what is the limit in any single case.

It is a browser-based and not a server-based limit.

The same queries to the same server that do not work in MSIE *will* often
work in gecko-based (and other) browsers (Moz, et.al)

On a side note, this is one of the few times when, IMO, a MSIE difference
in implementation is, once agin, IMO, No Big Deal(TM). As opposed to all
the MSIE bugs in, for example, CSS rendering, this GET vs POST limitation
is not a bug but merely a particular interpretation of the W3C
recommendations. One that other browsers have interpreted more liberally.

Whatever. later...