Validation handling for Post-Redirect-Get

There are plenty of descriptions of the Post-Redirect-Get pattern online, but I am bit surprised and disappointed to see that most descriptions do not bother to cover a validation path.

With the obvious exception of search forms, most of the forms that I encounter online or develop in my day job will involve some input validation so I am taking it as not being a moot point.

As a toy application we can think of a web application which prompts the user to enter their date of birth and then displays back some information about that date - it could be the person's current age or a mash up of other people born on the same day and important events for that date, use your imagination.

Let's consider the application as consisting of two views:

• input form to accept the day, month and year
• display interesting information about the date specified through the form

In this setup the Post-Redirect-Get pattern would work as follows:

• Web browser HTTP GET request results in display of html page with the input form view.  The input form specifies method as POST and action as the appropriate form processing action on the server.
• A form submission results in an HTTP POST request being sent to the server including any form values that have been populated.
• In the Happy Days scenario a valid date has been specified, the server side action performs any necessary calculation or lookup and redirects the browser to a GET resource which will duly present the second view.  To avoid having to consider passing any state with the redirect this example application might embed the date into the resource URL - /doDateStuff/{yyyy}/{mm}/{dd} might work as a suitable resource URL pattern.

Now, what about the situation where an invalid date has been entered?  For example, 29 February 2015 is an invalid date because 2015 is not a leap year.

My preferred approach to this is to allow the POST request to provide a response with the input form view along with the validation error message(s).  In this path there is no redirect to a GET resource.  If the browser refreshes then the form submission will be repeated and the validation will fail again and the input form will show the error(s) afresh.

An alternative approach that I have never used in my 14 or so years of professional web development treats the Post-Redirect-Get approach as applying to validation.  In my opinion this approach involves additional complexity for carrying the validation state across to the request that the browser will send when it receives the redirect response.  The use of a short-lived cookie seems to be the hack for this.

Taking the non Happy Days scenario further, what happens if the user refreshes the invalid form?

• In my preferred approach the browser will probably detect that a POST request is going to be repeated and present a dialogue asking if the user really wants to do that.  If the user accepts the warning and continues with the repeat submission then the form post is repeated, the validation is applied by the server and the same input form view response with the same validation error messages will show.
• With the short-lived cookie approach the GET request will go to the server and the input form view will be rendered without the old error messages and without the values showing in the form  - because the short-lived cookie has been disposed of.