Excluding page from back button history

2) They would be frustrated of not being able to see the previous page
when they want to check some data they typed or saw.

I have some sympathy with wanting a "back" button that takes you to the
parent page, especially when using Internet Explorer, which seems to
treat the "Back" button logically as "Go back one page, then press "Reload".

Perhaps the OP should include a "Return" button, for those who want to
go to the parent page.

I have my own reasons for wanting to suppress "back". My pages are all
CGI scripts, and I have a real problem with people who go back several
pages then accidentally hit reload/refresh. I get fed up sending
responses such as "You've already done that once, you buffoon!"

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

On Wed, 05 Dec 2007 05:45:22 +0100, Steve Swift <Steve.J.Swift (AT) gmail (DOT) com>
wrote:

2) They would be frustrated of not being able to see the previous page
when they want to check some data they typed or saw.

I have some sympathy with wanting a "back" button that takes you to the
parent page, especially when using Internet Explorer, which seems to
treat the "Back" button logically as "Go back one page, then press
"Reload".

Perhaps the OP should include a "Return" button, for those who want to
go to the parent page.

I have my own reasons for wanting to suppress "back". My pages are all
CGI scripts, and I have a real problem with people who go back several
pages then accidentally hit reload/refresh. I get fed up sending
responses such as "You've already done that once, you buffoon!"

Which is solved usually as followed:
1. You have a page(/URL) for displaying content/forms/whatever.
2. You have a page(/URL) which purpose is to alter data.
3. The page/URL altering data does not display anything, it instead usesa
302 header redirect to a page of the (1) variant after it's finished
(effectively changing the method of retrieval from a POST to a GET).

One drawback of this is that when a problem arises (entered values not
valid etc.), it becomes somewhat more verbose to get that error to the
users screen than just to print/echo it where it occurs. In PHP, I solve
this by using sessions, and I store (page-specific) error-messages on the
server to be displayed on that certain page the next time it's shown
during the sessions.

PHP would be off-topic here, but a little peak on pseudo code how this
would be done:

----the processing page----
$valid = true;
//something's not valid:
if(empty($_POST['required_field'])){
//store into the sessions
$_SESSION['specific_pagename']['errors'][] = 'Required field is empty..';
$valid = false;
}
...........
header('302 Found');
if($valid){
header('Location: /path/to/form.php');
} else {
header('Location: /path/to/success.php');
}
---------------------------
----the viewing page-------
//check for stored errors
if(isset($_SESSION['specific_pagename']['errors'])){
echo '<ul class="errorlist">';
foreach($_SESSION['specific_pagename']['errors'] as $error) echo
"<li>$error</li>\n";
echo '</ul>';
//remove all errors now, we have displayed them:
unset($_SESSION['specific_pagename']['errors']);
}
---------------------------

This kind of construct will leave everything the user sees 'intact', he
can use his history normally, without being asked to resubmit data. Only
when the user clicks a button (/does a POST), something will be processed
again. It requires seperation of displaying data/forms and actually
processsing them, but it's quite easy to get the hang off. Seperating
processing & displaying is a good thing. Even if you like to keep the
script for displaying forms in the same file as the one processing it,
there's no reason a page cannot do a 302 redirect to itself, and be
configured only to process values on a POST.
--
Rik Wasmus

Rik Wasmus wrote:

On Wed, 05 Dec 2007 05:45:22 +0100, Steve Swift <Steve.J.Swift (AT) gmail (DOT) com
I have my own reasons for wanting to suppress "back". My pages are all
CGI scripts, and I have a real problem with people who go back several
pages then accidentally hit reload/refresh. I get fed up sending
responses such as "You've already done that once, you buffoon!"
Which is solved usually as followed:
1. You have a page(/URL) for displaying content/forms/whatever.
2. You have a page(/URL) which purpose is to alter data.
3. The page/URL altering data does not display anything, it instead uses
a
302 header redirect to a page of the (1) variant after it's finished
(effectively changing the method of retrieval from a POST to a GET).

302 is inappropriate (you're relying on user agents BUGS), use 303 instead.
From RFC-2616:

Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.

303 is perfectly appropriate in this case. It indicates to the user
agent that, it should look at the given location but the new page
isn't the same resource as the posted page.
On the other hand, 302 means: "This resource is provided at this new
URI, please, access this resource through this new URI"
This is fundamentally different: 303 points to a new resource. 302
points to the same resource.

A "302 Found" redirection should be transparent to the user, and,
ideally, the original URI should be kept in the address bar, allowing
people to see and bookmark the old URI, as it's the reference URI (but
that's not the behavior of current user agents, probably for security
reasons).

--
If you've a question that doesn't belong to Usenet, contact me at
<tabkanDELETETHISnaz at yahoDELETETHATo.fr>

André Gillibert wrote:

The status codes 303 and 307 have been added for servers that wish to
make unambiguously clear which kind of reaction is expected of the
client.

303 is perfectly appropriate in this case. It indicates to the user
agent that, it should look at the given location but the new page
isn't the same resource as the posted page.

Thank you for bringing Status 303 to my attention. I will almost never
use 302 from now on. My O'Reilly Apache reference defines 303 as "See
other" which didn't really catch my attention in the way your POST did.

As it happens, my applications keep the same URL throughout, just using
the content of the POST data to deduce what to do next, so I've
accidentally complied with that suggestion. My reason was that it is
simpler (for me) to keep all the action in one CGI script.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk

On 12/3/2007 6:34 PM, David E. Ross wrote:

On 12/3/2007 2:42 AM, jim.richardson (AT) hiteclabs (DOT) com wrote:
Hi all,

I'd like a page to be excluded from the back button history, that is,
when a user hits their browser's back button, it never backs into this
particular page.

Can anybody please tell me how to do this?

I thought perhaps there would be some kind of special meta tag that
says something like "exclude me from browser's history", but have been
unable to find what I'm looking for.

Any pointers would be very much appreciated.

The most effective way to do that is to launch the page in a new window.
However, that too is considered user-hostile. Launching a new window
is so much condemned that several browsers now have the options to
display such pages in a new tab on the same window and even to reuse the
current window for the page, defeating any attempt to force a new window.

Note that one of the "W3C Quality Assurance Tips for Webmasters" at
http://www.w3.org/QA/Tips/> is subtitled: "Don't break the back
button!" Research shows that the Back button is one of the two most
frequently used capabilities of browsers.

You might also look at #1 under Jakob Nielsen's "The Top Ten Web Design
Mistakes of 1999" at <http://www.useit.com/alertbox/990530.html>. While
not recent, it's still apropriate.

--
David E. Ross
<http://www.rossde.com/>

Natural foods can be harmful: Look at all the
people who die of natural causes.

In article <_IWdnYkJg6FhfcXanZ2dnUVZ_sSlnZ2d (AT) softcom (DOT) net>,
"David E. Ross" <nobody (AT) nowhere (DOT) not> wrote:

On 12/3/2007 6:34 PM, David E. Ross wrote:
On 12/3/2007 2:42 AM, jim.richardson (AT) hiteclabs (DOT) com wrote:
Hi all,

I'd like a page to be excluded from the back button history, that is,
when a user hits their browser's back button, it never backs into this
particular page.
[snip]

Note that one of the "W3C Quality Assurance Tips for Webmasters" at
http://www.w3.org/QA/Tips/> is subtitled: "Don't break the back
button!" Research shows that the Back button is one of the two most
frequently used capabilities of browsers.


You might also look at #1 under Jakob Nielsen's "The Top Ten Web Design
Mistakes of 1999" at <http://www.useit.com/alertbox/990530.html>. While
not recent, it's still apropriate.

"The connection timed out" - did anyone manage to snag a copy?

In article <_IWdnYkJg6FhfcXanZ2dnUVZ_sSlnZ2d (AT) softcom (DOT) net>,
"David E. Ross" <nobody (AT) nowhere (DOT) not> wrote:

On 12/3/2007 6:34 PM, David E. Ross wrote:
On 12/3/2007 2:42 AM, jim.richardson (AT) hiteclabs (DOT) com wrote:
Hi all,

I'd like a page to be excluded from the back button history, that is,
when a user hits their browser's back button, it never backs into this
particular page.

Can anybody please tell me how to do this?

I thought perhaps there would be some kind of special meta tag that
says something like "exclude me from browser's history", but have been
unable to find what I'm looking for.

Any pointers would be very much appreciated.

The most effective way to do that is to launch the page in a new window.
However, that too is considered user-hostile. Launching a new window
is so much condemned that several browsers now have the options to
display such pages in a new tab on the same window and even to reuse the
current window for the page, defeating any attempt to force a new window.

Note that one of the "W3C Quality Assurance Tips for Webmasters" at
http://www.w3.org/QA/Tips/> is subtitled: "Don't break the back
button!" Research shows that the Back button is one of the two most
frequently used capabilities of browsers.


You might also look at #1 under Jakob Nielsen's "The Top Ten Web Design
Mistakes of 1999" at <http://www.useit.com/alertbox/990530.html>. While
not recent, it's still apropriate.

I must say that, still, I would like to be able to do it. One of the
pages here reloads the contents of a frame depending on buttons the user
presses. All of that seems to go in the history stack. I would like to
be able to exclude that, so that the Back button does something useful
from this page.

Tim Streater wrote:

In article <_IWdnYkJg6FhfcXanZ2dnUVZ_sSlnZ2d (AT) softcom (DOT) net>,
"David E. Ross" <nobody (AT) nowhere (DOT) not> wrote:

On 12/3/2007 6:34 PM, David E. Ross wrote:
On 12/3/2007 2:42 AM, jim.richardson (AT) hiteclabs (DOT) com wrote:
Hi all,

I'd like a page to be excluded from the back button history, that is,
when a user hits their browser's back button, it never backs into this
particular page.

Can anybody please tell me how to do this?

I thought perhaps there would be some kind of special meta tag that
says something like "exclude me from browser's history", but have been
unable to find what I'm looking for.

Any pointers would be very much appreciated.
The most effective way to do that is to launch the page in a new window.
However, that too is considered user-hostile. Launching a new window
is so much condemned that several browsers now have the options to
display such pages in a new tab on the same window and even to reuse the
current window for the page, defeating any attempt to force a new window.

Note that one of the "W3C Quality Assurance Tips for Webmasters" at
http://www.w3.org/QA/Tips/> is subtitled: "Don't break the back
button!" Research shows that the Back button is one of the two most
frequently used capabilities of browsers.

You might also look at #1 under Jakob Nielsen's "The Top Ten Web Design
Mistakes of 1999" at <http://www.useit.com/alertbox/990530.html>. While
not recent, it's still apropriate.

I must say that, still, I would like to be able to do it. One of the
pages here reloads the contents of a frame depending on buttons the user
presses. All of that seems to go in the history stack. I would like to
be able to exclude that, so that the Back button does something useful
from this page.

Suppose the useful thing you would like it to do was actually 10 pages
ago. If the user wants to go back to that point, he would assume that
the Back button *wouldn't* take him there, at least not without hitting
it 10 times, at which point he will either (a) use the pop-up menu next
to the Back button to try to go there directly, in which case your
machination won't have made any difference--except perhaps make it more
*difficult* for the user to find it, since in eyeballing the list he
won't be expecting to find it at the top, or (b) look for a link to take
him there directly, which he will expect to see given that this is a
page that's so clearly useful for him at this point.

The general problem with trying to "help" users by making controls act
unexpectedly is that the number of people you hinder and confuse can
exceed the number of people you help.

In article <5rt2d6F16ho9uU1 (AT) mid (DOT) individual.net>,
Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

Tim Streater wrote:
In article <_IWdnYkJg6FhfcXanZ2dnUVZ_sSlnZ2d (AT) softcom (DOT) net>,
"David E. Ross" <nobody (AT) nowhere (DOT) not> wrote:

On 12/3/2007 6:34 PM, David E. Ross wrote:
On 12/3/2007 2:42 AM, jim.richardson (AT) hiteclabs (DOT) com wrote:
Hi all,

I'd like a page to be excluded from the back button history, that is,
when a user hits their browser's back button, it never backs into this
particular page.

Can anybody please tell me how to do this?

I thought perhaps there would be some kind of special meta tag that
says something like "exclude me from browser's history", but have been
unable to find what I'm looking for.

Any pointers would be very much appreciated.
The most effective way to do that is to launch the page in a new window.
However, that too is considered user-hostile. Launching a new window
is so much condemned that several browsers now have the options to
display such pages in a new tab on the same window and even to reuse the
current window for the page, defeating any attempt to force a new window.

Note that one of the "W3C Quality Assurance Tips for Webmasters" at
http://www.w3.org/QA/Tips/> is subtitled: "Don't break the back
button!" Research shows that the Back button is one of the two most
frequently used capabilities of browsers.

You might also look at #1 under Jakob Nielsen's "The Top Ten Web Design
Mistakes of 1999" at <http://www.useit.com/alertbox/990530.html>. While
not recent, it's still apropriate.

I must say that, still, I would like to be able to do it. One of the
pages here reloads the contents of a frame depending on buttons the user
presses. All of that seems to go in the history stack. I would like to
be able to exclude that, so that the Back button does something useful
from this page.

Suppose the useful thing you would like it to do was actually 10 pages
ago. If the user wants to go back to that point, he would assume that
the Back button *wouldn't* take him there, at least not without hitting
it 10 times, at which point he will either (a) use the pop-up menu next
to the Back button to try to go there directly, in which case your
machination won't have made any difference--except perhaps make it more
*difficult* for the user to find it, since in eyeballing the list he
won't be expecting to find it at the top, or (b) look for a link to take
him there directly, which he will expect to see given that this is a
page that's so clearly useful for him at this point.

The general problem with trying to "help" users by making controls act
unexpectedly is that the number of people you hinder and confuse can
exceed the number of people you help.

These pages are seen by a limited audience. If I were able to do that,
and they didn't like it, they'd soon let me know. It's the sort of
feature request I get, in fact.

Tim Streater wrote:

In article <_IWdnYkJg6FhfcXanZ2dnUVZ_sSlnZ2d (AT) softcom (DOT) net>,
"David E. Ross" <nobody (AT) nowhere (DOT) not> wrote:

On 12/3/2007 6:34 PM, David E. Ross wrote:
On 12/3/2007 2:42 AM, jim.richardson (AT) hiteclabs (DOT) com wrote:
Hi all,

I'd like a page to be excluded from the back button history, that
is, when a user hits their browser's back button, it never backs
into this particular page.

Can anybody please tell me how to do this?

I thought perhaps there would be some kind of special meta tag that
says something like "exclude me from browser's history", but have
been unable to find what I'm looking for.

Any pointers would be very much appreciated.

The most effective way to do that is to launch the page in a new
window. However, that too is considered user-hostile. Launching a
new window
is so much condemned that several browsers now have the options to
display such pages in a new tab on the same window and even to
reuse the current window for the page, defeating any attempt to
force a new window.

Note that one of the "W3C Quality Assurance Tips for Webmasters" at
http://www.w3.org/QA/Tips/> is subtitled: "Don't break the back
button!" Research shows that the Back button is one of the two most
frequently used capabilities of browsers.


You might also look at #1 under Jakob Nielsen's "The Top Ten Web
Design Mistakes of 1999" at
http://www.useit.com/alertbox/990530.html>. While not recent, it's
still apropriate.

I must say that, still, I would like to be able to do it. One of the
pages here reloads the contents of a frame depending on buttons the
user presses. All of that seems to go in the history stack. I would
like to be able to exclude that, so that the Back button does
something useful from this page.

This is doable but not for static html page. Your server must send next two
lines in HTTP header

Cache-Control: no-cache, no-store, no-transform, must-revalidate
Pragma: no-cache

You can send this header using Perl or PHP. If you use cookies then these
lines must be send _before_ any cookies.

--
Petr Vileta, Czech republic
(My server rejects all messages from Yahoo and Hotmail. Send me your
mail from another non-spammer site please.)

Please reply to <petr AT practisoft DOT cz>