ResourceHttpRequestHandler shouldn't return 404 when mime-type of existing resource can't be determined (and maybe try harder) [SPR-7713]

[spring-projects-issues]

Joris Kuipers opened SPR-7713 and commented

Currently, the ResourceHttpRequestHandler returns a 404 NOT FOUND when a resource is requested for which ServletContext#getMimeType() returns null. This causes severe issues when common files have no associated mime type configured in the server, which might be avoidable by using some generic mime type and/or by trying an alternative approach like the Java Activation framework to determine the mime type if the servlet context can't.
I ran into this on a WebLogic 10.3.2 server, which didn't even return a mime type for .gif, .png and .js files. Not sure if this was caused by a misconfiguration of the server or if WebLogic really doesn't have any pre-configured mime types for these files, but now the only solution was to add a bunch of mime type mappings to the web.xml.

---

Affects: 3.0.5

Attachments:

• AdvancedResourceHttpRequestHandler.java (2.93 kB)

Backported to: 3.0.7

5 votes, 4 watchers

[spring-projects-issues]

Brian Relph commented

This is also an issue with Websphere 7 - it does not detect .png files. I also think the default behavior should change from returning a 404 to instead returning either without a content-type header set, or returning "application/octet-stream" as the content type. This allows client to still retrieve the resource, and make their own determination about the content type. See section 7.2.1 in http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html

[spring-projects-issues]

Brian Relph commented

Attaching an example implementation, that uses the same internal javax.activation.FileTypeMap detection that is in ResourceHttpMessageConverter

[spring-projects-issues]

Juergen Hoeller commented

As of 3.1 GA and 3.0.7, ResourceHttpRequestHandler simply sends content without a content-type header if no media type could be determined.

Additionally, as of 3.1 GA, we also have a Java Activation Framework fallback in ResourceHttpRequestHandler, as well as a ServletContext.getMimeType check before the JAF fallback in ContentNegotiatingViewResolver. As a consequence, the MIME type resolution algorithms are consistent there now.

Juergen