Improve Redirect after POST (with validation errors) [SPR-13768]

[spring-projects-issues]

smallufo opened SPR-13768 and commented

I think Redirect after POST (with validation errors) is a very common scenario in every web framework. But I find SpringMVC solves it in an especially cumbersome way.

Take the example in this link : http://stackoverflow.com/a/23749112/298430

Look how many "register" repeats in the code ( I count 5 ) , and it is String , not type safety.
It is against the DRY pattern.

Is it possible to eliminate such cumbersome ?

---

Affects: 4.2.3

Reference URL: http://stackoverflow.com/a/23749112/298430

[spring-projects-issues]

Rossen Stoyanchev commented

Spring MVC supports the POST-redirect-GET pattern which means redirect after a successful POST in order to avoid a duplicate (successful) submission. In case of validation errors however you remain on the same page. This is how it's expected to be:

@RequestMapping(path="/accounts", method=POST)
public String addAccount(Account account, BindingResult bindingResult) {
    if (bindingResult.hasErrors()) {
        return "editAccount";
    }
    // save the account ...
    return "redirect:/accounts/" + account.getId();
}

Note that when you remain on the same page both the Acocunt and the BindingResult are already in the model and don't need to be added explicitly. In other words when you follow this pattern it should be easy and there is no need carry the BindingResult across a redirect.

The question is why do you want to redirect after validation/binding errors?

[spring-projects-issues]

smallufo commented

In your example . when error occurs , the page shown in the browser is "accounts" , not "editAccount" .

When user inputs data , he is in the "editAccount" page . When error occurs , I hope user redirected back to "editAccount" , not the "/accounts" page (which only accepts POST , when he reload , it will throw GET not supported exception )

The question is why do you want to redirect after validation/binding errors?

I hope the user redirected to the original page , and in the page , there'll be hints about which field goes wrong.

The link in SO perfectly solve my problem , but it's too non-typesafety and cumbersome.

[spring-projects-issues]

Rossen Stoyanchev commented

It's confusing to focus on page names and exact work flow since that may vary by application. The bottom line is: (1) no redirect after validation errors but rather remain on the same page that submitted the form POST and (2) redirect after successful POST submission in order to avoid a duplicate submission.

The question again is why do you want to redirect after validation errors?

[spring-projects-issues]

smallufo commented

The question again is why do you want to redirect after validation errors?

I just feel it is normal , and I see many websites following such pattern (redirect to original page after validation error).
Is there anything wrong with this ?

I think it is a common pattern , and there should be a easy way to achieve this.

[spring-projects-issues]

Rossen Stoyanchev commented

The main motivation to redirect after a POST is to avoid re-submitting (e.g. hitting Refresh or going back in history) and causing unintended side effects such as a duplicate web purchase. What I normally see is a confirmation/success page displayed after a redirect and you can safely refresh or bookmark it and you it's safe when using the browser back button.

I don't see the motivation to redirect after validation errors. It seems perfectly reasonable and simple to remain on the same page. There are no side effects if the user hits Refresh or re-submits, even the browser prompt is appropriate at that point. By contrast, redirecting leads to more complexity and questions for no apparent benefit. Even if you make validation errors available after a redirect, what do you do with if the user hits Refresh after the redirect? It would render a blank form without the validation errors which is odd from a user experience. You could store the validation errors on the server side (in the session) but why go through all that for no apparent reason.

[spring-projects-issues]

smallufo commented

Wait , in the SO example , when error occurs , there will be redirected back to the original page , with error hints (achieved by flash scope parameters) , there will be no re-submitting problem. Even user reload , it just reload the original page , will not re-submit.

It seems perfectly reasonable and simple to remain on the same page.

To make thinks clear. Take your code for example.
User inputs data in "editAccount" page , and form submit(POST) to "/accounts" .
And when error occurs , browser's URL stays in "accounts" (but content is editAccount). right ?

But the problem is , when user browser reload , it will throw "GET not supported" exception. I don't think it is a good idea.

Moreover , if the user is from "editAccount?id=1" page , and when error occurs , returning "editAccount?id=1" will cause "template not found" exception.

[spring-projects-issues]

Rossen Stoyanchev commented

In the SO example, it's very clear this is being done out of necessity as a workaround for another problem, not because it is the preferred way.

User inputs data in "editAccount" page , and form submit(POST) to "/accounts" . And when error occurs , browser's URL stays in "accounts" (but content is editAccount). right ? But the problem is , when user browser reload , it will throw "GET not supported" exception.

Nope it won't do that. You're confusing URLs with HTML template file names. A Refresh will cause the POST /accounts to be re-submitted, which will once again result in a validation error. The browser will warn that you're re-submitting a POST with potential side effects. Most people won't refresh after validation errors. Even if they do the browser prompt is perfectly reasonable and there will be no side effects.

[spring-projects-issues]

smallufo commented

I am not confusing . I tried both scenario . I used to code your style for years (which is JavaEE's standard style, I think) , but feel it just not so good.

The browser will warn that you're re-submitting a POST with potential side effects. Most people won't refresh after validation errors.

That's true . But user may direct click browser's URL bar , and click ENTER , which triggers GET action , and throws 'GET not supported exception'

[spring-projects-issues]

Rossen Stoyanchev commented

I keep trying to find out why you feel it is not good. I'm open to new ideas but so far the only argument I've heard the "'GET not supported exception" you mention. Is that what it boils down to?

At this point I would have to ask for a sample application (e.g. https://github.com/spring-projects/spring-framework-issues) so I can see more concretely why you're getting the exception. It's not what I would expect to happen.