Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Strange POST Behavior / Possible Caching Issue

by vroom (His Eminence)
on Jun 06, 2002 at 18:25 UTC ( [id://172303]=perlquestion: print w/replies, xml ) Need Help??

vroom has asked for the wisdom of the Perl Monks concerning the following question:

We are in the process of migrating our intranet from IIS to Apache. I've encountered some strange behavior with one of my applications.

The problem is that data from the form doesn't seem to consistently get posted. I've added a $query->Dump to view what is getting passed to the script.

Some descriptions of the behavior:

  • Everything works fine on the first pageload after restarting Apache
  • The problem doesn't ever appear when using Opera
  • The problem does appear when using IE
  • After not hitting the script for a few minutes I can usually get one correct execution using IE, after that parameters don't seem to get posted.

    I've tried adding

    <META HTTP-EQUIV="Pragma" CONTENT="no-cache"> <META HTTP-EQUIV="Expires" CONTENT="-1">
    to prevent caching but that didn't seem to help either.

    Any ideas?

  • Replies are listed 'Best First'.
    Re: Strange POST Behavior / Possible Caching Issue
    by dws (Chancellor) on Jun 06, 2002 at 18:30 UTC
      We had problems with caching with a web app a while back, and found that <META> tags weren't sufficient. Adding   Cache-Control: no-cache did the trick. And this was for a POST problem, which shouldn't get cached anyway. We live in a strange world.

    (wil) Re: Strange POST Behavior / Possible Caching Issue
    by wil (Priest) on Jun 06, 2002 at 18:35 UTC
      There are known problems with post caching in earlier versions of IE. To my knowledge this was only recently 'fixed'. What browser versions are you having problems with this?

      Unfortunately, the only work around we managed was to append a dummy paramater to the end of the URL, maybe generated randomly or by the date so that this would trick IE into thinking that it's fetching an unique URL everytime.

      - wil
        That's exactly what I did, in my case adding a timestamp up to the millisecond.
        ()-()
         \"/
          `                                                     
        
    Re: Strange POST Behavior / Possible Caching Issue
    by Dog and Pony (Priest) on Jun 06, 2002 at 19:15 UTC
      Well, different browsers seems to obey different headers, etc, so if you really want to be reasonably sure all caching is disabled, you might need to emit several headers.

      I once found a good example here in the PHP docs, that has seemed to work for all cases I've seen. It is most certainly overkill, but if no other solution presents itself...

      This is the original code, which is easy to translate into perl, since it is just prints at the right moment (as in first). :) The function header in PHP is basically a print, that adds the correct \015\012 and must be emitted before the HTML itself, as expected.

      header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); // alwa +ys modified header("Cache-Control: no-store, no-cache, must-revalidate"); // HTTP/ +1.1 header("Cache-Control: post-check=0, pre-check=0", false); header("Pragma: no-cache"); // HTTP/1.0

      That said it is pretty strange if it was the browser caching a POST, as I've never seen IE have that problem. But it is hard to think otherwise, since you say that Opera doesn't have that issue.


      You have moved into a dark place.
      It is pitch black. You are likely to be eaten by a grue.
    Re: Strange POST Behavior / Possible Caching Issue
    by Aristotle (Chancellor) on Jun 06, 2002 at 19:16 UTC

      IE can be very stubborn. I've had issues with it caching cookies it shouldn't have, and to my dismay there wasn't much I could do to beat it into behaving. Adding a Cache-control header as dws proposed is avisable - in fact, I advise sending actual headers rather than the META tags you have.

      On the other hand, in your case it sounds like it could well be an issue on the server side, as though your script is being kept alive after one invocation and won't accept data after one run; after some idle time it's killed, and then takes data once more when it's rerun.

      The fact that behaviour differs depending on user agent is odd however - either way.

      Maybe it's due to some strange kind of HTTP/1.1 keepalive handling? What configuration are the scripts running under? What exact browser versions have you tested this with? Specifically IE's behaviour can change from one build to the next - obscure bugs crop up and disappear overnight. Really frustrating.

      Makeshifts last the longest.

    Re: Strange POST Behavior / Possible Caching Issue
    by Juerd (Abbot) on Jun 06, 2002 at 18:37 UTC

      POST requests should never be cached, only for when the user uses the "back" function. Opera had some problems in versions 4 and 5 with this (it was reported a lot), and this is why I haven't bothered trying Opera 6. If it doesn't cache POST requests anymore, the problem has been fixed. This seems to be the case.

      If the script gets executed, a cached version of the page is not being used. I don't know what $query->Dump should do, but you might want to check the raw contents waiting in STDIN (use a BEGIN block to make sure you are faster than CGI.pm or any module that slurps STDIN) to know for sure that it's not a bug in the module you're using.

      Some modules don't work well with mod_perl. Do you work with mod_perl here? If so, you might want to check whether you're using a global instead of a lexical, or if a module does that.

      Does this happen with MSIE on one computer, or on multiple computers? Have you tried several versions? I know of some who had to reinstall Windows because of strange MSIE behaviour. Does the problem occur with Mozilla too? Because of my disappointing experiences with Opera and caching, I wouldn't recommend using Opera for sane comparisons.

      - Yes, I reinvent wheels.
      - Spam: Visit eurotraQ.
      

    Re: Strange POST Behavior / Possible Caching Issue
    by hacker (Priest) on Jun 07, 2002 at 13:31 UTC
      And for those wondering how to do this with CGI.pm, this seemed to work for me:
      print header({-pragma=>'no-cache'}); print $query->start_html(-title=>'My Florb'', -author=>'web@domain.com', -base=>'true', -meta=>{'keywords'=> 'Palm PDA parser', 'copyright'=> 'Copyright &copy; 2002 +Florb, Inc.', 'Cache-Control'=>'no-cache', 'robots'=> 'index,follow'}, );
      Microsoft has a Support article on this exact topic:
      "When you use the <HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE"> metatag in the header section at the beginning of an HTML Web page, the Web page may still be cached in the Temporary Internet Files folder."
      Also:

      As of version 1.56, all HTTP headers produced by CGI.pm contain the Pragma: no-cache instruction. However, as of version 1.57, this is turned OFF by default because it causes Netscape 2.0 and higher to produce an annoying warning message every time the ``back'' button is hit. Turn it on again with the method cache().

      Here's a smaller test example:
      use CGI qw/:standard/; $modtime = scalar(gmtime(time - (3600 * 8))) . " GMT"; $exptime = scalar(gmtime) . " GMT"; print header(-expires=>$exptime, 'last-modified'=>$modtime, 'cache-control'=>"no-cache, must-revalidate", 'pragma'=>"no-cache"), start_html('Header Test'), pre("\nModtime: $modtime\nExptime: $exptime\n"), end_html;
      HEAD on this will show (among other things):
      200 OK Cache-Control: no-cache, must-revalidate Pragma: no-cache Expires: Fri Jun 7 13:23:22 2002 GMT Last-Modified: Fri Jun 7 05:23:22 2002 GMT
      RFC 2068 goes over this a bit as well.

      The Pragma: no-cache and Expires headers are the important ones for clients which do not understand the Cache-Control header.

    Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Domain Nodelet?
    Node Status?
    node history
    Node Type: perlquestion [id://172303]
    Approved by cacharbe
    help
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this?Last hourOther CB clients
    Other Users?
    Others avoiding work at the Monastery: (4)
    As of 2024-03-29 06:47 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      No recent polls found