When favorPathExtension is false ResourceHttpRequestHandler serves resources with different content type in 4.3 compared to 4.2 [SPR-14577]

[spring-projects-issues]

Andy Wilkinson opened SPR-14577 and commented

As a result of this change, when favoring of path extensions is disabled ResourceHttpRequestHandler serves static resources with a content type based on the request's accept header. In the referenced Spring Boot issue this leads to HTML being served as application/json as the accept header was Accept: application/json,text/plain,\*/\*. With 4.2.x, the HTML page is served as text/html as expected.

I've attached a small Spring Boot application that reproduces the problem. It's configured to use Spring Framework 4.3.2 in order to reproduce the problem. Removing the override of the spring.version property from the pom will show the old, desired behaviour with Spring Framework 4.2.x.

With Spring Framework 4.3.2:

$ curl -I localhost:8080/ -H "Accept: application/json,text/plain,*/*"
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Last-Modified: Wed, 10 Aug 2016 09:49:22 GMT
Accept-Ranges: bytes
Content-Type: application/json;charset=UTF-8
Content-Language: en-US
Content-Length: 7
Date: Wed, 10 Aug 2016 09:49:32 GMT

With Spring Framework 4.2:

$ curl -I localhost:8080/ -H "Accept: application/json,text/plain,*/*"
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Last-Modified: Wed, 10 Aug 2016 10:44:33 GMT
Accept-Ranges: bytes
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 7
Date: Wed, 10 Aug 2016 10:44:45 GMT

---

Affects: 4.3.2

Reference URL: spring-projects/spring-boot#6562

Attachments:

• gh-6562.zip (53.13 kB)

Issue Links:

• #18233 ResourceHttpRequestHandler does not take into account mime types configured in WebMvcConfigurerAdapter
• #19417 ResourceHttpRequestHandler no longer works as prototype bean

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for the example app.

Arguably the fix for #18233 went too far by falling back on any configured strategy in the ContentNegotiationManager and applications are exposed to idiosyncratic browser Accept headers. The issue is further exacerbated when the path extension strategy is turned off. What we really want is make use of registered file extension types (the original motivation of #18233), if any, or otherwise always check the file extension as was done in 4.2.x.