While this is an old issue(closed PR here https://github.com/spring-projects/spring-framework/pull/232#issuecomment-648104570 ), I think it is a genuine usecase and a viable alternative to the Variant mechanism (request.getVariant() call ) that can be found in Jersey implementations.
I am migrating an application from Jersey to Spring MVC and I stumbled upon this. For the language part in the Variant implementation, the LocaleResolver was a good alternative.
For the other 2 dimensions of MediaType and encoding that is found in the Jersey implementation, this seems a good fit.
In my case I want to write to a StreamingResponseBody and the old implementation was using Variants to determine encoding. The encoding was specified in the the accept header in the request (MediaType/MimeType) and the parameter portion of the MediaType contained the charset. Using the resolver in the PR I can get the encoding here, where I need to know it beforehand so that I can specify the correct encoding that the client expects and specified in the request header, to write with in my OutputStream/Writer.
In my case I am using text/plain and the client can ask me various encoding in order of his preference and I can accomadate it in my Response.
Does that make sense for you guys.
I think this resolver belongs in Spring by default.
Originally posted by @ahsanfz in https://github.com/spring-projects/spring-framework/pull/232#issuecomment-648104570
Comment From: snicoll
Let's continue the conversation in the original issue.