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

714

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

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

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

Svish
источник
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 явно преобразует их в нижний регистр, прежде чем сделать их доступными в объекте запроса.

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

jayarjo
источник
Это потому, что узел / 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, предполагают, что заголовки пишутся с большой буквы.
поэтому, хотя в документах говорится, что они не чувствительны к регистру, плохие программисты в основном изменили документы.

GideonMax
источник
-4

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

headers = headers.set('Content-Type'
ППК
источник