Как мне защитить файлы, развернутые Tomcat в контексте, от кэширования в браузере?

Question

Я работаю над приложением Java / Struts, которое использует Tomcat 6.0.10.Это типичное веб-приложение, которое позволяет пользователям редактировать некоторые формы и транслировать PDF-файлы.Много лет назад мы добавили:

<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 мы обнаружили, что "иногда" страницы кэшируются, хотя мы не полностью определили, когда именно.Помимо КОНФИДЕНЦИАЛЬНОГО флага, у нас также был:

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

Но мы удалили их, потому что это, по-видимому, вызывало уродливые предупреждения о повторной публикации в IE6, и мы подумали, что гарантия КОНФИДЕНЦИАЛЬНОГО переноса также включает в себя все необходимые механизмы для предотвращения кэширования страницы браузером.Мы бы предпочли оставить решение этого вопроса на усмотрение Tomcat.

Каков "правильный" способ сделать это, чтобы у нас не было (как много) проблем в будущем?

Вызваны ли наши проблемы с кэшированием конкретной ошибкой в IE6?Или просто определенный набор релизов?Позволяет ли это произойти в 7 и / или 8?

Обновить: Мы проверили, и Tomcat корректно отправляет параметры Pragma, Cache-Control и Expires, так что это не проблема (ну, значения no-string и max-age не отправляются, но это все равно не проблема).

Проблема оказалась в Apache Portable Runtime (APR) 1.1.8.Каким-то образом, хотя мы не совсем уверены почему, это создает повторяющиеся действия браузера из одного запроса.Для нас это выглядело так, как будто страница была кэширована, потому что она содержала недопустимый токен транзакции Struts, но на самом деле вторая исполняемая версия того же запроса (с неправильным идентификатором сеанса) перезаписывала токен исходного запроса в сеансе.Обновление до 1.1.16 устранило проблему.

Почему некоторые запросы дублировались (но с разными идентификаторами сеансов), до сих пор остается загадкой ...

Пол.

Answer 1

Ни один браузер не должен кэшировать любые элементы, которые он получает по протоколу SSL, поэтому я бы склонялся к ошибке в IE6.Вы могли бы попробовать 0 или -1 в качестве значения Expires вместо 1, но все остальное, что вы делаете, мне кажется нормальным.

response.setHeader("Expires", 0);