Beefy Boxes and Bandwidth Generously Provided by pair Networks Cowboy Neal with Hat
Pathologically Eclectic Rubbish Lister

IIS 6 x64 CGI variable problem

by karlk123 (Novice)
on Dec 23, 2010 at 22:53 UTC ( #878900=perlquestion: print w/ replies, xml ) Need Help??
karlk123 has asked for the wisdom of the Perl Monks concerning the following question:

I have a perl app that works just fine on both Apache and IIS 6 on two different 32 bit Win 2003 Server platforms. However I have a problem with it on IIS 6 on Win 2003 Server x64. ActivePerl 5.8.9 build 826 and build 826 (64-bit) are installed. With I am creating web pages with the POST method to hide the posted variables.

For some reason on the x64 machine, after I click a submit button the second time, the passed variables from the prior submit action are now visible in the browser URL window with either IE7 or FF3.6 browsers.

For example, it would show:;Fcn=Login

With each successive Submit action, the prior list of vars is displayed. It is not clear what is going on, and why just on this server with x64 code. Any ideas on what I need to fix/check for?

Comment on IIS 6 x64 CGI variable problem
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's sticky form values feature....

      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?
        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

Re: IIS 6 x64 CGI variable problem
by andal (Friar) 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.

      I am using the post method. That's why this is baffling.
      <form method="post" action="" 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.

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;
    ... $|++; $ENV{REQUEST_METHOD} = 'POST'; # Added this line ...



    "Language shapes the way we think, and determines what we can think about."
    -- B. L. Whorf
      this kind of Band-Aid is the best you can do

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

      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?


        > 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 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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://878900]
Front-paged by Arunbear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2014-04-17 11:10 GMT
Find Nodes?
    Voting Booth?

    April first is:

    Results (445 votes), past polls