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

Re: caching form data? (etc.)

Expand Messages
  • 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 1 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 2 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 3 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 4 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.