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
- Page displays a list, with the content area of the page empty
- User clicks item in the list
- Browser posts back
- 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";
}
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.
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.
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.