HTTP请求返回200 OK但没有响应内容 [英] HTTP Request returns 200 OK but no content in response
问题描述
在开发特定网站时，我在Firefox中加载网站时出现间歇性问题（无法在IE或Chrome中进行比较）。该网站加载了几个javascript文件，css样式表，图像等。偶尔，一个或多个文件无法正确加载。响应表示状态为200 OK，但内容长度表示0.这会在不同时间在不同文件上发生。当它是一个无法加载的javascript文件时，该网站无法正常运行，但仍可能显示内容。当它恰好是无法加载的index.html文件时，Firefox会显示一个带有以下html的空白页面：
In developing a particular web site, I have an intermittent issue when loading the site in Firefox (haven't been able to compare in IE or Chrome). The site loads several javascript files, css stylesheets, images, etc. Occasionally, one or more of the files fail to load properly. The response indicates a status of 200 OK, but the content-length indicates 0. This happens on different files at different times. When it is a javascript file that fails to load, the site does not function properly, but may still display content. When it happens to be the index.html file that fails to load, Firefox displays an empty page with the following html:
<html>
<head></head>
<body><pre></pre></body>
</html>
（我相信这是来自Firefox的默认空页面视图）
(I believe this comes from Firefox as the default "empty" page view)
似乎可以从浏览器缓存中正确获取以前成功的加载，并且响应状态为304 Not Modified。失败后，下次请求资源时，我们会看到200 OK的响应状态，后续请求再次响应304。
It appears that previous successful loads may be fetched properly from the browser cache, and the response status is 304 Not Modified. After a failure, the next time the resource is requested we see a response status of 200 OK, with subsequent requests again responding with 304's.
以下是Firebug报告的请求/响应标头的示例：
Here are examples of the request/response headers as reported by Firebug:
一般成功案例（回复状态：304未修改，内容长度：288）
General Success Case: (Response Status: 304 Not Modified, Content-length: 288)
请求标题：
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<shouldn't matter>
Host: ???.???.???.???:8442
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT
If-None-Match: W/"228-1398777506000"
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0
响应标题：
Cache-Control: no-cache
Date: Tue, 29 Apr 2014 13:36:35 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Pragma: No-cache
Server: Apache-Coyote/1.1
来自缓存的响应标头：
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 288
Content-Type: text/javascript
Date: Tue, 29 Apr 2014 13:36:35 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT
Pragma: No-cache
Server: Apache-Coyote/1.1
Firebug中的缓存选项卡指示以下内容：
Data Size: 288
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 81
Last Fetched: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:35 GMT-05:00 (CDT)
案例失败： （响应状态：200 OK，内容长度：0）
Failed Case: (Response Status: 200 OK, Content-length: 0)
请求标题：
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<same as above>
Host: ???.???.???.???:8442
If-Modified-Since: Tue, 29 Apr 2014 13:18:26 GMT
If-None-Match: W/"228-1398777506000"
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0
回复标题：
Content-Length: 0
Date: Tue, 29 Apr 2014 13:36:28 GMT
Server: Apache-Coyote/1.1
缓存选项卡Firebug表示以下内容：
Data Size:
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 83
Last Fetched: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:42 GMT-05:00 (CDT)
下一次成功案例（响应状态：200 OK，内容长度：288）
Next Success Case: (Response Status: 200 OK, Content-length: 288)
请求标题：
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en/q=0.5
Connection: keep-alive
Cookie: JSESSIONID=<same as above>
Host: ???.???.???.???:8442
Referrer: https://???.???.???.???:8442/mySite/
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131023 Firefox/17.0
响应标题：
Accept-Ranges: bytes
Cache-Control: no-cache
Content-Length: 288
Content-Type: text/javascript
Date: Tue, 29 Apr 2014 13:37:03 GMT
Etag: W/"288-1398777506000"
Expires: Thu, 01 Jan 1970 00:00:00 GMT-00:00
Last-Modified: Tue, 29 Apr 2014 13:18:26 GMT
Pragma: No-cache
Server: Apache-Coyote/1.1
Firebug中的缓存选项卡指示以下内容：
Data Size: 288
Device: disk
Expires: Wed Dec 31 1969 18:00:00 GMT-06:00 (CST)
Fetch Count: 85
Last Fetched: Tue Apr 29 2014 08:28:54 GMT-05:00 (CDT)
Last Modified: Tue Apr 29 2014 08:28:53 GMT-05:00 (CDT)
我们正在举办在JBoss-EAP v6.1中的网站，我在Firefox 10,17和24中尝试过这个，结果相同。我知道有更新版本可用（更不用说不同的浏览器），但它们不一定适合我们。我希望解决方案是一个简单的配置更改，但在我尝试搜索此问题时，我没有看到任何人遇到同样的问题，所以它可能不是那么简单。我很感激任何建议。另外，如果我需要提供更多信息（例如，web.xml，jboss.conf等），请告诉我。
We are hosting the site in JBoss-EAP v6.1, and I have tried this in Firefox 10, 17 and 24 with the same results. I understand there are newer versions available (not to mention different browsers), but they aren't necessarily an option for us. I'm hoping the solution is a simple configuration change, but in my attempts at searching for this issue I have not seen anyone having the same problem, so it may not be so simple. I appreciate any suggestions. Also, please let me know if I need to provide more information (e.g., web.xml, jboss.conf, etc)
混合中的其他产品：
- Require.js v2.1.2
- Java 1.6
- CAS 3.2.1
- Atmosphere 2.1.3
- Require.js v2.1.2
- Java 1.6
- CAS 3.2.1
- Atmosphere 2.1.3
更新：我基本上排除了缓存问题的可能性。我按照 RequireJS API 页面中的建议实现了缓存清理模块加载过程，但我仍然看到了问题。但是，这一次，而不是所有304状态代码，它们都是200个。
Update: I have essentially ruled out the possibility of a cache issue. I implemented a cache busting module load process as suggested in the RequireJS API page, and I still see the problem. This time, however, instead of all of the 304 status codes, they are all 200's.
更新2 ：我下载了JBossWeb 7.2.0.Final的源代码并完成了调试此问题。显然有一个名为org.apache.coyote.http11.Http11ConnectionHandler的类，它维护一个Http11Processor实例池，每个实例都有自己的Request和Response对象。请求完成后，Http11Processor将被回收并重新放回池中。
Update 2: I downloaded the source for JBossWeb 7.2.0.Final and worked through debugging this issue. Apparently there is a class called org.apache.coyote.http11.Http11ConnectionHandler that maintains a pool of Http11Processor instances, each with its own Request and Response objects. When a request is completed, the Http11Processor is "recycled" and put back into the pool.
似乎回收逻辑中可能存在线程问题，因为响应.recycle应该将committed设置为false，但是在调用response.recycle（）之后我的（条件）断点会随response.committed == true而停止。这是导致稍后失败的响应的原因。当Http11Processor包含已提交的Response对象时，Response不能用于返回任何信息。它只响应状态：200，内容长度：0。
It appears that there may be a threading issue in the recycling logic because the Response.recycle is supposed to set the "committed" to false, but my (conditional) breakpoint immediately after call to response.recycle() stops with response.committed == true. This is what causes the failed responses later on. When a Http11Processor that contains an already committed Response object, the Response can not be used to return any information. It simply responds with Status: 200, Content-Length: 0.
当我关闭具有使用服务器端事件的Atmosphere连接的网站时，这似乎正在发生。 我是否正常使用Atmosphere连接？我应该实现特殊的清理逻辑吗？
This seems to be happening when I close a website that has an Atmosphere connection that uses Server Side Events. Am I using the Atmosphere connection improperly? Is there special cleanup logic I should be implementing?
推荐答案
经过大量调查和调试，我发现了允许Atmosphere库操作一个已被回收并用于以后请求的Response对象。受影响的响应的状态为200，内容长度为0，并且承诺使得不能进行其他修改。给出这个损坏的响应实例的不幸请求线程无法用于提供实际内容。
After a lot of investigation and debugging, I found out that the Atmosphere library was being allowed to manipulate a Response object that had been recycled and getting used for a later request. The affected Response was given a status of 200, content-length of 0, and it was committed such that no other modifications could be made. The unlucky request thread that is given this "corrupted" Response instance is unable to be used to provide the actual content.
为防止此修改影响JBoss服务器，我将以下内容添加到jboss.properties文件中：
To prevent this modification from affecting the JBoss server, I added the following to the jboss.properties file:
org.apache.catalina.connector.RECYCLE_FACADES=true
另一种选择是使用安全管理器。
（请参阅此页面的安全部分，以及提供的建议此页面的最后几段）
Another option is to use a Security Manager. (See the Security section of this page, and the advice offered in the last few paragraphs of this page)
这显然会阻止请求和响应的回收，因此我们总是为每个请求获得一个新的响应实例。
This apparently prevents recycling of requests and responses, so we always get a fresh Response instance for each request.
这篇关于HTTP请求返回200 OK但没有响应内容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
