Java 使用tomcat在内容类型标头响应中保留分号后的空格

我们有一个遗留的客户机，它使用部署在Tomcat8.5上的servlet。 此旧客户端正在等待此格式的内容类型标头响应（请注意分号和“字符集”之间的空格）：

然而，在服务器端，Tomcat总是在修整这个空白，尽管我们在servlet中强制它：

response.setContentType("text/xml; charset=utf-8");

甚至在自定义扩展名为

HttpServletResponseWrapper

的筛选器中，如中所建议

无论我尝试什么，返回的内容类型头总是不带空格

Content-type: text/xml;charset=utf-8

作为参考，我在tomcat官方网站上找到了：

Tomcat删除“；”之间的空白字符以及“charset”关键字

我知道http标准说分号后面的空格是可选的，正如在另一篇文章中提到的，但是由于有问题的客户机运行的是遗留版本，我想知道是否有任何方法可以强制tomcat保留这个空格

Content-type: text/xml;charset=utf-8

我正在考虑其他选择，比如在apache或nginx（tomcat之上）中修改内容类型头，但如果可能的话，我更喜欢tomcat级别的解决方案

---

任何帮助都将不胜感激。

如评论中所述，这是我们无法避免的，因为它是在tomcat中硬编码的

在我们的特定用例中，我们终于能够稍微更改遗留客户端，因此现在它可以以标准格式处理内容类型头（没有空间）

---

感谢@zack6849 por指出这一点。

这似乎表明没有选项可以禁用@zack6849！谢谢你的评论。我看到了，但是由于contentType的getter和setter方法都是public方法，我想知道是否有什么方法可以替代它们或类似的东西。无论如何，谢谢。如果你的旧客户端允许特殊字符，如引号，你可以打破硬编码修剪，但从你所说的你的客户端不允许。RFC2616说，可以用一个空格替换标题值中的LWS，但没有说可以删除标题值中的空格。传统客户只犯了一半罪。谢谢@EugèneAdell。你说“打破硬编码修剪”是什么意思？老实说，我不确定legacy客户端是否允许引用，所以也许我应该试试你的suggestion@zack6849显示了Tomcat的代码，其中trim函数删除了您需要的空间。我对他的评论投了赞成票。如果不是空格，而是字符集=。。如果使用了“SPACE\u charset=…”或“SPACE\u charset=…”，则trim函数将不会执行任何操作，因为该值将不再以空格开头。