Jersey响应的原因短语在Tomcat 7和8.5中不一致 [英] Jersey response's reason phrase is inconsistent in tomcat 7 and 8.5

查看:168
本文介绍了Jersey响应的原因短语在Tomcat 7和8.5中不一致的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我在一台服务器上使用Tomcat 8.5,在另一台服务器上使用Tomcat 7,我拥有以下球衣资源:

I'm using Tomcat 8.5 in one server and Tomcat 7 in different server and I have the following jersey resource:

@Path("main")
public class MyResource {


@POST
@Path("path")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public PojoResponse sendMailTemplate(PojoRequest paramsMap) throws Exception {
    return service.execute(paramsMap);
}

使用@ApplicationPath("root")MyApplication(extends ResourceConfig)注册的

使用JMeter/Postman(到/root/main/path)提交请求时,HTTP的原因短语

When submitting request using JMeter/Postman (to /root/main/path) I'm getting inconsistent HTTP's Reason Phrase

不需要客户检查或显示原因短语.

The client is not required to examine or display the Reason- Phrase.

协议不是强制性的

此处列出的原因短语仅是建议-可以用本地等效项替换它们而不会影响协议.

The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol.

我从Tomcat 7服务器上看到200 OK的有效"响应:

I see a "valid" response of 200 OK from Tomcat 7 server:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
Content-Length: 32

以及来自Tomcat 7服务器的200 200的无效"响应(相同的请求):

and an "invalid" response of 200 200 from Tomcat 7 server (same request) :

HTTP/1.1 200 200
Server: Apache
Content-Type: application/json
Content-Length: 32
X-Content-Type-Options: nosniff
X-XSS-Protection: 1
Connection: close
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

当我检查响应我找不到更新原因短语的参考, 那么这种矛盾应该被忽略还是可以解决?

When I check Response I don't find any reference to updating reason phrase, So should this inconsistency be ignored or can it be fixed?

编辑

我的应用程序还注册了JacksonFeature:

My application also register JacksonFeature:

register(JacksonFeature.class);

编辑2

实际上,我发现我在第二个环境中有多余的jar:

Actually I found that I have extra jar in second environment:

 jersey-entity-filtering-2.19

普通罐子:

jersey-client-2.19.jar
jersey-common-2.19.jar
jersey-container-servlet-2.19.jar
jersey-container-servlet-core-2.19.jar
jersey-guava-2.19.jar
jersey-media-jaxb-2.19.jar
jersey-media-json-jackson-2.6.jar
jersey-server-2.19.jar
jersey-spring3-2.6.jar

编辑3

我在Tomcat 8.5中发现了一个 bug ,其中说出了原因短语已删除

I found a bug in Tomcat 8.5 which saying reason phrase was removed

克里斯托弗·舒尔茨(Christopher Schultz):我很惊讶地看到Tomcat主动删除了原因短语.我最初以为这只是Tomcat从Tomcat生成的每个响应中删除原因短语(例如,来自DefaultServlet的所有内容,各种内部错误等),但是它正在主动剥离由应用程序明确设置的原因短语.

Christopher Schultz : I was surprised to see that Tomcat actively strips-out the reason phrase. I had initially thought this was simply Tomcat removing reason-phrases from every response generated by Tomcat (e.g. everything coming from the DefaultServlet, various internal errors, etc.), but it's actively stripping reason phrases explicitly-set by applications.

Michael Osipov: 不,这不会发送任何原因短语.仅HTML错误页面.我知道,因为我上次重写了ErrorReportValve.

Michael Osipov: No, this does not send any reason phrase. Only the HTML error page. I know, because I have rewritten the ErrorReportValve the last time.

编辑4

我发现了相关问题,但我并不完全理解

I found relevant question but I didn't fully understand it

Tomcat 8.5从响应中删除了"HTTP状态原因短语",因此您将在响应中获得HTTP 200而不是HTTP 200 OK.您的观察结果可能来自将状态代码复制到状态原因短语中进行显示的软件.

Tomcat 8.5 removed the "HTTP status reason phrase" from the response, so you'll get HTTP 200 instead of HTTP 200 OK in the response. It's possible that your observations are from software that duplicates the status code into the status reason phrase for display.

您如何观察状态码?您可能会发现,如果执行协议跟踪,将会看到Tomcat/httpd仅发送一个状态代码. 您确定双重状态代码"实际上不是(正常)状态代码,并且原因短语恰好与状态代码相同吗?

How are you observing the status code? You may find that if you do a protocol trace, you'll see that there is only a single status code being sent by Tomcat / httpd. Are you sure the "double status code" isn't actually a (normal) status code and a reason phrase that happens to be the same text as the status code?

推荐答案

我刚刚回答了类似的问题(52821653)两天前.

I just answered a similar question (52821653) two days ago.

简而言之:当前版本的HTTP协议(HTTP/2)已删除了对原因短语的支持.

In short: the current version of HTTP protocol (HTTP/2) has removed support for the reason phrase.

此功能已消失.不要依赖它.

This feature is gone. Do not rely on it.

更新:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1

HTTP/1.1 200 200
Server: Apache

默认情况下,当前版本的Tomcat 8.5的HTTP连接器将以HTTP/1.1 200响应(无原因短语).参见org.apache.coyote.http11.Http11OutputBuffer.

The HTTP connector of current versions of Tomcat 8.5 by default will respond with HTTP/1.1 200 (with no reason phrase). See org.apache.coyote.http11.Http11OutputBuffer.

由于某些HTTP服务器的限制,默认情况下,当前版本的Tomcat 8.5的AJP连接器将默认以HTTP/1.1 200 200响应(使用状态码作为原因短语).参见org.apache.coyote.ajp.AjpProcessor.

The AJP connector of current versions of Tomcat 8.5 by default will respond with HTTP/1.1 200 200 (using the status code as the reason phrase), because of limitations of some HTTP servers. See org.apache.coyote.ajp.AjpProcessor.

两个响应都是有效的.

可以通过在sendReasonPhrase="true"来在Tomcat 8.5中启用生成"OK"字符串的功能. ="nofollow noreferrer">连接器.不建议使用此选项.

Generating the "OK" string can be enabled in Tomcat 8.5 by setting sendReasonPhrase="true" on a Connector. This option is deprecated.

这篇关于Jersey响应的原因短语在Tomcat 7和8.5中不一致的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆