Как сохранить файлы, развернутые 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);