Weird caching problem in windows browsers

[kyle dawkins <ky...@centralparksoftware.com>]

hey guys

i have a pretty big mod_perl system up and running and have run into a
weird problem with browser caching (or rather, not caching) on windows.

i have a series of complex forms that submit to and are generated by a
mod_perl handler.  each submitted form is validated and another form is
generated.  in some cases, there are about three or four forms in the
sequence.  for some reason, in windows, hitting the back button results
in both IE and Netscape giving "Warning: page has expired" error pages.
I have numerous places on the site that do this, and it's been working
fine all this time.  Now, the new forms all cause the error, whereas the
old ones are still fine.  I have been trying to figure out what's
different between the old ones that work and the new ones but I can't
really see anything.  There are occasions with the newer ones where an
entire sequence of forms submits to the same URL, like this:

<form method=post action=/path_to_my_handler/someNamedAction>

so I wrote some code to generate unique URLs for each subsequent POST
and that still produces the same results.

The weird thing is that if you refresh the page that produces the error,
it will "remember" that page from then on and never show the error for
that form again.

Does anyone have any idea what might be causing this?  I am stumped.
It's also extra tough to debug because everything works perfectly in
Linux so I have to run windows in VMware to even reproduce the error.
Ugh.

Kyle
kyle@centralparksoftware.com

Re: Weird caching problem in windows browsers (solved)

[kyle dawkins <ky...@centralparksoftware.com>]

hey all

found the problem and it had nothing to do with caching or browsers or
OSes, but it's worth a mention here for future reference.

for debugging purposes, i had 

use CGI::Carp qw(fatalsToBrowser);

in my handler.  for the most part, it was useful, except in this case.
deep down in one of my classes, i was using eval to trap a potential
error.  in the situations where that error occurred, i trapped it,
logged a warning, and continued to generate a response that I returned.
it seems, however, the CGI::Carp was somehow thinking that an error had
occurred and it was *changing* the response code from 200 to 500.  So
the browser was getting a Status of 500 but my page was being generated,
so I didn't know there was anything wrong with it.

I took out CGI::Carp and it all works.  Mmmmm.  Side effects.  Yummy.

Kyle
kyle@centralparksoftware.com
http://www.centralparksoftware.com




> hey guys
> 
> i have a pretty big mod_perl system up and running and have run into a
> weird problem with browser caching (or rather, not caching) on windows.
> 
> i have a series of complex forms that submit to and are generated by a
> mod_perl handler.  each submitted form is validated and another form is
> generated.  in some cases, there are about three or four forms in the
> sequence.  for some reason, in windows, hitting the back button results
> in both IE and Netscape giving "Warning: page has expired" error pages.
> I have numerous places on the site that do this, and it's been working
> fine all this time.  Now, the new forms all cause the error, whereas the
> old ones are still fine.  I have been trying to figure out what's
> different between the old ones that work and the new ones but I can't
> really see anything.  There are occasions with the newer ones where an
> entire sequence of forms submits to the same URL, like this:
> 
> <form method=post action=/path_to_my_handler/someNamedAction>
> 
> so I wrote some code to generate unique URLs for each subsequent POST
> and that still produces the same results.
> 
> The weird thing is that if you refresh the page that produces the error,
> it will "remember" that page from then on and never show the error for
> that form again.
> 
> Does anyone have any idea what might be causing this?  I am stumped.
> It's also extra tough to debug because everything works perfectly in
> Linux so I have to run windows in VMware to even reproduce the error.
> Ugh.
> 
> Kyle
> kyle@centralparksoftware.com
> 
> 
>