You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by dave_apache_asp <da...@yahoo.com> on 2002/10/04 22:13:47 UTC
Re: caching form data? (etc.)
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 <mi...@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@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: scoping for asp subs
Posted by dave_apache_asp <da...@yahoo.com>.
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" <da...@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@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: scoping for asp subs
Posted by dave_apache_asp <da...@yahoo.com>.
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@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: caching form data? (etc.)
Posted by Josh Chamas <jo...@chamas.com>.
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@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org