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

RequestMappingInfoHandlerMapping.handleNoMatch throws 415 when it should throw 406 [SPR-14397] #18969

Closed
spring-projects-issues opened this issue Jun 24, 2016 · 8 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jun 24, 2016

Nick opened SPR-14397 and commented

When two methods have the same mapping but differ on what media types they consume, handleNoMatch is throwing a 415 Unsupported media type when it should be throwing 406 Not acceptable. In the following example, we have two methods that both produce JSON, but take different input formats:

  1. POST /test, Input (consumes): JSON, Output (produces): JSON
  2. POST /test, Input (consumes): TEXT, Output (produces): JSON
@RestController
@RequestMapping(value = "/test")
public class Controller {
    @RequestMapping(value = "",
        method = { RequestMethod.POST },
        consumes = { MediaType.APPLICATION_JSON_VALUE },
        produces = { MediaType.APPLICATION_JSON_VALUE }
    )
    public String post1() {
        return "Accept: JSON";
    }

    @RequestMapping(value = "",
        method = { RequestMethod.POST },
        consumes = { MediaType.TEXT_PLAIN_VALUE },
        produces = { MediaType.APPLICATION_JSON_VALUE }
    )
    public String post2() {
        return "Accept: TEXT";
    }
}

The following requests fail with 415 when they should be 406:

  • POST /test, Content-Type: JSON, Accept: application/xml
  • POST /test, Content-Type: TEXT, Accept: applicaton/xml

This is because in my project, I also have an HttpMessageConverter that can produce XML. If I didn't, I would get a 406, since the sequence of events would be:

  1. handleNoMatch throws 415
  2. AbstractMessageConverterMethodProcessor attempts to convert this exception with the current message handlers
  3. It finds none and throws a 406 which causes the 415 to be ignored

But since there is also an HttpMessageConverter that can write XML, #3 in the above sequence succeeds and an error message is printed in XML and an HTTP status of 415 is returned.


Affects: 4.3 GA

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

415 is the status code for the "Content-Type" of the request payload:
https://tools.ietf.org/html/rfc7231#section-6.5.13

406 Not Acceptable refers to the representation requested with the "Accept" header for response:
https://tools.ietf.org/html/rfc7231#section-6.5.6

@spring-projects-issues
Copy link
Collaborator Author

Nick commented

@Rossen Stoyanchev - Yes, but the Content-Type is NOT what's wrong with the request, it's the Accept header.

With these two endpoints:

  1. POST /test, Input (consumes, Content-Type header): JSON, Output (produces, Accept header): JSON
  2. POST /test, Input (consumes, Content-Type header): TEXT, Output (produces, Accept header): JSON

This fails with a 415: POST /test, Content-Type: JSON, Accept: application/xml
This fails with a 406: POST /test, Content-Type: JSON, Accept: application/pdf

The first request should also return 406 - 415 shouldn't be raised because there is an endpoint that supports Content-Type: JSON but it can't produce application/xml.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

Ah, I misunderstood then. I will have a closer look.

@spring-projects-issues
Copy link
Collaborator Author

Nick commented

Thanks Rossen, I figured it might be difficult to verify so I submitted a repro project to make it easier.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

Thanks for the repro project.

I think we can improve the handleNoMatch method (of RMIHM) to keep narrowing the set down just like we do currently with the patternAndMethodMatches set. We need continue the same process and narrow it down by consumible before continuing to producible, and so on. I'll give it a try for 4.3.1 still.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

I've pushed a commit that should fix the issue. Would you mind giving it a try with 4.3.1.BUILD-SNAPSHOT (from repo.spring.io/snapshots) when the next build is done? Thanks.

@spring-projects-issues
Copy link
Collaborator Author

Nick commented

Just pulled down spring-core-4.3.1.BUILD-20160629.200020-43 and everything looks great, all of my tests are passing. Thanks Rossen.

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

Thanks for confirming and reporting the issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants