You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AnnotationMethodHandlerAdapter.RequestMappingInfoComparator doesn't appear to order the requested accept value by quality. Meaning that if I submit a request value like the following:
@Controller
public class ExampleController {
@RequestMapping(value="/secure/example", headers="accept=text/html", method=RequestMethod.GET)
public String showHtml() {
...
}
@RequestMapping(value="/secure/example", headers="accept=image/png", method=RequestMethod.GET)
public String showPng() {
...
}
}
Then the showHtml method is selected because it is closest to the left where the showPng method should have been selected as it expresses a higher preferred quality level from the client (default quality=1).
This issue is related to #11663 but the order of the header media types should probably be taken into account AFTER the quality is taken into account.
This issue is also related to #11617 though since it appears #11617 won't make it into 3.0.x I think that this issue represents a more direct problem with a more straight forward solution that I believe should be included in to a 3.0.x release.
I think the order of media type method resolution should be the following:
Mike Youngstrom opened SPR-7000 and commented
AnnotationMethodHandlerAdapter.RequestMappingInfoComparator doesn't appear to order the requested accept value by quality. Meaning that if I submit a request value like the following:
(Taken from Webkit's standard accept header)
And I have a controller like the following:
Then the showHtml method is selected because it is closest to the left where the showPng method should have been selected as it expresses a higher preferred quality level from the client (default quality=1).
This issue is related to #11663 but the order of the header media types should probably be taken into account AFTER the quality is taken into account.
This issue is also related to #11617 though since it appears #11617 won't make it into 3.0.x I think that this issue represents a more direct problem with a more straight forward solution that I believe should be included in to a 3.0.x release.
I think the order of media type method resolution should be the following:
FYI, the patch for #11617 includes a MediaType comparator that will sort by quality before specificity if you want to use it.
Affects: 3.0.1
Issue Links:
Referenced from: commits 753a540
The text was updated successfully, but these errors were encountered: