"Warning: Page has Expired" - How to aviod when using browser back button?

[Dave Smithz]

Hi,

In summary:
I want to a form to submit information via a HTTP POST, however, when using
Internet Explorer I want to be able to use the back button and all the
information retained. Presently we get a "Page has expired" message. How can
we avoid this?

Full details:
Having searched for postings on how to avoid the "Page has Expired" they are
numerous, however, I have not found one that answers the question
adequately.

Hence this posting.

One posting directed me to the following webpage:
http://in.php.net/session_cache_limiter

but I played around with "session_cache_limiter()" and it did not give the
desired results. (It seem to make no difference). Also many people say to
use HTTP GET instead but this is not an option in this case.

Where can I find concise definitive information on how to avoid "Warning:
Page has Expired" and allow the user to press the back button and see the
form as it was before they submitted it?

Kind regards,
Dave

[Philip Ronan]

Dave Smithz wrote:

Hi,

In summary:
I want to a form to submit information via a HTTP POST, however, when using
Internet Explorer I want to be able to use the back button and all the
information retained. Presently we get a "Page has expired" message. How can
we avoid this?

Use GET instead of POST

See <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10>

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Janwillem Borleffs]

Dave Smithz wrote:

In summary:
I want to a form to submit information via a HTTP POST, however, when
using Internet Explorer I want to be able to use the back button and
all the information retained. Presently we get a "Page has expired"
message. How can we avoid this?

Apart the obvious usage of GET instead of POST, there's another way. This
involves submitting the form data to an intermediate page, which sends a
Location header through the header() function to a third page, which can be
used to preview the submitted data or to show a message (Thank you, Data
contains errors etc.).

When the user hits the back button on this third page, the intermediate page
will be skipped and the form page will be shown, without the warning.
JW

[Philip Ronan]

Janwillem Borleffs wrote:

Dave Smithz wrote:

In summary:
I want to a form to submit information via a HTTP POST, however, when
using Internet Explorer I want to be able to use the back button and
all the information retained. Presently we get a "Page has expired"
message. How can we avoid this?

Apart the obvious usage of GET instead of POST, there's another way. This
involves submitting the form data to an intermediate page, which sends a
Location header through the header() function to a third page, which can be
used to preview the submitted data or to show a message (Thank you, Data
contains errors etc.).

When the user hits the back button on this third page, the intermediate page
will be skipped and the form page will be shown, without the warning.

Just two problems with that:

1. The visitor's browser will have to submit the POST data twice

2. Browser support for POST redirects is rather unreliable (see
<http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html>)

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Janwillem Borleffs]

Philip Ronan wrote:

1. The visitor's browser will have to submit the POST data twice

Only when the submit button is hit again. The page itself, with the
prefilled values, is retrieved from the browser cache.
2. Browser support for POST redirects is rather unreliable (see
http://ppewww.ph.gla.ac.uk/~flavell/...-redirect.html)

I'm aware of the caveats, but I have found this method to be reliable enough
in most cases.
JW

[Philip Ronan]

Janwillem Borleffs wrote:

Philip Ronan wrote:

1. The visitor's browser will have to submit the POST data twice

Only when the submit button is hit again. The page itself, with the
prefilled values, is retrieved from the browser cache.

No, I mean when you send a "Location" header [1] back to the client, it has
to resubmit the POST data to the new URL. But you can't actually rely on
this happening anyway because...

2. Browser support for POST redirects is rather unreliable (see
http://ppewww.ph.gla.ac.uk/~flavell/...-redirect.html)

I'm aware of the caveats, but I have found this method to be reliable enough
in most cases.

That sounds like the sort of argument used to support the use of "mailto:"
as a form action. If you're not complying with the standards, then you're
asking for trouble. Sending a "Location" header with PHP simply isn't good
enough.

You also seem to have missed the URL I referrer to earlier on in this
thread: <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10>

Once data has been submitted by the POST method, it immediately becomes
stale. So it shouldn't be cached anywhere, even in your browser's local
cache. I can't see how redirecting the request should make any difference.

[1] Actually you should also be sending a "HTTP/1.1 307 Temporary redirect"
header. If you just send a "Location" header by itself, PHP generates a "302
Found" response, which asks the client to send a GET request to the new URL.
That means the POST data will all be lost.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Janwillem Borleffs]

Philip Ronan wrote:

No, I mean when you send a "Location" header [1] back to the client,
it has to resubmit the POST data to the new URL. But you can't
actually rely on this happening anyway because...

No, it hasn't. The idea is that the intermediate page processes the request
and just redirects to the final page, which only shows a message and doesn't
perform any processing. Hitting the back button will only retrieve the
cached form page.

When you have FireFox installed with the LiveHeaders extension, check it out
and see what happens.
JW

[Philip Ronan]

Janwillem Borleffs wrote:

Philip Ronan wrote:

No, I mean when you send a "Location" header [1] back to the client,
it has to resubmit the POST data to the new URL. But you can't
actually rely on this happening anyway because...

No, it hasn't. The idea is that the intermediate page processes the request
and just redirects to the final page, which only shows a message and doesn't
perform any processing. Hitting the back button will only retrieve the
cached form page.

Sorry, ignore what I just said. I was getting confused with another thread.
--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Alan J. Flavell]

On Sat, 19 Feb 2005, Philip Ronan wrote:

2. Browser support for POST redirects is rather unreliable (see
<http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html>)

Although I see that the discussion has since moved on, I believe it
would be useful if I made a comment on that point, lest anyone should
go away with the wrong impression.

There are, broadly speaking, two different scenarios examined in the
page of mine that you have cited. I think your comment was related
to one of them, but it wasn't the one that was pertinent in this
particular thread.

1. If the POST transaction is carried out at the first URL, and the
server-side script then returns a status (303 or 302) inviting the
client to view the URL of a result page, then everything is fine and
dandy ("entirely feasible" as I call it in the conclusions). AIUI
this is the scenario that was envisaged on this thread.

2. If the POST transaction is meant to be redirected from the first
URL to a second URL and the "work" carried out there (using status
307 or 301), then the situation is pretty hopeless, in a WWW context.
As my conclusion says:

Redirection of a POST transaction to another URL as POST evidently
works only in a subset of browsers

But I don't believe that was what was intended here.
On the more general point: non-idempotent transactions are *supposed*
to be carried out via a POST. Redirecting a POST transaction,
complete with its submission parameters, to a GET transaction and then
actioning that transaction as a second URL, would be to defeat/
subvert the very mechanism that had been designed for carrying out
non-idempotent transactions -- just as badly (or worse) as if the
transaction had been submitted via GET in the first place.

hope that's useful.

(more details, of course - maybe more than you ever wanted :-} - are
on the page itself.)

[Philip Ronan]

Alan J. Flavell wrote:

There are, broadly speaking, two different scenarios examined in the
page of mine that you have cited. I think your comment was related
to one of them, but it wasn't the one that was pertinent in this
particular thread.
Sorry about that -- I was getting muddled up with another thread ("Passing
HTTP POST information to another script - How?")
On the more general point: non-idempotent transactions are *supposed*
to be carried out via a POST. Redirecting a POST transaction,
complete with its submission parameters, to a GET transaction and then
actioning that transaction as a second URL, would be to defeat/
subvert the very mechanism that had been designed for carrying out
non-idempotent transactions -- just as badly (or worse) as if the
transaction had been submitted via GET in the first place.

But why anyone would need to use the "BACK" button to return to a previously
submitted POST form? If the OP is trying to -- for example -- add several
similar items to a database, then it would be much better to submit the form
to the same URL and pre-fill it with the items submitted last time. Relying
on the BACK button as a means of retrieving stale data sounds like the wrong
way of doing things.

BTW Alan, nice website!

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Dave Smithz]

"Philip Ronan" <in*****@invalid.invalid> wrote in message
news:BE3BFDD8.2B637%in*****@invalid.invalid...

Dave Smithz wrote:
Use GET instead of POST

See <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10>

As I said in my original posting use of GET is not an option. Is there a way
of doing it without using GET?

[Dave Smithz]

"Philip Ronan" <in*****@invalid.invalid> wrote in message
news:BE3E1EFF.2B7F6%in*****@invalid.invalid...

But why anyone would need to use the "BACK" button to return to a previously submitted POST form? If the OP is trying to -- for example -- add several
similar items to a database, then it would be much better to submit the form to the same URL and pre-fill it with the items submitted last time. Relying on the BACK button as a means of retrieving stale data sounds like the wrong way of doing things.

OK interesting comments Alan. Steering things back to the problem I was
originally trying to solve the following is the scenario.

1) Client uses a search web page to search for matching results in a MySQL
DB.
2) They are shown a list of matching results when submitting a search
(currently as POST)
3) They sometimes click in to view full details of a particular result.
----
4) Further to this they sometimes like to click back and then click to view
the full details of another particular result.
5) Sometimes they like to go back even further, going back to the original
search page and make some minor changes to the original search criteria they
put in (without putting it in all over again).

In IE (which client uses and probably wont change):
* When using POST in the search form at point 4, when pressing back they
either get Page Expired or it takes them back to the search page. If it does
go to the search page, all the search fields have been cleared
* When using GET, they can go back to the search results page and choose
another (Great). If they go back to the search page, all the search fields
are cleared (it like you have clicked on the search page link for the first
time - it even takes a while to load up)

Note that using Firefox, using the back button behaves much better, as a
human would expect it to, but not going to be easy to get client to use it
so need to look at IE solution.

Also because there are a lot of SEARCH fields, I was worried about using a
GET because I was worried that it would be too much information for a GET to
carry and feel more comfortable using POST because it is what I have always
done for form submissions.

So the ideal scenario is, I use POST on the search form, the user can go
back, and they actually see what they saw before they clicked the link. This
is what my client expects.

Also note: you may be tempted to criticise the initial design, but this DB
is inherited from another company and we have taken over management. Major
changes will come, but later, so looking for quick fixes.

Hope that spells it out a bit more clearly and I hope someone can spell out
a clearer quick answer for me or convince me that it is fine to use GET,
even when you have a very large number of form fields to submit with long
names.

Regards

Dave

[Dave Smithz]

WHOOPS - This was still sitting in my outbox and got sent - Please ignore as
the discussion has moved on anyway
"Dave Smithz" <SPAM FREE WORLD> wrote in message
news:42********@news1.homechoice.co.uk...

"Philip Ronan" <in*****@invalid.invalid> wrote in message
news:BE3BFDD8.2B637%in*****@invalid.invalid...

Dave Smithz wrote:
Use GET instead of POST

See <http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10>
As I said in my original posting use of GET is not an option. Is there a

way of doing it without using GET?

WHOOPS - This was still sitting in my outbox and got sent - Please ignore as
the discussion has moved on anyway

[R. Rajesh Jeba Anbiah]

Dave Smithz wrote:
<snip>

One posting directed me to the following webpage:
http://in.php.net/session_cache_limiter

but I played around with "session_cache_limiter()" and it did not give the desired results. (It seem to make no difference).

Yes, that wouldn't make any sense, if you're not using sessions. So,
play with header().

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

[sharma]

Hi,

Use this n top of your .php file

header("Cache-control: private"); // IE 6 Fix.

sharma

[John Murtari]

"Dave Smithz" <SPAM FREE WORLD> writes:

I want to a form to submit information via a HTTP POST, however, when using
Internet Explorer I want to be able to use the back button and all the
information retained. Presently we get a "Page has expired" message. How can
we avoid this?

Full details:
Having searched for postings on how to avoid the "Page has Expired" they are
numerous, however, I have not found one that answers the question
adequately.

Hence this posting.

One posting directed me to the following webpage:
http://in.php.net/session_cache_limiter

but I played around with "session_cache_limiter()" and it did not give the
desired results. (It seem to make no difference). Also many people say to
use HTTP GET instead but this is not an option in this case.

Where can I find concise definitive information on how to avoid "Warning:
Page has Expired" and allow the user to press the back button and see the
form as it was before they submitted it?

Kind regards,
Dave

We have some similar applications where folks look at search
results but then want to backup. We added the following header and
it seems to do fine:

<?
header("Cache-Control: max-age=300, must-revalidate");
?>

You will 'know' if it is 'working' by playing with the
max-age value. In this case you can go 'back' for up to 5 minutes
without getting an expired warning -- after more time you will.

Hope this helps.

--
John
__________________________________________________ _________________
John Murtari Software Workshop Inc.
jmurtari@following domain 315.635-1968(x-211) "TheBook.Com" (TM)
http://thebook.com/

[Dave Smithz]

"sharma" <sh*************@gmail.com> wrote in message >

Use this n top of your .php file

header("Cache-control: private"); // IE 6 Fix.

I tried this but I was still getting the same problem. Anything else I need
to do for this to work?

Regards

Dave