One of my 2 readers, Steve Morse, asked a question about my post about the back button.

"A common pattern is "post backs" to the same page as a user interacts with the page. For example, the page displays a list with details of a selected item below. When a user clicks a list item it posts back, and the page now displays the details below. This is standard .ASPX with "view state". Are you saying there is something wrong with this technique?"

My other reader, Dave Sweeny, asked me to explain a bit more.

Being happy I have readers, I’ll try to take it down a level.

Steve, I think your scenario is this

1. Page displays a list, with the content area of the page empty
2. User clicks item in the list
3. Browser posts back
4. Server uses some form field to determine what to display, fills in the content with that item, and returns the page

I created a simple asp.net web project to show highlight what I think the problem is.

Our Form

The class behind our form
protected void Page_Load(object sender, EventArgs e)
{

    // These lines force pages to not cache.  Server is requested

    // for every display.  This is generally considered to

    // be normal PRG practice due to the nature of these apps.

    // It also helps to highlight the issue.  It is not

    // required by PRG

    Response.Cache.SetExpires(DateTime.Now);

    Response.Cache.SetCacheability(HttpCacheability.NoCache);

    // If this was a GET, determine the correct item

    // to display.  If it was a post, the item is displayed

    // another way.

    if ((this.IsPostBack == false)

        && (Request.QueryString["index"] != null))

    {

        int i = int.Parse(Request.QueryString["index"]);

        TextBox1.Text = "PRG-" + ListBox1.Items[i];

        ListBox1.SelectedIndex = i;

    }

}

protected void btnPRG_Click(object sender, EventArgs e)

{

    // The PRG approach sends a redirect request as a

    // result of the PRG Button POST

    Response.Redirect("default.aspx?index="

        + ListBox1.SelectedIndex);

}

protected void btnPF_Click(object sender, EventArgs e)

{

    // The PF approach (which is clouded by ASP.NET)

    // forwards to the same page.

    if (ListBox1.SelectedItem != null)

        TextBox1.Text = "PF-" + ListBox1.SelectedItem.Text;

    else

        TextBox1.Text = "PF-Nothing Selected";

}

Explained
Select any 3 items from the list, and hit either Post/Forward or Post/Redirect/Get.  Both accomplish the same thing with the different strategies: the text box is filled in with the value of the selected item on the server and an updated page is returned to the browser.

Since caching is turned off, when you use the browser controls to navigate around, the server is asked for a fresh version of the page every time the page is selected thru a back or forward button.  Note, you get the same symptoms with cache enabled if you back button then refresh.

Now play with it
First start with the PF button.  Select an item, hit PF, repeat.  Now start playing with the back button.  You get the trusty “Page Is Expired” error advising you to hit the refresh button. 

When you do, you get a message box you get another cryptic message warning you about a resubmit and to be careful if you were trying to buy something.

I agree.  If you were trying to buy something from this site, you should be very, very careful.

Next try playing with the PRG button.  Again, select an item, hit PRG, repeat enough times to clear your way past the nasty PF junk.  You should notice that the URL now indicates what you are looking at (it didn’t with PF).  Back button, Forward button, Refresh…   NO PROBLEMS!  You can even bookmark the URL and come back!

Google works this way too.  When you search Google, they redirect the URL back to you.  I would not be able to post this link if they used PF.

http://www.google.com/search?hl=en&q=www.strong-point.com

Conclusion
The problem I have with Steve’s scenario is not that it does not work.  It does work.  The problem I have with it is that it causes unexpected things to happen when the browser navigation controls are used.  It is heavily dependent on the sequence of actions performed by the user.

With PRG, browser navigation happens more easily.  As you can see, it is just as easy to code with PRG as it is with PF.  When you factor in all of the things you must do to prevent potential problems caused by PF…   there is no contest, PRG is easier.

The warning messages received during the PF scenarios are just the tip of the iceberg.  Much more serious problems can arise than just these messages.

References
In creating this response, I used this very good explanation of web caching.
http://www.mnot.net/cache_docs/#CONTROL