Q: Back Button Clicked and Error Messages on Previous Page Still Display I have a very simple 1 page form using ASP.NET MVC 3.
It has 3 inputs. If the user enters the correct inputs and the database retrieves a pdf, that pdf is displayed in the next page. I have used the PRG pattern, in so far as it is possible in this scenario:
public ActionResult Index()
{
  SomeModel model = new SomeModel
  {
    ... properties
  };

  return View(model);
}

[HttpPost]
public ActionResult Index(SomeModel model)
{
  byte[] blob = someService.GoGetDetails(model);
  TempData.Add("blobkey", blob);

  return RedirectToAction("DisplayPdf");
}

public ActionResult DisplayPdf()
{
    return File(TempData["blobkey"] as byte[], "application/pdf");
}

The problem use case is as follows. 
User enters incorrect details and clicks Submit button. Red error text displays. 
User then enters correct details and clicks Submit button. Pdf displays.
User THEN hits back button. Form displays with previous red error text visible.
A tester has made up a requirement that the red text should not be there when the back button is clicked.
Seems easy. Until you try. Does anyone have the magic bullet for this.
One thing I tried as a compromise did not work. That is, I tried to kill caching on the browser with this code inside the DisplayPdf acttion method:
        this.ControllerContext.HttpContext.Response.Expires = 60;
        this.ControllerContext.HttpContext.Response.ExpiresAbsolute = DateTime.Now.AddSeconds(-1);
        this.ControllerContext.HttpContext.Response.AddHeader("pragma", "no-cache");
        this.ControllerContext.HttpContext.Response.CacheControl = "no-cache";

It has no effect. Perhaps that works in the webforms world. Not here with the FileResult.
When back button is hit, there is no request to the server. It is all client-side. So, I do have access to javascript. But javascript has no access to the http headers, so there's no way of differentiating from where the page was loaded.
I'm keen to see if this has been solved before. My Googling came up empty. 
Thanks

A: OK. I'm now satisfied. If :


*

*Amazon.com

*JsFiddle.net 

*Outlook.com 

*Dropbox.com


all exhibit the same behavour, then my work is not falling short of best practice. 
Intercepting the navigation buttons of browsers seems very hacky to me. This is one use case where we have to make sure our code does no damage when users do dumb stuff. But resolve elegantly? Probably not a big driver when control is taken out of your hands by the browser.
