ContentNegotiatingViewResolver should be able to follow redirect:views [SPR-8611]

[spring-projects-issues]

Dave Syer opened SPR-8611 and commented

ContentNegotiatingViewResolver should be able to follow redirect:views. It seems inconsistent that if the controller clearly says that it wants a redirect view by returning the string "redirect:xxx" then it is unfortunate that the ContentNegotiatingViewResolver does not respect that wish. It works fine if the controller returns a RedirectView instance, so it is also inconsistent that the string convention is not followed. N.B. it works if the preferred media type is one that leads to an HTML view (so browser clients generally don't notice), but machine and command line clients do not work because they get a 200 instead of a 302.

---

Affects: 3.0.5

Referenced from: commits 37d22ad

[spring-projects-issues]

Rossen Stoyanchev commented

Doesn't the CNVR delegate to other ViewResolvers either nested (CNVR#setViewResolvers) or in the context? I would assume that if there is a UrlBasedViewResolver among those, it would recognize the "redirect:" prefix and return a RedirectView instance. Is that not the case?

[spring-projects-issues]

Dave Syer commented

Yes, that is the case. That's what I meant when I said "browser clients generally don't notice" because they are usually going to be served content by a UrlBasedViewResolver. The problem arises when I want to use "redirect:..." in a controller that serves non-UI content (e.g. JSON) and want the client to follow redirects.

If the client adds "Accept: application/json" he gets a completely different result than if he uses "Accept: text/html" - not just differently rendered, but a different model as well. The result isn't even a 302, it's a 200, which is really not very helpful to the client because he has no idea where to go next.

If there's a way to configure myself out of this I'm happy to hear about it, but it seems like a pretty common use case, and the controller shouldn't have to use RedirectView() if he doesn't want to, so I'd like to see if we can make it easier for others.

[spring-projects-issues]

Rossen Stoyanchev commented

Ok, so ContentNegotiatingViewResolver accumulates all the Views it can find including RedirectView but then ignores it since RedirectView inherits content type "text/html" from AbstractView and that doesn't match for a request with "Accept: application/json". The ContentNegotiatingViewResolver should probably detect RedirectView by type rather than by media type. It's pretty safe to say that redirecting is what the controller wishes to do at that point. We can also consider setting the content type to null since the RedirectView does not do anything with the response body.

[spring-projects-issues]

Rossen Stoyanchev commented

Dave, could you give the fix a try? It should be available tomorrow.

[spring-projects-issues]

Sean Colyer commented

I'm not sure that I understand the advantage of using the candidate view in this one case rather than the media type.

Suppose I'm using Jackson for JSON requests and the normal UrlBasedViewResolver for Html requests. Typically, objects will be added to the Model, and a String object representing the jsp view will be returned from the method (NOT a redirect). However, suppose I'm using the RedirectView exclusively for error/exception handling. When something goes wrong I want to bring a user back to some sort of root page. In this case if I return a model that contains a flash "alert" object (or a more general Response Object that has an error/alert value) and a view of "redirect:xx" the page will 302 regardless of if the request is JSON or HTML. In JSON the desired return would really be this notification/alert rather than a 302.

I took a look at: filosganga@8b2e0ce which I think is the commit that addresses this. As my experiences indicate, it seems that redirect views are just bypassed as hinted at in this JIRA thread, but I don't understand the advantage of this?

[spring-projects-issues]

Rossen Stoyanchev commented

As my experiences indicate, it seems that redirect views are just bypassed as hinted at in this JIRA thread, but I don't understand the advantage of this?

The commit has a test that shows what you can expect. If the view name starts with "redirect:" it results in the use of RedirectView and hence an actual redirect.

In JSON the desired return would really be this notification/alert rather than a 302.

It would be strange if we ignored a "redirect:" prefixed view entirely and serialized the model as JSON instead. You probably wouldn't want to return a 200 status code in that case either. Maybe you need to restructure your controller method. One option to consider is splitting your methods by content type -- one with @RequestMapping(value="/foo", produces="application/json"), which never redirects and another with @RequestMapping("/foo") for HTML, which can redirect.