Отключение кэша клиента с сервера Jetty для запросов REST

У меня есть сервер REST Java, реализованный с помощью Джерси, работающего на Jetty. Похоже, что некоторые браузеры (IE7) внутренне кэшируют все запросы к серверу.

Что я хотел бы сделать, так это отправить определенный HTTP-заголовок в ответе с сервера REST, указав браузеру, что он не должен кэшировать этот ответ, и поэтому снова запросит сервер в следующий раз, когда ему понадобится доступ к этому ресурсу.

Любые идеи о том, как настроить Jersey/Jetty для этого? Или единственный способ настроить это на стороне клиента?


http rest caching jetty jersey
person Santiago Palladino    schedule 24.09.2008    source источник

Ответы (4)


arrow_upward
3
arrow_downward

response.setHeader("Прагма", "без кеша");

No, No. No!

Использование заголовка pragma для отключения кэширования на стороне клиента является неправильным, это заголовок запроса, который не оказывает нулевого влияния на ответ.

http://www.mnot.net/cache_docs/#PRAGMA

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32

Кроме того, установка Expires: 0 неверна, Expires должна быть датой, а не количеством секунд, однако это будет работать, так как недопустимая дата http интерпретируется как «уже просроченная».

http://www.mnot.net/cache_docs/#EXPIRES

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21

person Dave Cheney    schedule 04.10.2008
comment
Обратите внимание, что спецификация HTTP определяет Pragma как общий заголовок, что означает, что его можно использовать для запросов или ответов. Я не знаю, насколько часто его используют в качестве заголовка ответа, но вот небольшое доказательство: спецификация OAuth2 требуется заголовок ответа Pragma: no-cache, а также заголовок ответа Cache-Control: no-store при выдаче токена доступа. - person jbyler; 14.01.2014

arrow_upward
2
arrow_downward

Вы ничего не можете сделать с мошенническими клиентами, но Jetty может отправлять соответствующие HTTP-заголовки. Попробуйте здесь получить информацию о настройке заголовков Last-Modified и Cache-Control.

person Hank Gay    schedule 24.09.2008

arrow_upward
2
arrow_downward

На стороне сервера вы можете попробовать это, если у вас есть доступ к ответу (возможно, вы сможете сделать это через фильтры).

response.setHeader("Pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Expires", "0");

Еще один трюк, который вы можете попробовать на стороне клиента, — это добавить лишний аргумент к URL-адресу, например «http://www.company.com/services/staff?id=xxx&requestTime="+(new Date()).getTime(); Таким образом, запрашиваемый URL-адрес каждый раз отличается, и его нельзя кэшировать.

person Steve g    schedule 24.09.2008

arrow_upward
0
arrow_downward

@ Дэйв Чейни: ну, что я понял из http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 заключается в том, что Cache-control имеет смысл как для запроса, так и для ответа. И когда ответ является ответом, контролируемым кешем, это спецификация того, что клиент (браузер) должен делать с ресурсом (см. следующий раздел, 14.9.1).

@all: Кроме того, в разделе 14.21 того же документа указано, что заголовок Expires, установленный на 0, означает «недопустимую дату» и может игнорироваться клиентами. И мои тесты с отправкой даты истечения срока действия до 1 января 1970 года (отметка времени 0) не вызывают ничего, кроме игнорирования от IE (и ff, если на то пошло), который все равно будет кэшировать ответ.

Мое решение состояло в том, чтобы отправить текущую дату для поля Expires, о чем говорится в спецификации.

person lucaa    schedule 02.02.2010