Контрольный вопрос кеша

Question

Если я установлю это для управления кэшем на моем сайте:

Header unset Pragma
FileETag None
Header unset ETag

# 1 YEAR
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|mp3|mp4)$">
Header set Cache-Control "public"
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
Header unset Last-Modified
</FilesMatch>

# 2 HOURS
<FilesMatch "\.(html|htm|xml|txt|xsl)$">
Header set Cache-Control "max-age=7200, must-revalidate"
</FilesMatch>

# CACHED FOREVER
# MOD_REWRITE TO RENAME EVERY CHANGE
<FilesMatch "\.(js|css)$">
Header set Cache-Control "public"
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
Header unset Last-Modified
</FilesMatch>

... тогда что, если я обновлю какой-либо файл CSS или изображение или другие файлы, будет ли браузер пользователей по-прежнему использовать версию кэша до истечения срока ее действия (год спустя)?

Спасибо

Answer 1

Ваши css, js и файлы изображений никогда не будут кэшироваться, так как вы устанавливаете дату в прошлом.

Я предполагаю, что это ошибка, и вы намеревались установить ее на год в будущемЭто одна из причин, по которой максимальный срок более истекает.

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

Существует два возможных подхода к решению проблемы.возможность снижения риска застоя.Один из них заключается в том, чтобы установить гораздо меньшее время истечения и использовать электронные теги и даты изменения, чтобы после истечения этого срока вы могли отправить 304, если нет изменений, поэтому серверу нужно отправить только несколько байтов, а не всеentity.

Другой способ - сохранить срок действия в году, но изменить URI, используемый при изменении.Это может быть полезно в случае, например, большого файла, который используется почти на каждой странице вашего сайта.Это требует, чтобы вы изменили все ссылки на этот ресурс, когда он действительно изменяется (потому что вы по сути меняете использование нового ресурса), что может быть неудобным и поэтому рекомендуется в качестве оптимизации только в некоторых случаях горячей точки.Если файл игнорирует атрибуты запроса (например, он просто подается прямо из файла), браузер этого не узнает, поэтому вы можете использовать что-то вроде /scripts/bigScript.js?version=1.2.3 и затем изменить на /scripts/bigScript.js?version=1.2.4 при изменении bigScript.js.Это не повлияет на bigScript.js, но заставит браузер получить новый файл, поскольку он знает, что это совершенно другой ресурс.

Answer 2

Да, ответ с датой истечения срока действия в будущем будет считаться свежим до даты истечения срока действия:

В поле заголовка объекта Expires указывается дата / время, после которого ответ считается устаревшим. [...]

Наличие поля заголовка Expires со значением даты в будущем в ответе, который в противном случае по умолчанию не кэшируется, указывает на то, что ответ кэшируется, если иное не указано в поле заголовка Cache-Control ( раздел 14,9 ).

Обратите внимание, что дата истечения более одного года в будущем может интерпретироваться как никогда не истекает :

Чтобы пометить ответ как «никогда не истекает», сервер отправителя отправляет дату истечения срока действия примерно через год с момента отправки ответа. Серверы HTTP / 1.1 НЕ ДОЛЖНЫ отправлять даты окончания срока действия более одного года в будущем.

Таким образом, если в кеше хранится ответ, он, вероятно, примет ответ из кеша даже без повторной проверки кэшированного ответа перед его отправкой.

Теперь, если вы измените ресурс, который уже хранится в кешах и еще свеж, нет способа сделать их недействительными :

[…] хотя они могут оставаться «свежими», они не точно отражают то, что сервер отправителя вернул бы для нового запроса на этот ресурс.

Протокол HTTP не может гарантировать, что все такие записи кэша помечены как недействительные. Например, запрос, вызвавший изменение на исходном сервере, возможно, не прошел через прокси, где хранится запись в кэше.

Это причина того, почему такие бесконечные ресурсы используют уникальный номер версии в URL (например, style-v123.css), который изменяется при каждом обновлении. Это также то, что я рекомендую в этом случае.

Кстати, объявление ответа с помощью Cache-Control как public ничего не делает в этом случае. Это используется только в том случае, если ответ, требующий авторизации, должен быть кэширован:

public - указывает, что ответ МОЖЕТ быть кеширован любым кешем, даже если он обычно не кешируется или кешируется только в не кешируемом кеше. (См. Также Авторизация, , раздел 14.8 , для получения дополнительной информации.)

Для получения дополнительной информации о кэшировании HTTP:

• Спецификация HTTP 1.1 - Кэширование в HTTP
• Учебник Марка Ноттингема по кэшированию