0

Tomcat 6.0.10 を使用する Java/Struts アプリケーションに取り組んでいます。これは、ユーザーがいくつかのフォームを編集し、PDF をストリーミングできるようにする典型的な Web アプリケーションです。さかのぼって、次のように追加しました。

<security-constraint>
    <web-resource-collection>
        <web-resource-name>GeneralRequests</web-resource-name>
        <url-pattern>/WR1/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

そのため、非ストリーミング ページはすべて https に強制され、キャッシュされません (私たちは考えました)。システム内のストリーミング ページには別の制約エントリがあります。

IE6 での最近のテストでは、「ときどき」ページがキャッシュされていることがわかりました。CONFIDENTIAL フラグと同様に、以前は次のものも使用していました。

        response.setHeader("Pragma", "No-cache");
        response.setHeader("Cache-Control", "no-cache,no-store,max-age=0");
        response.setDateHeader("Expires", 1);

しかし、IE6 で醜い再投稿警告を引き起こしているように見えたため、これらを削除しました。CONFIDENTIAL transport-guarantee には、ページのブラウザー キャッシュを防止するための適切なメカニズムもすべて含まれていると考えました。この問題は Tomcat に任せて適切に処理してもらいたいと考えています。

これを行うための「正しい」方法は何ですか。そうすれば、将来（できるだけ多くの）問題が発生しなくなりますか？

キャッシングの問題は IE6 の特定のバグが原因ですか? それとも特定のリリースのセットだけですか? これは 7 および/または 8 で発生しますか?

更新:チェックしたところ、Tomcat は Pragma、Cache-Control、および Expires パラメータを正しく送信しているため、それは問題ではありません (まあ、no-string と max-age の値は送信されていませんが、それでも問題ではありません)。 .

問題は、Apache Portable Runtime (APR) 1.1.8 であることが判明しました。理由は完全にはわかりませんが、どういうわけか、単一のリクエストから重複したブラウザ アクションを作成しています。無効な Struts トランザクション トークンが含まれているため、ページがキャッシュされているように見えましたが、実際には、同じリクエストの 2 番目の実行バージョン (間違ったセッション ID を持つ) が、セッション内の元のリクエストのトークンを上書きしていました。1.1.16 にアップグレードすると、問題が修正されました。

一部のリクエストが重複している (ただしセッション ID が異なる) 理由は、まだ謎です...

ポール。

4

1 に答える 1

1

ブラウザーは、SSL 経由で受信したアイテムをキャッシュするべきではないため、IE6 のバグに傾倒します。Expires の値として 1 の代わりに 0 または -1 を試すこともできますが、それ以外はすべて問題ないように見えます。

response.setHeader("Expires", 0);
于 2009-07-16T15:25:54.987 に答える