My application disables caching on the browser via responses headers and then uses the Post-Redirect-Get pattern to enable the back button to "re-Get" the current page.
However on retesting this now with Firefox 12 and IE 8 I'm not seeing the results I was expecting (or that I had seen before with IE 6).
Upon selecting the back button I can see that the browser is attempting to perform the original request (the Post), not the redirected request (the Get). When I look at the requests on the network tab of Firebug I see the following:
Looks like the browser is treating the Post and Get as the same request and hence selecting the back button is re-submitting the Post:
I am using JSF, but I think this is a browser issue. Does anyone know why the browser is not performing a get of the redirected page?
It's working fine. The back button re-executes the request before "POST accountDetails.xhtml" which is not listed in your 1st screenshot, but is according the 2nd screenshot apparently (and logically) a "GET accountDetails.xhtml". You're apparently in the bean associated with that view or in some filter doing some checks and redirecting to "registrationWelcome.xhtml". The "POST accountDetails.xhtml" in the 1st screenshot is the current request which has been redirected to "reviewInfo.xhtml".
The back button does not re-execute the redirect. It's your own code which did it. The back button does also not re-execute the POST request, which is confirmed in the 2nd screenshot.
Related
I'm working on an asp.net web app. One of my web page received a posted value from a remote server:
HiddenField1.Value = Request.Form.Get("something")
And further on I'm using javascript to manipulate value from this HiddenField1.
The weird thing's that if I clicked on the "reload this page" icon on any browser:
reload page icon
page's reloaded and HiddenField's value's there
However if I moved mouse to the address area and clicked on the url,
address area examplethe url string's background turned blue and I hit Enter key,looked like the page's behavior's exactly the same: reloaded. However, the HiddenField's value's gone.
Any hint what's the difference between the two scenario?
This is not strictly related to ASP.Net: it is actually a common browser behavior and you would experience the same with a different server language (php, python or whatever).
In your second scenario, the browser will send a new (GET) request to the server, asking for the last loaded URL. It would be the same if you just type the address starting from a blank Address area.
In the first case instead, you are telling your browser "please, repeat the last request you made". Maybe it was a POST request sending data (form fields) to the server, and the server did answer to the previous request inserting the hidden field you are noticing.
To recap, the second scenario is "send a GET request for this address, ignore everything else". The first is "Repeat the last request you send. If it was a POST request with form data, send it again as the time before"
Very likely in your case, the server code inserts the hidden field just in case of a particular POST request (possibly according to posted data), and not for a GET request
If you don't know the difference between POST and GET for an HTTP request, this answer can be helpful
I am using the Post Get Redirect method to submit a form using asp.net webforms. It's a very simple setup:
Step 1) Post form on Page1.aspx
Step 2) Process form and redirect using Response.Redirect to Page2.aspx
Step 3) Page2.aspx redirects using Response.Redirect to Page3.aspx
If you are on Page3.aspx and hit the back button, I think it should take you back to Page2.aspx and redirect you right back to Page3.aspx. This would lessen the chance of you getting back to Page1.aspx and submitting the data again.
Instead, I am being taken straight back to Page1.aspx when I hit the back button. I have also tried using a 303 Redirect, but that did not work either.
What could be going on here?
The behavior you are seeing is the right thing to do.
Various browsers, to better support how some sites (like google) operate don't keep a page that redirects immediately in the back history.
Consider this:
You search google.com
You click on a link
This link actually takes you back to google.coms servers before immediately forwarding you to the actual page.
You decide that wasn't the right link and click the back button.
At this point, most browsers will take you back to the page identified on step 2. This is the normally desired and expected behavior of millions of netizens.
To go back to step 3 only to be forwarded on to step 4 would, well, piss some people off. As certain versions of IE recently did until the behavior was patched.
Point is, the behavior you are seeing is exactly how the rest of the web works. You should look into some other mechanism to change this, if you really really want to.
update
#NinjaBomb: Somehow I missed your follow up question, so the following is probably not much use.
The answer is that instead of doing the redirect in c# code you embed some javascript in Page2 that does the redirect when the page load is complete. The browser then "stores" the reference to page 2. When they click the back button from 3 it will go back to 2 then redirect on to 3.
Of course, the user could simply hit the back button twice...interrupting 2's redirect and letting them go to 1. The only other way I can think of is to have page 1, on load, test some session or cookie value to see if they've already been sent on. If so, then page 1 should do a redirect instead of showing itself.
Move backward through history skipping the same page with different query string
The above is similar to my question, but I'll be more specific as mine concerns POSTs:
Scenario:
User is on Product Listing page. (Shorts.aspx)
User picks a product and navigates to product detail page (Best-Cargo-Shorts.aspx)
User clicks add to cart which performs postback (POST) of form to same page. (Best-Cargo-Shorts.aspx) -- this now shows Details page again, but with an Added TO Cart message at the top.
Current Behavior:
After the Add TO Cart form post; when the user clicks the Back button they navigate back to the "pre-post" version of the same page.
Desire:
When a user clicks the BACK button, I'd like it to go to Shorts.aspx, NOT Best-Cargo-Shorts.aspx, effectively Skipping the "pre-POST" page, or more accurately NOT STORING the 2nd POSTed page (Best-Cargo-Shorts.aspx).
Furthermore, I always want to avoid that "Page Content Expired" message. I just never want the POSTed version of the page in history. In this way, the following could also be true.
Shorts.aspx > Best-Cargo-Shorts.aspx > Best-Cargo-Shorts.aspx [POST] > Cart.aspx
If on cart and BACK button is pressed, I want the browser to navigate to Best-Cargo-Shorts.aspx (without the POST).
Is this possible with C#? Furthermore, is there a non-javascript solution?
Thanks.
One common way of handling this is the Post-Redirect-Get pattern.
In essence, the target of a POST request always responds with a 303 See Other (if HTTP 1.1) or 302 Moved Temporarily (if HTTP 1.0) status code redirecting the request as a GET, and usually eliminating the expired POST page from history. Potential downsides include the form parameters possibly remaining attached to the GET as a query string, and I've no clue how well it would (or wouldn't) integrate with ASP.Net Forms, MVC, or other web frameworks.
Generally, you should be using the post-redirect-get pattern, i.e. after the user adds the item to the card using POST, redirect him to Best-Cargo-Shorts.aspx with 302.
Now to your question, I would use Ajax for the post. I cannot think of a cross-browser way to achieve the desired behaviour using only server side code.
My question is - what is the difference between page refresh (if I press f5) and postback (If I press a button)?
Can anyone please tell me?
Thanks in advance.
A refresh mean a complete reload of the page, without any form data. This is essentially an HTTP GET.
A post back is when the page is posted to itself (through the form action=""). This is essentially an HTTP POST.
Lets have the actual difference between refresh and explicitily submitting a page :
1) Refresh does not mean to post back the page with get method..(You can check it with response.write request.form("some input type")).
2)Difference lies with the data sent to the server :
in case of explicit submit form is submitted with latest value(i.e it recognize the changes in form elements)
But in case of refresh, form is submitted with default form value.(i.e if you change the value of form element it will not reflect at server.)
when page is refresh that means page is sending request to server without any data that means HTTP GET but in another case suppose a event is fired that causes postback after
page completely load on browser if we press f5 or do refresh then it will send privious data with request instance, that means again for that data server will perform operation...
have u seen somtimes while you are doing online sopping after selecting item and press accepet button uyou get total price ,now again if you refresh then for that selected item it will again go to server that means you are buying same things twice.....i think now you get everything what i want to say...
in when page is postback then code of that page again compile and also processing `request data`. this process will going on
Consider the scenario:
I visited a page of a website built using ASP.NET. The page is a simple aspx page containing ASP.NET server controls.
I clicked on a link which takes me to some other page on the same website.
I clicked the BACK button of the browser.
QUESTION: What happens in terms of page life cycle? Does all the events occur or the browser just displays the cached version of the page without making any requests?
I think the best answer is: It depends on the browser, especially after a post/postback.
Older browsers used to pop up a confirmation dialog to the effect of "the page contains POST data which will be resubmitted", and you could either proceed (resubmit) or cancel out. Since everything that happens in ASP.NET WebForms is part of the FORM element (ViewState, events, etc.), this would cause the entire lifecycle to be repeated.
Of course, this caused no end of trouble with duplicate submissions, so many sites had to come up with workarounds for the dupe problem, and today most browsers just fetch the page from cache instead.
...That is unless you override the cache-control headers and force the browser not to store the page in cache. Obviously, in that case, it can't be retrieved from cache, so it will usually end up being resubmitted. But, again, it depends on the browser - for example, some browsers won't allow the resubmission over SSL, so if that's the protocol in use then the user will just see a message saying that the page has expired / can't be shown.
Come to think of it, probably an even better answer is: As a site designer, you really can't depend on any specific behaviour from the user's browser when the Back button is clicked. If a duplicate submission could have negative side-effects (such as charging a credit card twice), then you need to take adequate measures to prevent that from happening. It's good practice anyway as it's entirely possible for a user to simply double-click the "submit" button by accident.
we have even tried
Response.ExpiresAbsolute = DateTime.Parse("1/1/1980");
Response.AddHeader("cache-control", "no-store, must-revalidate, private");
Response.AddHeader("Pragma", "no-cache");
to resolve this kind of problem
The page would be displayed from Cache.
usually all the events should occur, but if you have an uber browser than it could happen to display a cached page
you can just put a breakpoint in your Page Load and see if it's going to occur