Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Expiring a Page 2
- Thread starter jfrost10
- Start date
-
2
- #2
<%
Response.Expires = 15
Response.ExpiresAbsolute = Now() - 2
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "private"
%>
was the old way w/ASP. I would assume it would still work w/ asp.net
paul
Response.Expires = 15
Response.ExpiresAbsolute = Now() - 2
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "private"
%>
was the old way w/ASP. I would assume it would still work w/ asp.net
paul
- Thread starter
- #3
- Thread starter
- #5
Affect postbacks in what way? I don't think so, since a postback is technically "Forward".
All it does is make it so that a page cannot be re-visited via the back button... ergo, the page expired message.
Since when you press "Back", the page is loaded from browser cache, the above disables that, and you get the message.
While we're on this subject, though, we had to completely disable the back button on a recent project (which is the reason why I **think** you may be asking this), and I think a more elegant way to do this is to put:
<script language=javascript>
history.go(1);
</script>
on any page you don't want a user to go "Back" to. Pretty easy to see what it does, and it works quite well. Only problem is that it will tend to confuse the less savvy user, so custom navigation buttons are usually in order if you use this method.
paul
All it does is make it so that a page cannot be re-visited via the back button... ergo, the page expired message.
Since when you press "Back", the page is loaded from browser cache, the above disables that, and you get the message.
While we're on this subject, though, we had to completely disable the back button on a recent project (which is the reason why I **think** you may be asking this), and I think a more elegant way to do this is to put:
<script language=javascript>
history.go(1);
</script>
on any page you don't want a user to go "Back" to. Pretty easy to see what it does, and it works quite well. Only problem is that it will tend to confuse the less savvy user, so custom navigation buttons are usually in order if you use this method.
paul
- Thread starter
- #8
- Thread starter
- #9
Hey guys,
k, the code is acting really wanky for some reason.
I put Craig's code into my page_load, but it doesn't always redirect to a warning:expired page for every back button pressed.
i.e. I have a page with a few panels and some buttons that show/hide the panels. I can click between those buttons, and the back button, and never see the message. Yet, other times I do. Is there something I'm missing with this?
Thanks,
Jack
k, the code is acting really wanky for some reason.
I put Craig's code into my page_load, but it doesn't always redirect to a warning:expired page for every back button pressed.
i.e. I have a page with a few panels and some buttons that show/hide the panels. I can click between those buttons, and the back button, and never see the message. Yet, other times I do. Is there something I'm missing with this?
Thanks,
Jack
Paul: You noted the purpose of this message was to disable browser caching...what do you mean exactly by that?
Generally, I have kept the use of Session State to a minimum, taking advantage of it at certain areas of the web site, and then clearing SS after the user is finished; however, during this time the user ventures off to other pages, reviews graphs, etc... and then returns to the orginal page - where all the textboxes are reloaded with their values from Session State. Obviously, having the disable browser caching on would shut down this process.
Q: When is this routine important? Can somebody cite one or two examples where you'd want this to happen? Another point, at several places in my site, the user links via VB generated URLs to specified sites on other web sites -- and they may stay there 10 minutes or so, and when they return the original page is regenerated with Session State variables; again, another situation where you wouldn't want this to occur.
Generally, I have kept the use of Session State to a minimum, taking advantage of it at certain areas of the web site, and then clearing SS after the user is finished; however, during this time the user ventures off to other pages, reviews graphs, etc... and then returns to the orginal page - where all the textboxes are reloaded with their values from Session State. Obviously, having the disable browser caching on would shut down this process.
Q: When is this routine important? Can somebody cite one or two examples where you'd want this to happen? Another point, at several places in my site, the user links via VB generated URLs to specified sites on other web sites -- and they may stay there 10 minutes or so, and when they return the original page is regenerated with Session State variables; again, another situation where you wouldn't want this to occur.
- Thread starter
- #11
If you don't want your users to navigate backwards, then you'd need to disable cache.
i.e. a user enters a record, then deletes it. You wouldn't want that user clicking 'back', making changes, then trying to update a record that doesn't exist. Also, if its a shared pc, you don't want a user that has lower priveleges navigating back to pages viewed by a preivous user that has higher priveleges.
Those are some of the reasons why I need to implement it.
D
i.e. a user enters a record, then deletes it. You wouldn't want that user clicking 'back', making changes, then trying to update a record that doesn't exist. Also, if its a shared pc, you don't want a user that has lower priveleges navigating back to pages viewed by a preivous user that has higher priveleges.
Those are some of the reasons why I need to implement it.
D
I'll give you an example of where I used it last.
I have an online ordering system for surveys. So on the page, they give me information about various things, and I determine how many surveys they need. Then, they submit their order.
On this same page, I show them how many surveys they have already ordered, if any, and give them the chance if they have already ordered, to re-order more.
So, if they click submit, and order their surveys, and then they press "Back", then the order page would be loaded from their browser cache, and it would show that they have ordered no surveys, since my server routines would not run. This might confuse them, and they might order more and more surveys, all the time thinking the site isn't working.
So, I put this script on the page, and if they press back, they get the "page expired" message, and are encouraged to press "Refresh". When they do so, the server routines are run, and it will show that they have an order.
So it just cuts down on the ever-present "unexpected results" that we, as developers, have a hard time working with/through.
Like I said, though. I think that the history.go(1) option is a more elegant solution to disabling the back button for these types of situations where you don't want a user pressing that button.
hope that clears it up a bit.
paul
I have an online ordering system for surveys. So on the page, they give me information about various things, and I determine how many surveys they need. Then, they submit their order.
On this same page, I show them how many surveys they have already ordered, if any, and give them the chance if they have already ordered, to re-order more.
So, if they click submit, and order their surveys, and then they press "Back", then the order page would be loaded from their browser cache, and it would show that they have ordered no surveys, since my server routines would not run. This might confuse them, and they might order more and more surveys, all the time thinking the site isn't working.
So, I put this script on the page, and if they press back, they get the "page expired" message, and are encouraged to press "Refresh". When they do so, the server routines are run, and it will show that they have an order.
So it just cuts down on the ever-present "unexpected results" that we, as developers, have a hard time working with/through.
Like I said, though. I think that the history.go(1) option is a more elegant solution to disabling the back button for these types of situations where you don't want a user pressing that button.
hope that clears it up a bit.
paul
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question