Reputation: 21
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.
Upvotes: 2
Views: 2247
Reputation: 3241
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.
Upvotes: 0
Reputation: 36534
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.
Upvotes: 0