Кэширование на клиенте: Expire

Речь пойдет именно о версии 1.1 протокола HTTP и кэшировании на стороне клиента. Под клиентом я имею ввиду не только броузер на рабочей станции но и любой прокси-сервер на пути к нему.

Вспомнил тут на днях один интересный факт. Все знают, что любой серьезный браузер или прокси умеют кэшировать ответ сервера, чтобы в дальнейшем использовать этот кэш для отдачи. Многие начинающие программисты сталкиваются с кэшированием на стороне клиента, которое встает проблемой. Для того, чтобы получать свежие данные с сервера, строятся разные велосипеды на подобии добавления к урлу страницы какого-то GET параметра со случайным значением, например, так (javascript):

var path = http://some.server.org/any/script/path?r=’ + Math.random();

Не буду кривить душой, я и сам пользовался таким способом в начале.

То, откуда берет броузер данные, из кеша, или запрашивает у сервера, на самом деле зависит от заголовков в ответе сервера.  Заголовки HTTP описаны в RFC2616. я постараюсь часть, относящуюся к кэшированию на стороне клиента, объяснить исходя из этого комментария человеческим языком, но не уходя далеко от первоначального источника.

Истечение срока документа

Основная задача HTTP кэширования — прозрачное предотвращение клиентским кэшем запроса к серверу и отдача свежего содержимого клиенту. Главный способ такого предотвращения запросов состоит в том, что сервер может явно указать, когда в будущем документ можно будет считать просроченным. И, соответственно, до того момента можно считать, что документ не был изменен и является актуальным.

Здесь стоит подметить, что дату истечения срока документа нужно тщательно определять, потому-что иногда выдача неактуальной информации из кеша в ответ на запрос может нести серьезные последствия.

Таким образом, если серверу требуется, чтобы запрос не кэшировался вовсе, он может явно указать дату истечения документа на прошедшее время. Фактически это означает, что ответ сервера всегда просрочен, и его актуальность требуется проверить. Так же в этом случае сервер должен указать директиву must-revalidate в заголовке Cache-Control.

Протокол HTTP предусматривает два основных заголовка для управления истечения срока документа: Expires и Cache-Control. В этой записи я расскажу о первом заголовке.

Был еще один заголовок: Pragma:no-cache. Он запрещал кэширование документа. Этот заголовок поддерживается в режиме совместимости с протоколом HTTP версии 1.0 некоторыми клиентами и является ненадежным. Это значит, что не все клиенты перестанут кэшировать документы с таким заголовком, и полагаться на него не стоит.

Заголовок Expires

Значение этого заголовка говорит о том, начиная с какой даты и времени документ можно считать просроченным, т.е. когда его нужно снова запрашивать у сервера или удостоверяться в его актуальности. Формат заголовка:

Expires: HTTP-дата

Дата в этом заголовке имеет формат, определенный в RFC1123, например:

Thu, 01 Dec 1994 16:00:00 GMT

Следует не забывать, что дата в заголовке Expires должна быть согласована с серверными настройками даты и времени, потому-что сервер обязан включать свои дату и время в заголовоке Date.

Если нужно сделать, чтобы документ был вечным, заголовок Expires должен содержать дату и время, которые позже на год, чем дата отдачи сервером документа.

Резюмируя

Таким образом, вместо использования различных костылей текущий стандарт предлагает продуманное и функциональное решение.

Реклама
Запись опубликована в рубрике http. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s