Excluding page from back button history

[jim.richardson]

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.

[Rik Wasmus]

On Mon, 03 Dec 2007 11:42:52 +0100, <ji************@hiteclabs.comwrote:

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.

There is no such thing. However:
- if you're doing this to prevent the message that's something like 'the
page is expired, resubmit values?' look into header redirects on the page
receiving the posted values.
- pages altered/loaded with javascript don't always show up in the
history: ask in comp.lang.javascript when exactly pages are added, and
when they're not. The reverse of your issue (I _want_ to have the page in
the history) has been tackled a lot.
--
Rik Wasmus

[André Gillibert]

ji************@hiteclabs.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.

Without further information about *why* you want that, we can just think
that you're trying to do something evil. The user should be the only
master of what he keeps in the history.
If it's because you want to redirect an URL to another one, than, don't
use the ugly HTML META hack, use proper HTTP 301 redirects, and you'll get
a good history handling by all browsers.

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

[Adrienne Boswell]

Gazing into my crystal ball I observed ji************@hiteclabs.com
writing in news:de0d9b7b-c43a-489f-a8a7-
ef**********@d61g2000hsa.googlegroups.com:

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.

Me thinks this might be a form, or a series of forms. Best thing to do
is to check server side. You really don't want to mess with the user's
browser, as others have pointed out.

--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

[Jim]

Hi all,

Thanks for all your suggestions, but I can assure you that it my
purpose is not evil. Or at least I don't think it is.

To give you a bit more info, what I'm actually doing is developing an
ISAPI application which allows the users to enter one or more rows of
data into a database table.

The problem is, that I want to allow them to add many rows of data
(with each page representing a single row of data), by providing them
with a "submit this row and add another new row" button (so to speak),
which will take them to another page for creating a new row.

Of course, if they choose to create 10 new rows, this means that they
would have to hit the back button 10 times before they get back to the
page that they wanted to get back to. All I want to do is mark each
editing page as "don't include in the back history" so that when they
click back the first time, it goes back to the page that they want to
get back to.

Again, any thoughts on all this will be appreciated...

[Rik Wasmus]

On Tue, 04 Dec 2007 10:38:19 +0100, Jim <ji************@hiteclabs.com>
wrote:

Thanks for all your suggestions, but I can assure you that it my
purpose is not evil. Or at least I don't think it is.

To give you a bit more info, what I'm actually doing is developing an
ISAPI application which allows the users to enter one or more rows of
data into a database table.

The problem is, that I want to allow them to add many rows of data
(with each page representing a single row of data), by providing them
with a "submit this row and add another new row" button (so to speak),
which will take them to another page for creating a new row.

Of course, if they choose to create 10 new rows, this means that they
would have to hit the back button 10 times before they get back to the
page that they wanted to get back to. All I want to do is mark each
editing page as "don't include in the back history" so that when they
click back the first time, it goes back to the page that they want to
get back to.

If I'd do that (hit the back button), I'd like to see my previously
entered row (my UA will remember what I entered in those fields)...

Again, any thoughts on all this will be appreciated...

Store the 'calling page' somewhere (either in a server-side session or a
hidden form-input), and also provide them with a "submit this row and then
send me back to the overview I was coming from"-button (use a HTTP header
redirect to send them back), and/or possible a "just go back to the
overview and disregard what I was doing here"-button or link.
--
Rik Wasmus

[Harlan Messinger]

Jim wrote:

Hi all,

Thanks for all your suggestions, but I can assure you that it my
purpose is not evil. Or at least I don't think it is.

To give you a bit more info, what I'm actually doing is developing an
ISAPI application which allows the users to enter one or more rows of
data into a database table.

The problem is, that I want to allow them to add many rows of data
(with each page representing a single row of data), by providing them
with a "submit this row and add another new row" button (so to speak),
which will take them to another page for creating a new row.

Of course, if they choose to create 10 new rows, this means that they
would have to hit the back button 10 times before they get back to the
page that they wanted to get back to.

Assuming they have some reason to return to that page, they *can* click
the little arrow next to the back button and then select it from the
pop-up menu.

You can also have a link on your page that takes them to it if you think
it's something they're likely to want to do.

All I want to do is mark each
editing page as "don't include in the back history" so that when they
click back the first time, it goes back to the page that they want to
get back to.

Again, any thoughts on all this will be appreciated...

[Steve Swift]

Rik Wasmus wrote:

>I'd like a page to be excluded from the back button history
...
Can anybody please tell me how to do this?

I think one way to do this is to send them to a page which causes a
redirect to the page you want them to go to. I've often seen people
complaining that such a mechanism breaks the history mechanism.

It may be necessary to achieve the redirect with a real "Status: 302"
HTTP header rather than relying on those "airy-fairy" pragma schemes.

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

[André Gillibert]

Jim wrote:

Thanks for all your suggestions, but I can assure you that it my
purpose is not evil. Or at least I don't think it is.

Your intent wasn't evil, but the resulting web page would be evil.

The problem is, that I want to allow them to add many rows of data
(with each page representing a single row of data), by providing them
with a "submit this row and add another new row" button (so to speak),
which will take them to another page for creating a new row.

Of course, if they choose to create 10 new rows, this means that they
would have to hit the back button 10 times before they get back to the
page that they wanted to get back to.

No, they wouldn't have to. Most people have their own browsing style and
don't like it to be modified/broken by web sites.
Some users are aware of "advanced" browser features such as a back history
shown in a popup menu that most browsers provide.
Other users use multi-page or multi-windows browsing (even IE 4 and NS 4
provide this feature) and would've kept the home page open.
Other users may have assigned a keyboard shortcut or bookmarked the page,
and access it with a keyboard shortcut, nickname, click, or even type the
URL by hand with or without help of auto-completion.
Or, they may follow a link (A element) to the "home" page on the form
page. If you didn't provide this link, then, you should add it. You may
even provide a form button "submit last row" that would go back (303 See
Also) to the home page.

All I want to do is mark each
editing page as "don't include in the back history" so that when they
click back the first time, it goes back to the page that they want to
get back to.

1) They would be confused.
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.
3) This would "break the back and back history buttons", but also "break
the history panel" or add an inconsistency between the back history and
the general history.

Additionally, your database system must accept the fact that people can
post data several times. Ideally, it should do what the user expects. For
this problem, I think that the most appropriate behavior is to modify the
specific row if the data is posted again, unless the posted data is empty.

That way, it would be easy to fix the errors, by using the back history!

--
Sincerely.
André Gillilbert.

[Steve Swift]

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

[Rik Wasmus]

On Wed, 05 Dec 2007 05:45:22 +0100, Steve Swift <St***********@gmail.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

[André Gillibert]

Rik Wasmus wrote:

On Wed, 05 Dec 2007 05:45:22 +0100, Steve Swift <St***********@gmail.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>

[Steve Swift]

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