caching http-заголовки - Какова функция HTTP-заголовка «Vary:Accept»?





заголовок max-age=0 (5)


На самом деле в ближайшее время (и уже в Chrome) появилось значительное количество новых функций, которые делают заголовок Vary чрезвычайно полезным. Например, рассмотрите подсказку клиента . Например, при использовании в сочетании с изображениями подсказка клиента позволяет серверу оптимизировать ресурсы, такие как изображения, в зависимости от:

  • Ширина изображения
  • Ширина видового экрана
  • Тип кодирования, поддерживаемый браузером (думаю, WebP)
  • Вниз (по существу, скорость сети)

Таким образом, сервер, который поддерживает эти функции, должен указывать заголовок Vary .

Chrome рекламирует поддержку WebP, устанавливая «image / webp» как часть заголовка Vary для каждого запроса. Таким образом, сервер может переписать образ как WebP, если браузер поддерживает его, поэтому прокси-сервер должен будет проверить заголовок, чтобы не кэшировать образ WebP, а затем обслуживать его в браузере, который не поддерживает WebP. Очевидно, если ваш сервер этого не сделает, это не имеет значения. Так как ответ сервера зависит от заголовка запроса принятия, ответ должен включать это, чтобы не путать прокси:

Vary: Accept

Другим примером может быть ширина изображения. В мобильном браузере заголовок Width может быть довольно маленьким для отзывчивого изображения, по сравнению с тем, что было бы, если смотреть с браузера рабочего стола. Таким образом, в этом случае Width будет добавлен в заголовок Vary что важно для прокси-сервера, чтобы не кэшировать небольшую мобильную версию и не использовать ее для настольных браузеров, или наоборот. В этом случае заголовок может включать:

Vary: Accept, Width

Или в том случае, если сервер поддерживает все спецификации подсказок для клиента, заголовок будет выглядеть примерно так:

Vary: Accept, DPR, Width, Save-Data, Downlink

Я использую PHP для создания динамических веб-страниц. Как указано в следующем учебном пособии (см. Ссылку ниже), MIME-тип документов XHTML должен быть «application / xhtml + xml», когда это разрешает $ _SERVER ['HTTP_ACCEPT']. Поскольку вы можете обслуживать одну и ту же страницу с двумя разными MIME («application / xhtml + xml» и «text / html»), вы должны установить HTTP-заголовок «Vary» в «Accept». Это поможет кешу прокси.

Ссылка: http://keystonewebsites.com/articles/mime_type.php

Теперь я не уверен в значении: header ('Vary: Accept'); Я не совсем уверен в том, что «Vary: Accept» будет точно ...

Единственное объяснение, которое я нашел, это:

После заголовка Content-Type заголовок Vary отправляется (если я его правильно понимаю) сообщает промежуточным кэшам, например прокси-серверам, о том, что тип содержимого документа зависит от возможностей клиента, который запрашивает документ. http://www.456bereastreet.com/archive/200408/content_negotiation/

Любой может дать мне «реальное» объяснение этого заголовка ( с этим значением ). Я думаю, что я понимаю такие вещи, как: Vary: Accept-Encoding, где кеш на прокси-серверах может основываться на кодировке обслуживаемой страницы, но я не понимаю: Vary: Accept




Vary: Accept просто говорит, что ответ был сгенерирован на основе заголовка Accept в запросе. Запрос с другим заголовком Accept может получить другой ответ.

(Вы можете видеть, что связанный PHP-код смотрит на $HTTP_ACCEPT . Это значение заголовка запроса принятия.)

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

Теперь это имеет значение только в том случае, если страница является кешируемой в первую очередь. По умолчанию страницы PHP не являются. Страница PHP может пометить вывод как кешируемый путем отправки определенных заголовков (например, Expires ). Но нужно ли и как это сделать, это другой вопрос.







  • Заголовок cache-control является основным механизмом для HTTP-сервера, который указывает кэширующему прокси-серверу «свежесть» ответа. (т. е. как / если долго хранить ответ в кеше)

  • В некоторых ситуациях директивы cache-control недостаточны. Здесь обсуждается обсуждение рабочей группы HTTP here, описывающее страницу, которая изменяется только на языке. Это неправильный вариант использования для заголовка переменной, но этот контекст является ценным для нашего обсуждения. (Хотя я считаю, что заголовок Vary разрешит проблему в этом случае, есть лучший способ.) С этой страницы:

Vary строго для тех случаев, когда он безнадежен или чрезмерно усложнен для прокси-сервера для репликации того, что сделает сервер.

  • Vary описывает использование заголовка с точки зрения сервера, RFC2616 «Кэширование согласованных ответов» с точки зрения прокси-сервера. Он предназначен для указания набора заголовков HTTP-запросов, которые определяют уникальность запроса.

Надуманный пример:

У вашего HTTP-сервера есть большая целевая страница. У вас есть две несколько разные страницы с одинаковым URL-адресом, в зависимости от того, был ли пользователь раньше. Вы различаете запросы и пользовательский «счет посещений» на основе файлов cookie. Но - так как целевая страница вашего сервера настолько велика, вы хотите, чтобы посреднические прокси кэшировали ответ, если это возможно.

Заголовки URL, Last-Modified и Cache-Control недостаточно для того, чтобы дать это представление прокси-серверу кеширования, но если вы добавите Vary: Cookie , механизм кэширования добавит заголовок Cookie к его решениям кэширования.

Наконец, для небольшого трафика динамические веб-сайты - я всегда нашел простой Cache-Control: no-cache, no-store и Pragma: no-cache достаточно.

Изменить - чтобы более точно ответить на ваш вопрос: заголовок HTTP-запроса «Принять» определяет типы контента, которые клиент может обработать. Если у вас две копии одного и того же контента по одному и тому же URL-адресу, отличающиеся только содержимым-типом, то использование Vary: Accept может быть подходящим.

Обновление 11 сентября 12:

Я включаю пару ссылок, которые появились в комментариях, поскольку этот комментарий был первоначально опубликован. Они оба отличные ресурсы для реальных примеров (и проблем) с помощью Vary: Accept; Если вы читаете этот ответ, вам нужно также прочитать эти ссылки.

Первый, от выдающегося EricLaw, от поведения Internet Explorer с заголовком Vary и некоторыми проблемами, которые он представляет разработчикам: blogs.msdn.com/ieinternals/archive/2009/06/17/… . Короче говоря, IE (pre IE9) не кэширует какой-либо контент, который использует заголовок Vary, потому что кэш запросов не включает заголовки HTTP-запроса. EricLaw (Эрик Лоуренс в реальном мире) является менеджером программ в команде IE.

Второй - от Eran Medan, и это постоянное обсуждение неожиданного поведения, связанного с Vary, в Chrome: Backing не обрабатывает заголовок Vary правильно . Это связано с поведением IE, за исключением того, что разработчики Chrome использовали другой подход, хотя он, похоже, не был преднамеренным выбором.




ASP.NET 2 и службы отчетов SQL Server 2005 имеют ограничение в 2028. Я нашел это с большим трудом, когда мой динамический генератор URL-адресов не передавал некоторые параметры в отчет за пределами этой точки. Это было в Internet Explorer 8.







http caching proxy