En-têtes HTTP personnalisés : conventions d'appellation

Question

Plusieurs de nos utilisateurs nous ont demandé d'inclure les données relatives à leur compte dans la base de données de l'UE. En-têtes HTTP des demandes que nous leur envoyons, ou même des réponses qu'ils obtiennent de notre API. Quelle est la convention générale pour ajouter des en-têtes HTTP personnalisés, en termes de dénomination , format ... etc.

De plus, n'hésitez pas à poster toute utilisation intelligente de ces éléments que vous avez trouvée sur le web ; nous essayons de mettre en œuvre ce système en utilisant ce qu'il y a de mieux comme cible :)

Answer 1

La recommandation es était de commencer leur nom par "X-". Par exemple. X-Forwarded-For , X-Requested-With . Ceci est également mentionné dans l'article 5 a.o. de la loi sur la protection de l'environnement. RFC 2047 .

---

Mise à jour 1 : En juin 2011, le premier Projet IETF a été posté sur déprécier la recommandation d'utiliser le préfixe "X-" pour les en-têtes non standard. La raison en est que lorsque les en-têtes non standard préfixés par "X-" deviennent standard, la suppression du préfixe "X-" rompt la compatibilité ascendante, obligeant les protocoles d'application à prendre en charge les deux noms (par ex, x-gzip & gzip sont désormais équivalentes). La recommandation officielle est donc de les nommer simplement raisonnablement sans le préfixe "X-".

---

Mise à jour 2 : Le juin 2012, la dépréciation de la recommandation d'utiliser le préfixe "X-" est devenue officielle en tant que RFC 6648 . Vous trouverez ci-dessous des citations pertinentes :

3. Recommandations pour les créateurs de nouveaux paramètres

...

3. NE DEVRAIENT PAS préfixer le nom de leurs paramètres par "X-" ou par un signe similaire. similaires.

4. Recommandations pour les concepteurs de protocoles

...

4. NE DEVRAIT PAS interdire les paramètres avec un préfixe "X-" ou un code similaire. d'être enregistrés.

5. NE DOIT PAS stipuler qu'un paramètre avec un préfixe "X-" ou des constructions similaires doit être compris comme non normalisé.

6. NE DOIT PAS stipuler qu'un paramètre sans préfixe "X-" ou des constructions similaires doit être compris comme normalisé.

Notez que "SHOULD NOT" ("découragé") n'est pas la même chose que "MUST NOT" ("interdit"), voir aussi RFC 2119 pour une autre spécification sur ces mots-clés. En d'autres termes, vous pouvez continuer à utiliser des en-têtes préfixés "X-", mais ce n'est plus officiellement recommandé et vous ne pouvez certainement pas les documenter comme s'il s'agissait d'une norme publique.

---

Résumé :

• la recommandation officielle est de les nommer simplement raisonnablement sans le préfixe "X-".
• vous pouvez continuer à utiliser des en-têtes préfixés "X-", mais ce n'est plus officiellement recommandé et vous ne devez absolument pas les documenter comme s'il s'agissait de normes publiques

Answer 2

La question mérite d'être relue. La question posée n'a rien à voir avec les préfixes des fournisseurs dans les propriétés CSS, pour lesquels il convient de prévoir l'avenir et de penser au support des fournisseurs et aux normes officielles. La question posée s'apparente davantage au choix des noms des paramètres d'interrogation des URL. Personne ne devrait se soucier de ce qu'ils sont. Mais espacer les noms des paramètres personnalisés est une chose parfaitement valable, courante et correcte.

Justification :
Il s'agit de des conventions entre développeurs pour les en-têtes personnalisés et spécifiques à une application -- " les données relatives à leur compte " -- qui n'ont rien à voir avec les vendeurs, les organismes de normalisation ou les protocoles à mettre en œuvre par des tiers, si ce n'est que le développeur en question doit simplement éviter les noms d'en-tête qui peuvent avoir une autre utilisation prévue par les serveurs, les mandataires ou les clients. Pour cette raison, les exemples donnés de "X-Gzip/Gzip" et "X-Forwarded-For/Forwarded-For" sont sans objet. La question posée concerne les conventions dans le contexte d'une API privée, à l'instar des conventions de dénomination des paramètres de requête d'URL. Il s'agit d'une question de préférence et d'espacement des noms ; les inquiétudes concernant la prise en charge de "X-ClientDataFoo" par un mandataire ou un fournisseur sans le "X" sont clairement déplacées.

Le préfixe "X-" n'a rien de spécial ou de magique, mais il permet d'indiquer clairement qu'il s'agit d'un en-tête personnalisé. En fait, les RFC-6648 et autres contribuent à renforcer les arguments en faveur de l'utilisation d'un préfixe "X-", car, à mesure que les vendeurs de clients et de serveurs HTTP abandonnent le préfixe, votre mécanisme de passage de données personnelles, spécifique à votre application et à votre API privée est encore mieux protégé contre les collisions d'espace de noms avec le petit nombre de noms d'en-têtes officiels réservés. Cela dit, ma préférence personnelle et ma recommandation sont d'aller un peu plus loin et de faire par exemple "X-ACME-ClientDataFoo" (si votre société de widgets est "ACME").

Je pense que la spécification de l'IETF n'est pas suffisamment spécifique pour répondre à la question du PO, car elle ne fait pas la distinction entre des cas d'utilisation complètement différents : (A) les fournisseurs introduisant de nouvelles fonctionnalités applicables globalement comme "Forwarded-For" d'une part, et (B) les développeurs d'applications passant des chaînes spécifiques à l'application vers/depuis le client et le serveur. La spécification ne concerne que le premier cas, (A). La question ici est de savoir s'il existe des conventions pour (B). Il en existe. Elles consistent à regrouper les paramètres par ordre alphabétique et à les séparer des nombreux en-têtes de type (A) pertinents pour les normes. L'utilisation du préfixe "X-" ou "X-ACME-" est pratique et légitime pour (B), et n'entre pas en conflit avec (A). Plus les fournisseurs cesseront d'utiliser le préfixe "X-" pour les en-têtes de type (A), plus les en-têtes de type (B) seront clairement distincts.

Exemple :
Google (qui a un peu de poids dans les divers organismes de normalisation) utilise actuellement - à partir d'aujourd'hui, 20141102 dans cette légère modification de ma réponse - "X-Mod-Pagespeed" pour indiquer la version de leur module Apache impliqué dans la transformation d'une réponse donnée. Quelqu'un suggère-t-il vraiment que Google devrait utiliser "Mod-Pagespeed", sans le "X-", et/ou demander à l'IETF d'approuver son utilisation ?

Résumé :
Si vous utilisez des en-têtes HTTP personnalisés (comme alternative parfois appropriée aux cookies) dans votre application pour transmettre des données à/depuis votre serveur, et que ces en-têtes ne sont, explicitement, PAS destinés à être utilisés en dehors du contexte de votre application, l'espacement des noms avec un préfixe "X-" ou "X-FOO-" est une convention raisonnable et courante.

Answer 3

Le format des en-têtes HTTP est défini dans la spécification HTTP. Je vais parler de HTTP 1.1, dont la spécification est la suivante RFC 2616 . La section 4.2, "En-têtes de message", définit la structure générale d'un en-tête :

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

Cette définition repose sur deux piliers principaux, le jeton et le TEXTE. Tous deux sont définis à la section 2.2, "Règles de base". Le jeton est :

   token          = 1*<any CHAR except CTLs or separators>

Il repose à son tour sur le CHAR, le CTL et les séparateurs :

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

Le texte est :

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

Où LWS est l'espace blanc linéaire, dont je ne reproduirai pas la définition, et OCTET est :

   OCTET          = <any 8-bit sequence of data>

La définition est accompagnée d'une note :

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

Donc, deux conclusions. Tout d'abord, il est clair que l'en-tête nom doit être composé d'un sous-ensemble de caractères ASCII - alphanumériques, quelques signes de ponctuation, pas grand-chose d'autre. Deuxièmement, il n'y a rien dans la définition d'un en-tête valeur qui le limite à l'ASCII ou exclut les caractères 8 bits : il est explicitement composé d'octets, seuls les caractères de contrôle étant interdits (notez que CR et LF sont considérés comme des contrôles). De plus, le commentaire sur la production TEXT implique que les octets doivent être interprétés comme étant en ISO-8859-1, et qu'il existe un mécanisme d'encodage (qui est horrible, soit dit en passant) pour représenter les caractères en dehors de cet encodage.

Ainsi, pour répondre à @BalusC en particulier, il est tout à fait clair que selon la spécification, les valeurs d'en-tête sont en ISO-8859-1. J'ai envoyé des caractères de haut-8859-1 (plus précisément, certaines voyelles accentuées utilisées en français) dans un en-tête de Tomcat, et ils ont été interprétés correctement par Firefox, donc dans une certaine mesure, cela fonctionne aussi bien en pratique qu'en théorie (bien qu'il s'agisse d'un en-tête Location, qui contient une URL, et que ces caractères ne soient pas légaux dans les URL, donc c'était en fait illégal, mais en vertu d'une règle différente !)

Cela dit, je ne compterais pas sur le fait que la norme ISO-8859-1 fonctionne sur tous les serveurs, proxies et clients, et je m'en tiendrais donc à l'ASCII par mesure de précaution.

Answer 4

Modifier, ou plus exactement, en ajoutant des en-têtes HTTP supplémentaires est un excellent outil de débogage de code, à défaut d'autre chose.

Lorsqu'une demande d'URL renvoie une redirection ou une image, il n'y a pas de "page" html sur laquelle écrire temporairement les résultats du code de débogage - du moins pas une qui soit visible dans un navigateur.

Une approche consiste à écrire les données dans un fichier journal local et à consulter ce fichier ultérieurement. Une autre consiste à ajouter temporairement des en-têtes HTTP reflétant les données et les variables en cours de débogage.

J'ajoute régulièrement des en-têtes HTTP supplémentaires comme X-fubar-somevar : ou X-testing-someresult : pour tester les choses - et j'ai trouvé beaucoup de bogues qui auraient été autrement très difficiles à repérer.

Answer 5

Le registre des noms de champs d'en-tête est défini dans le document suivant RFC3864 et il n'y a rien de spécial avec "X-".

Pour autant que je sache, il n'existe aucune directive concernant les en-têtes privés ; dans le doute, évitez-les. Vous pouvez aussi jeter un coup d'œil au HTTP Extension Framework ( RFC 2774 ).

Il serait intéressant de comprendre davantage le cas d'utilisation ; pourquoi l'information ne peut-elle pas être ajoutée au corps du message ?