In my Spring XML I have the following snippet:
<bean class="org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping">
<property name="useDefaultSuffixPattern" value="false"/>
</bean>
<mvc:annotation-driven>
<mvc:message-converters>
<bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter">
<property name="objectMapper" ref="objectMapper" />
</bean>
</mvc:message-converters>
</mvc:annotation-driven>
From what I understand, this means that Spring should NOT register "abc.*" and "abc/" when I have a mapping for "abc".
In one of my controllers I have a method which writes an image to the response:
@RequestMapping(value="{path}", method=RequestMethod.GET, produces=MediaType.IMAGE_PNG_VALUE)
@ResponseBody
public void getPath(
@PathVariable String path,
HttpServletResponse res) {
...
}
This works great when I request something like "abc", but when I request "abc.com" it throws a 406 error with the text:
The resource identified by this request is only capable of generating responses with characteristics not acceptable according to the request "accept" headers."
When I request "abc.img", the "path" parameter only receives the text "abc"; Spring omits the extension.
It seems Spring is not correctly ignoring the suffix pattern. Why is this?
Edit: I translated the java config from Dirk's comment, and the following XML seems to fix this issue:
<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
<property name="favorPathExtension" value="false" />
</bean>
<mvc:annotation-driven content-negotiation-manager="contentNegotiationManager">
<mvc:message-converters>
<bean class="org.springframework.http.converter.json.MappingJacksonHttpMessageConverter">
<property name="objectMapper" ref="objectMapper" />
</bean>
</mvc:message-converters>
</mvc:annotation-driven>
I'm still not sure why the original code I had was not working, but this has resolved my issue
When a request comes in to the spring dispatcher, part of the controller mapping/matching is matching accepted media types on the client side to producible media types on the controller side (so you can have controllers that are only distinguishable by their produced media types).
The bad news is that springmvc in its default configuration favors the extension of the requested url over any accept header in the request.
In your example, when you are requesting abc
there is no match on the extension so other contentent negotiation strategies are kicking in eventually resolving to the right type (via accept
header). But if you request abc.com
spring will derive a mime type of application/octet-stream
that doesn't match the produces
of your controller and generating a 406
(because there is no matching controller).
You can find the default mime matching for path extensions in the spring-context-support.jar in org/springframework/mail/javamail/mime.types
(see https://github.com/spring-projects/spring-framework/blob/master/spring-context-support/src/main/resources/org/springframework/mail/javamail/mime.types#L278 ).
You can disable this 'feature' in your dispatcher config so spring will not use the path extension to resolve the mime-type:
<bean id="contentNegotiationManager" class="org.springframework.web.accept.ContentNegotiationManagerFactoryBean">
<property name="favorPathExtension" value="false" />
</bean>
If you are using java config have a look at my related question/answer.
来源:https://stackoverflow.com/questions/23578742/spring-does-not-ignore-file-extension