Список полей заголовка HTTP
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 ] Например, браузер может указать, что он принимает информацию на немецком или английском языке (предпочтительно немецкий), установив значение q для de
выше, чем у en
, следующее:
Accept-Language: de; q=1.0, en; q=0.5
Ограничения по размеру
[ редактировать ]Стандарт не накладывает ограничений на размер каждого имени или значения поля заголовка, а также на количество полей. Однако большинство серверов, клиентов и прокси-программ налагают некоторые ограничения по практическим соображениям и соображениям безопасности. Например, сервер Apache 2.3 по умолчанию ограничивает размер каждого поля до 8190 байт, и в одном запросе может быть не более 100 полей заголовка. [ 10 ]
Поля запроса
[ редактировать ]Стандартные поля запроса
[ редактировать ]Имя | Описание | Пример | Статус | Стандартный |
---|---|---|---|---|
ЦЕЛЬ | Допустимые экземпляры-манипуляции для запроса. [ 11 ] | A-IM: feed |
Постоянный | RFC 3229 |
Принимать | Типы носителей, которые приемлемы для ответа. См. Согласование контента . | Accept: text/html |
Постоянный | РФК 9110 |
Accept-Charset | Приемлемые наборы символов. | Accept-Charset: utf-8 |
Постоянный | РФК 9110 |
Accept-Datetime | Приемлемая версия по времени. | Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT |
Временный | RFC 7089 |
Принять-кодирование | Список допустимых кодировок. См. HTTP-сжатие . | Accept-Encoding: gzip, deflate |
Постоянный | РФК 9110 |
Accept-Язык | Список приемлемых человеческих языков для ответа. См. Согласование контента . | Accept-Language: en-US |
Постоянный | РФК 9110 |
Метод-запрос контроля доступа, Заголовки запросов контроля доступа [ 12 ] |
Инициирует запрос на совместное использование ресурсов между источниками с Origin (ниже). | Access-Control-Request-Method: GET |
Постоянный: стандартный | |
Авторизация | Учетные данные для аутентификации HTTP . | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Постоянный | РФК 9110 |
Кэш-Контроль | Используется для указания директив, которым должны подчиняться все механизмы кэширования в цепочке запрос-ответ. | Cache-Control: no-cache |
Постоянный | RFC 9111 |
Связь | Параметры управления текущим соединением и список полей пошагового запроса. [ 13 ]
Не следует использовать с HTTP/2. [ 14 ] |
Connection: keep-alive
|
Постоянный | РФК 9110 |
Кодирование контента | Тип кодировки, используемый для данных. См. HTTP-сжатие . | Content-Encoding: gzip |
Постоянный | РФК 9110 |
Длина контента | Длина тела запроса в октетах (8-битные байты). | Content-Length: 348 |
Постоянный | РФК 9110 |
Контент-MD5 | Двоичная Base64 . в кодировке сумма MD5 содержимого тела запроса | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Устаревший [ 15 ] | RFC 1544 , 1864 , 4021 |
Тип контента | Тип носителя тела запроса (используется с запросами POST и PUT). | Content-Type: application/x-www-form-urlencoded |
Постоянный | РФК 9110 |
печенье | ранее HTTP-куки, отправленный сервером с помощью Set-Cookie (ниже). |
Cookie: $Version=1; Skin=new; |
Постоянный: стандартный | РФК 2965 , 6265 |
Дата | Дата и время создания сообщения (в формате «HTTP-дата», как определено в RFC 9110: Семантика HTTP, раздел 5.6.7 «Форматы даты и времени» ). | Date: Tue, 15 Nov 1994 08:12:31 GMT |
Постоянный | РФК 9110 |
Ожидать | Указывает, что клиенту требуется определенное поведение сервера. | Expect: 100-continue |
Постоянный | РФК 9110 |
Переадресовано | Раскройте исходную информацию о клиенте, подключающемся к веб-серверу через HTTP-прокси. [ 16 ] | Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43 Forwarded: for=192.0.2.43, for=198.51.100.17 |
Постоянный | RFC 7239 |
От | Адрес электронной почты пользователя, сделавшего запрос. | From: [email protected] |
Постоянный | РФК 9110 |
Хозяин | Доменное имя сервера (для виртуального хостинга ) и номер TCP-порта , который прослушивает сервер. Номер порта может быть опущен, если порт является стандартным портом для запрошенной услуги.
Обязательно начиная с HTTP/1.1. [ 17 ] Если запрос генерируется непосредственно в HTTP/2, его не следует использовать. [ 18 ] |
Host: en.wikipedia.org:8080
|
Постоянный | РФК 9110 , 9113 |
HTTP2-Настройки | Запрос на обновление с HTTP/1.1 до HTTP/2 ДОЛЖЕН включать ровно один HTTP2-Settings поле заголовка. HTTP2-Settings Поле заголовка — это поле заголовка для конкретного соединения, которое включает параметры, управляющие соединением HTTP/2, предоставляемые в ожидании принятия сервером запроса на обновление. [ 19 ] [ 20 ]
|
HTTP2-Settings: token64
|
Устаревший | RFC 7540 , 9113 |
Если-Матч | Выполняйте действие только в том случае, если объект, предоставленный клиентом, соответствует тому же объекту на сервере. В основном это касается таких методов, как PUT, которые обновляют ресурс только в том случае, если он не был изменен с момента последнего обновления пользователем. | If-Match: "737060cd8c284d8af7ad3082f209582d" |
Постоянный | РФК 9110 |
Если-Изменено-С тех пор | Позволяет 304 Not Modified, если содержимое не изменилось. вернуть | If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
Постоянный | РФК 9110 |
Если-Нет-Матча | Позволяет код 304 Not Modified, вернуть если содержимое не изменилось, см. HTTP ETag . | If-None-Match: "737060cd8c284d8af7ad3082f209582d" |
Постоянный | РФК 9110 |
If-Range | Если объект не изменился, пришлите мне недостающую часть(и); в противном случае пришлите мне всю новую сущность. | If-Range: "737060cd8c284d8af7ad3082f209582d" |
Постоянный | РФК 9110 |
Если-Немодифицировано-С тех пор | Отправляйте ответ только в том случае, если объект не был изменен с определенного времени. | If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT |
Постоянный | РФК 9110 |
Макс-Форварды | Ограничьте количество раз, когда сообщение может быть перенаправлено через прокси или шлюзы. | Max-Forwards: 10 |
Постоянный | РФК 9110 |
Источник [ 12 ] | Инициирует запрос на совместное использование ресурсов между источниками (запрашивает у сервера поля ответа Access-Control-* ). | Origin: http://www.example-social-network.com |
Постоянный: стандартный | RFC 6454 |
Прагма | Поля, зависящие от реализации, которые могут иметь различные последствия в любом месте цепочки запрос-ответ. | Pragma: no-cache |
Постоянный | RFC 9111 |
Предпочитать | Позволяет клиенту запрашивать определенное поведение сервера при обработке запроса. | Prefer: return=representation
|
Постоянный | RFC 7240 |
Прокси-Авторизация | Авторизационные данные для подключения к прокси. | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Постоянный | РФК 9110 |
Диапазон | Запросить только часть объекта. Байты нумеруются с 0. См. раздел «Обработка байтов» . | Range: bytes=500-999 |
Постоянный | РФК 9110 |
Реферер [ так в оригинале ] | Это адрес предыдущей веб-страницы, с которой была проведена ссылка на запрошенную в данный момент страницу. (Слово «реферер» было написано с ошибкой в RFC, а также в большинстве реализаций до такой степени, что оно стало стандартным использованием и считается правильной терминологией) | Referer: http://en.wikipedia.org/wiki/Main_Page |
Постоянный | РФК 9110 |
ТО | Кодировки передачи, которые готов принять пользовательский агент: можно использовать те же значения, что и для поля заголовка ответа Transfer-Encoding, плюс значение «трейлеры» (связанное с методом передачи « фрагментами ») для уведомления сервера, который он ожидает получить дополнительные поля в трейлере после последнего фрагмента нулевого размера.
Только |
TE: trailers, deflate |
Постоянный | РФК 9110 |
Трейлер | Значение общего поля Trailer указывает, что данный набор полей заголовка присутствует в трейлере сообщения, закодированного с помощью кодирования фрагментированной передачи . | Trailer: Max-Forwards
|
Постоянный | РФК 9110 |
Передача-кодирование | Форма кодирования, используемая для безопасной передачи объекта пользователю. В настоящее время определены следующие методы: chunked , compress, deflate, gzip,identity.
Не следует использовать с HTTP/2. [ 14 ] |
Transfer-Encoding: chunked
|
Постоянный | РФК 9110 |
Пользовательский агент | Строка пользовательского агента пользовательского агента. | User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0 |
Постоянный | РФК 9110 |
Обновление | Попросите сервер перейти на другой протокол.
Не должен использоваться в HTTP/2. [ 14 ] |
Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket |
Постоянный | РФК 9110 |
С помощью | Сообщает серверу прокси, через которые был отправлен запрос. | Via: 1.0 fred, 1.1 example.com (Apache/1.1) |
Постоянный | РФК 9110 |
Предупреждение | Общее предупреждение о возможных проблемах с телом сущности. | Warning: 199 Miscellaneous warning |
Устаревший [ 21 ] | RFC 7234 , 9111 |
Общие нестандартные поля запроса
[ редактировать ]Имя поля | Описание | Пример |
---|---|---|
Небезопасные запросы на обновление [ 22 ] | Сообщает серверу (предположительно, в середине миграции HTTP -> HTTPS) размещает смешанный контент, который клиент предпочел бы перенаправление на HTTPS и может обработать. Content-Security-Policy: upgrade-insecure-requests
|
Upgrade-Insecure-Requests: 1
|
X-запрошено-с | В основном используется для идентификации запросов Ajax (большинство фреймворков JavaScript отправляют это поле со значением XMLHttpRequest ); также идентифицирует приложения Android с помощью WebView [ 23 ] |
X-Requested-With: XMLHttpRequest
|
ДНТ [ 24 ] | Запрашивает веб-приложение отключить отслеживание пользователя. Это версия поля заголовка X-Do-Not-Track от Mozilla (начиная с Firefox 4.0 Beta 11). Safari и IE9 также поддерживают это поле. [ 25 ] 7 марта 2011 г. проект предложения был представлен в IETF. [ 26 ] Рабочая группа W3C по защите от отслеживания разрабатывает спецификацию. [ 27 ] | DNT: 1 (Не отслеживать включено)
|
X-Перенаправлено-Для [ 28 ] | Фактический . стандарт для определения исходного IP-адреса клиента, подключающегося к веб-серверу через HTTP-прокси или балансировщик нагрузки Заменено заголовком Forwarded . | X-Forwarded-For: client1, proxy1, proxy2
|
X-переадресованный хост [ 29 ] | Стандарт де-факто для идентификации исходного хоста , запрошенного клиентом в Host Заголовок HTTP-запроса, поскольку имя хоста и/или порт обратного прокси-сервера (балансировщика нагрузки) могут отличаться от имени исходного сервера, обрабатывающего запрос. Заменено заголовком Forwarded . |
X-Forwarded-Host: en.wikipedia.org:8080
|
X-Forwarded-Proto [ 30 ] | Фактический для определения исходного протокола HTTP-запроса, поскольку обратный прокси-сервер (или балансировщик нагрузки) может взаимодействовать с веб-сервером с использованием HTTP , стандарт даже если запрос к обратному прокси-серверу является HTTPS. Альтернативная форма заголовка (X-ProxyUser-Ip) используется клиентами Google, взаимодействующими с серверами Google. Заменено заголовком Forwarded . | X-Forwarded-Proto: https
|
Интерфейсные HTTPS [ 31 ] | Нестандартное поле заголовка, используемое приложениями Microsoft и балансировщиками нагрузки. | Front-End-Https: on
|
X-Http-Method-Override [ 32 ] | Запрашивает веб-приложение переопределить метод, указанный в запросе (обычно POST), методом, указанным в поле заголовка (обычно PUT или DELETE). Это можно использовать, когда пользовательский агент или брандмауэр препятствует прямой отправке методов PUT или DELETE (это либо ошибка в программном компоненте, которую следует исправить, либо преднамеренная конфигурация, и в этом случае обход ее может быть неправильным). что нужно сделать). | X-HTTP-Method-Override: DELETE
|
X-ATT-DeviceId [ 33 ] | Позволяет упростить анализ MakeModel/Firmware, который обычно находится в строке User-Agent устройств AT&T. | X-Att-Deviceid: GT-P7320/P7320XXLPG
|
X-Wap-профиль [ 34 ] | Ссылки на XML-файл в Интернете с полным описанием и сведениями о подключаемом в данный момент устройстве. В примере справа показан XML-файл для Samsung Galaxy S2 от AT&T. | x-wap-profile: http://wap.samsungmobile.com/uaprof/SGH-I777.xml
|
Прокси-соединение [ 35 ] | Реализовано из-за неправильного понимания спецификаций HTTP. Часто встречается из-за ошибок в реализации ранних версий HTTP. Имеет точно такую же функциональность, что и стандартное поле «Соединение».
Не следует использовать с HTTP/2. [ 14 ] |
Proxy-Connection: keep-alive
|
Х-ТЫ [ 36 ] [ 37 ] [ 38 ] | на стороне сервера Глубокая проверка пакетов по уникальному идентификатору, идентифицирующему клиентов Verizon Wireless ; также известное как «постоянное печенье» или «суперпеченье». | X-UIDH: ...
|
X-Csrf-токен [ 39 ] | Используется для предотвращения подделки межсайтовых запросов . Альтернативные имена заголовков: X-CSRFToken [ 40 ] и X-XSRF-TOKEN [ 41 ] |
X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql
|
X-запрос-ID, [ stackoverflow2 1 ] [ 42 ]
Идентификатор X-корреляции, [ 43 ] Идентификатор корреляции [ 44 ] |
Сопоставляет HTTP-запросы между клиентом и сервером. Заменяется заголовком Traceparent. | X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
|
Сохранить данные [ 46 ] | Заголовок запроса подсказки клиента Save-Data, доступный в браузерах Chrome, Opera и Яндекс, позволяет разработчикам предоставлять более легкие и быстрые приложения пользователям, которые включили режим сохранения данных в своем браузере. | Save-Data: on
|
Сек-ГПХ [ 47 ] | Заголовок запроса Sec-GPC ( Global Privacy Control ) указывает, согласен ли пользователь на то, чтобы веб-сайт или служба продавали или делились своей личной информацией с третьими лицами. | Sec-GPC: 1
|
Поля ответа
[ редактировать ]Стандартные поля ответа
[ редактировать ]Имя поля | Описание | Пример | Статус | Стандартный |
---|---|---|---|---|
Принять-CH | Запрашивает подсказки HTTP-клиента | Accept-CH: UA, Platform |
Экспериментальный | RFC 8942 |
Доступ-Контроль-Разрешить-Происхождение, Доступ-Контроль-Разрешить-Учетные данные, Заголовки Access-Control-Expose-Headers, Доступ-Контроль-Макс-Возраст, Методы контроля доступа, Заголовки Access-Control-Allow-Headers [ 12 ] |
Указание того, какие веб-сайты могут участвовать в совместном использовании ресурсов между источниками. | Access-Control-Allow-Origin: * |
Постоянный: стандартный | RFC 7480 |
Accept-Patch [ 48 ] | Указывает, какие форматы документов исправлений поддерживает этот сервер. | Accept-Patch: text/example;charset=utf-8 |
Постоянный | RFC 5789 |
Accept-Диапазоны | Какие типы частичного диапазона контента поддерживает этот сервер посредством обслуживания байтов | Accept-Ranges: bytes |
Постоянный | РФК 9110 |
Возраст | Возраст нахождения объекта в кэше прокси в секундах | Age: 12 |
Постоянный | RFC 9111 |
Позволять | Допустимые методы для указанного ресурса. Использование метода 405 запрещено. | Allow: GET, HEAD |
Постоянный | РФК 9110 |
Alt-Svc [ 49 ] | Сервер использует заголовок «Alt-Svc» (что означает «Альтернативные службы»), чтобы указать, что к его ресурсам также можно получить доступ в другом сетевом расположении (хост или порт) или с использованием другого протокола.
При использовании HTTP/2 серверы должны вместо этого отправлять кадр ALTSVC. [ 50 ] |
Alt-Svc: http/1.1="http2.example.com:8001"; ma=7200 |
Постоянный | |
Кэш-Контроль | Сообщает всем механизмам кэширования от сервера к клиенту, могут ли они кэшировать этот объект. Оно измеряется в секундах | Cache-Control: max-age=3600 |
Постоянный | RFC 9111 |
Связь | Параметры управления текущим соединением и список полей ответа для каждого шага. [ 13 ]
Не следует использовать с HTTP/2. [ 14 ] |
Connection: close |
Постоянный | РФК 9110 |
Содержание-Расположение [ 51 ] | Возможность вызвать диалоговое окно «Загрузка файла» для известного типа MIME в двоичном формате или предложить имя файла для динамического контента. Кавычки необходимы со специальными символами. | Content-Disposition: attachment; filename="fname.ext" |
Постоянный | RFC 2616 , 4021 , 6266 |
Кодирование контента | Тип кодировки, используемый для данных. См. HTTP-сжатие . | Content-Encoding: gzip |
Постоянный | РФК 9110 |
Язык контента | Естественный язык или языки целевой аудитории прилагаемого контента. [ 52 ] | Content-Language: da |
Постоянный | РФК 9110 |
Длина контента | Длина тела ответа в октетах (8-битные байты). | Content-Length: 348 |
Постоянный | РФК 9110 |
Содержание-Местоположение | Альтернативное расположение возвращаемых данных | Content-Location: /index.htm |
Постоянный | РФК 9110 |
Контент-MD5 | Двоичная Base64. в кодировке сумма MD5 содержимого ответа | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Устаревший [ 15 ] | RFC 1544 , 1864 , 4021 |
Диапазон содержимого | Где в полном теле сообщения принадлежит это частичное сообщение | Content-Range: bytes 21010-47021/47022 |
Постоянный | РФК 9110 |
Тип контента | MIME -тип этого контента | Content-Type: text/html; charset=utf-8 |
Постоянный | РФК 9110 |
Дата | Дата и время отправки сообщения (в формате «HTTP-дата», как определено в RFC 9110). | Date: Tue, 15 Nov 1994 08:12:31 GMT |
Постоянный | РФК 9110 |
Дельта-База | Указывает тег объекта дельта-кодирования ответа. [ 11 ] | Delta-Base: "abc" |
Постоянный | RFC 3229 |
ETag | Идентификатор конкретной версии ресурса, часто дайджеста сообщения. | ETag: "737060cd8c284d8af7ad3082f209582d" |
Постоянный | РФК 9110 |
Срок действия истекает | Дает дату/время, после которых ответ считается устаревшим (в формате «HTTP-дата», как определено в RFC 9110). | Expires: Thu, 01 Dec 1994 16:00:00 GMT |
Постоянный: стандартный | RFC 9111 |
В | Манипуляции с экземплярами, применяемые к ответу. [ 11 ] | IM: feed |
Постоянный | RFC 3229 |
Последнее изменение | Дата последнего изменения запрошенного объекта (в формате «HTTP-дата», как определено в RFC 9110). | Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT |
Постоянный | РФК 9110 |
Связь | Используется для выражения типизированной связи с другим ресурсом, где тип связи определен в RFC 5988. | Link: </feed>; rel="alternate" [ 53 ] |
Постоянный | РФК 5988 |
Расположение | Используется при перенаправлении или при создании нового ресурса. |
|
Постоянный | РФК 9110 |
P3P | Предполагается, что в этом поле задается политика P3P в виде P3P:CP="your_compact_policy" . Однако P3P не взлетел, [ 54 ] большинство браузеров никогда не реализовали его полностью, многие веб-сайты задавали в этом поле поддельный текст политики, этого было достаточно, чтобы обмануть браузеры о существовании политики P3P и предоставить разрешения для сторонних файлов cookie . |
P3P: CP="This is not a P3P policy! See https://en.wikipedia.org/wiki/Special:CentralAutoLogin/P3P for more info." |
Постоянный | |
Прагма | Поля, зависящие от реализации, которые могут иметь различные последствия в любом месте цепочки запрос-ответ. | Pragma: no-cache |
Постоянный | RFC 9111 |
Применимо по предпочтениям | Указывает, какие токены Prefer были приняты сервером и применены к обработке запроса. | Preference-Applied: return=representation
|
Постоянный | RFC 7240 |
Прокси-аутентификация | Запросите аутентификацию для доступа к прокси. | Proxy-Authenticate: Basic |
Постоянный | РФК 9110 |
Публичные ключи [ 55 ] | HTTP Public Key Pinning объявляет хэш подлинного TLS- сертификата веб-сайта. | Public-Key-Pins: max-age=2592000; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; |
Постоянный | RFC 7469 |
Повторить попытку после | Если объект временно недоступен, клиенту предлагается повторить попытку позже. Значением может быть указанный период времени (в секундах) или HTTP-дата. [ 56 ] |
|
Постоянный |
РФК 9110 |
Сервер | Имя для сервера | Server: Apache/2.4.1 (Unix) |
Постоянный | РФК 9110 |
Set-Cookie | куки HTTP- | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
Постоянный: стандартный | RFC 6265 |
Строгая транспортная безопасность | Политика HSTS, информирующая HTTP-клиент, как долго кэшировать политику только HTTPS и применимо ли это к поддоменам. | Strict-Transport-Security: max-age=16070400; includeSubDomains |
Постоянный: стандартный | |
Трейлер | Значение общего поля Trailer указывает, что данный набор полей заголовка присутствует в трейлере сообщения, закодированного с помощью кодирования фрагментированной передачи . | Trailer: Max-Forwards |
Постоянный | РФК 9110 |
Передача-кодирование | Форма кодирования, используемая для безопасной передачи объекта пользователю. В настоящее время определены следующие методы: chunked , compress, deflate, gzip,identity.
Не следует использовать с HTTP/2. [ 14 ] |
Transfer-Encoding: chunked |
Постоянный | РФК 9110 |
Тк | Заголовок статуса отслеживания, значение, которое предлагается отправить в ответ на DNT (не отслеживать), возможные значения:
"!" — under construction "?" — dynamic "G" — gateway to multiple parties "N" — not tracking "T" — tracking "C" — tracking with consent "P" — tracking only if consented "D" — disregarding DNT "U" — updated |
Tk: ?
|
Постоянный | |
Обновление | Попросите клиента перейти на другой протокол.
Не следует использовать в HTTP/2. [ 14 ] |
Upgrade: h2c, HTTPS/1.3, IRC/6.9, RTA/x11, websocket |
Постоянный | РФК 9110 |
Отличаться | Сообщает нижестоящим прокси-серверам, как сопоставлять будущие заголовки запросов, чтобы решить, можно ли использовать кэшированный ответ вместо запроса нового с исходного сервера. |
|
Постоянный | РФК 9110 |
С помощью | Сообщает клиенту прокси, через которые был отправлен ответ. | Via: 1.0 fred, 1.1 example.com (Apache/1.1) |
Постоянный | РФК 9110 |
Предупреждение | Общее предупреждение о возможных проблемах с телом сущности. | Warning: 199 Miscellaneous warning |
Устаревший [ 21 ] | RFC 7234 , 9111 |
WWW-аутентификация | Указывает схему аутентификации, которую следует использовать для доступа к запрошенному объекту. | WWW-Authenticate: Basic |
Постоянный | РФК 9110 |
Параметры X-Frame [ 57 ] | Защита от кликджекинга : deny - нет рендеринга внутри кадра, sameorigin - нет рендеринга при несоответствии происхождения, allow-from - разрешить из указанного места, allowall - нестандартный, разрешен из любого места |
X-Frame-Options: deny |
Устаревший [ 58 ] |
Распространенные нестандартные поля ответа
[ редактировать ]Имя поля | Описание | Пример |
---|---|---|
Политика безопасности контента, Политика безопасности X-контента, X-WebKit-CSP [ 59 ] |
Определение политики безопасности контента . | X-WebKit-CSP: default-src 'self'
|
Ожидайте-CT [ 60 ] | Уведомите, чтобы предпочесть обеспечить прозрачность сертификатов . | Expect-CT: max-age=604800, enforce, report-uri="https://example.example/report"
|
В [ 61 ] | Используется для настройки ведения журнала сетевых запросов. | NEL: { "report_to": "name_of_reporting_group", "max_age": 12345, "include_subdomains": false, "success_fraction": 0.0, "failure_fraction": 1.0 }
|
Политика разрешений [ 62 ] | Чтобы разрешить или отключить различные функции или API браузера. | Permissions-Policy: fullscreen=(), camera=(), microphone=(), geolocation=(), interest-cohort=()[63]
|
Обновить | Используется при перенаправлении или при создании нового ресурса. Это обновление перенаправляет через 5 секунд. Расширение заголовка, представленное Netscape и поддерживаемое большинством веб-браузеров. Определено стандартом HTML [ 64 ] | Refresh: 5; url=http://www.w3.org/pub/WWW/People.html
|
Отчет-Кому [ 65 ] | Указывает агенту пользователя хранить конечные точки отчетов для источника. | Report-To: { "group": "csp-endpoint", "max_age": 10886400, "endpoints": [ { "url": "https-url-of-site-which-collects-reports" } ] }
|
Статус | Поле заголовка CGI , определяющее статус ответа HTTP. Вместо этого в обычных ответах HTTP используется отдельная строка состояния, определенная RFC 9110. [ 66 ] | Status: 200 OK
|
Timing-Allow-Origin | The Timing-Allow-Origin Заголовок ответа указывает источники, которым разрешено видеть значения атрибутов, полученных с помощью функций API синхронизации ресурсов , которые в противном случае были бы указаны как ноль из-за ограничений между источниками. [ 67 ]
|
Timing-Allow-Origin: *
|
X-Content-Продолжительность [ 68 ] | Укажите продолжительность аудио или видео в секундах. Не поддерживается текущими браузерами — заголовок поддерживался только браузерами Gecko, поддержка которых была удалена в 2015 году. [ 69 ] | X-Content-Duration: 42.666
|
Параметры X-Content-Type [ 70 ] | Единственное определенное значение, «nosniff», не позволяет Internet Explorer перехватывать MIME-ответ в сторону от объявленного типа контента. Это также относится и к Google Chrome при загрузке расширений. [ 71 ] | X-Content-Type-Options: nosniff [ 72 ]
|
X-Powered-By [ stackoverflow1 1 ] | Указывает технологию (например, ASP.NET, PHP, JBoss), поддерживающую веб-приложение (сведения о версии часто указаны в файле). X-Runtime , X-Version , или X-AspNet-Version ) |
X-Powered-By: PHP/5.4.0
|
X-Redirect-By [ 73 ] | Указывает компонент, отвечающий за конкретное перенаправление. | X-Redirect-By: WordPress X-Redirect-By: Polylang
|
X-Request-ID, X-Correlation-ID [ stackoverflow2 1 ] | Сопоставляет HTTP-запросы между клиентом и сервером. | X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5
|
X-UA-совместимый [ 74 ] | Рекомендует предпочтительный механизм рендеринга (часто режим обратной совместимости), который следует использовать для отображения контента. Также используется для активации Chrome Frame в Internet Explorer. В стандарте HTML только IE=edge стоимость определена. [ 75 ] |
X-UA-Compatible: IE=edge X-UA-Compatible: IE=EmulateIE7 X-UA-Compatible: Chrome=1
|
X-XSS-Защита [ 76 ] | Фильтр межсайтового скриптинга (XSS) | X-XSS-Protection: 1; mode=block
|
Эффекты выбранных полей
[ редактировать ]Как избежать кэширования
[ редактировать ]Если веб-сервер отвечает 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.
The Cache-Control: no-cache
Поле заголовка HTTP/1.1 также предназначено для использования в запросах клиента. Это средство, с помощью которого браузер сообщает серверу и всем промежуточным кэшам, что ему нужна свежая версия ресурса. Pragma: no-cache
Поле заголовка, определенное в спецификации HTTP/1.0, имеет ту же цель. Однако он определяется только для заголовка запроса. Его значение в заголовке ответа не указано. [ 77 ] Поведение Pragma: no-cache
в ответе зависит от реализации. Хотя некоторые пользовательские агенты обращают внимание на это поле в ответах, [ 78 ] HTTP/1.1 RFC специально предостерегает от такого поведения.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ «Разбор полей» . Протокол передачи гипертекста (HTTP/1.1): синтаксис сообщений и маршрутизация . Июнь 2014. сек. 3.2.4. дои : 10.17487/RFC7230 . РФК 7230 .
- ^ HTTP/2 . Июнь 2022 г. doi : 10.17487/RFC9113 . РФК 9113 .
- ^ Пеон, Р.; Руэллан, Х. (май 2015 г.). «HPACK: сжатие заголовка для HTTP/2» . IETF . дои : 10.17487/RFC7541 . Проверено 13 декабря 2021 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ «Имена полей» . HTTP-семантика . Июнь 2022. сек. 5.1. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ «Методы: Обзор» . HTTP-семантика . Июнь 2022. сек. 9.1. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ Целевая группа по интернет-инжинирингу (1 июня 2012 г.). «РФК 6648» . дои : 10.17487/RFC6648 . Проверено 12 ноября 2012 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ «Заголовки сообщений» . Яна.орг. 11 июня 2014 года . Проверено 12 июня 2014 г.
- ^ «Комментарии» . HTTP-семантика . Июнь 2022. сек. 5.6.5. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ «Ценности качества» . HTTP-семантика . Июнь 2022. сек. 12.4.2. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ «ядро — HTTP-сервер Apache» . httpd.apache.org. Архивировано из оригинала 9 мая 2012 года . Проверено 13 марта 2012 г.
- ^ Перейти обратно: а б с РФК 3229 . дои : 10.17487/RFC3229 .
- ^ Перейти обратно: а б с «Обмен ресурсами между источниками» . Проверено 24 июля 2017 г.
- ^ Перейти обратно: а б «Заголовок подключения» . HTTP-семантика . Июнь 2022. сек. 7.6.1. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ Перейти обратно: а б с д и ж г час «Поля заголовка, специфичные для соединения» . HTTP/2 . Июнь 2022. сек. 8.2.2. дои : 10.17487/RFC9113 . РФК 9113 .
- ^ Перейти обратно: а б «Изменения от RFC 2616» . Протокол передачи гипертекста (HTTP/1.1): семантика и содержание . Июнь 2014. сек. Б. дои : 10.17487/RFC7231 . РФК 7231 .
- ^ Петерссон, А.; Нильссон, М. (июнь 2014 г.). «Пересылаемое расширение HTTP: Введение» . IETF . дои : 10.17487/RFC7239 . Проверено 7 января 2016 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ «Хост и :авторитет» . HTTP-семантика . Июнь 2022. сек. 7.2. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ «Запросить поля псевдозаголовка» . HTTP/2 . Июнь 2022. сек. 8.3.1. дои : 10.17487/RFC9113 . РФК 9113 .
- ^ «Заголовки сообщений» . www.iana.org . Проверено 26 ноября 2018 г.
- ^ «Поле заголовка HTTP2-Настройки» . Протокол передачи гипертекста версии 2 (HTTP/2) . сек. 3.2.1. дои : 10.17487/RFC7540 . РФК 7540 .
- ^ Перейти обратно: а б «Предупреждающий заголовок» . HTTP-кэширование . Июнь 2022. сек. 5.5. дои : 10.17487/RFC9111 . РФК 9111 .
- ^ «Обновление небезопасных запросов — кандидатская рекомендация W3C» . W3C . 8 октября 2015 г. Проверено 14 января 2016 г.
- ^ «Заголовок «X-Requested-With» — Стаутнер» .
- ^ «Попробуйте HTTP-заголовок «Не отслеживать»» . Проверено 31 января 2011 г.
- ^ «Защита от веб-слежения: минимальные стандарты и возможности для инноваций» . Проверено 24 марта 2011 г.
- ^ IETF «Не отслеживать»: универсальный отказ от стороннего веб-отслеживания, 7 марта 2011 г.
- ^ Выражение предпочтений отслеживания W3C (DNT) , 26 января 2012 г.
- ^ Амос Джеффрис (2 июля 2010 г.). «SquidFaq/ConfiguringSquid — Wiki веб-прокси Squid» . Проверено 10 сентября 2009 г.
- ^ Фонд программного обеспечения Apache. «mod_proxy — HTTP-сервер Apache версии 2.2» . Проверено 12 ноября 2014 г.
- ^ Дэйв Стейнберг (10 апреля 2007 г.). «Как мне настроить мой SSL-сайт для работы с балансировщиком нагрузки GeekISP?» . Проверено 30 сентября 2010 г.
- ^ «Помощь в обеспечении безопасности связи: клиент-сервер переднего плана» . 27 июля 2006 года . Проверено 23 апреля 2012 г.
- ^ «Спецификация сервера API OpenSocial Core 2.5.1» . Проверено 8 октября 2014 г.
- ^ «Идентификатор устройства АТТ» . Архивировано из оригинала 16 февраля 2012 года . Проверено 14 января 2012 г.
- ^ «WAP-профиль» . Проверено 14 января 2012 г.
- ^ де Бойн Поллард, Джонатан (2007). «Заголовок Proxy-Connection: является ошибкой в том, как некоторые веб-браузеры используют HTTP» . Проверено 16 января 2018 г.
- ^ «Verizon внедряет постоянные файлы cookie для отслеживания мобильных клиентов в обход контроля конфиденциальности» . Фонд электронных границ . Проверено 19 января 2014 г.
- ^ «Проверка известных маячков уникальных идентификаторов AT&T, Verizon, Sprint, Bell Canada и Vodacom» . Проверено 19 января 2014 г.
- ^ Крейг Тимберг. «Verizon и AT&T отслеживают своих пользователей с помощью «суперкуки» » . Вашингтон Пост . Проверено 19 января 2014 г.
- ^ «Защита от подделки межсайтовых запросов SAP» . САП СЭ . Проверено 20 января 2015 г.
- ^ «Защита от подделки межсайтовых запросов Django» . Джанго (веб-фреймворк) . Архивировано из оригинала 20 января 2015 года . Проверено 20 января 2015 г.
- ^ «Защита от подделки межсайтовых запросов Angular (XSRF)» . АнгулярJS . Проверено 20 января 2015 г.
- ^ «Идентификаторы HTTP-запросов» . devcenter.heroku.com . Проверено 22 марта 2022 г.
- ^ «Значение идентификаторов корреляции» . Блог Rapid7 . 23 декабря 2016 года . Проверено 13 апреля 2018 г.
- ^ Хилтон, Питер. «Идентификаторы корреляции для микросервисных архитектур — Питер Хилтон» . hilton.org.uk . Проверено 13 апреля 2018 г.
- ^ «Контекст трассировки W3C» . w3c.org . Проверено 19 июня 2024 г.
- ^ «Проект отчета группы сообщества Live Document API для сохранения данных 2.1.1. Поле заголовка запроса на сохранение данных» . Группа сообщества инкубатора веб-платформы . 30 июня 2020 г. Проверено 5 марта 2021 г.
- ^ Участники MDN (3 марта 2023 г.). «Сек-ГПК» . Веб-документы MDN . Проверено 12 марта 2023 г.
- ^ Дюссо, Л.; Снелл, Дж. (2010). «РФК 5789» . дои : 10.17487/RFC5789 . S2CID 42062521 . Проверено 24 декабря 2014 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ Ноттингем, М.; Макманус, П.; Решке, Дж. (апрель 2016 г.). «Альтернативные службы HTTP» . IETF. дои : 10.17487/RFC7838 . Проверено 19 апреля 2016 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ Ноттингем, М.; Макманус, П.; Решке, Дж. (апрель 2016 г.). «Альтернативные службы HTTP, раздел 3» . IETF. дои : 10.17487/RFC7838 . Проверено 8 июня 2017 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ Решке, Дж. (2011). «РФК 6266» . дои : 10.17487/RFC6266 . Проверено 13 марта 2015 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ «Контент-Язык» . HTTP-семантика . Июнь 2022. сек. 8.5. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ Укажите каноническую версию URL-адреса, ответив HTTP-заголовком Link rel="canonical". Проверено: 9 февраля 2012 г.
- ^ Работа W3C P3P приостановлена
- ^ «Расширение закрепления открытого ключа для HTTP» . IETF . Проверено 17 апреля 2015 г.
- ^ «Повторить попытку» . HTTP-семантика . Июнь 2022. сек. 10.2.3. дои : 10.17487/RFC9110 . РФК 9110 .
- ^ Росс, Д.; Гондром, Т. (2013). «Параметры X-Frame-поля заголовка HTTP» . IETF. дои : 10.17487/RFC7034 . Проверено 12 июня 2014 г.
{{cite journal}}
: Для цитирования журнала требуется|journal=
( помощь ) - ^ «Политика безопасности контента, уровень 2» . Проверено 2 августа 2014 г.
- ^ «Политика безопасности контента» . W3C. 2012 . Проверено 28 апреля 2017 г.
- ^ «Ожида-КТ» . Сеть разработчиков Mozilla . Проверено 23 июля 2021 г.
- ^ «НЭЛ» . Сеть разработчиков Mozilla . 2021 . Проверено 18 мая 2021 г.
- ^ «Политика разрешений» . W3C. 2020 . Проверено 1 мая 2021 г.
- ^ «Я FLoCed?» . ЭФФ. 2021 . Проверено 1 мая 2021 г.
- ^ «Определите заголовок обновления HTTP с помощью annevk · Pull Request #2892 · Whatwg/html» . Гитхаб . 9 августа 2017 года . Проверено 17 апреля 2021 г.
- ^ «CSP: отправитель отчета» . Сеть разработчиков Mozilla . 2021 . Проверено 18 мая 2021 г.
- ^ RFC 9110 : Семантика HTTP
- ^ «Время-разрешить-происхождение» . Сеть разработчиков Mozilla . Проверено 25 января 2018 г.
- ^ «Настройка серверов для Ogg media» . 26 мая 2014 года . Проверено 3 января 2015 г.
- ^ «Очистите отслеживание продолжительности и используйте зеркалирование для межпоточного доступа» . Багзилла@Mozilla . Проверено 9 февраля 2024 г.
- ^ Эрик Лоуренс (3 сентября 2008 г.). «Безопасность IE8, часть VI: обновление бета-версии 2» . Проверено 28 сентября 2010 г.
- ^ «Хостинг — Расширения Google Chrome — Google Code» . Проверено 14 июня 2012 г.
- ^ ван Кестерен, Энн (26 августа 2016 г.). «Выбрать стандарт» . ЧТОРГ . Архивировано из оригинала 26 августа 2016 года . Проверено 26 августа 2016 г.
- ^ «Заголовок ответа HTTP X-Redirect-By» . Проверено 29 мая 2021 г.
- ^ «Определение совместимости документов: указание режимов совместимости документов» . 1 апреля 2011 года . Проверено 24 января 2012 г.
- ^ «HTML Living Standard 4.2.5.3 Pragma-директивы, состояние X-UA-совместимости» . ЧТОРГ . 12 марта 2021 г. Проверено 14 марта 2021 г.
Для метаэлементов с атрибутом http-equiv в состоянии X-UA-Compatible атрибут содержимого должен иметь значение, соответствующее строке ASCII без учета регистра.
"IE=edge"
. - ^ Эрик Лоуренс (2 июля 2008 г.). «Безопасность IE8, часть IV: XSS-фильтр» . Проверено 30 сентября 2010 г.
- ^ «Прагме» . HTTP-кэширование . Июнь 2022. сек. 5.4. дои : 10.17487/RFC9111 . РФК 9111 .
- ^ «Как предотвратить кеширование в Internet Explorer» . Майкрософт . 22 сентября 2011 года . Проверено 15 апреля 2015 г.
На момент редактирования в этой статье используется содержимое из раздела «Что такое http-заголовок X-REQUEST-ID?» , автором которого является Стефан Кёгль из Stack Exchange, и который лицензируется таким образом, что разрешает повторное использование в соответствии с непортированной лицензией Creative Commons Attribution-ShareAlike 3.0 , но не под GFDL . Все соответствующие условия должны быть соблюдены.
- ^ Перейти обратно: а б «Что такое 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 . Все соответствующие условия должны быть соблюдены.
- ^ «Почему платформа ASP.NET добавляет в ответы HTTP-заголовок X-Powered-By:ASP.NET? - Stack Overflow» . Проверено 20 марта 2022 г.
Внешние ссылки
[ редактировать ]- Заголовки: имена полей заголовка постоянного сообщения
- RFC 6265 : Механизм управления состоянием HTTP IETF
- RFC 9110 : Семантика HTTP
- RFC 9111 : HTTP-кэширование
- RFC 9112 : HTTP/1.1.
- RFC 9113 : HTTP/2.
- RFC 9114 : HTTP/3.
- RFC 7239 : пересылаемое расширение HTTP.
- RFC 7240 : предпочитать заголовок для HTTP
- Заголовки HTTP/1.1 с точки зрения веб-сервера
- Internet Explorer и пользовательские заголовки HTTP — IEInternals от EricLaw — Главная страница — Блоги MSDN