Что является функцией, “Варьируйтесь: Принять” HTTP-заголовок?
Я использую PHP для генерации динамических Веб-страниц. Как указано на следующем учебном руководстве (см. ссылку ниже), тип MIME документов XHTML должен быть "application/xhtml+xml", когда $ _SERVER ['HTTP_ACCEPT'] позволяет его. Так как можно служить той же странице с 2 различными ПАНТОМИМАМИ ("application/xhtml+xml" и "текст/HTML"), необходимо установить "Варьироваться" HTTP-заголовок для "Принятия". Это поможет кэшу на прокси.
Ссылка: http://keystonewebsites.com/articles/mime_type.php
Теперь я не уверен в импликации: заголовок ('Варьируйтесь: Примите'); я не действительно уверен в том, какой 'Варьируйтесь: Примите', точно сделает...
Единственное объяснение, которое я нашел:
После заголовка Типа контента Варьироваться заголовок отправляется в (если я понимаю, это правильно) говорят промежуточным кэшам, как прокси-серверы, что тип контента документа варьируется в зависимости от возможностей клиента, который запрашивает документ. http://www.456bereastreet.com/archive/200408/content_negotiation/
Любой может дать мне "реальное" объяснение этого заголовка (с тем значением). Я думаю, что понимаю вещи как: Варьируйтесь: принятый закодированный, где кэш на прокси мог быть основан на кодировании подаваемой страницы, но я не понимаю: Варьируйтесь: Принять
2 ответа
Заголовок
cache controll- это основной механизм, с помощью которого HTTP-сервер сообщает кэширующему прокси-серверу "свежесть" ответа. (т.е. как/долго хранить ответ в кэше)В некоторых ситуациях директивы
cache-controlнедостаточны. Обсуждение в рабочей группе HTTP архивируется здесь, описывая страницу, которая изменяется только с помощью языка. Это не корректный вариант использования различного заголовка, но контекст ценен для нашего обсуждения. (Хотя я считаю, что заголовок Vary в этом случае решит проблему, есть и лучший способ). С этой страницы:
Vary- это строго для тех случаев, когда для прокси-сервера нецелесообразно или слишком сложно воспроизвести то, что мог бы сделать сервер.
- RFC2616 "Определения поля заголовка" описывает использование заголовка с точки зрения сервера, RFC2616 "Кэширование обговоренных ответов" с точки зрения прокси-сервера с точки зрения кэширования. Он предназначен для указания набора заголовков HTTP-запросов, определяющих уникальность запроса.
Извлеченный пример:
Ваш HTTP-сервер имеет большую целевую страницу. У вас есть две немного разные страницы с одним и тем же URL, в зависимости от того, был ли пользователь там раньше. Вы различаете запросы и "количество посещений" пользователя на основе Cookie-файлов. Но -- поскольку целевая страница вашего сервера настолько велика, вы хотите, чтобы промежуточные прокси кэшировали ответ, если это возможно.
URL, Last-Modified и Cache-Control заголовки недостаточны, чтобы дать такое представление о кэширующем прокси, но если вы добавите Vary: Cookie, кэш-движок добавит заголовок Cookie в свои решения по кэшированию.
Наконец, для небольшого трафика, динамических веб-сайтов -- я всегда находил простое Cache-Control: no-cache, no-store и Pragma: no-cache достаточным.
Правка -- для более точного ответа на вопрос: заголовок 'Accept' HTTP-запроса определяет Типы Контентов, которые может обрабатывать клиент. Если у вас есть две копии одного и того же содержимого по одному и тому же URL, отличающиеся только типом Content-Type, то используйте Vary: Принятие может быть уместным.
Обновление 11 сентября 12:
Я включаю пару ссылок, которые появились в комментариях с момента первоначального размещения этого комментария. Они оба являются отличным ресурсом для реальных примеров (и проблем) с Vary: Примите; если вы читаете этот ответ, то вам нужно прочитать и эти ссылки.
Первая, из выдающегося EricLaw, о поведении Internet Explorer с заголовком Vary: и некоторых проблемах, которые он представляет для разработчиков: Vary Header предотвращает кэширование в IE. Короче говоря, IE (pre IE9) не кэширует содержимое, использующее Vary header, потому что кэш запросов не включает заголовки HTTP запросов. EricLaw (Эрик Лоуренс в реальном мире) является менеджером программ в команде IE.
Второй - от Эрана Медана, и представляет собой продолжающееся обсуждение неожиданного поведения Vary в Chrome: Поддержка не обрабатывает заголовок Vary правильно . Это связано с поведением IE, за исключением того, что разработчики Chrome использовали другой подход - хотя, похоже, это не было преднамеренным выбором.
. Вари: Accept просто говорит, что ответ был сгенерирован на основе заголовка Accept в запросе. Запрос с другим заголовком Accept может получить другой ответ.
(Вы видите, что связанный PHP код смотрит на $HTTP_ACCEPT. Это значение заголовка Accept request header.)
To HTTP caches, это означает, что ответ должен быть кэширован с особой осторожностью. Это будет действительное совпадение только для более поздних запросов с точно таким же заголовком Принять.
Теперь это имеет значение только в том случае, если страница кэшируется в первую очередь. По умолчанию PHP-страницы не кэшируются. PHP-страница может пометить вывод как кэшируемый, отправив определенные заголовки (Expires, например). Но будет ли это и как это сделать - другой вопрос.