in reply to page expired message

This is actually a feature of the web browser that is saving you from having duplicate information. Form submissions are usually task processing in nature, which means for instance that if someone hits 'back' from your order confirmation page if the web browser resubmitted your form in all likelyhood it would generate a new order (now duplicate) and take you to the confirmed order page for the new order.

This doesn't really have anything to do with the fact that it is a secure site. If you redirect at the end of every form handler, you will not have this problem. This does however make report filtering type forms a bit more difficult, but that situation would be one of the few where a method="get" form would be an appropriate choice.

Replies are listed 'Best First'.
Re^2: page expired message
by £okì (Scribe) on Jan 03, 2005 at 17:17 UTC
    Yea, this has nothing to do with perl or his code. It is either a setting on the server or IE. It's just saying that you shouldn't use "back" to resubmit a form. Just modify your script to forward the user to a new page once the form processes instead of outputting a html page.
[reply]
Re^2: page expired message
by Hammy (Scribe) on Jan 03, 2005 at 17:56 UTC
    Pardon my ignorance, but what do you mean - redirect at the end of every form handler. The way my page is created, I build the page from several places. I basically create a print statement that puts out the header, the dynamic middle part, and the trailer. There is never really an html page except the one I am creating.

    Each page has a menu structure surrounded by a form that calls a main script (index.cgi) that builds the next page. So no matter what page you go to on my site, you are at index.cgi and it builds your output.

    Is there a way around this with my methodology? Thanks.
[reply]

      I mean that every time a user clicks a submit button to submit a POST form, you follow these steps:

      1. Handle the form. This means creating the order, flipping the status field on your table, or whatever
      2. Redirect to a status page. This might need some massaging of variables to be passed along the request line in order to get enough information to say what happened, but it will remove the flaw in your page-to-page flow.

      This all stems from HTML not being meant to contain state information, and having that bolted on leaves a few rough edges such as this one.

      If this is still unclear please say so and I'll try to come up with a fleshed out example

[reply]
      More a workaround than a solution, but...
      Add a big label that says "Do not use your back button" in the header (or in each script producing the "dynamic" content
      PLUS
      build into your footer a link to something reasonable. Use standard .html if you're using a HERE for the footer; quote and escape VERY carefully if your footer is comprised of a bunch of

      print "<p>something....</p>";
print "<p>something else...</p>";"
print "<p><a href='path/to/something/reasonable...'>something reasonab
+le</a></p>";
print "</body></html>";

      [download]

      where "something reasonable" is your home "page," the top "page" in the section from which the submit calls the cgi, etc.

[reply]
[d/l]
        Add a big label that says "Do not use your back button"
        just a note: i hate websites that do that, especially if you get wrong results if you do use the button. i have a browser with back- and forward buttons (or keyboard shortcuts), and i want to use them. i might not be the only one.

        i'm pretty sure every problem like this can be solved in a way so that the user might use their browser like it is meant to. otherwise HTTP is probably not the right protocol for the task.
        just my 2 cents.

[reply]

In Section Seekers of Perl Wisdom