Как сохранить файлы, развернутые Tomcat в контексте, от кэширования в браузере? - PullRequest
Новая
       36

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

0 голосов
/ 16 июля 2009

Я работаю над приложением 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 решило проблему.

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

Paul.

1 Ответ

1 голос
/ 16 июля 2009

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

response.setHeader("Expires", 0);
...