@RequestMapping get '406 Not Acceptable' when change 'produces' order [SPR-16205]

[spring-projects-issues]

Loi Huu Mai opened SPR-16205 and commented

I have a Rest API for download Media Resource. Inside this API, an exception would be thrown if some conditions are satisfied, no physical file found for example. I have a @ControllerAdvice class which will catch that exception and returns a JSON Object.

The problem is when an exception is thrown and caught in ControllerAdvice, if I had the produces with MediaType.APPLICATION_JSON_VALUE stand first, it will work fine, a JSON Object will be returned.

@RequestMapping(value = "/download", method = RequestMethod.GET, produces = { MediaType.APPLICATION_JSON_VALUE, MediaType.APPLICATION_OCTET_STREAM_VALUE})

{
    "id": 2,
    "message": "Test message"
}

However, MediaType.APPLICATION_OCTET_STREAM_VALUE stand first, 406 Not Acceptable status will be returned

@RequestMapping(value = "/download", method = RequestMethod.GET, produces = { MediaType.APPLICATION_OCTET_STREAM_VALUE, MediaType.APPLICATION_JSON_VALUE}

I did some debug into the framework and found this:
!Debug.png|thumbnail!

The result should be the same regardless the order of produces.

---

Affects: 4.3.12

Reference URL: https://github.com/maihuuloi123/accept_mapping_bug.git

Attachments:

• Debug.png (98.65 kB)

Issue Links:

• Content negotiation fails with the conjonction of text/plain and ExceptionHandler [SPR-14411] #18982 Content negotiation fails with the conjonction of text/plain and ExceptionHandler ("duplicates")

[spring-projects-issues]

Loi Huu Mai commented

@Brian: Do you need me provide more information?

[spring-projects-issues]

Brian Clozel commented

Hi Loi Huu Mai,

Sorry about the long delay. I believe this is working as expected.

Your @RequestMapping annotation is listing all media types that can be produced here. When Spring MVC is trying to select one, it does roughly the following:

1. ordering those media types by specificity and quality
2. selecting the first media type that's concrete and use it

In your case, both MediaType.APPLICATION_OCTET_STREAM_VALUE and MediaType.APPLICATION_JSON_VALUE are equally concrete. So the first one that matches is used.

If you wish to use one over the other, feel free to use quality parameters in your media types; this will be taken into account during the sorting phase:

MediaType applicationOctetStream = new MediaType("application", "octet-stream", 0.5);
MediaType.APPLICATION_JSON_VALUE // quality is 1.0 by default

Please reopen this issue if you think something is wrong here and how it should behave with respect to the HTTP spec.

Thanks!

[spring-projects-issues]

Loi Huu Mai commented

Hi @Brian Clozel,

If it is Spring feature, I think it is better to change them to automatically recognize the returned value format and no exception should be present here.

It is not make sense that API has produces options are

{ MediaType.APPLICATION_OCTET_STREAM_VALUE, MediaType.APPLICATION_JSON_VALUE}

and still throw an error when a JSON is returned.

Please tell me if you have any question to be clear. I will explain with more details.

Thank you,

[spring-projects-issues]

Brian Clozel commented

OK, so the actual issue is about content negotiation at the @ExceptionHandler level.
In this case, I'm closing this as a duplicate of #18982, which is more on point.

Let's continue the discussion there.
Thanks for the report!