2016-05-16 6 views
4

Я настроить кэш браузера для статического сайта с помощью файла .htaccess путем установки:Как настроить ETag с кэшированием браузера

# BROWER CACHING - 1 Day for images 
<filesMatch ".(jpg|jpeg|gif|ico)$"> 
Header set Cache-Control "max-age=86400, public" 
</filesMatch> 

Я в порядке с этими изображениями, имеющий кэш 1 день, но часто меняются сайты, поэтому я не хочу кэшировать файлы CSS и JS.

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

  1. Я правильно понял ETag?
  2. Как его настроить? Я огляделся, но не смог найти никакой информации о его конфигурации.

ответ

0

ETAG не является самым важным атрибутом. Основной атрибут, который вам не хватает, истекает. Я на 100% уверен, кеш браузера будет работать без etag. Проверьте приведенную ниже конфигурацию на http://pisrs.si. Как проверить? Hit F12 в браузере, перейдите на вкладку сети, посмотрите, как извлекаются ресурсы, сравните с вашим сайтом. Ресурсы localhost кэшируются по-разному. Проверьте информацию о своем браузере.

Ниже приведена рабочая конфигурация из основного домена, работающего. Убедитесь, что у вас есть необходимые моды.

<IfModule mod_mime.c> 
    AddType text/css .css 
    AddType application/x-javascript .js 
    AddType image/bmp .bmp 
    AddType image/gif .gif 
    AddType application/x-gzip .gz .gzip 
    AddType image/x-icon .ico 
    AddType image/jpeg .jpg .jpeg .jpe 
    AddType image/png .png 
    AddType application/x-font-ttf .ttf .ttc 
    AddType application/zip .zip 
</IfModule> 
<IfModule mod_expires.c> 
    ExpiresActive On 
    ExpiresByType text/css A31536000 
    ExpiresByType application/x-javascript A31536000 
    ExpiresByType application/javascript A31536000 
    ExpiresByType text/javascript A31536000 
    ExpiresByType text/x-js A31536000 
    ExpiresByType image/bmp A31536000 
    ExpiresByType image/gif A31536000 
    ExpiresByType application/x-gzip A31536000 
    ExpiresByType image/x-icon A31536000 
    ExpiresByType image/jpeg A31536000 
    ExpiresByType application/x-font-otf A31536000 
    ExpiresByType image/png A31536000 
    ExpiresByType application/x-font-ttf A31536000 
    ExpiresByType application/zip A31536000 
</IfModule> 
<IfModule mod_deflate.c> 
    <IfModule mod_headers.c> 
     Header append Vary User-Agent env=!dont-vary 
    </IfModule> 
     AddOutputFilterByType DEFLATE text/html text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/plain image/x-icon image/png image/gif 
    <IfModule mod_mime.c> 
     # DEFLATE by extension 
     AddOutputFilter DEFLATE js css htm html xml png gif 
    </IfModule> 
</IfModule> 
<FilesMatch "\.(gif|ico|jpg|jpeg|png|GIF|ICO|JPG|JPEG|PNG|css|js|woff|CSS|JS|WOFF|ttf|TTF)$"> 
    <IfModule mod_headers.c> 
     Header unset Set-Cookie 
     Header set Cache-Control "max-age=31536000, public" 
    </IfModule> 
</FilesMatch> 
2

Вы должны использовать либо FileETag MTime Size или Header unset Etag и FileEtag none. Не используйте оба (Create ETag и Remove ETag) и выберите только тот, который лучше всего работает на вашем конкретном сервере.

# Create the ETag (entity tag) response header field 
FileETag MTime Size 

или

# Remove the ETag (entity tag) response header field 
Header unset ETag 
FileETag none 
-1

HTTP имеет несколько features related to caching, и они применяются как агента пользователя (браузера) кэша и прокси-кэшей (будь то прозрачный или нет, например, прокси-сервер в сети клиента или обратный прокси-сервер сидя рядом с сервером). Эти функции входят в две группы: expiration (может полностью предотвратить запрос) и validation (может предотвратить передачу данных).

Entity tag (ETag) является одной из этих функций и относится к группе валидации. Другой в этой группе - это последнее время модификации (Last-Modified). Тэг Entity допускает недействительность кеша из-за изменения содержимого вместо более позднего последнего времени модификации. Подробнее о how entity tag works в Википедии. Короче говоря, типичное использование является:

  1. Сервер добавляет ETag заголовок ответа, содержащего ресурс обслуживается.

  2. Клиент кэширует ресурс и запоминает его тег объекта (значение ETag).

  3. В следующий раз, когда клиенту нужен ресурс, он запрашивает его с сервера условно. В запросе он содержит заголовок If-None-Match, содержащий тег объекта.

  4. Если ресурс изменен (тег объекта в If-None-Match считается устаревшим на сервере), сервер отправляет ответ, содержащий текущую версию ресурса (и новый тег объекта), иначе он просто отвечает 304 Not Modified и не утруждайте себя отправкой ресурса.

Для статических файлов (ни создается динамически с помощью CGI сценария или так, на каждый запрос), Apache может быть сконфигурирован для формирования ETag через FileETag directive. По умолчанию, без внесения каких-либо изменений в конфигурацию, Apache будет генерировать ETag, и его значение будет основано на последнем времени модификации файла (mtime) и размере в Apache 2.4. В Apache 2.3.14 по умолчанию используется также номер индекса inode.

Если файл обслуживается динамически, Apache не может сгенерировать ETag, поскольку он не знает сведений о том, как генерируется ресурс, который будет кэшироваться. Для сценария необходимо установить ETag и обработать If-None-Match. Например. в mod_perl часть If-None-Match может обрабатываться с использованием Apache2::Request::meets_conditions, которая реализует обработку условных запросов HTTP/1.1 в целом.

Если вы хотите полагаться исключительно на ETag, вам необходимо отключить другие функции проверки и механизм истечения срока действия. Установите Cache-Control: max-age=0, must-revalidate и Expires: 0, чтобы принудительно повторить проверку элементов кэша (т. Е. Всегда делать запрос). Вы также можете удалить заголовок Last-Modified из ответов, но HTTP/1.1 advises against that, in general.

Для сравнения Last-Modified и ETag см них:

Обратите внимание, что Last-Modified is seen as a HTTP/1.0 compatibility feature. ETag может содержать одно и то же значение и работать точно так же (кроме If-None-Match вместо If-Modified-Since).

В качестве побочного примечания я хотел бы добавить, что предлагаемый стандарт RFC 7232 существует и связан с деталями тегов сущностей и условных запросов. См. Его приложение A для changes it introduces from HTTP/1.1.

2

ETags - это всего лишь уникальный непрозрачный тег, вы не можете сравнивать их, кроме равенства, поэтому, если у вас есть 2 ETags для одного и того же ресурса (например, URI), вы не можете определить, какой ресурс является более новым. Для этого вам нужен заголовок Last-Modified.

Даже заголовок Last-Modified является проблематичным, так как он имеет только разрешение до 1 с, а на сильно измененных сайтах (например, в популярных блогах) вполне возможно, что кэш имеет несколько представлений файла с различными ETags и то же самое последнее модифицированное значение. Это позор, который они не считают нужным, чтобы сделать ETags монотонно увеличивающимися, чтобы их можно было сравнить.

ETag используется в условных запросах с заголовком If-None-Match для GET и If-Match для PUT, и в первом случае сервер должен возвращать полное тело, только если ни один из ETag (-ов) не был предоставлен сопоставить текущий ETag для ресурса (он изменился), а во втором случае (для PUT или PATCH), только если он соответствует, поэтому вы работаете над правильной версией.

И ETag, и Last-Modified являются кешем валидатор заголовки. Большая часть преимуществ кеширования связана с концепцией свежесть. Валидаторы позволяют проверить, действительно ли имеющаяся у вас версия, но все равно требуется сделать запрос на сервер. Все, что вы можете сэкономить, это передача полезной нагрузки, и для многих вещей в наши дни это просто не стоит.

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

+0

Я не согласен. В нашем прокси-кеше было бы очень полезно убрать из рассмотрения представления, основанные на сравнении Etag. – Adrien

 Смежные вопросы

  • Нет связанных вопросов^_^