Loading ...
Sorry, an error occurred while loading the content.
 

caching form data? associating with filename / timestamp?

Expand Messages
  • dave_apache_asp
    I m experiencing some weirdness: My front page links to a login page for users that aren t currently logged in. The login page processes QueryString and Form
    Message 1 of 8 , Oct 4, 2002
      I'm experiencing some weirdness:

      My front page links to a login page for users that aren't currently
      logged in. The login page processes QueryString and Form data if
      they exist. The login form submits to itself and forwards to the
      front page on a successful login. It also forwards to the front page
      if the user is already logged in. The front page displays a logout
      link for users who are already logged in.

      Unfortunately, when the login link is followed and then the form
      submitted, the form data appears to be discarded. This does not
      happen when the login page is navigated to directly by typing the
      URL, only when a link is followed, suggesting it might be linked
      somehow to HTTP_REFERRER.

      If a user logs in successfully, then logs out, then follows the login
      link from the front page again, the login page acts as if it just
      received the previous (successful) form submission and logs the user
      in without a new form submission, but the Form object should really
      be empty at this point since this Request originates from a simple
      hyperlink.

      Here's the kicker: I can make everything behave perfectly by simply
      `touch`ing the login page immediately before submitting its form or
      following the login link. Something seems to be associating Requests
      for files with their accompanying data and binding so tightly that
      new Requests for the same files can't erase or replace the original
      data. Updating the files' timestamps forces proper behavior though.

      I really like Apache::ASP, but this has been frustrating. I could
      probably get around it by using a login processor page, but that
      seems clumsy.

      I don't know whether the OS / etc. makes any difference, but it's
      FreeBSD 4.6 / Apache 1.3.26 / mod_perl 1.2.7

      thanks for any help.

      -dave


      ---------------------------------------------------------------------
      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • Josh Chamas
      ... This sounds like a my closure problem... things like defining subs in scripts or XMLSubs in global.asa can help create these problems. Setting PerlSetVar
      Message 2 of 8 , Oct 4, 2002
        dave_apache_asp wrote:
        > I'm experiencing some weirdness:
        >
        > If a user logs in successfully, then logs out, then follows the login
        > link from the front page again, the login page acts as if it just
        > received the previous (successful) form submission and logs the user
        > in without a new form submission, but the Form object should really
        > be empty at this point since this Request originates from a simple
        > hyperlink.
        >
        > Here's the kicker: I can make everything behave perfectly by simply
        > `touch`ing the login page immediately before submitting its form or
        > following the login link. Something seems to be associating Requests
        > for files with their accompanying data and binding so tightly that
        > new Requests for the same files can't erase or replace the original
        > data. Updating the files' timestamps forces proper behavior though.
        >

        This sounds like a my closure problem... things like defining subs
        in scripts or XMLSubs in global.asa can help create these problems.
        Setting PerlSetVar UseStrict and PerlWarn can help catch these problems.

        Please see http://www.apache-asp.org/style.html#Do%20not%20definc430b103
        for a bit more on this topic.

        If you have a brief code sample we can look at that reproduces
        this problem, & you still need help, please post it.

        Regards,

        Josh
        ________________________________________________________________
        Josh Chamas, Founder phone:925-552-0128
        Chamas Enterprises Inc. http://www.chamas.com
        NodeWorks Link Checking http://www.nodeworks.com


        ---------------------------------------------------------------------
        To unsubscribe, e-mail: asp-unsubscribe@...
        For additional commands, e-mail: asp-help@...
      • dave_apache_asp
        Thanks a lot! Indeed, I was using a subroutine in the asp. I was planning on moving it out to a module once it was more mature, but now I guess I ll just
        Message 3 of 8 , Oct 4, 2002
          Thanks a lot! Indeed, I was using a subroutine in the asp. I was
          planning on moving it out to a module once it was more mature, but
          now I guess I'll just have to do it The Right Way (tm). :)

          -dave


          ---------------------------------------------------------------------
          To unsubscribe, e-mail: asp-unsubscribe@...
          For additional commands, e-mail: asp-help@...
        • Michael Chrisman
          Dave, I see a couple of issue here. The first is the mixing of QueryString and Form data. Some web servers (like apache) do not allow you to mix this in the
          Message 4 of 8 , Oct 4, 2002
            Dave,

            I see a couple of issue here. The first is the mixing of QueryString
            and Form data. Some web servers (like apache) do not allow you to mix
            this in the same "submit." If the web server see's QueryString data,
            then it will ignor the Form data is there is any. (Some web servers,
            like IIS, will let you do both.) It's not a good practice to mix
            QueryData and Form data, not to mention it is not that hard to fix.
            For example the following code that mixes them:
            <FORM ACTION="myPage.asp?ID=11234&User=BOB" METHOD="POST">
            ... some text and input fields ...
            This can be changed to either all QUERYSTRING by changing the method to
            GET:
            <FORM ACTION="myPage.asp?ID=11234&User=BOB" METHOD="GET">
            ... some text and input fields ...
            Or can be changed all to FORM data by:
            <FORM ACTION="myPage.asp" METHOD="POST">
            <INPUT TYPE="HIDDEN" NAME="ID" VALUE="11234">
            <INPUT TYPE="HIDDEN" NAME="User" VALUE="BOB">
            ... some text and input fields ...
            There are some size limitation with the GET method, so I would suggest
            the POST method.

            The other issue is the page caching. This is a fustrating issue for
            most programmers. The browser tends to want to cache the page and
            re-display it rather than have the server build a new page. The
            browser does check with the web server to see if the page has been
            changed since the last display of it and if not, it displays the old
            page. After doing some research I found the HTML code you can add to
            each page you don't want to cache and the browser will not cache it. In
            the <HEAD> section, add the following code:
            <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
            <meta http-equiv="Expires" content="-1">
            Plus, in-order to get IE not to cache the page, after the close body
            tag, add another <head> section:
            </body>
            <Head>
            <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
            </head>
            </html>
            I realize that this looks strange to have another <Head> section after
            the <body> section, but this is what it takes to make sure that
            Microsoft's Internet Explorer does not cache the page (I got this from
            Microsoft's web site). If you do not add the section <Head> section,
            then IE will still try to cache the page. I have tested this code in
            IE, Netscape, Mozilla, Opera and it has worked perfectly.

            I hope this helps.

            - Mike Chrisman


            --- dave_apache_asp <dave_apache_asp@...> wrote:
            > I'm experiencing some weirdness:
            >
            > My front page links to a login page for users that aren't currently
            > logged in. The login page processes QueryString and Form data if
            > they exist. The login form submits to itself and forwards to the
            > front page on a successful login. It also forwards to the front page
            >
            > if the user is already logged in. The front page displays a logout
            > link for users who are already logged in.
            >
            > Unfortunately, when the login link is followed and then the form
            > submitted, the form data appears to be discarded. This does not
            > happen when the login page is navigated to directly by typing the
            > URL, only when a link is followed, suggesting it might be linked
            > somehow to HTTP_REFERRER.
            >
            > If a user logs in successfully, then logs out, then follows the login
            >
            > link from the front page again, the login page acts as if it just
            > received the previous (successful) form submission and logs the user
            > in without a new form submission, but the Form object should really
            > be empty at this point since this Request originates from a simple
            > hyperlink.
            >
            > Here's the kicker: I can make everything behave perfectly by simply
            > `touch`ing the login page immediately before submitting its form or
            > following the login link. Something seems to be associating Requests
            >
            > for files with their accompanying data and binding so tightly that
            > new Requests for the same files can't erase or replace the original
            > data. Updating the files' timestamps forces proper behavior though.
            >
            > I really like Apache::ASP, but this has been frustrating. I could
            > probably get around it by using a login processor page, but that
            > seems clumsy.
            >
            > I don't know whether the OS / etc. makes any difference, but it's
            > FreeBSD 4.6 / Apache 1.3.26 / mod_perl 1.2.7
            >
            > thanks for any help.
            >
            > -dave
            >
            >
            > ---------------------------------------------------------------------
            > To unsubscribe, e-mail: asp-unsubscribe@...
            > For additional commands, e-mail: asp-help@...
            >
            >
            >


            __________________________________________________
            Do you Yahoo!?
            New DSL Internet Access from SBC & Yahoo!
            http://sbc.yahoo.com

            ---------------------------------------------------------------------
            To unsubscribe, e-mail: asp-unsubscribe@...
            For additional commands, e-mail: asp-help@...
          • dave_apache_asp
            Mike: Thanks for the suggestions. Actually, I wasn t really mixing Form and QueryString data (at least not at the input stage). I always post forms. I
            Message 5 of 8 , Oct 4, 2002
              Mike:

              Thanks for the suggestions.

              Actually, I wasn't really "mixing" Form and QueryString data (at
              least not at the input stage). I always "post" forms. I was just
              trying to make the routine generic enough that it would process
              either one (or both) if they were present, so the page could be
              called via a hyperlink *or* via a form submission.

              I had already made sure this wasn't a browser-caching issue with a
              random number display; it is definitely server-side. Per Joshua's
              suggestion, I took the subroutine out of the ASP and that seems to
              have solved the problem. Apparently subroutines compiled in ASPs
              retain their original variables?

              thanks again though,

              -dave

              --- In apache-asp@y..., Michael Chrisman <michael_chrisman@y...>
              wrote:
              > Dave,
              >
              > I see a couple of issue here. The first is the mixing of QueryString
              > and Form data. Some web servers (like apache) do not allow you to
              mix
              > this in the same "submit." If the web server see's QueryString data,
              > then it will ignor the Form data is there is any. (Some web servers,
              > like IIS, will let you do both.) It's not a good practice to mix
              > QueryData and Form data, not to mention it is not that hard to fix.
              > For example the following code that mixes them:
              > <FORM ACTION="myPage.asp?ID=11234&User=BOB" METHOD="POST">
              > ... some text and input fields ...
              > This can be changed to either all QUERYSTRING by changing the
              method to
              > GET:
              > <FORM ACTION="myPage.asp?ID=11234&User=BOB" METHOD="GET">
              > ... some text and input fields ...
              > Or can be changed all to FORM data by:
              > <FORM ACTION="myPage.asp" METHOD="POST">
              > <INPUT TYPE="HIDDEN" NAME="ID" VALUE="11234">
              > <INPUT TYPE="HIDDEN" NAME="User" VALUE="BOB">
              > ... some text and input fields ...
              > There are some size limitation with the GET method, so I would
              suggest
              > the POST method.
              >
              > The other issue is the page caching. This is a fustrating issue for
              > most programmers. The browser tends to want to cache the page and
              > re-display it rather than have the server build a new page. The
              > browser does check with the web server to see if the page has been
              > changed since the last display of it and if not, it displays the old
              > page. After doing some research I found the HTML code you can add
              to
              > each page you don't want to cache and the browser will not cache
              it. In
              > the <HEAD> section, add the following code:
              > <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
              > <meta http-equiv="Expires" content="-1">
              > Plus, in-order to get IE not to cache the page, after the close body
              > tag, add another <head> section:
              > </body>
              > <Head>
              > <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
              > </head>
              > </html>
              > I realize that this looks strange to have another <Head> section
              after
              > the <body> section, but this is what it takes to make sure that
              > Microsoft's Internet Explorer does not cache the page (I got this
              from
              > Microsoft's web site). If you do not add the section <Head> section,
              > then IE will still try to cache the page. I have tested this code in
              > IE, Netscape, Mozilla, Opera and it has worked perfectly.
              >
              > I hope this helps.
              >
              > - Mike Chrisman
              >
              >



              ---------------------------------------------------------------------
              To unsubscribe, e-mail: asp-unsubscribe@...
              For additional commands, e-mail: asp-help@...
            • Josh Chamas
              ... subroutines that have variables they are using that are improperly scoped will be retained in subsequent requests. Improper scoping of variables can result
              Message 6 of 8 , Oct 4, 2002
                dave_apache_asp wrote:
                >
                > I had already made sure this wasn't a browser-caching issue with a
                > random number display; it is definitely server-side. Per Joshua's
                > suggestion, I took the subroutine out of the ASP and that seems to
                > have solved the problem. Apparently subroutines compiled in ASPs
                > retain their original variables?
                >

                subroutines that have variables they are using that are
                improperly scoped will be retained in subsequent requests.
                Improper scoping of variables can result in my closure behavior.

                As long as all variables in a subroutine are accessing
                global variables ( like $main::Response ) or my()
                scoped variables, then that subroutine should be able to
                be written in a ASP script fine. Moving subs to a real
                perl module/package avoids these problems by forcing
                variables to be properly scoped during compilation.

                Regards,

                Josh
                ________________________________________________________________
                Josh Chamas, Founder phone:925-552-0128
                Chamas Enterprises Inc. http://www.chamas.com
                NodeWorks Link Checking http://www.nodeworks.com


                ---------------------------------------------------------------------
                To unsubscribe, e-mail: asp-unsubscribe@...
                For additional commands, e-mail: asp-help@...
              • dave_apache_asp
                I added this line to my subroutine, which also fixes it: my $Request = $main::Request; I have been using strict all along, but referring to $Request in a
                Message 7 of 8 , Oct 4, 2002
                  I added this line to my subroutine, which also fixes it:

                  my $Request = $main::Request;

                  I have been using strict all along, but referring to $Request in a
                  subroutine without fully qualifying it seems to be the problem. That
                  was apparently causing the first $Request to be cached.

                  thanks so much,
                  -dave

                  > As long as all variables in a subroutine are accessing
                  > global variables ( like $main::Response ) or my()
                  > scoped variables, then that subroutine should be able to
                  > be written in a ASP script fine. Moving subs to a real
                  > perl module/package avoids these problems by forcing
                  > variables to be properly scoped during compilation.



                  ---------------------------------------------------------------------
                  To unsubscribe, e-mail: asp-unsubscribe@...
                  For additional commands, e-mail: asp-help@...
                • dave_apache_asp
                  Actually, that line doesn t work after all... I went back to removing the subroutine which is the only thing that has seemed to work. The only variables that
                  Message 8 of 8 , Oct 4, 2002
                    Actually, that line doesn't work after all...

                    I went back to removing the subroutine which is the only thing that
                    has seemed to work. The only variables that aren't declared as 'my'
                    in the subroutine are the intrinsic objects so I don't know how it
                    could be a scoping issue. I guess I'm stumped. I'll just shut up
                    now.

                    thanks for tolerating me,
                    -dave

                    --- In apache-asp@y..., "dave_apache_asp" <dave_apache_asp@y...>
                    wrote:
                    > I added this line to my subroutine, which also fixes it:
                    >
                    > my $Request = $main::Request;
                    >
                    > I have been using strict all along, but referring to $Request in a
                    > subroutine without fully qualifying it seems to be the problem.
                    That
                    > was apparently causing the first $Request to be cached.
                    >
                    > thanks so much,
                    > -dave
                    >
                    > > As long as all variables in a subroutine are accessing
                    > > global variables ( like $main::Response ) or my()
                    > > scoped variables, then that subroutine should be able to
                    > > be written in a ASP script fine. Moving subs to a real
                    > > perl module/package avoids these problems by forcing
                    > > variables to be properly scoped during compilation.
                    >
                    >
                    >
                    > --------------------------------------------------------------------
                    -
                    > To unsubscribe, e-mail: asp-unsubscribe@p...
                    > For additional commands, e-mail: asp-help@p...


                    ---------------------------------------------------------------------
                    To unsubscribe, e-mail: asp-unsubscribe@...
                    For additional commands, e-mail: asp-help@...
                  Your message has been successfully submitted and would be delivered to recipients shortly.