客户期待＆＃34; OK＆＃34;在＆＃34; 200＆＃34;之后当收到HTTP响应时：
HTTP / 1.1 200确定
如果没有＆＃34; OK＆＃34;，客户端无法正确解析HTTP响应。如何解决问题
我已修好了
@Bean
public EmbeddedServletContainerCustomizer containerCustomizer() {
return container -> {
if (container instanceof TomcatEmbeddedServletContainerFactory) {
TomcatEmbeddedServletContainerFactory tomcat = (TomcatEmbeddedServletContainerFactory)container;
tomcat.addConnectorCustomizers((TomcatConnectorCustomizer)connector -> {
ProtocolHandler protocolHandler = connector.getProtocolHandler();
if (protocolHandler != null && protocolHandler instanceof AbstractHttp11Protocol) {
AbstractProtocol protocol = (AbstractProtocol)protocolHandler;
// fix tomcat 8.5 can't send reason phrase
protocol.setSendReasonPhrase(true);
}
});
}
};
}
答案 0 :(得分：3)
请参阅https://tomcat.apache.org/tomcat-8.5-doc/config/http.html
sendReasonPhrase
如果您希望在响应中包含原因短语，请将此属性设置为true。默认值为false。
注意：此选项已弃用，将在Tomcat 9中删除。不会发送原因短语。
讨论：https://bz.apache.org/bugzilla/show_bug.cgi?id=60362
我肯定会尝试修改/更改客户端。
答案 1 :(得分：1)
HTTP规范（RFC 2616 Section 6.1）说 1 表示＆＃34;原因短语＆＃34;由零个或多个字符组成。它还说：
此处列出的原因短语仅为 建议 - 它们可以由当地的等价物替换而不用 影响协议。
换句话说，HTTP规范允许服务器为原因短语使用不同的文本，或者完全不使用。
最新版本的HTTP规范（RFC 7230 Section 3.1.2）更明确地说明了客户端行为。
原因 - 短语元素的存在仅仅是为了提供一个 主要是与数字状态代码相关联的文本描述 出于对早期互联网应用程序协议的尊重 更常用于交互式文本客户端。客户应该 忽略原因 - 短语内容。
如果您的客户端依赖于任何响应的原因短语的特定值，则它是不可互操作的，并且可以说是破坏了。
在这种情况下，你遇到过Tomcat的开发人员决定忽略原因短语的情况......大概是因为他们是多余的。虽然您可以在Tomcat 8.5中解决此问题，但从Tomcat 9开始，除了修复客户端代码而不依赖于原因短语之外，您将别无选择。
如果您计划将来继续使用Tomcat服务器，则应修复或更换客户端。
1 - RFC 7231中的措辞实际上是相同的。