Czy w nagłówkach HTTP rozróżniana jest wielkość liter?


712

W poście na blogu używam następującego PHP, aby ustawić typ zawartości odpowiedzi:

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

Właśnie komentarz na to stanowisko, mówiąc, że content-typemusi być kapitalizowane, Content-type. Czy to jest poprawne? Wydaje mi się, że działa ze wszystkimi małymi literami i założyłem, że nagłówki HTTP nie uwzględniają wielkości liter. A może po prostu działa, ponieważ przeglądarki są fajne?


26
Rozróżnia małe i duże litery, ale jeśli zamierzasz naprawić skrzynkę, powinna to być „Content-Type”.
mc0e

10
FWIW, wysyłanie „zestawu znaków” z aplikacją / json jest bezcelowe. Nie ma takiego parametru.
Julian Reschke,

5
@JulianReschke - To fałsz, zestaw znaków jest prawidłowym parametrem w nagłówku Content-Type. Zobacz w3.org/International/articles/http-charset/index and developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type
cchamberlain

8
@NullUserException - wadą (oprócz zmarnowanych bajtów) jest dalsze wprowadzanie ludzi w błąd co do parametrów zestawu znaków. Zamiast tego napraw te komponenty.
Julian Reschke

10
@JulianReschke jest poprawny. Aplikacja IANA / przypisanie json mówi, że charset nie ma znaczenia dla tego typu mediów. nic nie robi. Proszę nie dodawać, ponieważ hałas prowadzi do niepotrzebnego zamieszania.
Przywróć Monikę 2331977

Odpowiedzi:


934

W nazwach nagłówków nie jest rozróżniana wielkość liter.

Z RFC 2616 - „Protokół przesyłania hipertekstu - HTTP / 1.1” , sekcja 4.2, „Nagłówki wiadomości” :

Każde pole nagłówka składa się z nazwy, dwukropka („:”) i wartości pola. Nazwy pól są CASE- w czuły.

Aktualizacja RFC 7230 nie zawiera żadnych zmian w stosunku do RFC 2616 w tej części.


96
Odpowiedź jest nadal prawdziwa, RFC 7230 stwierdza: „Każde pole nagłówka składa się z nazwy pola bez rozróżniania wielkości liter, po której następuje dwukropek („: ”), opcjonalne wiodące białe znaki, wartość pola i opcjonalne końcowe białe znaki.”
Martin Müller,

6
W polach nagłówka rozróżniana jest wielkość liter, gdy używa się PHP do uzyskania wartości pola nagłówka za pomocą metody „apache_request_headers ()”.
Harm

7
Czy ktoś może podać przykłady popularnych przeglądarek, które nie są zgodne ze specyfikacją w tym zakresie?
David W

7
@Harm To tylko dlatego, że porównanie ciągów znaków w PHP rozróżnia wielkość liter.
MrWhite

7
Dla każdego, kto szuka, tutaj RFC 7230 wyraźnie stwierdza, że ​​nagłówki pól powinny być traktowane jako bez rozróżniania wielkości liter: tools.ietf.org/html/rfc7230#section-3.2
JZ

238

Nazwy nagłówków HTTP nie rozróżniają wielkości liter, zgodnie z RFC 2616 :

4.2:

Każde pole nagłówka składa się z nazwy, dwukropka („:”) i wartości pola. Nazwy pól nie uwzględniają wielkości liter.

( Wartości pól mogą, ale nie muszą uwzględniać wielkości liter).

Jeśli ufasz, że główne przeglądarki tego przestrzegają, wszystko gotowe.


BTW, w odróżnieniu od większości HTTP, metody (czasowniki) wielkość liter:

5.1.1 Metoda

Token metody wskazuje metodę, która ma zostać wykonana na
zasobie określonym przez identyfikator URI żądania. W metodzie rozróżniana jest wielkość liter.

   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

Inny komentarz mówi, że ta odpowiedź jest nieaktualna. Czy to prawda? Jeśli tak, być może możesz go zaktualizować, aby ludzie się nie mylili.
Speedplane

36

tldr; zarówno nagłówki HTTP / 1.1, jak i HTTP / 2 nie rozróżniają wielkości liter.

Zgodnie z RFC 7230 (HTTP / 1.1):

Każde pole nagłówka składa się z nazwy pola bez rozróżniania wielkości liter, po której następuje dwukropek („:”), opcjonalne początkowe białe znaki, wartość pola i opcjonalne końcowe białe znaki.

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

Ponadto RFC 7540 (HTTP / 2):

Podobnie jak w HTTP / 1.x, nazwy pól nagłówka są ciągami znaków ASCII,
które są porównywane bez rozróżniania wielkości liter.

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


19
wyjaśnienie: nazwy pól nie uwzględniają wielkości liter; W wartościach pól rozróżniana jest wielkość liter, w zależności od nazwy pola.
Julian Reschke,

7
Ciąg dalszy cytat z HTTP / 2 RFC: „Jednak nazwy pól nagłówka MUSZĄ zostać przekonwertowane na małe litery przed ich kodowaniem w HTTP / 2. Żądanie lub odpowiedź zawierające nazwy pól nagłówka MUSZĄ być traktowane jako zniekształcone (sekcja 8.1.2.6)”
Borek Bernard

1
Właśnie zauważyłem część „MUSI zostać przekonwertowana na małe ...” również. Dlaczego? CamelCase wydaje się być preferowaną obudową w praktyce (narzędzia dla programistów, popularne biblioteki kodów), więc dlaczego HTTP / 2 miałby się sprzeciwiać temu trendowi?
jimp

7
@ jimp - ponieważ standardy dotyczą spójności - użycie wielbłąda może być niejednoznaczne - szczególnie w przypadku skrótów, inicjalizacji i akronimów. Na przykład - czy byłoby to „Front-End-Https” czy „Front-End-HTTPS” - „WWW-Authenticate” lub „Www-Authenticate” - określenie wszystkich małych liter usuwa dwuznaczność poprzez standaryzację pola. To z kolei upraszcza obsługę wszystkich nagłówków.
Fraser,

16

header('Content-type: image/png') nie działał z PHP 5.5 obsługującym IE11, ponieważ w strumieniu obrazu pokazano jako tekst

header('Content-Type: image/png') działał, jak na obrazie pojawił się jako obraz

Jedyną różnicą jest duża litera „T”.


18
Wtedy oczywiście jest problem z implementacją, ponieważ wszystkie pola nagłówka powinny być odczytywane jako bez rozróżniania wielkości liter. Ławka Apache jest również pomieszana. Nie lubi małych nazw pól.
obligacja

8

Nie rozróżniają wielkości liter. W rzeczywistości serwer WWW NodeJS jawnie konwertuje je na małe litery, zanim udostępni je w obiekcie żądania.

Należy tutaj zauważyć, że wszystkie nagłówki są reprezentowane tylko małymi literami, niezależnie od tego, w jaki sposób klient je faktycznie wysłał. Upraszcza to zadanie analizowania nagłówków w dowolnym celu.


Jest tak, ponieważ w węźle / javascript rozróżniana jest wielkość liter, więc w celu uproszczenia rzeczy normalizują wszystko do małych liter, co oznacza, że ​​nagłówki HTTP nie uwzględniają wielkości liter.
Svish

4

RFC dla HTTP (jak cytowano powyżej) dyktuje, że w nagłówkach nie jest rozróżniana wielkość liter, jednak przekonasz się, że w niektórych przeglądarkach (patrzę na ciebie, IE), pisanie wielkimi literami każdego słowa jest najlepsze:

Location: http://stackoverflow.com

Content-Type: text/plain

vs

location: http://stackoverflow.com

content-type: text/plain

To nie jest standard „HTTP”, ale po prostu kolejne dziwactwo przeglądarki, o czym my, programiści, musimy pomyśleć.


3
Czy możesz podać jakieś dowody?
Julian Reschke

3
Miałem na myśli konkretny przypadek testowy; Mam IE do przetestowania.
Julian Reschke

11
Dlaczego dokładnie tak jest najlepiej?
Svish

Zrobię przeglądarkę, która wysyła nagłówki z przypadkowymi
dużymi

0

oficjalnie w nagłówkach nie jest rozróżniana wielkość liter, jednak powszechną praktyką jest pisanie wielkimi literami każdego słowa.
ale ponieważ jest to powszechna praktyka, niektóre programy, takie jak IE, zakładają, że nagłówki są pisane wielkimi literami.
więc chociaż doktorzy mówią, że nie rozróżniają wielkości liter, źli programiści zasadniczo zmienili dokumenty.


-4

w nagłówku słowa nie rozróżniana jest wielkość liter, ale po prawej stronie, podobnie jak typ zawartości, dobrą praktyką jest pisanie go w ten sposób, ponieważ rozróżnia duże i małe litery. jak mój przykład poniżej

headers = headers.set('Content-Type'
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.