Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1
Related
So I am concerned with
webdriver.navigate().back();
in particular. AFter reading How does the Back button in a web browser work?
it made me think of how can I make sure back button behaves as expected?
Here's different ways of having "back" navigation. How would you go about detecting which approach to use? Listen to whether POST or GET is being made? Listen for AJAX requests and plan the appropriate plan?
a) navigate back() (essentially hitting back button in firefox)
b) make GET request to the previous page url
c) click on "return to results" on current page
with a) back() sometimes do not work correctly for AJAX sites with no breadcrumbs. or for POST search results for example where pressing back will prompt alert message.
with b) my concern is that the url may not match up,
ex) dynamic urls with unique hash sessionid parameters
http://www.aa.com/results.php?sessionid=29756293changeseverytime
So how do I create a contingency to make sure the back navigation works correctly as expected for a variety of web apps and sites (there are lot of variability in terms of how the back button will behave).
Why don't you store the location of the page that you want to verify, hit a link, use the goBack and then verify location of check the variables (the one you stored and the location of the verify page)?
By the way, if your site uses AJAX I suggest you use the pause function that waits for the AJAX lib. To fully load, or set the speed of your site (maybe combine them together in rare cases).
1) I saw an interview question on this, and I'm assuming it's something to do with form submission and avoiding double submissions. Can someone confirm this?
2) Assuming this assumption is correct, can this be done with Ajax? If so is there a link someone can point me to?
(I'm assuming you'd generate some sort of random number and include it in the form as a hidden field, then ensure that number hadn't been submitted before for the session).
Redirect-after-post is a technique to avoid problems with the user refreshing or using the back button to get back to a posted form. In short, instead of providing a response page to an HTTP post, which will trigger another post if its reloaded, you issue a 303 redirect (or a 302, to support ancient browsers by taking advantage of a bug that is as old as the web). This causes the browser to issue a second HTTP request - a get this time - and if the response page to that is reloaded there shouldn't be any problems. Just make sure that all the changes are made by the post handler and the page you redirect to has no side effects.
If you post using XMLHttpRequest then the redirect will be followed; unless you specifically support it using the hash part of the location or the new HTML5 history methods then the back button and reload aren't going to trigger an AJAX post again.
I'm working on a web application developed classic asp. It has logout button on the top menu which basically does the following actions
Session.Abandon()
Redirect to Index.asp, where users can login again.
After logging off users return to index.asp. But if users click back button the browser, they go to previous page. I don't want this to happen. I want a message saying that they are already logged off.I have implemented following steps
1.Add Response.Expires=-1 and Response.CacheControl="no-cache" at the top of each page.
2.On each page i'm checking session object to see it is not empty. If empty i'm creating a message saying that they are already logged off and need to log in again.
Now when users click back button after logging off, instead off showing logged out message, i get "Web page expired" message on IE8. I see the same behavior when users click back button on some page while logged in.
Any ideas how i can implement this better.
Thanks.
You can't stop users pressing back. A common scenario to work around this is that POSTs target a server page that displays no output but redirects to a new location instead (where the results can be seen).
There are additional non caching declarations that sometimes help:
Response.Expires = 0
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "no-cache"
I did read some time ago (hence inability to find link) that setting an expires to -1 can cause some browser to ignore it rather than have it expire immediately.
Even adding these extra cache controls won't stop some browsers from caching some things some of the time. FF quite often ignores a forced cache reload by the user, so you are in the browser makes hands to a certain extent.
Regarding your "Web page expired" message, this is (as mentioned) the result of the browser trying to stop you from resubmitting POST data (and potentially duplicating what you last did). The best way to get around this, and solve a number of other common UI issues on forms is to POST back to the same page, then if/when the action is completed, using a response.redirect to the same page, maybe with a URL encoded message to say "all done successfully". This allows your users to refresh and helps with the back button issue as most browsers now don't store properly redirected pages in their history.
I have a very strict requirement to use POST to pass in request parameters to my application upon entry. Once entering the application (page1), entering form information and continuing to the next page (page2) via a commandButton, the expectation is that the data will be posted and later read from a session scoped manage bean. All works well except when using browser back on page2 to navigate back to page1.
I have tried adding a redirect tag on the navigation rule that navigates from page1 to page2 to no avail. I have also tried this implementation of the Post-Get-Redirect pattern (http://balusc.blogspot.com/2007/03/post-redirect-get-pattern.html). Am I missing something obvious here?
Abel, the scope of page1 is request.
The solution we came up with which is no means ideal is to disable browser caching on the previous page. What this means is that whenever you refresh the page using the browser refresh button or click the browser back button, the browser will indicate that the page is expired and prompt a warning asking whether you want to re-submit the request.
We do have a work around which is to provide navigation buttons within the webpage but the idea was to support browser back. This would be easy using GET parameters, but POST provides additional complexity which we have decided to mitigate by by providing our in-house navigation buttons.
I am implementing a web application using ASP .Net and C#. One of the pages has a requirement that it always needs to be fetched from the server, rather than from the local browser cache. I have been able to achieve this.
We have a back button in the application, which simply invokes javascript:history.back() method. The problem is that when the back button is clicked to navigate to the page which is always to be reloaded from the server, the browser displays a "Web page expired message".
The intent here is to force the browser to reload the page rather than display the web page expired message.
Any help would be highly appreciated. Thanks a ton in advance.
You will probably need to change the implementation to make the browser load the URL explicitly:
window.location.href = 'http://....';
instead of invoking the back button, since the intention of the back button is to get the last page from the cache.
(If browsers would not act that way, they would re-send your form data multiple times when using the back button during a registration process or similar.)
You mean you want to control browser behaviour, which is not possible. I doubt you can solve it that way. You could set the expiration time to a small value (1 minute perhaps?) so that the page is still valid if one navigates back quickly.