Back button after doing posts on the same page

Question

I have 3 pages to my site. The 1st page allows you to select a bunch of options. Those options get sent to the 2nd page to be displayed with some data about those options. From here I can click on a link to get to page 3 on 1 of the options. On page 3 I can create a new/edit/delete all on the same page where reloads come back to page 3.

I want a "back" button on page 3 to go back to page 2, but retain the options it had from the original page 1 request. Page 1 has a bunch of check boxes which are passed to page 2 as arrays to the controller. My thought is that I have to pass these arrays (I converted them to lists) to page 3 (even thought page 3 directly doesn't need them) so that page 3 can use them in the back link to it can recreate the values page 1 sent to page 2 originally.

I'm using asp.net MVC and when I pass the converted array it seems to convert it to the type instead of actually showing the values: "types=System.Collections.Generic.List" (where types is a List.

Is this what is needed or are there other options to getting a "back" button in this case to go back to page 2. It's sort of a pain to pass information to page 3 that isn't really relevant to page 3 except the back button.

• user22815: Sounds like the type of data that belongs in a session.
• GrandmasterB: Whats the problem with the browser's regular back button? Is it that there's posted data and you cant go back without refreshing the page?
• user441521: @GrandmasterB Correct, there is posted data and using the browsers back will cause a repost and not get to page 2 after you have added/removed records from page 3.
• user40980: Have you considered the post redirect get pattern?

Answer 1

If the POST is changing state on the server, then respond to the POST with a 303 so that the browser can GET a page describing that new state (that is, from page 1 you are directed to page 2 and the information page 2 contains was affected by the POST). History will now work correctly.

If the state of page 2 is a reflection solely of the choices made on page 1, then it shouldn't be a POST in the first place, it should be a GET where the URI (perhaps including query string options) reflects the choices made. (E.g. most search engines work this way because e.g. going to https://www.google.com/search?q=some+search+criteria doesn't change anything on google, but it does affect what is returned. History will now work correctly.

If the state hasn't changed, but could have, or you are otherwise dealing with a very temporary situation, then respond directly to the POST (e.g. if doing the first approach here but reporting a validation error to the user instead of doing what they wanted). (History won't work without reposting, but then it shouldn't).

Answer 2

There's a couple ways of handling this.

On Page 1, you can post the form to itself (Page 1), and then if everything gets saved correctly, store the posted data in the session and then redirect the page to Page 2. Page 2 gets generated from the session information, not the data posted to it.

Another way would be to post the form via AJAX, store the posted info in the session on the server, and then redirect to Page 2 after the AJAX call completes.

Either way, when on Page 3, you should then be able to 'page back' to Page 2 without having to refresh the page because Page 2 was not the result of a POST.