Re: Raise your hand if you have ever wanted to disable the browser's BACK button
From: Tony Marston (tony_at_NOSPAM.demon.co.uk)
Date: 02/18/04
- Next message: Kieran Benton: "Re: PHP with MS SQL on Windows Box"
- Previous message: Jon Beckett: "First pre-alpha of content management script available..."
- In reply to: John Dunlop: "Re: Raise your hand if you have ever wanted to disable the browser's BACK button"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 18 Feb 2004 00:59:15 -0000
"John Dunlop" <john+usenet@johndunlop.info> wrote in message
news:MPG.1a9ca65ee3371839989698@News.Individual.NET...
> Tony Marston wrote:
>
> [About the explanation of history mechanisms and browser caches in
> http://www.tonymarston.co.uk/php-mysql/backbuttonblues.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
- Next message: Kieran Benton: "Re: PHP with MS SQL on Windows Box"
- Previous message: Jon Beckett: "First pre-alpha of content management script available..."
- In reply to: John Dunlop: "Re: Raise your hand if you have ever wanted to disable the browser's BACK button"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
