En-têtes HTTP personnalisés: conventions de nommage

plusieurs de nos utilisateurs nous ont demandé d'inclure des données relatives à leur compte dans le en-têtes HTTP des requêtes 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 nommant , format ... etc.

aussi, n'hésitez pas à poster n'importe quelle utilisation Intelligente de ceux-ci que vous avez trébuché sur le web; nous essayons de mettre en œuvre ceci en utilisant quoi de meilleur qu'une cible :)

884
demandé sur Julien Genestoux 2010-08-25 01:59:38
la source

6 ответов

en juin 2012, l'abandon de la recommandation d'utiliser le préfixe" X - "est devenu officiel en tant que RFC 6648 . Ci-dessous sont des villes de pertinence:

3. Recommandations pour les Créateurs de Nouveaux Paramètres

...

  1. ne doivent pas préfixer leur nom de paramètre avec "X -" ou similaire construire.

4. Recommandations pour les Concepteurs de Protocole

...

  1. construit à être enregistrés.

  2. ne doit pas stipuler qu'un paramètre avec un préfixe" X - " ou des concepts similaires doivent être compris comme non normalisés.

  3. NE DOIT PAS stipuler qu'un paramètre sans préfixe "X -" ou des concepts similaires doivent être compris comme normalisés.

Note que "ne DEVRAIT PAS" ("découragés") n'est pas la même chose que "ne DOIT PAS" ("interdit"), voir aussi RFC 2119 pour un autre spec 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 pas recommandé et vous ne pouvez pas les documenter comme s'ils étaient standards publics.


en juin 2011, le premier projet de l'IETF a été posté à déprécier la recommandation d'utiliser le préfixe "X -" pour les en-têtes non standard. La raison en est que lorsque des en-têtes non standards préfixés avec "X-" deviennent standards, la suppression du préfixe "X-" rompt la compatibilité en arrière, forçant les protocoles d'application à supporter les deux noms (par exemple x-gzip et gzip sont maintenant équivalents). Ainsi, l' il est recommandé de simplement les nommer raisonnablement sans le préfixe "X -".


la recommandation est était pour commencer leur nom par" X -". E. g. X-Forwarded-For , X-Requested-With . Ceci est également mentionné dans A. O. section 5 de RFC 2047 .

972
répondu BalusC 2016-10-10 17:57:40
la source

la question mérite une relecture. La question posée n'est pas semblable aux préfixes des fournisseurs dans les propriétés CSS, où il est approprié de prévoir l'avenir et de penser au soutien des fournisseurs et aux normes officielles. La question posée est plus proche du choix des noms de paramètres de requête D'URL. Personne ne devrait se soucier de ce qu'ils sont. Mais l'espacement des noms est une chose parfaitement valide -- et commune, et correcte -- à faire.

Justification:

Il s'agit d'environ conventions parmi les développeurs pour personnalisé, applications spécifiques en-têtes -- données pertinentes pour leur compte " qui n'ont rien à voir avec les fournisseurs, les organismes de normes, ou les protocoles à être mis en œuvre par des tiers, sauf que le développeur en question a simplement besoin d'é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, le" X-Gzip/Gzip " et Les exemples "X-Forwarded-For/Forwarded-For" donnés sont sans objet. La question posée concerne les conventions dans le contexte d'une API privée, qui s'apparente aux conventions de nommage des paramètres de requête URL. Il s'agit d'une question de préférence et d'espacement des noms; les préoccupations au sujet de "X-ClientDataFoo" pris en charge par un mandataire ou un fournisseur sans le "X" sont clairement déplacées.

il n'y a rien de spécial ou de magique dans le préfixe" X -", mais cela aide à préciser qu'il s'agit d'un en-tête personnalisé. En fait, RFC-6648 et al aide à renforcer la cause de l'utilisation d'un préfixe "X -", parce que -- comme les vendeurs de clients et serveurs HTTP abandonnent le préfixe -- votre application spécifique, privée-API, personal-data-passing-mechanism devient encore mieux-isolé contre les collisions nom-espace avec le petit nombre de noms d'en-tête réservés officiels. Cela dit, Ma préférence personnelle et la recommandation est d'aller un peu plus loin et faire par exemple "X-ACME-ClientDataFoo" (si votre compagnie de widget est "ACME").

IMHO the IETF la spécification n'est pas suffisamment spécifique pour répondre à la question de L'OP, car elle ne distingue pas entre les cas d'utilisation complètement différents: (a) les vendeurs introduisant de nouvelles fonctionnalités applicables à l'échelle mondiale comme "Forwarded-For" d'une part, et (B) les développeurs d'applications passant des chaînes spécifiques aux applications au client et au serveur. Le spec ne concerne que le premier, (A). La question est ici de savoir s'il existe des conventions pour B). Il y a des. Ils comporter le regroupement des 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 commode et légitime pour B), et n'entre pas en conflit avec A). Plus les vendeurs cesseront d'utiliser "X-" pour (a), plus les (B) deviendront clairs.

exemple:

Google (qui portent un peu de poids dans les différents organismes de normalisation) sont, à compter d'aujourd'hui, 20141102 dans cette édition légères à ma réponse -- Utilisant actuellement "X-Mod-Pagespeed" pour indiquer la version de leur module Apache impliqué dans la transformation d'une réponse donnée. Est-ce que Quelqu'un suggère vraiment que Google devrait utiliser "Mod-Pagespeed", sans le "X-", et/ou demander à L'IETF de bénir son utilisation?

résumé:

Si vous utilisez des en-têtes HTTP personnalisés (comme une alternative parfois appropriée aux cookies) dans votre application pour transmettre des données à/depuis votre serveur, et ces en-têtes sont, explicitement, pas destiné à être utilisé 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.

424
répondu cweekly 2015-01-26 11:36:58
la source

le format des en-têtes HTTP est défini dans la spécification HTTP. Je vais parler de HTTP 1.1, pour lequel la spécification est RFC 2616 . Dans la section 4.2, "en-têtes de messages", la structure générale d'un en-tête est définie:

   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, token et TEXT. Les deux sont définies à la section 2.2, "règles de base". Jeton est:

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

repose à son tour sur CHAR, CTL et 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

texte:

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

où LWS est linéaire espace blanc, dont la définition Je ne vais pas reproduire, et L'OCTET est:

   OCTET          = <any 8-bit sequence of data>

il y a une note accompagnant la définition:

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, une certaine ponctuation, pas un beaucoup d'autre. Deuxièmement, il n'y a rien dans la définition d'un en-tête valeur qui le restreint à ASCII ou exclut les caractères 8 bits: il est explicitement composé d'octets, avec seulement les caractères de contrôle barrés (notez que CR et LF sont considérés comme des contrôles). En outre, le commentaire sur la production de texte implique que les octets doivent être interprétés comme étant dans la norme 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.

donc, pour répondre à @BalusC en particulier, il est assez clair que selon la spécification, les valeurs d'en-tête sont en ISO-8859-1. J'ai envoyé des caractères high-8859-1 (en particulier des voyelles accentuées) dans un en-tête de Tomcat, et les ai fait interpréter correctement par Firefox, donc dans une certaine mesure, cela fonctionne dans la pratique aussi bien que dans la théorie (bien qu'il s'agisse d'un en-tête de localisation, qui contient une URL, et ces caractères ne sont pas légaux dans URLs, donc c'était en fait illégal, mais sous une règle différente!).

cela dit, je ne voudrais pas compter sur les ISO-8859-1 travail sur tous les serveurs, les serveurs proxy, et les clients, donc je m'en tiendrais aux ASCII comme une question de programmation défensives.

56
répondu Tom Anderson 2010-08-25 23:49:17
la source

le registre d'en-tête de nom de champ est défini dans RFC3864 , et il n'y a rien de spécial avec"X -".

autant que je sache, il n'y a pas de directives pour les en-têtes privés; dans le doute, évitez-les. Ou consultez le cadre D'Extension HTTP ( RFC 2774 ).

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

14
répondu Julian Reschke 2010-08-25 11:33:56
la source

modifier, ou plus correctement, ajouter headers HTTP supplémentaires est un excellent outil de débogage de code si rien d'autre.

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

Une approche consiste à écrire les données dans un fichier journal local et afficher ce fichier plus tard. Une autre est d'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 autrement été très difficiles à tracer.

14
répondu g1smd 2011-07-04 13:29:21
la source

RFC6648 recommande de supposer que votre en-tête personnalisé " Pourrait devenir standardisé, public, couramment déployé, ou Utilisable à travers plusieurs implémentations."Par conséquent, il est recommandé de ne pas le préfixer par "X-" ou des constructions similaires.

Cependant, il est une exception "où il est extrêmement peu probable que [votre titre] sera jamais normalisé."Pour de tels en-têtes" implémentation-specific and private-use", le RFC dit un namespace tel que en tant que fournisseur de préfixe est justifiée.

3
répondu Edward Brey 2018-07-24 16:50:45
la source

Autres questions sur http http-headers