show "webpage has expired" on back button

What is the requirement for the 开发者_JAVA技巧browser to show the ubiquitous "this page has expired" message when the user hits the back button?

What are some user-friendly ways to prevent the user from using the back button in a webapp?

---

Well, by default whenever you're dealing with a form POST, and then the user hits back and then refresh then they'll see the message indicating that the browser is resubmitting data. But if the page is set to expire immediately then they won't even have to hit refresh and they'll see the page has expired message when they hit back.

To avoid both messages there are a couple things to try:

1) Use a form GET instead. It depends on what you're doing but this isn't always a good solution as there are still size restrictions on a GET request. And the information is passed along in the querystring which isn't the most secure of options.

-- or --

2) Perform a server-side redirect to a different page after the form POST.

Looks like a similar question was answered here:

Redirect with a 303 after POST to avoid "Webpage has expired": Will it work if there are more bytes than a GET request can handle?

As a third option one could prevent a user from going back in their browser at all. The only time I've felt a need to do this was to prevent them from doing something stupid such as paying twice. Although there are better server-side methods to handle that. If your site uses sessions then you can prevent them from paying twice by first disabling cache on the checkout page and setting it expire immediately. And then you can utilize a flag of some sort stored in a session which will actually change the behavior of the page if you go back to it.

---

you need to set pragma-cache control option in HTTP headers: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

However, from the usability point of view, this is discouraged approach to the matter. I strongly encourage you to look for other options.

ps: as proposed by Steve, redirection via GET is the proper way (or check page movement with JS).

---

Try using the following code in the Page_Load

Response.Cache.SetCacheability(HttpCacheability.Private)

---

use one of the following before session_start:

session_cache_expire(60); // in minutes 

ini_set('session.cache_limiter', 'private');

/Note:

Language is PHP

---

I'm not sure if this is standard practice, but I typically solve this issue by not sending a Vary header for IE only. In Apache, you can put the following in httpd.conf:

BrowserMatch MSIE force-no-vary

According to the RFC:

The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation.

The practical effect is that when you go "back" to a POST, IE simply gets the page from the history cache. No request at all goes to the server side. I can see this clearly in HTTPWatch.

I would be interested to hear potential bad side-effects of this approach.