HTTPリクエストは200OKを返しますが、応答にコンテンツがありません
特定のWebサイトを開発する際に、Firefoxでサイトをロードするときに断続的な問題が発生します（IEまたはChrome）で比較できませんでした）。サイトはいくつかのjavascriptファイル、cssスタイルシートをロードします。 、画像など。場合によっては、1つ以上のファイルが正しく読み込まれません。応答は200 OKのステータスを示しますが、content-lengthは0を示します。これは異なるファイルで異なる時間に発生します。javascriptファイルの場合ロードに失敗した場合、サイトは正しく機能しませんが、コンテンツが表示される可能性があります。ロードに失敗したのがindex.htmlファイルである場合、Firefoxは次のhtmlを含む空のページを表示します。
<html>
<head></head>
<body><pre></pre></body>
</html>
（これはデフォルトの「空の」ページビューとしてFirefoxから来ていると思います）
以前に成功したロードはブラウザのキャッシュから適切にフェッチされているようで、応答ステータスは304 NotModifiedです。障害が発生した後、次にリソースが要求されると、応答ステータスが200 OKになり、後続の要求は再び304で応答します。
Firebugによって報告されたリクエスト/レスポンスヘッダーの例を次に示します。
一般的な成功事例：（応答ステータス：304変更なし、コンテンツ長：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）
リクエストヘッダー：
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）
リクエストヘッダー：
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-EAPv6.1でサイトをホストしており、Firefox 10、17、24でこれを試しましたが同じ結果になりました。新しいバージョンが利用可能であることは理解していますが（ブラウザが異なることは言うまでもありません）、必ずしもそれらが私たちの選択肢であるとは限りません。解決策が単純な構成変更であることを望んでいますが、この問題を検索しようとしたときに、同じ問題を抱えている人を見たことがないので、それほど単純ではない可能性があります。私はどんな提案にも感謝します。また、詳細情報（web.xml、jboss.confなど）を提供する必要がある場合はお知らせください。
ミックスの他の製品：
- Require.js v2.1.2
- Java 1.6
- CAS 3.2.1
- 雰囲気2.1.3
更新：私は基本的にキャッシュの問題の可能性を排除しました。 RequireJS API ページで提案されているように、キャッシュバスティングモジュールのロードプロセスを実装しましたが、それでも問題が発生します。ただし、今回は、304のステータスコードすべてではなく、すべて200です。
更新2：JBossWeb 7.2.0.Finalのソースをダウンロードし、この問題のデバッグに取り組みました。どうやら、それぞれが独自のRequestオブジェクトとResponseオブジェクトを持つHttp11Processorインスタンスのプールを維持するorg.Apache.coyote.http11.Http11ConnectionHandlerというクラスがあります。リクエストが完了すると、Http11Processorは「リサイクル」され、プールに戻されます。
Response.recycleは「committed」をfalseに設定することになっているため、リサイクルロジックにスレッドの問題があるようですが、response.recycle（）の呼び出し直後の（条件付き）ブレークポイントはresponse.committed =で停止します。 = true。これが、後で応答が失敗する原因です。すでにコミットされたResponseオブジェクトを含むHttp11Processorの場合、Responseを使用して情報を返すことはできません。ステータス：200、コンテンツの長さ：0で応答するだけです。
これは、サーバーサイドイベントを使用するAtmosphere接続があるWebサイトを閉じるときに発生しているようです。 Atmosphere接続を不適切に使用していますか？実装する必要のある特別なクリーンアップロジックはありますか？
多くの調査とデバッグを行った結果、Atmosphereライブラリが、リサイクルされて後のリクエストに使用されたResponseオブジェクトの操作を許可されていることがわかりました。影響を受けた応答には、ステータス200、コンテンツ長0が与えられ、他の変更を行うことができないようにコミットされました。この「破損した」応答インスタンスが与えられた不運なリクエストスレッドは、実際のコンテンツを提供するために使用することはできません。
この変更がJBossサーバーに影響を与えるのを防ぐために、jboss.propertiesファイルに以下を追加しました。
org.Apache.catalina.connector.RECYCLE_FACADES=true
別のオプションは、セキュリティマネージャを使用することです。 （ this ページのセキュリティセクション、および this ページの最後の数段落で提供されるアドバイスを参照してください）
これにより、リクエストとレスポンスのリサイクルが明らかに妨げられるため、リクエストごとに常に新しいResponseインスタンスを取得します。
エラーを飲み込んで出力を生成しないtrycatchブロックがある可能性があります。どこかにエラーを記録している可能性があります。