правильные заголовки ответа HTTP, чтобы вызвать 304s после истечения срока действия контента - PullRequest
7 голосов
/ 24 сентября 2010

Я бы хотел, чтобы срок действия ответа HTTP истекал через 24 часа (это означает, что браузер не будет запрашивать этот URL до завтра). Но, если запрос будет повторно выдан завтра после истечения срока действия, я хочу убедиться, что браузер отправит правильные заголовки запроса, чтобы сервер отправил 304 вместо того, чтобы заставлять клиента повторно загружать все тело ответа, если он не изменился на сервере. И я бы хотел, чтобы этот 304 также истек через 24 часа.

Во-первых, возможен ли этот сценарий? Или мне нужно выбирать между кэшированием в стиле Expiration и кэшированием в стиле 304, но не в обоих случаях? Если это возможно, каковы правильные заголовки ответа (как для первоначального ответа, так и для последующих 304), которые позволят этому произойти?

Если, как часто бывает, ответ варьируется в зависимости от типа / версии браузера, то какие заголовки работают для каких браузеров - и какие браузеры вообще не смогут делать то, что я хочу? Меня интересуют только самые распространенные на сегодняшний день браузеры (например, IE6 +, FF3 +, последняя версия Chrome, последняя версия Safari)?

Извиняюсь, если этот вопрос уже был задан на SO-- Я искал некоторое время и остался без ответа.

РАЗЪЯСНЕНИЕ : я задаю этот вопрос, потому что я собираю набор автоматизированных тестов, чтобы проверить, независимо от серверной платформы, что веб-приложение генерирует правильные заголовки HTTP для генерации клиента. поведение кэширования мы хотим, чтобы все наши веб-приложения имели. Так что меня не интересует (по крайней мере, пока), как настроить Apache / IIS / PHP / Rails / Django / JSP / ASP.NET / и т.д. генерировать правильные заголовки. Я просто хочу знать, только на уровне HTTP, каковы правильные заголовки.

ОБНОВЛЕНИЕ: Я нашел этот ТАК вопрос , который отвечает на часть моего вопроса. В соответствии с RFC 2616 10.3.5 говорится, что я должен включить заголовки Expires: или Cache-Control: max-age в 304, возвращаемые сервером. Это определенно желаемое поведение.

Однако этот вопрос не отвечает на вопрос, будет ли этот RFC-совместимый подход работать на существующих популярных браузерах, особенно на IE6 / 7/8, которые являются обычными виновниками соответствия стандартам, но также на IE9, FF4 +, последней версии Chrome. и последний Safari, который также должно поддерживать наше приложение. Если какой-либо из этих браузеров не работает как RFC-мандат, есть ли обходные пути, которые я могу использовать?

Ответы [ 2 ]

5 голосов
/ 22 августа 2011

Отправьте заголовок ETAG, чтобы клиент мог сделать условный HTTP-запрос для повторной проверки ответа после истечения срока его свежести.

Отправьте директиву Cache-Control: max-age или Expires, чтобы указать, когда вы хотите, чтобы ресурс истек.

Избегайте использования заголовка Vary или любых директив, запрещающих кэширование.

Эти директивы будут работать во всех популярных браузерах (IE6 +, Firefox, Chrome), за исключением Safari в Windows, в котором только отсутствует постоянный кэш HTTP, который работает в нескольких сеансах.

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx объясняет, что происходит, когда вы не в состоянии предоставить правильные заголовки кэширования.

Инспектор ответов кэширования Fiddler поможет вам понять, как будет кэшироваться данный ответ.

0 голосов
/ 22 октября 2010

Я рекомендую использовать заголовок ETag .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...