Rendering of a Resource should try to derive the served media type [SPR-14414]

Oliver Drotbohm opened SPR-14414 and commented

When a controller returns a Resource implementation to be served to clients and the client didn't send any preferred media type (either through the URI or via the Accept header).

The culprit is that the content negotiation calculates all compatible media types first and for that consults the HttpMessageConverter's supported media types. The one handling Resource instances returns */*. The converter backed by Jackson returns a more concrete media type and thus the converter handling Resource instances is called with a media type. That in turn causes the media type detection to be turned off as it's only triggered as fallback, i.e. when no media type is given in the first place — which is never the case in the server side use case.

As discussed with Rossen Stoyanchev, a potential solution could be to hand the value (or at least the type of the value) to an overload of getSupportedMediaTypes() so that the converter can return a more concrete media type for the object about to be rendered.

Affects: 4.3 GA

Issue Links:

• #18980 Allow defining custom file extension to media type mappings in ResourceHttpMessageConverter
• #19603 BufferedImageHttpMessageConverter cannot convert to a media type it claims it can

Start by tracing the Resource-handling HttpMessageConverter and its supported media types, including the ResourceHttpMessageConverter context mentioned in the linked issue. Verify how server-side rendering behaves when the client provides no preferred media type, and consider the work complete when the served Resource receives a derived concrete media type in that case.