Related to thymeleaf/thymeleaf#605, thymeleaf/thymeleaf#606 and thymeleaf/thymeleaf#607, it seems a good idea to make the Content-Type established by the ThymeleafView (both in reactive and non-reactive versions) not completely strict, i.e. make the configured values work as defaults but allow a certain degree of automatic resolution of the Content-Type, based on the information that is available at the moment of View resolution (which is the request).
So in an equivalent way to what is done at thymeleaf/thymeleaf#605 and according to Spring's content negotiation mechanism, if the request path ends in a well-known file extension suffix (and only in such case), the content type established by the ViewResolver at the response could vary, so that:
.html, .htm and .xhtml would set content type text/html.xml would set content type text/xml.rss would set content type application/rss+xml.atom would set content type application/atom+xml.jswould set content type application/javascript.json would set content type application/json.css would set content type text/css.txt would set content type text/plain
Also, if the contentType or characterEncoding properties at the ViewResolver or the View objects specify a charset by means of the ;charset=X parameter (or directly in the case of characterEncoding), this will be automatically added to the computed content type.
All this mechanism will be overridable by means of a forceContentType flag at ViewResolver and View implementations, which when set to true will force the specified contentType/characterEncoding without looking for known extensions in the view name. Default will be false, so this automatic resolution mechanism will be enabled by default.
Also, note that at the reactive side the implementation of this mechanism will need all these MIME types to be added to the list of supported media types of the ThymeleafReactiveViewResolver. That should be everything given Spring 5's content negotiation mechanism is built into the View rendering flow.
Related to thymeleaf/thymeleaf#605, thymeleaf/thymeleaf#606 and thymeleaf/thymeleaf#607, it seems a good idea to make the
Content-Typeestablished by theThymeleafView(both in reactive and non-reactive versions) not completely strict, i.e. make the configured values work as defaults but allow a certain degree of automatic resolution of the Content-Type, based on the information that is available at the moment ofViewresolution (which is the request).So in an equivalent way to what is done at thymeleaf/thymeleaf#605 and according to Spring's content negotiation mechanism, if the request path ends in a well-known file extension suffix (and only in such case), the content type established by the
ViewResolverat the response could vary, so that:.html,.htmand.xhtmlwould set content typetext/html.xmlwould set content typetext/xml.rsswould set content typeapplication/rss+xml.atomwould set content typeapplication/atom+xml.jswould set content typeapplication/javascript.jsonwould set content typeapplication/json.csswould set content typetext/css.txtwould set content typetext/plainAlso, if the
contentTypeorcharacterEncodingproperties at theViewResolveror theViewobjects specify a charset by means of the;charset=Xparameter (or directly in the case ofcharacterEncoding), this will be automatically added to the computed content type.All this mechanism will be overridable by means of a
forceContentTypeflag atViewResolverandViewimplementations, which when set totruewill force the specifiedcontentType/characterEncodingwithout looking for known extensions in the view name. Default will befalse, so this automatic resolution mechanism will be enabled by default.Also, note that at the reactive side the implementation of this mechanism will need all these MIME types to be added to the list of supported media types of the
ThymeleafReactiveViewResolver. That should be everything given Spring 5's content negotiation mechanism is built into theViewrendering flow.