Raise your hand if you have ever wanted to disable the browser's BACK button

[Tony Marston]

If the use of the browser's BACK button is interfering with the operation of
your web application then take a look at this article entitle "Back Button
Blues"

http://www.tonymarston.co.uk/php-mys...ttonblues.html

--
Tony Marston

http://www.tonymarston.net

[Chung Leong]

I don't understand your argument against using the humble hidden. The
bandwidth disadvantage is negligible. And you need to do a access check on
the initial GET anyway, doing it again in the subsequent POST can't be that
hard.

Uzytkownik "Tony Marston" <to**@NOSPAM.demon.co.uk> napisal w wiadomosci
news:c0*******************@news.demon.co.uk...

If the use of the browser's BACK button is interfering with the operation of your web application then take a look at this article entitle "Back Button
Blues"

http://www.tonymarston.co.uk/php-mys...ttonblues.html

--
Tony Marston

http://www.tonymarston.net

[Tony Marston]

On some screens the number of hidden fields could be quite large, which
means that the document will take longer to download as well as retransmit.
Those of you who say that document size is not a problem are being totally
inconsiderate to those users who do not have a broadband connection.

Some of this data may also have security implications, so it is not a good
idea to send it across the net within the body of the HTML document as it
can be seen by anyone, especially by someone with nefarious intent. It is
better to keep such data on the server.

That is my humble opinion, for what it's worth.

Tony Marston
http://www.tonymarston.net

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:gK********************@comcast.com...

I don't understand your argument against using the humble hidden. The
bandwidth disadvantage is negligible. And you need to do a access check on
the initial GET anyway, doing it again in the subsequent POST can't be that hard.

Uzytkownik "Tony Marston" <to**@NOSPAM.demon.co.uk> napisal w wiadomosci
news:c0*******************@news.demon.co.uk...

If the use of the browser's BACK button is interfering with the operation

of

your web application then take a look at this article entitle "Back

Button Blues"

http://www.tonymarston.co.uk/php-mys...ttonblues.html

--
Tony Marston

http://www.tonymarston.net

[Jason]

"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message news:<c0*******************@news.demon.co.uk>...

If the use of the browser's BACK button is interfering with the operation of
your web application then take a look at this article entitle "Back Button
Blues"

http://www.tonymarston.co.uk/php-mys...ttonblues.html

I totally understand not wanting to let users resubmit forms by using
the back button or hitting reload when something is going slowly.

The simplest way around it I've thought of is to put a counter in
$_SESSION. Every time any page loads, the counter is incremented.
The form page has a hidden field equal to $_SESSION['counter'] + 1.
When submitting, if the current $_SESSION['counter'] and
$_POST['counter'] don't match, nothing is done.

Not as cool as a program stack, granted. :)

[John Dunlop]

Tony Marston wrote:

http://www.tonymarston.co.uk/php-mys...ttonblues.html

It looks as if you're confused about the distinction between history
mechanisms and browser caches (RFC2616, sec. 13.13); in short, they
ain't one and the same.

I'm firmly sitting on my hands.

--
Jock

[Tony Marston]

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...

Tony Marston wrote:

http://www.tonymarston.co.uk/php-mys...ttonblues.html
It looks as if you're confused about the distinction between history
mechanisms and browser caches (RFC2616, sec. 13.13); in short, they
ain't one and the same.

I never said they are the same, which is why I have a separate paragraph
explaining each one. Unless the user clears his cache in the middle of a
session then everything in the history is also is also in the cache, but
everything in the cache may not be in the history.

Unless you know better, of course ...
I'm firmly sitting on my hands.

You'll get a lot of work done that way

--
Tony Marston
http://www.tonymarston.net

[John Dunlop]

Tony Marston wrote:

[About the explanation of history mechanisms and browser caches in
http://www.tonymarston.co.uk/php-mys...tonblues.html]

I never said they are the same, which is why I have a separate paragraph
explaining each one.
There is no explanation of browser caches in the paragraph following
the subhead "Browser Cache". Are they explained elsewhere?

The explanation of history stacks, following the subhead "Browser
History", could be misleading: a history stack might not contain "all
pages visited"; if, say, I visit three webpages, go back twice, then
visit a new webpage, my history stack won't contain all previously
visited webpages. Donning my pedant hat for a moment, the term
"list" is used to describe how browser history mechanisms store
information; mightn't the term "stack" be more fitting? Or, I'd
suggest, at least, in passing, mention the term "stack".

Also, will you provide an URL to a document which claims that
accessing a file from the history stack ever caused any client to
make an HTTP request? I tried searching, without success. I'm just
curious, because that would be a truly silly way to engineer a
history mechanism.

Perhaps it'd be better to leave the explanation of those browser
features up to the sufficiently explanative documents already
publicly available.
Unless the user clears his cache in the middle of a session then everything
in the history is also is also in the cache,
No; not necessarily. Uncacheable files might be in the history
stack, whilst not in the browser cache.
but everything in the cache may not be in the history.
Indeed.
Unless you know better, of course ...

I'd recommend you make up your own mind:

| History mechanisms and caches are different. In particular history
| mechanisms SHOULD NOT try to show a semantically transparent view
| of the current state of a resource. Rather, a history mechanism is
| meant to show exactly what the user saw at the time when the
| resource was retrieved.
|
| By default, an expiration time does not apply to history
| mechanisms. If the entity is still in storage, a history mechanism
| SHOULD display it even if the entity has expired, unless the user
| has specifically configured the agent to refresh expired history
| documents.
-- RFC2616, sec. 13.13, http://www.ietf.org/rfc/rfc2616.txt

My advice? Accept this "interference", and stop trying to do the
impossible.

--
Jock

[Tony Marston]

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...

Tony Marston wrote:

[About the explanation of history mechanisms and browser caches in
http://www.tonymarston.co.uk/php-mys...tonblues.html]

I never said they are the same, which is why I have a separate paragraph
explaining each one.
There is no explanation of browser caches in the paragraph following
the subhead "Browser Cache". Are they explained elsewhere?

The cache is where the complete contents of the page is stored so that the
next time the same page is requested it is retrieved from the cache instead
of downloaded from the server. I did not supply complete details about the
caching mechainsim as it is not germaine to the issue under discussion.
The explanation of history stacks, following the subhead "Browser
History", could be misleading: a history stack might not contain "all
pages visited"; if, say, I visit three webpages, go back twice, then
visit a new webpage, my history stack won't contain all previously
visited webpages. Donning my pedant hat for a moment, the term
"list" is used to describe how browser history mechanisms store
information; mightn't the term "stack" be more fitting? Or, I'd
suggest, at least, in passing, mention the term "stack".
The article is about using the browser's BACK button which is about moving
backwards through the browser's history. The fact that subsequent forward
movement may remove items from history is not germaine to the issue.
Also, will you provide an URL to a document which claims that
accessing a file from the history stack ever caused any client to
make an HTTP request? I tried searching, without success. I'm just
curious, because that would be a truly silly way to engineer a
history mechanism.
If you visit a page that exists in your browser's cache then your browser
will attempt to serve it from cache instead of re-issuing the request to the
server. However, the effects of the browser's cache can be turned off,
either by adjusting settings in your browser or by the page author inserting
settings in the document. Therefore it is possible to visit a page in the
history stack and issue a fresh HTTP request.
Perhaps it'd be better to leave the explanation of those browser
features up to the sufficiently explanative documents already
publicly available.

Unless the user clears his cache in the middle of a session then everything in the history is also is also in the cache,
No; not necessarily. Uncacheable files might be in the history
stack, whilst not in the browser cache.

but everything in the cache may not be in the history.

Indeed.

Unless you know better, of course ...

My document only contains that amount of information which is relevant to
the use of the BACK button. Everything else is superfluous.
I'd recommend you make up your own mind:

| History mechanisms and caches are different. In particular history
| mechanisms SHOULD NOT try to show a semantically transparent view
| of the current state of a resource. Rather, a history mechanism is
| meant to show exactly what the user saw at the time when the
| resource was retrieved.
|
| By default, an expiration time does not apply to history
| mechanisms. If the entity is still in storage, a history mechanism
| SHOULD display it even if the entity has expired, unless the user
| has specifically configured the agent to refresh expired history
| documents.
-- RFC2616, sec. 13.13, http://www.ietf.org/rfc/rfc2616.txt

My advice? Accept this "interference", and stop trying to do the
impossible.

--
Jock

I am not trying to do the impossible. That is the mechanism that I currently
use so it is not impossible. I am merely sharing my technique with the rest
of the world in case anybody is interested. Obviously you are not. Big deal.

--
Tony Marston
http://www.tonymarston.net

[Jochen Daum]

Hi !

On Tue, 17 Feb 2004 22:30:26 -0000, John Dunlop
<jo*********@johndunlop.info> wrote:

Tony Marston wrote:
(...)
Also, will you provide an URL to a document which claims that
accessing a file from the history stack ever caused any client to
make an HTTP request? I tried searching, without success. I'm just
curious, because that would be a truly silly way to engineer a
history mechanism.

If you use IE and write down what you experience I beleive you would
have such a document.

HTH, Jochen
--
Jochen Daum - Cabletalk Group Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
http://sourceforge.net/projects/phpdbedittk/

[John Dunlop]

Tony Marston wrote:

The cache is where the complete contents of the page is stored so that the
next time the same page is requested it is retrieved from the cache instead
of downloaded from the server.
Possibly.
I did not supply complete details about the caching mechainsim as it is not
germaine to the issue under discussion.
Well, parts of it are, as RFC2616 explains.
The article is about using the browser's BACK button which is about moving
backwards through the browser's history.
Yes. Something you cannot and should not influence.
If you visit a page that exists in your browser's cache then your browser
will attempt to serve it from cache instead of re-issuing the request to the
server.

Possibly. That depends on how you access it, the state of the
entity, configuration of your browser and any intermittent cache
proxy servers.

--
Jock

[John Dunlop]

John Dunlop wrote:

Possibly. That depends on how you access it, the state of the
entity, configuration of your browser and any intermittent cache
proxy servers.

That should read "...any intervening cache proxy servers". Sorry.
Must remember to proof read articles *before* sending. :-)

--
Jock

[John Dunlop]

Jochen Daum wrote:

If you use IE and write down what you experience I beleive you would
have such a document.

The folks responsible for that silly "browser" have openly documented
their ignorance of the internet standards. I'm not going to try to
understand what goes on in that piece of software specifically.

--
Jock

[Jochen Daum]

Hi John!
On Wed, 18 Feb 2004 08:56:02 -0000, John Dunlop
<jo*********@johndunlop.info> wrote:

Jochen Daum wrote:

If you use IE and write down what you experience I beleive you would
have such a document.

The folks responsible for that silly "browser" have openly documented
their ignorance of the internet standards. I'm not going to try to
understand what goes on in that piece of software specifically.

The point I try to make: You don't get around it, so you can construct
solutions, that serve all browsers and IE as well. IMO you don't need
to give up standards to serve it.

BTW.: I don't like the methods of MS, but I was impressed by an
article in a german linux Computer magazine in 2001. They tested 7
linux browsers and IE. IE 5 (I believe) rendered the pages fastest of
the tested browsers - in a Virtual machine.

So, I especially like it when open source browsers seem to copy all
the stuff that runs well in IE, without loosing all the ideas of the
Linux world. My favourite: Konqueror (3 upwards)
HTH, Jochen

[Tony Marston]

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...

Tony Marston wrote:

The cache is where the complete contents of the page is stored so that the next time the same page is requested it is retrieved from the cache instead of downloaded from the server.

Possibly.

Not possibly, definitely.

I did not supply complete details about the caching mechainsim as it is not germaine to the issue under discussion.

Well, parts of it are, as RFC2616 explains.

My article contains all the relevant information which is pertinent to the
topic in hand. Any other information is irrelevant.

The article is about using the browser's BACK button which is about moving backwards through the browser's history.

Yes. Something you cannot and should not influence.

This is where I, and many others, have to disagree. The BACK button was
designed when the internet consisted of nothing more than static pages
without the ability to store any session data on the server. The ability to
produce dynamic pages and maintain server-side session data using languages
such as PHP has chamged all that. Where navigation between pages is now
controlled by links within the application the use of the browser's BACK
button can foul that up. As it is not possible to completely disable the
BACK button I have designed a mechanism which allows it to be used but
without any foul ups.

If you visit a page that exists in your browser's cache then your browser will attempt to serve it from cache instead of re-issuing the request to the server.

Possibly. That depends on how you access it, the state of the
entity, configuration of your browser and any intermittent cache
proxy servers.

--
Jock

I am not going to waste my time with explanations of irrelevant details. The
cache was designed to save the contents of visited pages in memory so that
when visited again they can be reloaded from memory instead of downloaded
from the server. It is either being used or it is not. It can either be
turned off by the user or turned off by the page author. The effect of proxy
servers with their own caching mechanism is irrelevant to this discussion.

--
Tony Marston
http://www.tonymarston.net

[Bruce Lewis]

"Tony Marston" <to**@NOSPAM.demon.co.uk> writes:

On some screens the number of hidden fields could be quite large, which
means that the document will take longer to download as well as retransmit.
Those of you who say that document size is not a problem are being totally
inconsiderate to those users who do not have a broadband connection.
If a user is on a 56k modem, at least 4 kilobytes of data is needed to
add a second to upload/download time. For the vast majority of pages,
the possible time saved is not worth the loss of the back button.

As for being considerate of users' time, think about the much larger
amount of lost time if you're interrupted, say, by a child crying, and
return to your computer to find that the server has forgotten what you
were doing. Hidden variables have no timeout.

Speaking of interruptions, suppose you're using a helpdesk application
and are writing up the details on one trouble ticket. A call comes in
about another ticket, so you open a new window and start working on that
ticket. With hidden fields, each window has its own state. With
session data per-window state is much harder to do.

Finally, I would point out that those of you who recommend disabling the
browser's cache are being totally inconsiderate to those who do not have
a low-latency broadband connection to every web server they're
interested in.
Some of this data may also have security implications, so it is not a good
idea to send it across the net within the body of the HTML document as it
can be seen by anyone, especially by someone with nefarious intent. It is
better to keep such data on the server.

If you aren't competent to securely handle the content of hidden
variables, then you can't securely handle the content of non-hidden
variables either. Just stay out of forms processing entirely.

Here's what should be stored in session state:
* user identity
* anything unvarying in this user session, e.g. time zone
* large and complex data structures unwieldy to put in hidden
fields

Everything else related to the user's state should go client-side.

[John Dunlop]

Tony Marston wrote:

"John Dunlop" <jo*********@johndunlop.info> wrote in message
news:MP************************@News.Individual.NE T...

Tony Marston wrote:

The article is about using the browser's BACK button which is about
moving backwards through the browser's history.

Yes. Something you cannot and should not influence.

This is where I, and many others, have to disagree.

Thank you for the explanation I snipped. I think I now understand
*why* you believe the back button interferes with your design. But
still, I think we'll have to agree to disagree on the "should" part
of the above point, if you don't mind.

FWIW, my thoughts are near parallel with Jakob Nielsen's:
http://www.useit.com/alertbox/980920.html

--
Jock

[Tony Marston]

"Bruce Lewis" <br*****@yahoo.com> wrote in message
news:nm*************@home-on-the-dome.mit.edu...

"Tony Marston" <to**@NOSPAM.demon.co.uk> writes:

On some screens the number of hidden fields could be quite large, which
means that the document will take longer to download as well as retransmit. Those of you who say that document size is not a problem are being totally inconsiderate to those users who do not have a broadband connection.
If a user is on a 56k modem, at least 4 kilobytes of data is needed to
add a second to upload/download time. For the vast majority of pages,
the possible time saved is not worth the loss of the back button.

I am not disabing the back button, just preventing it from interfering with
my application.
As for being considerate of users' time, think about the much larger
amount of lost time if you're interrupted, say, by a child crying, and
return to your computer to find that the server has forgotten what you
were doing. Hidden variables have no timeout.

Speaking of interruptions, suppose you're using a helpdesk application
and are writing up the details on one trouble ticket. A call comes in
about another ticket, so you open a new window and start working on that
ticket. With hidden fields, each window has its own state. With
session data per-window state is much harder to do.
But not impossible. My software detects multiple browser instances from the
same client and treates each one as a separate session.
Finally, I would point out that those of you who recommend disabling the
browser's cache are being totally inconsiderate to those who do not have
a low-latency broadband connection to every web server they're
interested in.

Some of this data may also have security implications, so it is not a good idea to send it across the net within the body of the HTML document as it can be seen by anyone, especially by someone with nefarious intent. It is better to keep such data on the server.

If you aren't competent to securely handle the content of hidden
variables, then you can't securely handle the content of non-hidden
variables either. Just stay out of forms processing entirely.

Here's what should be stored in session state:
* user identity
* anything unvarying in this user session, e.g. time zone
* large and complex data structures unwieldy to put in hidden
fields

Everything else related to the user's state should go client-side.

I disagree. Only send to the client those details that need to be sent to
the client. Everything else should be kept on the server. This both aids
security and keeps to a minimum the amount of data sent over the net.

--
Tony Marston
http://www.tonymarston.net

[Chung Leong]

This is off topic, but does anyone know whether Konqueror's render engine
supports (or will support) ECMAScript 4?

Uzytkownik "Jochen Daum" <[e-mail]> napisal w wiadomosci
news:83********************************@4ax.com...

Hi John!
On Wed, 18 Feb 2004 08:56:02 -0000, John Dunlop
<jo*********@johndunlop.info> wrote:

Jochen Daum wrote:

If you use IE and write down what you experience I beleive you would
have such a document.

The folks responsible for that silly "browser" have openly documented
their ignorance of the internet standards. I'm not going to try to
understand what goes on in that piece of software specifically.

The point I try to make: You don't get around it, so you can construct
solutions, that serve all browsers and IE as well. IMO you don't need
to give up standards to serve it.

BTW.: I don't like the methods of MS, but I was impressed by an
article in a german linux Computer magazine in 2001. They tested 7
linux browsers and IE. IE 5 (I believe) rendered the pages fastest of
the tested browsers - in a Virtual machine.

So, I especially like it when open source browsers seem to copy all
the stuff that runs well in IE, without loosing all the ideas of the
Linux world. My favourite: Konqueror (3 upwards)
HTH, Jochen

[David Mackenzie]

On Wed, 18 Feb 2004 22:34:15 +1300, Jochen Daum <[e-mail]> wrote:

Hi John!
On Wed, 18 Feb 2004 08:56:02 -0000, John Dunlop
<jo*********@johndunlop.info> wrote:

Jochen Daum wrote:

If you use IE and write down what you experience I beleive you would
have such a document.

The folks responsible for that silly "browser" have openly documented
their ignorance of the internet standards. I'm not going to try to
understand what goes on in that piece of software specifically.

The point I try to make: You don't get around it, so you can construct
solutions, that serve all browsers and IE as well. IMO you don't need
to give up standards to serve it.

BTW.: I don't like the methods of MS, but I was impressed by an
article in a german linux Computer magazine in 2001. They tested 7
linux browsers and IE. IE 5 (I believe) rendered the pages fastest of
the tested browsers - in a Virtual machine.

I think IE is reasonably fast at rendering. It's just a lack of tabbed
windows, mouse gestures, pop-up blocker and everything else make it
slower to browse in general.

When I go "back" in IE, it appears to re-render the page from its
cache whereas Opera appears to cache the rendered page bitmap. This
makes going back in Opera very fast (as it's not re-rendering the
page), although leads to the odd visual glitch.

Notably, if I view page A, click on a link to page B, then click
"back", the link to page B is not displayed in the visited colour
until I mouse over it or refresh the page.

--
David ( @priz.co.uk )

[Markus Ernst]

"Jason" <pm*******@4lpi.com> schrieb im Newsbeitrag
news:cf**************************@posting.google.c om...

"Tony Marston" <to**@NOSPAM.demon.co.uk> wrote in message news:<c0*******************@news.demon.co.uk>...

If the use of the browser's BACK button is interfering with the operation of your web application then take a look at this article entitle "Back Button Blues"

http://www.tonymarston.co.uk/php-mys...ttonblues.html

I totally understand not wanting to let users resubmit forms by using
the back button or hitting reload when something is going slowly.

I handle the reload issue by calling the next page with the
header("Location:...") function after the postdata are processed rather than
with an include(). So you have a page that can be reloaded without
interfering with anything.
The simplest way around it I've thought of is to put a counter in
$_SESSION. Every time any page loads, the counter is incremented.
The form page has a hidden field equal to $_SESSION['counter'] + 1.
When submitting, if the current $_SESSION['counter'] and
$_POST['counter'] don't match, nothing is done.

Not as cool as a program stack, granted. :)

Interesting idea, but it means compare eggs with eggs while the problem is
bread (as the problem does not consist in the number of times a script is
submitted, but rather in preventing duplication of data).

A more direct version of your solution could be to serialize the $_POST and
$_FILES['name'] arrays and store them in $_SESSION['lastpost'][$page_id] and
then just compare that to the serializations of the submitted data before
processing the data.

--
Markus

[Bruce Lewis]

"Tony Marston" <to**@NOSPAM.demon.co.uk> writes:

I am not disabing the back button, just preventing it from interfering with
my application. [...] My software detects multiple browser instances from the
same client and treates each one as a separate session.

This morning I found myself as a user in a situation very apropos to
this discussion. Would your scheme have handled it?

I'm a member of a Toastmasters club, where people practice speaking in
front of a group. Another member sent me email asking if she could
switch speaking slots with me; she had a conflict with the meeting she
was scheduled to speak at. This was fine with me.

I went to the page that lists meeting dates and clicked on the date when
I was supposed to speak. This brought up the "signup sheet". There's a
text input that had "Bruce Lewis (CTM3)", i.e. my name and the speech I
was doing. I realized the cut/paste I wanted to do to swap us would be
easier if I had the signup sheet for her meeting up at the same time.

To get both signup sheets up at the same time, I clicked the Back
button, right clicked the date she was scheduled for, and opened the
link in a new window. Then I went back to the first window and clicked
Forward. So signup sheets for two different dates were now open for one
user, me.

I did my cut/paste, clicked each "Sign Up" button, and everything
worked, thanks to the hidden variables on each signup sheet. Are you
saying your scheme would have treated each signup sheet as a separate
session, and thus worked? The sample code you provided on the
backbuttonblues page does not do this. The first "Sign Up" click would
have popped the signup sheet off the stack, so that the second would
have resulted in an error.

This is not a contrived example. It really did happen this morning.

[Tony Marston]

"Bruce Lewis" <br*****@yahoo.com> wrote in message
news:nm*************@biohazard-cafe.mit.edu...

"Tony Marston" <to**@NOSPAM.demon.co.uk> writes:

I am not disabing the back button, just preventing it from interfering with my application. [...]

My software detects multiple browser instances from the
same client and treates each one as a separate session.

[snip]
Are you
saying your scheme would have treated each signup sheet as a separate
session, and thus worked? The sample code you provided on the
backbuttonblues page does not do this.

The sample code I provided was for dealing with the back button only. The
code I have for maintaining a different session for each browser instance is
different (and as yet unpublished).

--
Tony Marston
http://www.tonymarston.net