Back button issue

[Shimon Sim]

Hi,
Every time I write ASP.NET application I have the same problem - Back button
on the browser is my enemy. I have to tell client avoid using "Back" button
and if you use it make sure to refresh the page to latest information.

I decided to pay information to application on the web and I see that some
sites don't have those issues. Like I used some forum site that uses PERL
(files with ext. pl) and Back button from browser gets new updated page
everytime.
Can I do anything about this in ASP.NET?
Thanks,
Shimon.

 

[Flip]

I'm not sure how those other sites do it, but in .net you can use the
IsPostBack property to make your life a lot easier. In my current project
with JSP, we had to create an entire transaction framework to protect
us/data from the Back button too. After four months or so, I figured there
HAD to be a better way. There was, it's called .net! :> haha

Maybe the IsPostBack isn't going to solve your problem 100%, but I hope it's
a good start.

 

[Mark Sandfox]

Your page_load is rewriting the page each time you enter because you do not
have your code trap within the following:

If NOT IsPostBack then

End If

 

[Shimon Sim]

Sorry.
But you totally misunderstood the problem. I always check IsPostBack. It is
not the point.
The problem is what happens when user clicks on the "Back" button on the
browser. What I usually get is the old cashed on the client page that needs
to be refreshed to get updated information. That is not what user expects -
they want to use "Back" button on the browser and still get page with
updated results. Till now I thought that it is impossible unless user plays
around with browser history setting.
But now I see sites that do update the content of the page even if I click
"Back" button.

My question if it possible in ASP.NET and how?
Thanks,
Shimon

 

[Flip]

But you totally misunderstood the problem. I always check IsPostBack. It

is

Yup, I misunderstood as well, sorry 'bout that.

browser. What I usually get is the old cashed on the client page that
needs

Can you play with the expiry date for the page? Someone else with more html
and aspx knowledge should be able to chime in here so I can learn about this
too. But it sounds like you don't necessarily want to chop their fingers
off for using the Back button, just protect yourself from displaying
cached/old data? Setting the page expiry to something like zero should
force IE to refresh the page when the user hits the back button. Or maybe
I'm totally wrong? Sorry if I am.

 

[Shimon Sim]

I got second answer with IsPostBack... I know about it. It just solves the
issue that if you press a button on the form you don't want to do the same
actions that you do initial "arrival" to the page. It allows you to save
some calls to database and improve performance. In some cases you must use
it if you want to get new information from user.

Now ...
The problem is that if user clicks on the "Back" <-- button on the browser
then usually you get cash of the page that was saved by browser. (Am I wrong
about it? At least this is what I and my clients see). Really what I want to
get is updated version of the page.
Let say you have Product Information page that shows you basic information
about product. You have update functionality on a different page "Update
product information". Let say for sake of discussion after you update
product information you stay on the same page and don't redirect to Product
Information page. Now user wants to see product information page he /she
clicks on the "Back button on the browser (may be two times in my scenario)
and sees the page with old information (then client calls me and tells me
about a bug and I have to tell him/her to refresh the page. After few calls
the get the idea and I am off the hook.)

Can I do anything so the page will update after a user clicks on "Back"
button?
Again Thank you.
Shimon.

 

[Guest]

Maybe you want to look at the response object and tell it not to cache the
page. Or, I think the Cach API also has a method that you can sent along with
the response object to not to cache the page. Also, if you want your page to
load new data each time the page is loaded, then you should not enclose your
code in the If Not IsPostBack.

 

[bruce barker]

you can code the same in asp.net.

1) set the page to expire, so when back button is hit, it refreshed rather
than pulled from cache
2) break yourself from the asp.net postback model. once you do above, your
users will see the browser alert that data needs to be resent on a back to a
postback page. instead use real anchors (not link buttons) for navigation.
3) on pages that post, design so they can repost. for example with a cart,
ask for new the quanity instead of click to add one.

a little design work and the back button is your friend. its such a popular
feature, that windows apps are adding back button support.

-- bruce (sqlwork.com)

| Hi,
| Every time I write ASP.NET application I have the same problem - Back
button
| on the browser is my enemy. I have to tell client avoid using "Back"
button
| and if you use it make sure to refresh the page to latest information.
|
| I decided to pay information to application on the web and I see that some
| sites don't have those issues. Like I used some forum site that uses PERL
| (files with ext. pl) and Back button from browser gets new updated page
| everytime.
| Can I do anything about this in ASP.NET?
| Thanks,
| Shimon.
|
|

 

[Joerg Jooss]

you can code the same in asp.net.

1) set the page to expire, so when back button is hit, it refreshed
rather than pulled from cache

That's a dangerous fallacy. The HTTP 1.1 spec specifies that history
mechanisms are not caches and thus don't need to honor Cache-Control or
Expires headers. Not even Cache-Control: no-store.

Atually, many browsers *don't* work like that, provided the protocol is
HTTP 1.1. Thus, the "avoid caching" trick works more often than not,
Opera being one noticeable exception (maybe it's just that I've never
found the magic combination of Cache-Control/Expires headers that makes
it do that).

But once you're down to HTTP 1.0 it gets really nasty...

Cheers,