Question

我在一台服务器上使用Tomcat 8.5，在另一台服务器上使用Tomcat 7，并且具有以下球衣资源：

@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);
}

使用MyApplication注册到extends ResourceConfig（@ApplicationPath("root")）的人

使用JMeter / Postman（到/ root / main / path）提交请求时，HTTP的Reason Phrase不一致

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

协议不是强制性的

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

我从Tomcat 7服务器上看到200 OK的“有效”响应：

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

，并且来自Tomcat 7服务器的200 200的“无效”响应（相同的请求）：

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

当我检查Response时，没有发现更新原因短语的任何参考，那么这种矛盾应该被忽略还是可以解决？

编辑

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

register(JacksonFeature.class);

编辑2

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

 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，上面写着原因词组已删除

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

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

编辑4

我发现了relevant question，但我并不完全理解

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

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

Answer 1

两天前，我刚刚回答了a similar question（52821653）。

简而言之：当前版本的HTTP协议（HTTP / 2）已删除了对原因短语的支持。

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

更新：

看着

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。

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

两个响应都是有效的。

可以通过在Connector上设置sendReasonPhrase="true"在Tomcat 8.5中启用生成“ OK”字符串。此选项已弃用。

Answer 2

我认为您正在寻找的答案可以在RFC 2616, section 6中找到。

相关摘录：

状态代码供自动机使用，原因短语供人类用户使用。不需要客户检查或显示原因短语。

主要要点是，客户端代码中不应使用原因短语。但是，您可以并且应该依赖状态码。

如果您希望在HTTP响应中传达其他人类可读的上下文，通常的做法是将其放置在“自定义”响应标头中（例如“ X-MyApp-Message”）。请注意，自定义标头应以“ X-”开头。

Answer 3

问题出在使用具有错误的Apache Server 2.4.6，Apache 2.4.7的一项更改正在修复reason phrase to be returned：

核心：在HTTP响应标头中添加缺少的原因短语。 PR54946。[Rainer Jung]

relevant bug声明这是一个重大变化：

我们会得到从标准表中提取的http状态行：
HTTP/1.1<sp>200<sp>OK
现在，在Apache 2.2.24中，我们得到：
HTTP/1.1<sp>200<sp>
我们将其追溯到针对导致该问题的Apache错误44995进行的更改   新行为。该错误是对自定义状态代码的修复，但它也   最终违反了标准代码，因此不再返回标准   原因短语增强了响应。

我意识到RFC2616规范允许使用HTTP / 1.1200   响应，但我们的客户无法更改，并且在没有收到通知时崩溃   原因短语。

Jersey响应的原因短语在Tomcat 7和8.5中不一致

3 个答案: