|
Re: IIS 6 x64 CGI variable problem
by andal (Hermit) on Dec 24, 2010 at 08:28 UTC
|
Usually, the form fields show up in the URL only when the submit method of the form was "GET" instead of "POST". First make sure that generated form explicitly requests the method "POST". Just view the HTML source of the form. If the submit method is "POST" but you get variables in the URL, then it is bug of the browser. But if you don't specify the method (it should default to GET then) or the method is not POST, then it is bug of the form generator.
| [reply] |
|
|
I am using the post method. That's why this is baffling.
<form method="post" action="http://mysite.com/pgm.pl" enctype="multipa
+rt/form-data" name="labcal" id="labcal">
And it works fine on x32 Apache and IIS6 servers, just the IIS6 x64 server shows this symptom. It can't be a browser error as both IE7 and FF3.6 exhibit this.
I am using some javascript too, but I don't think it's the cause. This IIS6 x64 server consistently appends the prior submit vars on the second submit button action. | [reply]
[d/l] |
Re: IIS 6 x64 CGI variable problem
by Anonymous Monk on Dec 23, 2010 at 23:02 UTC
|
Any ideas on what I need to fix/check for?
Everything, first thing, make sure you're not using CGI.pm's sticky form values feature.... | [reply] |
|
|
Hmm .. how would I know if I'm using that? And if so, why does it work fine on a 32 bit Apache and IIS6 system, but not the IIS6 x64 system?
| [reply] |
|
|
Hmm .. how would I know if I'm using that?
By checking your source code to see if you disabled this feature, refer to the manual for how its enabled/disabled
And if so, why does it work fine on a 32 bit Apache and IIS6 system, but not the IIS6 x64 system?
Impossible to say, for all I know of IIS6, it could be an IIS6 feature
| [reply] |
|
|
Re: IIS 6 x64 CGI variable problem
by oko1 (Deacon) on Dec 25, 2010 at 02:23 UTC
|
I dimly recall running into a similar problem some years ago - I don't remember what the server type was (I don't think it was IIS), but the forms in the script worked fine with one server and had a similar kind of POST/GET confusion with another. I solved the problem by making 'POST' the default method for the entire script rather than just defining it in the form.
(I was rather hesitant about posting this, because I realize that it sounds like voodoo; it shouldn't have interfered with anything, or fixed anything. However... it fixed the problem, is still working a number of years down the road, and has not caused any problems on a variety of servers where it's been used. Sometimes, especially when a client is breathing down the back of your neck _and_ counting minutes/pennies, this kind of Band-Aid is the best you can do. :-[ )
Demonstration of how this works:
#!/usr/bin/perl -w
use strict;
use CGI qw/:standard/;
$|++;
print header, start_html, $ENV{REQUEST_METHOD}, end_html;
Output:
GET
...
$|++;
$ENV{REQUEST_METHOD} = 'POST'; # Added this line
...
Output:
POST
--
"Language shapes the way we think, and determines what we can think about."
-- B. L. Whorf
| [reply]
[d/l]
[select] |
|
|
Ok, this sounds interesting. I probably should have noted that my actual perl code is:
print start_multipart_form(-method=>'POST', -name=>'labcal', -id=>'lab
+cal');
The previously mentioned form statement was snagged from the view page source fcn and was generated by the multipart_form fcn. Are you recommending that maybe I not use this and instead hard code the form statment?
Also, help me here, just what does $|++ do?
Thx | [reply]
[d/l] |
|
|
> Are you recommending that maybe I not use this and instead hard code the form statment?
The forms that I was using weren't multipart/form-data - they were just plain old 'method="POST"' types - but as I recall, the data kept ending up being passed as GET rather than POST no matter what I did in 'start_form()'. I noticed that the default method used by CGI.pm was GET, decided to flip it to POST just so I could experiment a bit... and suddenly (and unexpectedly), everything worked fine. Again, this was for just that one server type ('thttpd', maybe? I really don't remember) - all the others worked fine both before and after the change.
As I'd mentioned, I'm not a fan of "magical" solutions where I don't understand the mechanism - hate'em, in fact, since they don't teach me how to solve that class of problems, only that one problem (and even that's a "maybe") - but A) it worked for me, and B) maybe someone here will have better insight/knowledge about the "why" of it.
> what does $|++ do?
From perlvar:
$| If set to nonzero, forces a flush right away and after eve
+ry
write or print on the currently selected output channel.
I generally turn buffering off whenever I have Perl talking to an external program - e.g., a web server or a database client, or any kind of a pipe. It prevents a host of related timing problems.
--
Education is not the filling of a pail, but the lighting of a fire.
-- W. B. Yeats
| [reply]
[d/l] |
|
|
|
|
| [reply] |