Question En-têtes HTTP personnalisés: conventions de dénomination


Plusieurs de nos utilisateurs nous ont demandé d'inclure des données relatives à leur compte 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 appellation, format... etc.

En outre, n'hésitez pas à poster toute utilisation intelligente de ceux que vous avez trébuché sur le web; Nous essayons d'implémenter ceci en utilisant ce qu'il y a de mieux là-bas comme cible :)


866
2017-08-24 21:59


origine


Réponses:


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

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

...

  1. NE DEVRAIT PAS préfixer leurs noms de paramètres avec "X-" ou similaire      construit.

4. Recommandations pour les concepteurs de protocole

...

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

  2. NE DOIT PAS stipuler qu'un paramètre avec un préfixe "X-" ou      Des constructions similaires doivent être comprises comme non normalisées.

  3. NE DOIT PAS stipuler qu'un paramètre sans préfixe "X-" ou      Des constructions similaires doivent être comprises comme standardisées.

Notez que "NE DEVRAIT PAS" ("découragé") n'est pas le même que "NE DOIT PAS" ("interdit"), voir aussi RFC 2119 pour une autre spécification sur ces mots-clés. En d'autres termes, vous pouvez continuer à utiliser les en-têtes préfixés "X-", mais ce n'est pas recommandé et vous ne pouvez pas les documenter comme s'ils étaient standard.


En juin 2011, le premier Projet de l'IETF a été posté à désapprouver 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 avec "X-" deviennent standard, la suppression du préfixe "X-" rompt la compatibilité ascendante, forçant les protocoles d'application à prendre en charge les deux noms (par exemple, x-gzip & gzip sont maintenant équivalents). Donc, la recommandation est de les nommer sensiblement sans le préfixe "X-".


La recommandation est  était pour commencer leur nom avec "X-". Par exemple. X-Forwarded-For, X-Requested-With. Ceci est également mentionné dans a.o. l'article 5 de RFC 2047.


956
2017-08-24 22:02



La question mérite d'être relue. La question posée n'est pas similaire aux préfixes de fournisseurs dans les propriétés CSS, où la pérennité et la réflexion sur le support des fournisseurs et les normes officielles sont appropriées. 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 personnalisés est une chose parfaitement valide - et commune, et correcte - à faire.

Raisonnement:
C'est à propos de conventions parmi les développeurs pour les en-têtes personnalisés, spécifiques aux applications - "données pertinentes pour leur compte"- qui n'ont rien à voir avec les fournisseurs, les organismes de normalisation, ou les protocoles à mettre en œuvre par des tiers, sauf que le développeur en question doit simplement éviter les noms d'en-tête susceptibles d'être utilisés par des serveurs, des mandataires ou des clients. raison, les exemples "X-Gzip / Gzip" et "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, semblable aux conventions de nommage des paramètres de requête URL. une question de préférence et d'espacement des noms: les inquiétudes concernant le fait que "X-ClientDataFoo" soit pris en charge par n'importe quel proxy ou fournisseur sans le "X" sont clairement égaré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 aident à soutenir l'utilisation d'un préfixe "X-", car - en tant que fournisseurs de clients HTTP et serveurs abandonnent le préfixe - votre API spécifique à l'application, API privée, données personnelles Le mécanisme passing est de mieux en mieux protégé contre les collisions d'espaces de noms avec le petit nombre de noms d'en-têtes réservés officiels. Cela dit, ma préférence personnelle et ma recommandation sont d'aller plus loin et de faire, par exemple, "X-ACME-ClientDataFoo" (si votre société de widgets est "ACME").

À mon humble avis la spécification IETF est insuffisamment spécifique pour répondre à la question OP, car il ne distingue pas entre les cas d'utilisation complètement différents: (A) les fournisseurs introduisant de nouvelles fonctionnalités applicables globalement comme "Forwarded-For", (B) développeurs d'applications transmettant des chaînes spécifiques à l'application vers / depuis le client et le serveur. La spécification ne concerne que la première, (A). La question ici est de savoir s'il existe des conventions pour (B). Il y a. Ils consistent à regrouper les paramètres par ordre alphabétique et à les séparer des nombreux en-têtes normalisés du type (A). L'utilisation du préfixe "X-" ou "X-ACME-" est pratique et légitime pour (B), et n'est pas en conflit avec (A). Plus les vendeurs cessent d'utiliser "X-" pour (A), plus les (B) deviendront nettement plus nets.

Exemple: 
Google (qui porte un peu de poids dans les différents organismes de normalisation) sont - à ce jour, 20141102 dans cette légère modification à ma réponse - actuellement en utilisant "X-Mod-Pagespeed" pour indiquer la version de leur module Apache impliqué dans transformer 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 vers / depuis votre serveur, ces en-têtes ne sont explicitement PAS destinés à être utilisés en dehors du contexte de votre application, les nommer avec un préfixe "X-" ou "X-FOO-" est une convention raisonnable et courante.


413
2017-10-28 16:39



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 message», 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éfinis dans la section 2.2, «Règles de base». Le jeton est:

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

À son tour reposant 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

Le texte est:

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

Où LWS est un espace blanc linéaire, dont la définition ne sera pas reproduite, et 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. Premièrement, il est clair que l'en-tête prénom doit être composé d'un sous-ensemble de caractères ASCII - alphanumériques, de la ponctuation, pas beaucoup d'autres. Deuxièmement, il n'y a rien dans la définition d'un en-tête valeurcela le limite à l'ASCII ou exclut les caractères de 8 bits: il est composé explicitement d'octets, avec seulement des 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 TEXT implique que les octets doivent être interprétés comme étant dans ISO-8859-1, et qu'il existe un mécanisme de codage (qui est horrible, incidemment) pour représenter les caractères en dehors de ce codage.

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

Cela dit, je ne compterais pas sur ISO-8859-1 fonctionnant sur tous les serveurs, les proxies et les clients, donc je m'en tenir à l'ASCII comme une question de programmation défensive.


56
2017-08-25 19:49



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

Pour autant que je sache, il n'y a pas de directives pour les en-têtes privés; dans le doute, évitez-les. Ou jetez un oeil à la structure d'extension HTTP (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?


15
2017-08-25 06:44



Modifier, ou plus correctement, ajouter En-têtes HTTP supplémentaires est un excellent outil de débogage de code si rien d'autre.

Lorsqu'une requête d'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 celui qui est visible dans un navigateur.

Une approche consiste à écrire les données dans un fichier journal local et à afficher 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 bugs qui auraient été autrement très difficiles à tracer.


14
2017-07-04 09:29



RFC6648 recommande de supposer que votre en-tête personnalisé "pourrait devenir standard, public, communément déployé ou utilisable sur plusieurs implémentations". Par conséquent, il recommande de ne pas le préfixer avec "X-" ou des constructions similaires.

Cependant, il y a une exception "quand il est extrêmement improbable que [votre en-tête] soit standardisé". Pour de tels en-têtes «spécifiques à l'implémentation et à usage privé», la RFC indique qu'un espace de noms tel qu'un préfixe de fournisseur est justifié.


1
2017-07-24 13:50