Spring不会忽略文件扩展名 [英] Spring does not ignore file extension

问题描述

在我的Spring XML中，我有以下代码段：

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>

据我所知，这意味着Spring应该不注册abc 。*和abc /当我有abc的映射。

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) {

    ...
}

当我请求类似abc的东西时，这很有用，但当我请求abc.com时，它会抛出406错误文本：

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."

当我请求abc.img时，path参数只接收文本abc;春天o mits扩展名。

When I request "abc.img", the "path" parameter only receives the text "abc"; Spring omits the extension.

看来Spring没有正确地忽略后缀模式。这是为什么？

It seems Spring is not correctly ignoring the suffix pattern. Why is this?

编辑：我从Dirk的评论中翻译了java配置，以下XML似乎解决了这个问题：

<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>

我仍然不确定为什么原来的代码不起作用，但是这个已经解决了我的问题

推荐答案

当请求进入spring调度程序时，控制器映射/匹配的一部分将客户端上接受的媒体类型与控制器端的可生成媒体类型相匹配（因此您可以使控制器只能通过其生成的媒体类型进行区分）。

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).

坏消息是，springmvc的默认配置支持请求的任何接受标头的请求网址的扩展名。

The bad news is that springmvc in its default configuration favors the extension of the requested url over any accept header in the request.

在您的示例中，当您请求 abc 时，扩展程序上没有匹配项，因此其他有争议的协商策略是最终解决到正确的类型（通过接受标题）。但是如果你请求 abc.com spring将派生一个mime类型的 application / octet-stream ，它不匹配生成您的控制器并生成 406 （因为没有匹配的控制器）。

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).

你可以在 org / springframework / mail / javamail / mime.types （参见 https://github.com/spring-projects/spring-framework/blob/master/spring-context-support/src/main/resources/org/springframework/mail /javamail/mime.types#L278 ）。

您可以在调度程序配置中禁用此功能，以便Spring不会使用路径扩展来解析mime-type：

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>

如果您使用的是java配置，请查看我的相关问题/答案。

If you are using java config have a look at my related question/answer.

这篇关于Spring不会忽略文件扩展名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！