Jersey:未设置 content-type 时，@Consumes 无法正常工作

Jersey: @Consumes doesn#39;t quite work when content-type is not set(Jersey:未设置 content-type 时，@Consumes 无法正常工作)

问题描述

我试图弄清楚@Consumes 在这里是如何工作的.

I'm trying to figure out how @Consumes works here.

我有一个如下所示的简化资源，我只希望该资源使用application/vnd.myApp+xml".

I have a simplified resource that looks like the below, and I only want this resource to consume "application/vnd.myApp+xml".

@Path("/app")
@Consumes("application/vnd.myApp+xml")
@Produces("application/vnd.myApp+xml")
public class AppResource {
    @POST
    public Response postStuff() {
        ...
    }
}

我有以下测试用例:-

public class AppResourceTest extends JerseyTest {
    @Test
    public void testApp() {
        // #1: Works fine
        ClientResponse response = resource().path("app")
                    .accept("application/vnd.myApp+xml")
                    .post(ClientResponse.class);

        ...

        // #2: Throws a 415 Unsupported Media Type
        ClientResponse response = resource().path("app")
                    .accept("application/vnd.myApp+xml")
                    .type("text/plain")
                    .post(ClientResponse.class);

        ...

        // #3: Works fine
        ClientResponse response = resource().path("app")
                    .accept("application/vnd.myApp+xml")
                    .type("application/vnd.myApp+xml")
                    .post(ClientResponse.class);

        ...
    }
}

从上面的 3 个测试中，#2 和 #3 按预期工作.

From the 3 tests above, #2 and #3 work as expected.

至于#1，如果我不设置content-type，为什么它也不会抛出415?

As for #1, if I don't set the content-type, why doesn't it throw a 415 too?

推荐答案

基于@Consumes api (http://jsr311.java.net/nonav/releases/1.0/javax/ws/rs/Consumes.html) 和 HTTP 类型规范 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1) 耦合根据您所看到的行为，我认为可以安全地得出以下 Jersey 实施:

Based on @Consumes api (http://jsr311.java.net/nonav/releases/1.0/javax/ws/rs/Consumes.html) and the HTTP type spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1) coupled with the behavior you are seeing I think it is safe to conclude the following Jersey implementation:

如果客户端没有设置 Content-Type，Jersey 不会默认但允许它通过任何/所有 @Consumes 注释.

If the Content-Type is NOT set by the client Jersey does NOT default but allows it to pass through any/all @Consumes annotions.

当为 URI 设置了多个 @Consumes {不同类型}且客户端未设置 Content-Type 时，Jersey 将默认为第一个 @Consumes 注释或可接受类型列表中的第一个类型.

When multiple @Consumes {different types} are set for the URI and the client has NOT set the Content-Type then Jersey will default to the first @Consumes annotation or first type in a list of acceptable types.

当设置了 Accepts 标头值时，Jersey 会找到最合适的方法来执行.如果多个方法最适合，它将默认使用第一个定义的方法.

When the Accepts header value is set Jersey will find the best fitting method to execute. If multiple methods are a best fit it will default to the first defined.

总之，@Consumes 仅当且仅当客户端设置 Content-Type 时才充当过滤器，否则 Jersey 将尝试找到最合适的匹配.这确实符合 HTTP 规范:

In conclusion the @Consumes only acts as a filter if and ONLY if the client sets the Content-Type otherwise Jersey will attempt to find the best fitting match. This does match the HTTP spec:

任何包含实体主体的 HTTP/1.1 消息都应该包含定义该主体的媒体类型的 Content-Type 标头字段.当且仅当媒体类型不是由 Content-Type 字段给出时，接收者可以尝试通过检查其内容和/或用于识别资源的 URI 的名称扩展来猜测媒体类型.如果媒体类型仍然未知，接收者应该将其视为类型application/octet-stream".

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

如果目标是让@Consumes 充当白名单，那么可以使用 servlet 过滤器在未设置请求的情况下默认 Content-Type.

If the goal is to have the @Consumes to act as a white list then a servlet filter could be used to default the Content-Type on requests where none is set.

这篇关于Jersey:未设置 content-type 时，@Consumes 无法正常工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！