Заголовки HTTP чувствительны к регистру?


714

В сообщении в блоге я использую следующий PHP, чтобы установить тип содержимого ответа:

header('content-type: application/json; charset=utf-8');

Я только что получил комментарий к этому сообщению, в котором говорится, что он content-typeдолжен быть написан заглавными буквами Content-type. Это правильно? Кажется, он работает со всеми строчными буквами, и я предположил, что заголовки HTTP не чувствительны к регистру. Или это просто работает, потому что браузеры хороши?


26
Он нечувствителен к регистру, но если вы собираетесь его исправить, он должен быть «Content-Type».
mc0e

10
FWIW, посылка "charset" с приложением / json не имеет смысла. Там нет такого параметра.
Джулиан Решке

5
@JulianReschke - значение false, кодировка является допустимым параметром в заголовке Content-Type. См. W3.org/International/articles/http-charset/index и developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type
cchamberlain

8
@NullUserException - обратная сторона (кроме потерянных байтов) состоит в том, чтобы продолжать сбивать людей с толку с параметром charset. Просто исправьте эти компоненты.
Джулиан Решке

10
@JulianReschke правильно. Приложение IANA / назначение json говорит, что кодировка не имеет смысла для этого типа носителя. это ничего не делает. Пожалуйста, не добавляйте это, потому что это шум, который приводит к ненужной путанице.
Восстановить Монику 2331977

Ответы:


935

Имена заголовков не чувствительны к регистру.

Из RFC 2616 - «Протокол передачи гипертекста - HTTP / 1.1» , раздел 4.2, «Заголовки сообщений» :

Каждое поле заголовка состоит из имени, за которым следуют двоеточие (":") и значение поля. Имена полей прецедентного в чувствительной.

Обновление RFC 7230 не содержит никаких изменений по сравнению с RFC 2616 в этой части.


96
Ответ остается верным, в RFC 7230 говорится: «Каждое поле заголовка состоит из имени поля без учета регистра, за которым следует двоеточие («: »), необязательный начальный пробел, значение поля и необязательный конечный пробел».
Мартин Мюллер

6
Поля заголовка чувствительны к регистру при использовании PHP для получения значения поля заголовка с помощью метода apache_request_headers ().
Вред

7
Кто-нибудь может привести примеры популярных браузеров, которые не соответствуют спецификации в этом отношении?
Дэвид W

7
@Harm Это только потому, что сравнение строк в PHP чувствительно к регистру.
MrWhite

7
Для тех, кто ищет, здесь RFC 7230 прямо заявляет, что заголовки полей должны рассматриваться как нечувствительные к регистру: tools.ietf.org/html/rfc7230#section-3.2
JZ

238

Имена заголовков HTTP нечувствительны к регистру, в соответствии с RFC 2616 :

4,2:

Каждое поле заголовка состоит из имени, за которым следуют двоеточие (":") и значение поля. Имена полей не чувствительны к регистру.

( Значения полей могут быть или не быть чувствительными к регистру.)

Если вы доверяете основным браузерам соблюдать это, все готово.


Кстати, в отличие от большинства HTTP, методы (глаголы) являются чувствительны к регистру:

5.1.1 Метод

Маркер Метода указывает метод, который должен быть выполнен на
ресурсе, идентифицированном Request-URI. Метод чувствителен к регистру.

   Method         = "OPTIONS"                ; Section 9.2
                  | "GET"                    ; Section 9.3
                  | "HEAD"                   ; Section 9.4
                  | "POST"                   ; Section 9.5
                  | "PUT"                    ; Section 9.6
                  | "DELETE"                 ; Section 9.7
                  | "TRACE"                  ; Section 9.8
                  | "CONNECT"                ; Section 9.9
                  | extension-method
   extension-method = token

Другой комментарий сказал, что этот ответ устарел. Это правда? Если так, возможно, вы можете обновить его, чтобы люди не запутались.
скоростной самолет

36

tldr; Заголовки HTTP / 1.1 и HTTP / 2 нечувствительны к регистру.

Согласно RFC 7230 (HTTP / 1.1):

Каждое поле заголовка состоит из нечувствительного к регистру имени поля, за которым следует двоеточие (":"), необязательный начальный пробел, значение поля и необязательный конечный пробел.

https://tools.ietf.org/html/rfc7230#section-3.2

Также RFC 7540 (HTTP / 2):

Как и в HTTP / 1.x, имена полей заголовков представляют собой строки символов ASCII
, которые сравниваются без учета регистра.

https://tools.ietf.org/html/rfc7540#section-8.1.2


19
просто уточняю: имена полей не чувствительны к регистру; Значения полей могут быть чувствительны к регистру, в зависимости от имени поля.
Джулиан Решке

7
Продолжение цитирования из HTTP / 2 RFC: «Однако имена полей заголовка ДОЛЖНЫ быть преобразованы в строчные буквы до их кодирования в HTTP / 2. Запрос или ответ, содержащие имена полей заголовка верхнего регистра, ДОЛЖНЫ рассматриваться как неправильно сформированные (раздел 8.1.2.6)»
Борек Бернард

2
Я только что заметил, что часть «ДОЛЖНА быть преобразована в строчные буквы». Это почему? CamelCase кажется предпочтительным вариантом на практике (инструменты для разработчиков, популярные библиотеки кода), так почему же HTTP / 2 пытается пойти против этой тенденции?
Jimp

7
@jimp - поскольку стандарты касаются согласованности - использование верблюжьего падежа может быть неоднозначным - особенно с аббревиатурами, инициализацией и аббревиатурами. Например - будет ли это "Front-End-Https" или "Front-End-HTTPS" - "WWW-Authenticate" или "Www-Authenticate" - указание всех строчных букв устраняет неоднозначность путем стандартизации поля. Это в свою очередь упрощает обработку заголовков со всех сторон.
Фрейзер

16

header('Content-type: image/png') не работал с PHP 5.5, обслуживающим IE11, так как в изображении поток отображался как текст

header('Content-Type: image/png') работал, как на изображении появился как изображение

Единственная разница - это заглавная буква «Т».


18
Тогда очевидно, что есть проблема с реализацией, потому что все поля заголовка должны читаться без учета регистра. Апачская Скамья также испорчена. Он не любит строчные имена полей.
связь

8

Они не чувствительны к регистру. Фактически веб-сервер NodeJS явно преобразует их в нижний регистр, прежде чем сделать их доступными в объекте запроса.

Здесь важно отметить, что все заголовки представлены только в нижнем регистре, независимо от того, как клиент фактически отправил их. Это упрощает задачу анализа заголовков для любых целей.


Это потому, что узел / javascript чувствителен к регистру, поэтому чтобы упростить вещи, они нормализуют все в нижний регистр, то есть в действительности заголовки HTTP не чувствительны к регистру.
Svish

4

RFC для HTTP (как упомянуто выше) диктует, что заголовки нечувствительны к регистру, однако вы обнаружите, что в некоторых браузерах (я смотрю на вас, IE) использование заглавных букв в каждом слове имеет тенденцию быть лучшим:

Location: http://stackoverflow.com

Content-Type: text/plain

против

location: http://stackoverflow.com

content-type: text/plain

Это не стандарт «HTTP», а просто еще одна особенность браузера, о которой мы, как разработчики, должны думать.


3
Не могли бы вы предоставить какие-либо доказательства по этому поводу?
Джулиан Решке

3
Я имел в виду конкретный контрольный пример; У меня есть IE для тестирования.
Джулиан Решке

11
Почему именно он имеет тенденцию быть лучшим?
Свиш

Я сделаю браузер, который отправляет заголовки со случайной заглавной
буквой,

0

официально заголовки нечувствительны к регистру, однако обычной практикой является использование заглавной буквы в каждом слове.
но, поскольку это обычная практика, некоторые программы, такие как IE, предполагают, что заголовки пишутся с большой буквы.
поэтому, хотя в документах говорится, что они не чувствительны к регистру, плохие программисты в основном изменили документы.


-4

Слово Заголовки не чувствительно к регистру, но с правой стороны, как Content-Type, хорошей практикой является написать его таким образом, потому что его регистр чувствителен. как мой пример ниже

headers = headers.set('Content-Type'
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.