4.7. Spécifier les champs d'en-tête HTTP

4.7. Spécifier les champs d'en-tête HTTP

Les applications ont souvent besoin de définir de nouveaux champs d'en-tête HTTP. Lorsqu'elles le font, elles DOIVENT les enregistrer dans le "Hypertext Transfer Protocol (HTTP) Field Name Registry" en suivant la procédure de [HTTP] Section 16.3.

[STRUCTURED-FIELDS] fournit une manière standardisée de définir les valeurs des champs d'en-tête, ce qui facilite leur analyse et leur gestion. Les applications DEVRAIENT utiliser les champs structurés lors de la définition de nouveaux champs d'en-tête.

Lors de la définition des champs d'en-tête, les applications doivent considérer:

• Le nom du champ d'en-tête DEVRAIT être descriptif et suivre les conventions de nommage de [HTTP] Section 16.3.1.

• Les champs d'en-tête NE DEVRAIENT PAS utiliser le préfixe "X-", conformément à [RFC6648].

• La syntaxe de la valeur du champ d'en-tête DEVRAIT être clairement spécifiée. L'utilisation de [STRUCTURED-FIELDS] est recommandée.

• La sémantique du champ d'en-tête DEVRAIT être clairement expliquée, y compris quand il doit être envoyé et comment il doit être interprété.

• Les applications DEVRAIENT considérer si le champ d'en-tête doit être saut par saut ou de bout en bout. La plupart des champs d'en-tête définis par l'application devraient être de bout en bout.

• Les applications DEVRAIENT spécifier ce qui se passe si le champ d'en-tête apparaît plusieurs fois dans un message.

• Les applications DEVRAIENT spécifier si le champ d'en-tête est destiné aux requêtes, aux réponses ou aux deux.

Les applications DEVRAIENT réutiliser les champs d'en-tête existants lorsque cela est possible plutôt que d'en définir de nouveaux. Par exemple, si une application doit identifier le type de contenu envoyé, elle devrait utiliser Content-Type plutôt que de définir un nouveau champ d'en-tête.

Lors de la réutilisation de champs d'en-tête existants, les applications DOIVENT respecter leur sémantique et syntaxe définies.