Apache 错误地将 jsp 页面转换为“text/plain”
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/933959/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Apache is incorrectly converting jsp pages to "text/plain"
提问by AndrewR
I've got a fairly normal setup in which Apache proxies requests to a servlet running inside Tomcat over the AJP protocol.
我有一个相当正常的设置，其中 Apache 代理通过 AJP 协议向在 Tomcat 内运行的 servlet 发出请求。
We've run this setup on Apache 2.0.46/Tomcat 5.0.28 for ages without problems but have recently updated to Apache 2.2.3/Tomcat 5.5.
我们已经在 Apache 2.0.46/Tomcat 5.0.28 上运行这个设置多年没有问题，但最近更新到 Apache 2.2.3/Tomcat 5.5。
The problem is that we've noticed that intermittently (maybe one time in 3) Apache will somehow convert the "Content-Type" HTTP header of a page served by the servlet from "text/html" to "text/plain", which results in the browser displaying the HTML source instead of rendering it.
问题是我们已经注意到，Apache 会间歇性地（可能是 3 次）将 servlet 服务的页面的“Content-Type”HTTP 标头从“text/html”转换为“text/plain”，这导致浏览器显示 HTML 源代码而不是呈现它。
Has anyone seen this sort of behavior before and know what might be the cause? I suspect we're doing something bad in our servlet code that the old version of Tomcat/Apache was more forgiving of.
有没有人以前见过这种行为并知道可能是什么原因？我怀疑我们在我们的 servlet 代码中做了一些不好的事情，旧版本的 Tomcat/Apache 更宽容。
Update: I have confirmed that it's Apache changing the headers. If I browse directly to Tomcat the problem doesn't occur.
更新：我已经确认是 Apache 更改了标头。如果我直接浏览到 Tomcat，则不会出现问题。
采纳答案by AndrewR
Ok. I figured it out, it was a bug in the servlet code:
好的。我想通了，这是servlet代码中的一个错误：
We were doing something like this to write serialized Java objects as the result of HTTP requests:
我们正在做这样的事情来编写序列化的 Java 对象作为 HTTP 请求的结果：
DeflaterOutputStream dos = new DeflaterOutputStream(response.getOutputStream());
ObjectOutputStream oos = new ObjectOutputStream(dos);
response.setContentType("application/x-java-serialized-object");
oos.writeObject(someObject);
What seemed to be happening was that the DeflaterOutputStreamand ObjectOutputStreamwould get garbage-collected three or four requests later when they were still attached to the response object's output stream and this would cause something to happen on the stream that confused Apache and caused it to rewrite the headers.
什么似乎是发生的是，DeflaterOutputStream并ObjectOutputStream会得到垃圾收集三个或四个请求后，当他们还在附于响应对象的输出流，这将导致一些事情发生在那个迷茫的Apache流并造成其重写头.
I replaced the above with:
我用以下内容替换了上面的内容：
ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
DeflaterOutputStream dos = new DeflaterOutputStream(byteStream);
oos = new ObjectOutputStream(dos);
response.setContentType("application/x-java-serialized-object");
oos.writeObject(someObject);
oos.flush();
dos.finish();
byteStream.writeTo(response.getOutputStream());
and the problem has gone away.
问题就解决了。
The following links seem to describe a similar problem:
以下链接似乎描述了类似的问题：
回答by Kyle Crawford
Some webapps do not properly set mime types of content they serve, but still may work properly when served standalone because client applications like browsers are able to interpret the type of the content. But when served behind Apache, these apps will not behave correctly because Apache will provide a default type of text/plain.
一些 web 应用程序没有正确设置它们所服务的内容的 mime 类型，但在独立服务时仍然可以正常工作，因为像浏览器这样的客户端应用程序能够解释内容的类型。但是当在 Apache 后面提供服务时，这些应用程序将无法正常运行，因为 Apache 将提供默认类型的文本/纯文本。
A solution is to add a DefaultType None line to your apache virtual host for these web apps:
一种解决方案是为这些 Web 应用程序在您的 apache 虚拟主机中添加一个 DefaultType None 行：
DefaultType None
http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype
http://httpd.apache.org/docs/2.2/mod/core.html#defaulttype
From my blog post: http://patternbuffer.wordpress.com/2011/11/30/mime-type-issue-with-apache-mod_jk-and-mod_proxy-serving-plain-text/
来自我的博客文章：http: //patternbuffer.wordpress.com/2011/11/30/mime-type-issue-with-apache-mod_jk-and-mod_proxy-serving-plain-text/
回答by gareth_bowles
If you're seeing this problem intermittently, it's almost certain to be something in the servlet code rather than a misconfiguration of Tomcat or httpd. Do you have logging that you can turn on to print the contents of the HTTP headers ?
如果您间歇性地看到此问题，则几乎可以肯定是 servlet 代码中的某些问题，而不是 Tomcat 或 httpd 的错误配置。您是否有可以打开以打印 HTTP 标头内容的日志记录？
To isolate the problem a bit further, you could also try bypassing httpd and going direct to the Tomcat URLs for your pages.
为了进一步隔离问题，您还可以尝试绕过 httpd 并直接访问页面的 Tomcat URL。
I haven't seen this particular behaviour before myself, so sorry I can't be more specific.
我之前没有见过这种特殊的行为，所以很抱歉我不能更具体。
回答by Dan Davies Brackett
By intermittent, do you mean that some pages exhibit this behaviour and others don't, or that there are pages that sometimes exhibit the behaviour and sometimes not?
间歇性是指某些页面表现出这种行为而其他页面没有表现出这种行为，还是说有些页面有时表现出这种行为有时不表现出这种行为？
Can you attach any logging to the AJP layer to log HTTP headers at that level, so you can verify whether it's Apache or Tomcat adding the bogus header?
您能否将任何日志记录附加到 AJP 层以记录该级别的 HTTP 标头，以便您可以验证是 Apache 还是 Tomcat 添加了虚假标头？
回答by Robert Swisher
Are you proxying back to a cluster? Maybe one of the servers is configured wrong.
您是否正在代理回集群？可能其中一台服务器配置错误。
回答by Rajeev Pandey
I was also facing the same issue it got resolved. If problem in only one folder then there is some servlet that is blocking the request/response and making a customize request/response to tomcat. Tomcat 7.0.x
我也面临同样的问题，它得到了解决。如果问题仅在一个文件夹中，则有一些 servlet 正在阻止请求/响应并向 tomcat 发出自定义请求/响应。雄猫 7.0.x
