Les en-têtes HTTP sont-ils sensibles à la casse?


714

Dans un article de blog, j'utilise le code PHP suivant pour définir le type de contenu d'une réponse:

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

Je viens de recevoir un commentaire sur ce poste en disant que les content-typebesoins à l' actif, Content-type. Est-ce correct? Cela semble fonctionner pour moi avec tous les minuscules et j'ai supposé que les en-têtes HTTP étaient insensibles à la casse. Ou cela fonctionne-t-il simplement parce que les navigateurs sont agréables?


26
Il est insensible à la casse, mais si vous voulez résoudre le cas, il devrait être de type de contenu.
mc0e

10
FWIW, envoyer "charset" avec application / json est inutile. Il n'y a pas un tel paramètre.
Julian Reschke

5
@JulianReschke - C'est faux, charset est un paramètre valide dans l'en-tête Content-Type. Voir w3.org/International/articles/http-charset/index et developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type
cchamberlain

8
@NullUserException - l'inconvénient (à part les octets gaspillés) est de continuer à confondre les gens au sujet du paramètre charset. Faites simplement réparer ces composants à la place.
Julian Reschke

10
@JulianReschke a raison. L' affectation IANA application / json indique que charset n'a pas de sens pour ce type de support. ça ne fait rien. Veuillez ne pas l'ajouter, car c'est du bruit qui crée une confusion inutile.
Rétablir Monica 2331977

Réponses:


935

Les noms d'en-tête ne sont pas sensibles à la casse.

De RFC 2616 - "Hypertext Transfer Protocol - HTTP / 1.1" , Section 4.2, "En-têtes de message" :

Chaque champ d'en-tête se compose d'un nom suivi de deux points (":") et de la valeur du champ. Les noms de champ sont en casse sensibles à la casse.

La mise à jour de la RFC 7230 ne répertorie aucun changement par rapport à la RFC 2616 dans cette partie.


96
La réponse est toujours vraie, la RFC 7230 déclare: "Chaque champ d'en-tête se compose d'un nom de champ insensible à la casse suivi d'un deux-points (": "), d'un espace de début facultatif, de la valeur du champ et d'un espace de fin facultatif."
Martin Müller

6
Les champs d'en-tête sont sensibles à la casse lors de l'utilisation de PHP pour obtenir la valeur d'un champ d'en-tête en utilisant la méthode 'apache_request_headers ()'.
Harm

7
Quelqu'un peut-il fournir des exemples de navigateurs populaires qui ne respectent pas les spécifications à cet égard?
David W

7
@Harm C'est uniquement parce que la comparaison de chaînes en PHP est sensible à la casse.
MrWhite

7
Pour tous ceux qui recherchent, voici où la RFC 7230 indique explicitement que les en-têtes de champ doivent être traités comme insensibles à la casse: tools.ietf.org/html/rfc7230#section-3.2
JZ

238

Les noms d'en-tête HTTP ne respectent pas la casse, selon la RFC 2616 :

4.2:

Chaque champ d'en-tête se compose d'un nom suivi de deux points (":") et de la valeur du champ. Les noms de champ ne respectent pas la casse.

(Les valeurs de champ peuvent ou non être sensibles à la casse.)

Si vous faites confiance aux principaux navigateurs pour respecter cela, vous êtes prêt.


BTW, contrairement à la plupart de HTTP, les méthodes (verbes) sont sensibles à la casse:

5.1.1 Méthode

Le jeton Méthode indique la méthode à exécuter sur la
ressource identifiée par l'URI de demande. La méthode est sensible à la casse.

   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

Un autre commentaire a déclaré que cette réponse était obsolète. Est-ce vrai? Si c'est le cas, vous pouvez peut-être le mettre à jour afin que les gens ne se trompent pas.
speedplane

36

tldr; les en-têtes HTTP / 1.1 et HTTP / 2 ne respectent pas la casse.

Selon RFC 7230 (HTTP / 1.1):

Chaque champ d'en-tête se compose d'un nom de champ insensible à la casse suivi d'un deux-points (":"), d'un espace de début facultatif, de la valeur du champ et d'un espace de fin facultatif.

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

En outre, RFC 7540 (HTTP / 2):

Tout comme dans HTTP / 1.x, les noms de champ d'en-tête sont des chaînes de
caractères ASCII qui sont comparées de manière non sensible à la casse.

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


19
juste pour clarifier: les noms de champ ne sont pas sensibles à la casse; les valeurs de champ peuvent être sensibles à la casse, selon le nom du champ.
Julian Reschke

7
Citation continue de HTTP / 2 RFC: "Cependant, les noms de champ d'en-tête DOIVENT être convertis en minuscules avant leur codage dans HTTP / 2. Une demande ou une réponse contenant des noms de champ d'en-tête en majuscule DOIT être traitée comme incorrecte (Section 8.1.2.6)"
Borek Bernard

2
Je viens de remarquer la partie "DOIT être converti en minuscules ..." aussi. Pourquoi donc? CamelCase semble être le boîtier préféré dans la pratique (outils de développement, bibliothèques de code populaires), alors pourquoi HTTP / 2 tenterait-il d'aller à l'encontre de cette tendance?
jimp

7
@jimp - parce que les normes concernent la cohérence - l'utilisation de la camel case peut être ambiguë - en particulier avec les abréviations, les initialisations et les acronymes. Par exemple - serait-ce "Front-End-Https" ou "Front-End-HTTPS" - "WWW-Authenticate" ou "Www-Authenticate" - en spécifiant que tous les minuscules suppriment l'ambiguïté en normalisant le champ. Cela simplifie à son tour la gestion des en-têtes tout autour.
Fraser

16

header('Content-type: image/png') ne fonctionnait pas avec PHP 5.5 servant IE11, comme dans le flux d'image était affiché sous forme de texte

header('Content-Type: image/png') travaillé, comme dans l'image apparue comme une image

La seule différence est le «T» majuscule.


18
Ensuite, il y a évidemment un problème avec l'implémentation parce que tous les champs d'en-tête sont censés être lus sans respecter la casse. Apache Bench est également foiré. Il n'aime pas les noms de champs en minuscules.
lien

8

Ils ne sont pas sensibles à la casse. En fait, le serveur Web NodeJS les convertit explicitement en minuscules, avant de les rendre disponibles dans l'objet de requête.

Il est important de noter ici que tous les en-têtes sont représentés en minuscules uniquement, quelle que soit la façon dont le client les a réellement envoyés. Cela simplifie la tâche d'analyse des en-têtes pour n'importe quel but.


C'est parce que node / javascript est sensible à la casse, donc pour simplifier les choses, ils normalisent tout en minuscules, ce qui signifie que les en-têtes HTTP en vigueur ne respectent pas la casse.
Svish

4

Le RFC pour HTTP (tel que cité ci-dessus) dicte que les en-têtes ne respectent pas la casse, mais vous constaterez qu'avec certains navigateurs (je vous regarde, IE), la mise en majuscule de chacun des mots a tendance à être la meilleure:

Location: http://stackoverflow.com

Content-Type: text/plain

contre

location: http://stackoverflow.com

content-type: text/plain

Ce n'est pas la norme "HTTP", mais juste une autre des bizarreries du navigateur, nous en tant que développeurs, devons penser.


3
Pourriez-vous fournir des preuves à ce sujet?
Julian Reschke

3
Je voulais dire un cas de test concret; J'ai un IE pour tester.
Julian Reschke

11
Pourquoi cela a-t-il tendance à être le meilleur?
Svish

Je ferai un navigateur qui envoie des en-têtes avec une capitalisation aléatoire juste pour baiser avec les développeurs
GideonMax

0

officiellement, les en-têtes ne respectent pas la casse, cependant, il est courant de mettre en majuscule la première lettre de chaque mot.
mais, comme c'est une pratique courante, certains programmes comme IE supposent que les en-têtes sont capitalisés.
Ainsi, alors que les documents disent qu'ils ne respectent pas la casse, les mauvais programmeurs ont fondamentalement changé les documents.


-4

le mot Headers n'est pas sensible à la casse, mais à droite comme le Content-Type, il est recommandé de l'écrire de cette façon, car sa casse est sensible. comme mon exemple ci-dessous

headers = headers.set('Content-Type'
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.