1

application/zipHTTP Content-Type を " " に、Content-Disposition を " attachment" に設定し、応答のOutputStream;に書き込むことでファイルを送信するサーブレットがあります。ローカル アプリケーション サーバーに展開すると正しく動作し、ブラウザにファイルをダウンロードするかどうかを選択するポップアップが表示されます。

ただし、クラスター化された jboss サーバーにデプロイする場合、IE は転送全体のファイル情報を要求して 0% でハングし、ファイルをダウンロードできないというエラー メッセージで失敗します。サーブレットは正しく動作します。つまり、localhost と同じように動作します。

手がかりはありますか？

サーブレット コードの重要な部分の小さなスニペットも提供できます。

response.setContentType("application/zip; name=" + f.getName());
response.setContentLength((int)f.length());     
response.addHeader("Content-Disposition", "attachment;filename=" + f.getName());
byte[] buf = new byte[1024];
int bytesRead;
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(f));
OutputStream os = response.getOutputStream();
while((bytesRead = bis.read(buf)) != -1) {
    os.write(buf, 0, bytesRead);                
}
os.flush();
bis.close();

問題がサーブレット コードにあるのか、クラスター化されたサーバー構成にあるのかはよくわかりませんが、2 番目のチャンスが正しい可能性があると推測し始めています...私のクラスター構成で何が問題なのかについてのアイデアがあれば教えてください。 ?

4

2 に答える 2

1

これは、次の記事で説明されているIEの動作の結果である可能性があります。

http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B181050

http://support.microsoft.com/default.aspx/kb/813827

同様の問題が発生しました（Tomcatでのみ）。これは、ファイルサイズが十分に大きい場合にのみ発生しました。ダウンロードを開始してからエラーメッセージが表示されるまでの時間を測定することで、それが当てはまるかどうかを簡単にテストできます。その時間が一定であれば、おそらく同じエラーが発生します。ファイルの読み込みが十分に速いため、ローカルでエラーが発生することはありません。

ファイルの生成時にタイムアウトが発生した場合、1つの解決策は、非同期でファイルを作成し、ファイルをダウンロードする準備ができた後で最初にダウンロードを開始することです。

于 2009-04-24T14:16:20.580 に答える
1

わかりました、私はそれを修正しました。

クライアントと個々のクラスター サーバーの間に立っているロード バランサーは、すべての HTTP 応答に 'Cache-Control: no-cache' を追加していたため、IE が怒っていました。

ヘッダー ディレクティブを削除すると、問題が解決しました。

于 2009-04-27T08:39:35.747 に答える