in reply to IIS 6 x64 CGI variable problem

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;

[download]
Output: 
GET

[download]
...
$|++;
$ENV{REQUEST_METHOD} = 'POST';    # Added this line
...

[download]

Output: 

POST

[download]

--
"Language shapes the way we think, and determines what we can think about."
-- B. L. Whorf

Replies are listed 'Best First'.
Re^2: IIS 6 x64 CGI variable problem
by Anonymous Monk on Dec 25, 2010 at 07:39 UTC
    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');

    [download]

    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.

      [download]

      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]
        B) maybe someone here will have better insight/knowledge about the "why" of it.

        There is only one explanation, the server was not implementing CGI protocol correctly

[reply]
Re^2: IIS 6 x64 CGI variable problem
by Anonymous Monk on Dec 25, 2010 at 02:34 UTC
    this kind of Band-Aid is the best you can do

    Correction, Batguano-Voodoo-Band-Aid; indeed :)

[reply]

In Section Seekers of Perl Wisdom