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

Re: caching form data? associating with filename / timestamp?

Expand Messages
  • 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 1 of 8 , Oct 4, 2002
    • 0 Attachment
      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 2 of 8 , Oct 4, 2002
      • 0 Attachment
        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 3 of 8 , Oct 4, 2002
        • 0 Attachment
          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 4 of 8 , Oct 4, 2002
          • 0 Attachment
            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 5 of 8 , Oct 4, 2002
            • 0 Attachment
              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 6 of 8 , Oct 4, 2002
              • 0 Attachment
                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 7 of 8 , Oct 4, 2002
                • 0 Attachment
                  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.