stringtranslate.com

Список полей заголовка HTTP

Поля заголовка HTTP представляют собой список строк , отправляемых и получаемых как клиентской программой, так и сервером при каждом HTTP-запросе и ответе. Эти заголовки обычно невидимы для конечного пользователя и обрабатываются или регистрируются только серверными и клиентскими приложениями. Они определяют, как кодируется информация, отправляемая/полученная через соединение (как в Content-Encoding ), проверка сеанса и идентификация клиента (как в файлах cookie браузера , IP-адресе, пользовательском агенте ) или их анонимность (маскировка VPN или прокси-сервера). , подмена пользовательского агента), то, как сервер должен обрабатывать данные (как в случае Do-Not-Track ), возраст (время нахождения данных в общем кеше ) загружаемого документа, среди прочего.

Общий формат

В HTTP версии 1.x поля заголовка передаются после строки запроса (в случае HTTP-сообщения запроса) или строки ответа (в случае ответного HTTP-сообщения), которая является первой строкой сообщения. Поля заголовка представляют собой пары «ключ-значение», разделенные двоеточием, в формате строки открытого текста , заканчивающиеся последовательностью символов возврата каретки (CR) и перевода строки (LF). Конец раздела заголовка обозначается пустой строкой поля, что приводит к передаче двух последовательных пар CR-LF. Раньше длинные строки можно было складывать в несколько строк; Строки продолжения обозначаются наличием пробела (SP) или горизонтальной табуляции (HT) в качестве первого символа следующей строки. Это свертывание объявлено устаревшим в RFC 7230. [1]

Вместо этого HTTP/2 [2] и HTTP/3 используют двоичный протокол , в котором заголовки кодируются в один HEADERSи ноль или более CONTINUATIONкадров с использованием HPACK [3] (HTTP/2) или QPACK (HTTP/3), которые оба обеспечивают эффективную сжатие заголовка. Строка запроса или ответа из HTTP/1 также была заменена несколькими полями псевдозаголовка, каждое из которых начинается с двоеточия ( :).

Имена полей

Основной набор полей стандартизирован Инженерной группой Интернета (IETF) в RFC  9110 и 9111. Имена полей, поля заголовков и хранилище предварительных регистраций поддерживаются IANA . Дополнительные имена полей и допустимые значения могут быть определены каждым приложением.

Имена полей заголовка не чувствительны к регистру. [4] В этом отличие от имен методов HTTP (GET, POST и т. д.), которые чувствительны к регистру. [5]

HTTP/2 налагает некоторые ограничения на определенные поля заголовка (см. ниже).

Нестандартные поля заголовка обычно обозначались префиксом к имени поля, X-но это соглашение было устарело в июне 2012 года из-за неудобств, которые оно вызывало, когда нестандартные поля становились стандартными. [6] Предыдущее ограничение на использование Downgraded-было снято в марте 2013 года. [7]

Значения полей

Некоторые поля могут содержать комментарии (например, в полях User-Agent, Server, Via), которые могут быть проигнорированы программным обеспечением. [8]

Многие значения полей могут содержать пару «ключ-значение» качества ( q ), разделенную знаком равенства , определяющим вес, используемый при согласовании содержимого . [9] Например, браузер может указать, что он принимает информацию на немецком или английском языке, причем немецкий является предпочтительным, установив значение qde выше, чем значение en, следующим образом:

Accept-Language: de; q=1.0, en; q=0.5

Ограничения по размеру

Стандарт не накладывает ограничений на размер каждого имени или значения поля заголовка, а также на количество полей. Однако большинство серверов, клиентов и прокси-программ налагают некоторые ограничения по практическим соображениям и соображениям безопасности. Например, сервер Apache 2.3 по умолчанию ограничивает размер каждого поля до 8190 байт, и в одном запросе может быть не более 100 полей заголовка. [10]

Поля запроса

Стандартные поля запроса

Общие нестандартные поля запроса

Поля ответа

Стандартные поля ответа

Распространенные нестандартные поля ответа

Эффекты выбранных полей

Как избежать кэширования

Если веб-сервер отвечает, Cache-Control: no-cacheто веб-браузер или другая система кэширования (промежуточные прокси-серверы) не должны использовать ответ для удовлетворения последующих запросов без предварительной проверки на исходном сервере (этот процесс называется проверкой). Это поле заголовка является частью HTTP версии 1.1 и игнорируется некоторыми кэшами и браузерами. Это можно смоделировать, установив в Expiresполе заголовка HTTP версии 1.0 значение времени, предшествующее времени ответа. Обратите внимание, что no-cache не дает браузеру или прокси-серверам указаний о том, следует ли кэшировать контент. Он просто сообщает браузеру и прокси-серверам проверить содержимое кэша на сервере перед его использованием (это делается с помощью атрибутов If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, упомянутых выше). Таким образом, отправка значения отсутствия кэша дает браузеру или прокси-серверу указание не использовать содержимое кэша просто на основе «критериев свежести» содержимого кэша. Другой распространенный способ предотвратить показ старого контента пользователю без проверки Cache-Control: max-age=0. Это сообщает пользовательскому агенту, что контент устарел и его следует проверить перед использованием.

Поле заголовка Cache-Control: no-storeпредназначено для того, чтобы дать приложению браузера указание сделать все возможное, чтобы не записывать его на диск (т. е. не кэшировать).

Запрос на то, чтобы ресурс не кэшировался, не является гарантией того, что он не будет записан на диск. В частности, определение HTTP/1.1 проводит различие между хранилищами истории и кэшами. Если пользователь возвращается на предыдущую страницу, браузер все равно может показать вам страницу, которая была сохранена на диске в хранилище истории. Это правильное поведение согласно спецификации. Многие пользовательские агенты демонстрируют различное поведение при загрузке страниц из хранилища истории или кэша в зависимости от протокола HTTP или HTTPS.

Поле Cache-Control: no-cacheзаголовка HTTP/1.1 также предназначено для использования в запросах клиента. Это средство, с помощью которого браузер сообщает серверу и всем промежуточным кэшам, что ему нужна свежая версия ресурса. Поле Pragma: no-cacheзаголовка, определенное в спецификации HTTP/1.0, имеет ту же цель. Однако он определяется только для заголовка запроса. Его значение в заголовке ответа не указано. [76] Поведение Pragma: no-cacheв ответе зависит от реализации. Хотя некоторые пользовательские агенты обращают внимание на это поле в ответах, [77] HTTP/1.1 RFC специально предостерегает от использования такого поведения.

Смотрите также

Рекомендации

  1. ^ «Разбор полей». Протокол передачи гипертекста (HTTP/1.1): синтаксис сообщений и маршрутизация. Июнь 2014. сек. 3.2.4. дои : 10.17487/RFC7230 . РФК 7230.
  2. ^ HTTP/2. Июнь 2022 г. doi : 10.17487/RFC9113 . РФК 9113.
  3. ^ Пеон, Р.; Руэллан, Х. (май 2015 г.). «HPACK: сжатие заголовка для HTTP/2». IETF . дои : 10.17487/RFC7541 . Проверено 13 декабря 2021 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  4. ^ «Имена полей». HTTP-семантика. Июнь 2022. сек. 5.1. дои : 10.17487/RFC9110 . РФК 9110.
  5. ^ «Методы: Обзор». HTTP-семантика. Июнь 2022. сек. 9.1. дои : 10.17487/RFC9110 . РФК 9110.
  6. ^ Целевая группа по интернет-инжинирингу (1 июня 2012 г.). «RFC 6648». дои : 10.17487/RFC6648 . Проверено 12 ноября 2012 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  7. ^ «Заголовки сообщений». Яна.орг. 11 июня 2014 года . Проверено 12 июня 2014 г.
  8. ^ «Комментарии». HTTP-семантика. Июнь 2022. сек. 5.6.5. дои : 10.17487/RFC9110 . РФК 9110.
  9. ^ «Ценности качества». HTTP-семантика. Июнь 2022. сек. 12.4.2. дои : 10.17487/RFC9110 . РФК 9110.
  10. ^ «ядро — HTTP-сервер Apache» . httpd.apache.org. Архивировано из оригинала 9 мая 2012 года . Проверено 13 марта 2012 г.
  11. ^ abc RFC 3229. doi : 10.17487/RFC3229 .
  12. ^ abc «Обмен ресурсами между источниками» . Проверено 24 июля 2017 г.
  13. ^ ab «Заголовок соединения». HTTP-семантика. Июнь 2022. сек. 7.6.1. дои : 10.17487/RFC9110 . РФК 9110.
  14. ^ abcdefghi «Поля заголовка, специфичные для соединения». HTTP/2. Июнь 2022. сек. 8.2.2. дои : 10.17487/RFC9113 . РФК 9113.
  15. ^ ab «Изменения по сравнению с RFC 2616». Протокол передачи гипертекста (HTTP/1.1): семантика и содержание. Июнь 2014. сек. Б. дои : 10.17487/RFC7231 . РФК 7231.
  16. ^ Петерссон, А.; Нильссон, М. (июнь 2014 г.). «Пересылаемое расширение HTTP: Введение». IETF . дои : 10.17487/RFC7239 . Проверено 7 января 2016 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  17. ^ "Хост и: авторитет" . HTTP-семантика. Июнь 2022. сек. 7.2. дои : 10.17487/RFC9110 . РФК 9110.
  18. ^ «Запросить поля псевдозаголовка» . HTTP/2. Июнь 2022. сек. 8.3.1. дои : 10.17487/RFC9113 . РФК 9113.
  19. ^ «Заголовки сообщений». www.iana.org . Проверено 26 ноября 2018 г.
  20. ^ «Поле заголовка HTTP2-Настройки» . Протокол передачи гипертекста версии 2 (HTTP/2). сек. 3.2.1. дои : 10.17487/RFC7540 . РФК 7540.
  21. ^ ab «Заголовок предупреждения». HTTP-кэширование. Июнь 2022. сек. 5.5. дои : 10.17487/RFC9111 . РФК 9111.
  22. ^ «Обновление небезопасных запросов — рекомендация кандидата W3C» . W3C . 8 октября 2015 г. Проверено 14 января 2016 г.
  23. ^ "Заголовок "X-Requested-With" - Стаутнер" .
  24. ^ «Попробуйте HTTP-заголовок «Не отслеживать»» . Проверено 31 января 2011 г.
  25. ^ «Защита от веб-слежения: минимальные стандарты и возможности для инноваций» . Проверено 24 марта 2011 г.
  26. ^ IETF «Не отслеживать»: универсальный отказ от стороннего веб-отслеживания, 7 марта 2011 г.
  27. ^ Выражение предпочтений отслеживания W3C (DNT), 26 января 2012 г.
  28. ↑ Амос Джеффрис (2 июля 2010 г.). «SquidFaq/ConfiguringSquid — Wiki веб-прокси Squid» . Проверено 10 сентября 2009 г.
  29. ^ Фонд программного обеспечения Apache. «mod_proxy — HTTP-сервер Apache версии 2.2» . Проверено 12 ноября 2014 г.
  30. ↑ Дэйв Стейнберг (10 апреля 2007 г.). «Как мне настроить мой SSL-сайт для работы с балансировщиком нагрузки GeekISP?» . Проверено 30 сентября 2010 г.
  31. ^ «Помощь в обеспечении безопасной связи: клиент-сервер переднего плана» . 27 июля 2006 года . Проверено 23 апреля 2012 г.
  32. ^ «Спецификация сервера API OpenSocial Core 2.5.1» . Проверено 8 октября 2014 г.
  33. ^ «Идентификатор устройства ATT» . Архивировано из оригинала 16 февраля 2012 года . Проверено 14 января 2012 г.
  34. ^ «Профиль WAP» . Проверено 14 января 2012 г.
  35. ^ де Бойн Поллард, Джонатан (2007). «Заголовок Proxy-Connection: является ошибкой в ​​том, как некоторые веб-браузеры используют HTTP» . Проверено 16 января 2018 г.
  36. ^ «Verizon внедряет постоянные файлы cookie для отслеживания мобильных клиентов в обход контроля конфиденциальности» . Фонд электронных границ . Проверено 19 января 2014 г.
  37. ^ «Проверка известных маяков уникальных идентификаторов AT&T, Verizon, Sprint, Bell Canada и Vodacom» . Проверено 19 января 2014 г.
  38. ^ Крейг Тимберг. «Verizon и AT&T отслеживают своих пользователей с помощью «суперкуки»». Вашингтон Пост . Проверено 19 января 2014 г.
  39. ^ «Защита от подделки межсайтовых запросов SAP» . САП СЭ . Проверено 20 января 2015 г.
  40. ^ «Защита от подделки межсайтовых запросов Django» . Джанго (веб-фреймворк) . Архивировано из оригинала 20 января 2015 года . Проверено 20 января 2015 г.
  41. ^ «Защита от подделки межсайтовых запросов Angular (XSRF)» . АнгулярJS . Проверено 20 января 2015 г.
  42. ^ «Идентификаторы HTTP-запросов». devcenter.heroku.com . Проверено 22 марта 2022 г.
  43. ^ «Значение идентификаторов корреляции» . Блог Rapid7 . 23 декабря 2016 года . Проверено 13 апреля 2018 г.
  44. ^ Хилтон, Питер. «Идентификаторы корреляции для микросервисных архитектур - Питер Хилтон». hilton.org.uk . Проверено 13 апреля 2018 г.
  45. ^ «API для сохранения данных, проект живого документа, отчет группы сообщества 2.1.1. Поле заголовка запроса на сохранение данных» . Группа сообщества инкубатора веб-платформы . 30 июня 2020 г. Проверено 5 марта 2021 г.
  46. ^ Участники MDN (3 марта 2023 г.). «Сек-ГПК». Веб-документы MDN . Проверено 12 марта 2023 г.
  47. ^ Дюссо, Л.; Снелл, Дж. (2010). «RFC 5789». дои : 10.17487/RFC5789. S2CID  42062521 . Проверено 24 декабря 2014 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  48. ^ Ноттингем, М.; Макманус, П.; Решке, Дж. (апрель 2016 г.). «Альтернативные службы HTTP». IETF. дои : 10.17487/RFC7838 . Проверено 19 апреля 2016 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  49. ^ Ноттингем, М.; Макманус, П.; Решке, Дж. (апрель 2016 г.). «Альтернативные службы HTTP, раздел 3». IETF. дои : 10.17487/RFC7838 . Проверено 8 июня 2017 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  50. ^ Решке, Дж. (2011). «RFC 6266». дои : 10.17487/RFC6266 . Проверено 13 марта 2015 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  51. ^ "Язык контента" . HTTP-семантика. Июнь 2022. сек. 8.5. дои : 10.17487/RFC9110 . РФК 9110.
  52. ^ Укажите каноническую версию URL-адреса, ответив HTTP-заголовком Link rel="canonical". Проверено: 9 февраля 2012 г.
  53. ^ Работа W3C P3P приостановлена
  54. ^ «Расширение закрепления открытого ключа для HTTP» . IETF . Проверено 17 апреля 2015 г.
  55. ^ «Повторить попытку после». HTTP-семантика. Июнь 2022. сек. 10.2.3. дои : 10.17487/RFC9110 . РФК 9110.
  56. ^ Росс, Д.; Гондром, Т. (2013). «Параметры X-Frame поля заголовка HTTP». IETF. дои : 10.17487/RFC7034 . Проверено 12 июня 2014 г. {{cite journal}}: Требуется цитировать журнал |journal=( помощь )
  57. ^ «Политика безопасности контента, уровень 2» . Проверено 2 августа 2014 г.
  58. ^ «Политика безопасности контента». W3C. 2012 . Проверено 28 апреля 2017 г.
  59. ^ "Ожидать-КТ". Сеть разработчиков Mozilla . Проверено 23 июля 2021 г.
  60. ^ "НЭЛ". Сеть разработчиков Mozilla . 2021 . Проверено 18 мая 2021 г.
  61. ^ «Политика разрешений». W3C. 2020 . Проверено 1 мая 2021 г.
  62. ^ «Я FLoCed?». ЭФФ. 2021 . Проверено 1 мая 2021 г.
  63. ^ «Определите заголовок обновления HTTP с помощью annevk · Запрос на извлечение № 2892 · Whatwg/html» . Гитхаб . 9 августа 2017 года . Проверено 17 апреля 2021 г.
  64. ^ "CSP: отчет" . Сеть разработчиков Mozilla . 2021 . Проверено 18 мая 2021 г.
  65. ^ RFC 9110: Семантика HTTP
  66. ^ "Время-разрешить-происхождение" . Сеть разработчиков Mozilla . Проверено 25 января 2018 г.
  67. ^ «Настройка серверов для Ogg Media». 26 мая 2014 года . Проверено 3 января 2015 г.
  68. ^ «Очистите отслеживание продолжительности и используйте зеркалирование для межпоточного доступа». Багзилла@Mozilla . Проверено 9 февраля 2024 г.
  69. ↑ Эрик Лоуренс (3 сентября 2008 г.). «Безопасность IE8, часть VI: обновление бета-версии 2» . Проверено 28 сентября 2010 г.
  70. ^ «Хостинг — Расширения Google Chrome — Код Google» . Проверено 14 июня 2012 г.
  71. ↑ ван Кестерен, Энн (26 августа 2016 г.). «Выбрать стандарт». ЧТОРГ . Архивировано из оригинала 26 августа 2016 года . Проверено 26 августа 2016 г.
  72. ^ «Заголовок ответа HTTP X-Redirect-By» . Проверено 29 мая 2021 г.
  73. ^ «Определение совместимости документов: указание режимов совместимости документов» . 1 апреля 2011 года . Проверено 24 января 2012 г.
  74. ^ «HTML Living Standard 4.2.5.3 Директивы Pragma, состояние X-UA-совместимости» . ЧТОРГ . 12 марта 2021 г. Проверено 14 марта 2021 г. Для метаэлементов с атрибутом http-equiv в состоянии X-UA-Compatible атрибут содержимого должен иметь значение, соответствующее строке ASCII без учета регистра ."IE=edge"
  75. ↑ Эрик Лоуренс (2 июля 2008 г.). «Безопасность IE8, часть IV: XSS-фильтр» . Проверено 30 сентября 2010 г.
  76. ^ "Прагме". HTTP-кэширование. Июнь 2022. сек. 5.4. дои : 10.17487/RFC9111 . РФК 9111.
  77. ^ «Как предотвратить кеширование в Internet Explorer». Майкрософт . 22 сентября 2011 года . Проверено 15 апреля 2015 г.

На момент редактирования в этой статье используется содержимое из раздела «Что такое HTTP-заголовок X-REQUEST-ID?» , автором которого является Стефан Кёгль из Stack Exchange, и которое лицензируется таким образом, что разрешает повторное использование в соответствии с лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License , но не в соответствии с GFDL . Все соответствующие условия должны быть соблюдены.

  1. ^ ab "Что такое http-заголовок X-REQUEST-ID?" . Проверено 20 марта 2022 г.

На момент редактирования в этой статье используется содержимое статьи «Почему платформа ASP.NET добавляет в ответы HTTP-заголовок X-Powered-By:ASP.NET?» , автором которого является Адриан Григоре из Stack Exchange, и который лицензируется таким образом, что разрешает повторное использование в соответствии с лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License , но не в соответствии с GFDL . Все соответствующие условия должны быть соблюдены.

  1. ^ «Почему платформа ASP.NET добавляет в ответы HTTP-заголовок X-Powered-By:ASP.NET? - Stack Overflow» . Проверено 20 марта 2022 г.

Внешние ссылки