1

以前は JBoss と WebLogic を使用していましたが、現在の仕事では OC4J を使用しています。これは初めてです。私の問題はそれに関連している可能性があると思います。内部に 1 つの WAR ファイルを含む EAR ファイルを作成しています。最上位の JSP は正しく表示されているように見えますが、secure/index.do や secure/header.jsp などのサブディレクトリにある JSP を表示しようとすると、ブラウザからファイルを保存するかどうか尋ねられます。保存すると、サイズが 0 バイトのファイルになります。実際、存在しないことがわかっているsecure/index.xyzも試してみましたが、同じことが起こりました。それらの他のファイル/サーブレットが存在することは知っています。これを引き起こしている可能性のあるものについてのヒントはありますか?

4

5 に答える 5

1

私はDanatheSaneに同意します。おそらく、WebサーバーまたはJBossが応答で間違ったコンテンツタイプを返しています。Wiresharkを使用している場合は、クライアントでwiresharkを実行してから、応答のHTTPヘッダーを確認します。コンテンツタイプヘッダーは、ブラウザが処理または表示する方法を知らないものであると思います。

于 2009-03-14T02:44:35.533 に答える
1

ブラウザが認識できないコンテンツ タイプのファイルを保存するように促すと思います。この場合、サーバーの応答には、文字化けした、または正しくないコンテンツ タイプが含まれている可能性があります。

問題の残りの説明から、一般的なサーバー構成の問題のように思えます。行うことの 1 つは、サンプル プロジェクト (または EAR) がサーバーに付属しているかどうかを確認し、同じ問題を再現できるかどうかを確認することです。同じ動作が見られる場合、これは構成を指しています。そうでない場合は、展開が気に入らない可能性があります。

于 2009-03-13T21:53:01.883 に答える
0

FirefoxインストールLiveHTTPHeadersを使用している場合は、問題のあるURLにアクセスしたときにサーバーがブラウザーに何を返すかを確認してください。それが奇妙なcontent-type値であるか、content-dispositionヘッダーがある場合、それが問題です。

于 2009-03-14T02:50:44.180 に答える
0

エディは正しいです!

そうしないと、サーバーの負荷が高すぎる場合に、レンダリング エラーが発生する可能性があります。

于 2009-03-14T03:26:44.967 に答える
0

それを見つけた。コンテンツ タイプの問題については本質的に正しかったのですが、私のコードには根本的なバグがあり、それが原因でした。/secure/* URL があるたびに呼び出される SecureActionFilter というフィルターを作成しました。問題は、チェーンを壊したことです。「doFilter」メソッドの最後に「chain.doFilter(req, res)」を追加するのを忘れていました。そのため、リクエストは JSP に転送されず、MIME タイプを含む何もブラウザに返されず、ブラウザは長さ 0 のコンテンツをファイル システムに保存しようとしました。

于 2009-03-23T23:00:08.747 に答える