Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ContentNegotiatingViewResolver to be strict ant return a 406 if no view found [SPR-6467] #11133

Closed
spring-projects-issues opened this issue Nov 28, 2009 · 2 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Nov 28, 2009

Oliver Drotbohm opened SPR-6467 and commented

Currently ContentNegotiatingViewResolver acts lenient as it returns null when it can not resolve any view to indicate that further ViewResolvers configured shall step in and try to resolve the view.

In cases when ContentNegotiatingViewResolver is the only resolver configured, not resolving the view should be answered with a 406 Not Acceptable status code. A quick hack I did was to add a property beStrict to CNVR an implement an inner class to return the appropriate statuscode. See applied patch.

This solves the problem at a first glance but I think it would be more clean to prevent processing of the request entirely if no valid accept header was set by using the algorithm getmediaTypes(..) in CNVR. Currently this method is not public, but I could imagine a HandlerInterceptor implementation that gets a reference to the CNVR injected and call to getMediaType(..) to decide whether to process the request at all.


Affects: 3.0 RC2

Attachments:

Issue Links:

Referenced from: commits 1cd0a97

@spring-projects-issues
Copy link
Collaborator Author

Arjen Poutsma commented

Applied the patch, thanks!

I did change the name of the property to 'useNotAcceptableStatusCode', though, as 'strict' was a bit vague.

I also agree to the point you made in the second part of the description, but I currently don't see any way of fixing this.

@spring-projects-issues
Copy link
Collaborator Author

Oliver Drotbohm commented

Thanks a lot, Arjen! I just thought one could provide a HandlerInterceptor that gets a reference to the CNVR which is in turn able to determine in advance, whether the current request is supported. Of course this would need a new boolean supportsMediaTypeFor(HttpServletRequest request) on CNVR. This way preHandle could then throw an appropriate exception.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants