stringtranslate.com

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

Поля заголовка HTTP представляют собой список строк , отправленных и полученных как клиентской программой, так и сервером при каждом запросе и ответе HTTP. Эти заголовки обычно невидимы для конечного пользователя и обрабатываются или регистрируются только сервером и клиентскими приложениями. Они определяют, как кодируется информация, отправленная/полученная через соединение (как в Content-Encoding ), проверку сеанса и идентификацию клиента (как в cookie-файлах браузера , IP-адресе, user-agent ) или их анонимность (маскировка VPN или прокси, подмена user-agent ), как сервер должен обрабатывать данные (как в 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, упомянутых выше). Таким образом, отправка значения no-cache указывает браузеру или прокси-серверу не использовать содержимое кэша, основываясь только на «критериях свежести» содержимого кэша. Другой распространенный способ предотвратить показ пользователю старого содержимого без проверки — Cache-Control: max-age=0. Это сообщает пользовательскому агенту, что контент устарел и его следует проверить перед использованием.

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

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

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

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

Ссылки

  1. ^ "Разбор полей". Протокол передачи гипертекста (HTTP/1.1): Синтаксис и маршрутизация сообщений. Июнь 2014 г., раздел 3.2.4. doi : 10.17487/RFC7230 . RFC 7230.
  2. ^ HTTP/2. Июнь 2022 г. doi : 10.17487/RFC9113 . RFC 9113.
  3. ^ Peon, R.; Ruellan, H. (май 2015 г.). "HPACK: Сжатие заголовков для HTTP/2". IETF . doi :10.17487/RFC7541 . Получено 13 декабря 2021 г. . {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  4. ^ "Имена полей". HTTP Semantics. Июнь 2022. раздел 5.1. doi : 10.17487/RFC9110 . RFC 9110.
  5. ^ "Методы: Обзор". HTTP Semantics. Июнь 2022. раздел 9.1. doi : 10.17487/RFC9110 . RFC 9110.
  6. ↑ Internet Engineering Task Force (1 июня 2012 г.). "RFC 6648". doi :10.17487/RFC6648 . Получено 12 ноября 2012 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  7. ^ "Заголовки сообщений". Iana.org. 11 июня 2014 г. Получено 12 июня 2014 г.
  8. ^ "Комментарии". HTTP Semantics. Июнь 2022. раздел 5.6.5. doi : 10.17487/RFC9110 . RFC 9110.
  9. ^ «Значения качества». HTTP Semantics. Июнь 2022. раздел 12.4.2. doi : 10.17487/RFC9110 . RFC 9110.
  10. ^ "core - Apache HTTP Server". Httpd.apache.org. Архивировано из оригинала 9 мая 2012 г. Получено 13 марта 2012 г.
  11. ^ abc RFC 3229. doi : 10.17487/RFC3229 .
  12. ^ abc "Cross-Origin Resource Sharing" . Получено 24 июля 2017 г. .
  13. ^ ab "Заголовок соединения". HTTP Semantics. Июнь 2022. раздел 7.6.1. doi : 10.17487/RFC9110 . RFC 9110.
  14. ^ abcdefgh «Поля заголовка, специфичные для соединения». HTTP/2. Июнь 2022 г. раздел 8.2.2. doi : 10.17487/RFC9113 . RFC 9113.
  15. ^ ab "Изменения по сравнению с RFC 2616". Протокол передачи гипертекста (HTTP/1.1): семантика и содержимое. Июнь 2014 г. раздел B. doi : 10.17487/RFC7231 . RFC 7231.
  16. ^ Петерссон, А.; Нильссон, М. (июнь 2014 г.). «Расширение перенаправленного HTTP: введение». IETF . doi :10.17487/RFC7239 . Получено 7 января 2016 г. . {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  17. ^ "Хост и :authority". HTTP Semantics. Июнь 2022. раздел 7.2. doi : 10.17487/RFC9110 . RFC 9110.
  18. ^ "Поля псевдозаголовка запроса". HTTP/2. Июнь 2022 г. раздел 8.3.1. doi : 10.17487/RFC9113 . RFC 9113.
  19. ^ "Заголовки сообщений". www.iana.org . Получено 26 ноября 2018 г. .
  20. ^ "HTTP2-Settings Header Field". Протокол передачи гипертекста версии 2 (HTTP/2). раздел 3.2.1. doi : 10.17487/RFC7540 . RFC 7540.
  21. ^ ab "Заголовок предупреждения". HTTP-кэширование. Июнь 2022 г. раздел 5.5. doi : 10.17487/RFC9111 . RFC 9111.
  22. ^ "Upgrade Insecure Requests - W3C Candidate Recommendation". W3C . 8 октября 2015 г. Получено 14 января 2016 г.
  23. ^ «Заголовок «X-Requested-With» – Стаутнер».
  24. ^ "Попробуйте HTTP-заголовок "Do Not Track"" . Получено 31 января 2011 г.
  25. ^ "Защита от веб-отслеживания: минимальные стандарты и возможности для инноваций" . Получено 24 марта 2011 г.
  26. ^ IETF Do Not Track: Универсальный отказ от стороннего веб-отслеживания 7 марта 2011 г.
  27. ^ Выражение предпочтения отслеживания W3C (DNT), 26 января 2012 г.
  28. ↑ Амос Джеффрис (2 июля 2010 г.). "SquidFaq/ConfiguringSquid - Squid Web Proxy Wiki" . Получено 10 сентября 2009 г.
  29. ^ Apache Software Foundation. "mod_proxy - Apache HTTP Server Version 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 Device ID". Архивировано из оригинала 16 февраля 2012 г. Получено 14 января 2012 г.
  34. ^ "WAP Profile" . Получено 14 января 2012 г. .
  35. ^ de Boyne Pollard, Jonathan (2007). "Заголовок Proxy-Connection: является ошибкой в ​​том, как некоторые веб-браузеры используют HTTP" . Получено 16 января 2018 г.
  36. ^ "Verizon внедряет постоянные файлы cookie для отслеживания мобильных клиентов, обходя средства контроля конфиденциальности". Electronic Frontier Foundation . Получено 19 января 2014 г.
  37. ^ "Проверка известных маяков уникального идентификатора AT&T, Verizon, Sprint, Bell Canada и Vodacom" . Получено 19 января 2014 г. .
  38. ^ Крейг Тимберг. «Verizon, AT&T отслеживают своих пользователей с помощью «суперкуки»». The Washington Post . Получено 19 января 2014 г.
  39. ^ "Защита от подделки межсайтовых запросов SAP". SAP SE . Получено 20 января 2015 г.
  40. ^ "Защита от подделки межсайтовых запросов Django". Django (веб-фреймворк) . Архивировано из оригинала 20 января 2015 г. Получено 20 января 2015 г.
  41. ^ "Защита от подделки межсайтовых запросов (XSRF) Angular". AngularJS . Получено 20 января 2015 г. .
  42. ^ "HTTP Request IDs". devcenter.heroku.com . Получено 22 марта 2022 г. .
  43. ^ "Значение идентификаторов корреляции". Блог Rapid7 . 23 декабря 2016 г. Получено 13 апреля 2018 г.
  44. ^ Хилтон, Питер (12 июля 2017 г.). "Идентификаторы корреляции для архитектур микросервисов - Питер Хилтон". hilton.org.uk . Получено 13 апреля 2018 г. .
  45. ^ "W3C Trace Context". w3c.org . Получено 19 июня 2024 г. .
  46. ^ "Save Data API Living Document Draft Community Group Report 2.1.1. Save-Data Request Header Field". Web Platform Incubator Community Group . 30 июня 2020 г. Получено 5 марта 2021 г.
  47. ^ Участники MDN (3 марта 2023 г.). "Sec-GPC". MDN Web Docs . Получено 12 марта 2023 г.
  48. ^ Dusseault, L.; Snell, J. (2010). "RFC 5789". doi :10.17487/RFC5789. S2CID  42062521 . Получено 24 декабря 2014 г. . {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  49. ^ Ноттингем, М.; Макманус, П.; Решке, Дж. (апрель 2016 г.). «Альтернативные службы HTTP». IETF. doi : 10.17487/RFC7838 . Получено 19 апреля 2016 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  50. ^ Ноттингем, М.; Макманус, П.; Решке, Дж. (апрель 2016 г.). «Альтернативные службы HTTP, раздел 3». IETF. doi : 10.17487/RFC7838 . Получено 8 июня 2017 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  51. ^ Решке, Дж. (2011). «RFC 6266». дои : 10.17487/RFC6266 . Проверено 13 марта 2015 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  52. ^ "Content-Language". HTTP Semantics. Июнь 2022. раздел 8.5. doi : 10.17487/RFC9110 . RFC 9110.
  53. ^ Укажите каноническую версию URL, ответив HTTP-заголовком Link rel="canonical" Получено: 2012-02-09
  54. ^ Работа W3C P3P приостановлена
  55. ^ "Расширение закрепления открытого ключа для HTTP". IETF . Получено 17 апреля 2015 г.
  56. ^ "Retry-After". Семантика HTTP. Июнь 2022 г. раздел 10.2.3. doi : 10.17487/RFC9110 . RFC 9110.
  57. ^ Росс, Д.; Гондром, Т. (2013). "HTTP Header Field X-Frame-Options". IETF. doi : 10.17487/RFC7034 . Получено 12 июня 2014 г. {{cite journal}}: Цитировать журнал требует |journal=( помощь )
  58. ^ "Политика безопасности контента, уровень 2" . Получено 2 августа 2014 г.
  59. ^ «Политика безопасности контента». W3C. 2012. Получено 28 апреля 2017 г.
  60. ^ "Expect-CT". Mozilla Developer Network . Получено 23 июля 2021 г.
  61. ^ "NEL". Mozilla Developer Network . 2021. Получено 18 мая 2021 г.
  62. ^ «Политика разрешений». W3C. 2020. Получено 1 мая 2021 г.
  63. ^ "Am I FLoCed?". EFF. 2021. Получено 1 мая 2021 г.
  64. ^ "Определение заголовка HTTP Refresh от annevk · Pull Request #2892 · whatwg/html". GitHub . 9 августа 2017 г. . Получено 17 апреля 2021 г. .
  65. ^ "CSP: report-to". Mozilla Developer Network . 2021. Получено 18 мая 2021 г.
  66. ^ RFC 9110: Семантика HTTP
  67. ^ "Timing-Allow-Origin". Mozilla Developer Network . Получено 25 января 2018 г.
  68. ^ "Настройка серверов для Ogg media". 26 мая 2014 г. Получено 3 января 2015 г.
  69. ^ «Очистите отслеживание длительности и используйте зеркалирование для доступа между потоками». Bugzilla@Mozilla . Получено 9 февраля 2024 г.
  70. ^ Эрик Лоуренс (3 сентября 2008 г.). "IE8 Security Part VI: Beta 2 Update" . Получено 28 сентября 2010 г.
  71. ^ "Хостинг - Расширения Google Chrome - Google Code" . Получено 14 июня 2012 г. .
  72. ^ van Kesteren, Anne (26 августа 2016 г.). "Fetch standard". WHATWG . Архивировано из оригинала 26 августа 2016 г. Получено 26 августа 2016 г.
  73. ^ "Заголовок ответа HTTP X-Redirect-By" . Получено 29 мая 2021 г. .
  74. ^ «Определение совместимости документов: указание режимов совместимости документов». 1 апреля 2011 г. Получено 24 января 2012 г.
  75. ^ "HTML Living Standard 4.2.5.3 Pragma directives, X-UA-Compatible state". WHATWG . 12 марта 2021 г. . Получено 14 марта 2021 г. Для элементов meta с атрибутом http-equiv в состоянии X-UA-Compatible атрибут content должен иметь значение, которое является нечувствительным к регистру ASCII соответствием для строки ."IE=edge"
  76. ↑ Эрик Лоуренс (2 июля 2008 г.). "IE8 Security Part IV: The XSS Filter" . Получено 30 сентября 2010 г. .
  77. ^ "Pragme". HTTP-кэширование. Июнь 2022 г. раздел 5.4. doi : 10.17487/RFC9111 . RFC 9111.
  78. ^ "Как предотвратить кэширование в Internet Explorer". Microsoft . 22 сентября 2011 г. Получено 15 апреля 2015 г.

На момент редактирования эта статья использует контент из статьи "Что такое заголовок X-REQUEST-ID http?" , автором которой является Стефан Кёгль на 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 г.

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