Affects: v3.x and v2.x

Given I have created a GET mapping with the following produces value application/test;version=1. When I make a request to that mapping and set the accept header to application/test;version=2, application/test;version=1 my request mapping executes, as it should because the second entry in the accept header is a match, but the response contains the content-type header with a value of application/test;version=2

The content-type should beapplication/test;version=1 since that is what it matched on.

Comment From: edyda99

I can look into it if someone can guide me to a starting point

Comment From: bclozel

As described in this issue comment, media type parameters are useful mostly for the codecs and the processing of it, but they don't really have a huge influence on content negotiation.

Rossen mentioned that the content negotiation process in Spring Framework does its best to match the request with the expected handler. This case is not about the matching, but the selection of the most specific media type for the response.

The algorithm tries to select the most specific and compatible media type for the response, but here this is failing because we can't really compare media types with their parameters. This case looks obvious, but things start to get more complex with version=A.12 or when several parameters are involved.

For this reason I think we're going to decline this issue. Before closing it, I'd like to get the opinion of other team members about this.

Comment From: HazzMan2409

@bclozel thanks for the response.

You state that parameters don’t have a huge influence on content negotiation, yet if the request accept header only contained application/test;version=2 the response would be a 406. So it seems like there is some check on the parameters.

I think the behaviour I was hopeful for was doing an equality check on the parameters and having that weight highest when deciding the media type that has matched. That would make the common case of versioning a media type with an integer possible, currently Spring’s behaviour doesn’t allow this approach.

Doing that equality check and weighting it highest means that the other cases you talked about, multiple parameters and multiple components to the parameter value are not a concern. If they equal a value in the accept header, we have a match, otherwise do whatever Spring currently does.

Comment From: rstoyanchev

We do support mapping requests by content type parameter. You can see more about the original use case in #27999, but essentially this is only meant to choose among two or more controller methods. Once a controller method is chosen, all of its produces media types are used equally and in order for content negotiation.

In theory we could try to take this further by paying attention to declared parameters in the selection of the response media type, but I'm not sure it wouldn't lead to surprising outcomes. I expect that creating 2 methods, one for each version works.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.