2.1. Champs HTTP (HTTP Fields)

2.1. Champs HTTP

Le nom de composant pour un champ HTTP est la forme en minuscules de son nom de champ tel que défini à la Section 5.1 de [HTTP]. Bien que les noms de champs HTTP soient insensibles à la casse, les implémentations DOIVENT utiliser des noms de champs en minuscules (par ex. content-type, date, etag) lorsqu'ils servent de noms de composants.

La valeur de composant pour un champ HTTP est la valeur de champ pour le champ nommé, telle que définie à la Section 5.5 de [HTTP]. La valeur de champ DOIT être tirée du champ d'en-tête nommé du message cible, sauf si ce comportement est modifié par des paramètres et règles supplémentaires, tels que les indicateurs req et tr ci-dessous. Pour la plupart des champs, la valeur de champ est une chaîne ASCII comme recommandé par [HTTP], et la valeur de composant est exactement cette chaîne. D'autres encodages peuvent exister dans certaines implémentations, et toutes les valeurs de champ non ASCII DOIVENT être encodées en ASCII avant d'être ajoutées à la base de signature. Le paramètre bs, décrit à la Section 2.1.3, fournit une méthode pour encapsuler de telles valeurs de champ problématiques.

Sauf modification par des paramètres et règles supplémentaires, les valeurs de champ HTTP DOIVENT être fusionnées en une seule valeur comme défini à la Section 5.2 de [HTTP] pour créer la valeur de composant. En particulier, les champs HTTP envoyés en plusieurs instances DOIVENT être fusionnés en concaténant les valeurs avec une seule virgule et un seul espace comme séparateur ("," + " "). Notez que les intermédiaires peuvent fusionner les valeurs de champs HTTP avec une quantité quelconque d'espaces entre les virgules, et si le vérificateur n'en tient pas compte, la signature peut échouer, car le signataire et le vérificateur verront une valeur de composant différente dans leur base de signature respective. Pour la robustesse, il est RECOMMANDÉ que les messages signés n'incluent qu'une seule instance de tout champ couvert par la signature, en particulier avec la valeur pour tout champ de type liste sérialisée selon l'algorithme ci-dessous. Cette approche augmente les chances que la valeur de champ reste intacte à travers les intermédiaires. Lorsque ce n'est pas possible et que plusieurs instances d'un champ doivent être envoyées séparément, il est RECOMMANDÉ que signataires et vérificateurs traitent tout champ de type liste en prenant toutes les valeurs de champ individuelles et en les fusionnant selon l'algorithme strict ci-dessous, pour contrer le comportement possible des intermédiaires. Lorsque le champ en question est un Structured Field de type List ou Dictionary, on peut obtenir cet effet plus directement en exigeant la sérialisation stricte Structured Field de la valeur de champ, comme décrit à la Section 2.1.1.

Notez que certains champs HTTP, tels que Set-Cookie [COOKIE], ne suivent pas une syntaxe permettant la fusion des valeurs de champ de cette manière (de sorte que la sortie fusionnée soit non ambiguë à partir de plusieurs entrées). Même si la valeur de composant n'est jamais analysée par le processus de signature de message et n'est utilisée que dans la base de signature (Section 2.5), il faut être prudent lors de l'inclusion de tels champs dans les signatures, car la valeur fusionnée peut être ambiguë. Le paramètre bs, décrit à la Section 2.1.3, fournit une méthode pour encapsuler de tels champs. Voir Section 7.5.6 pour plus de discussion.

Si la valeur fusionnée correcte n'est pas directement disponible pour un champ donné dans une implémentation, l'algorithme suivant produira des résultats canonisés pour les champs de type liste:

1. Créer une liste ordonnée des valeurs de champ de chaque instance du champ dans le message, dans l'ordre où elles apparaissent (ou apparaîtront) dans le message.

2. Supprimer les espaces en tête et en fin de chaque élément de la liste. Comme les valeurs de champ HTTP ne peuvent pas contenir d'espaces en tête ou en fin, ce serait une absence d'opération dans une implémentation conforme.

3. Supprimer tout pli de ligne obsolète dans la ligne et le remplacer par un seul espace (" "), comme indiqué à la Section 5.2 de [HTTP/1.1]. Ce comportement est propre à HTTP/1.1 et ne s'applique pas aux autres versions de la spécification HTTP, qui n'autorisent pas le pli de ligne interne.

4. Concaténer la liste de valeurs avec une seule virgule (",") et un seul espace (" ") entre chaque élément.

La chaîne résultante est la valeur de composant pour le champ.

Notez que certains champs HTTP ont des valeurs avec plusieurs sérialisations valides sémantiquement équivalentes, par exemple des valeurs insensibles à la casse que des intermédiaires pourraient modifier. Les applications qui signent et traitent de tels champs DOIVENT réfléchir à la manière de gérer les valeurs pour garantir que le signataire et le vérificateur dérivent la même valeur, comme à la Section 7.5.2.

Les exemples suivants sont non normatifs; ils illustrent des valeurs de composant pour des champs d'en-tête, étant donné le fragment de message HTTP d'exemple suivant:

Host: www.example.com Date: Tue, 20 Apr 2021 02:07:56 GMT X-OWS-Header: Leading and trailing whitespace. X-Obs-Fold-Header: Obsolete line folding. Cache-Control: max-age=60 Cache-Control: must-revalidate Example-Dict: a=1, b=2;x=1;y=2, c=(a b c)

L'exemple suivant montre les valeurs de composant pour ces champs d'en-tête d'exemple, présentées au format de base de signature défini à la Section 2.5:

"host": www.example.com "date": Tue, 20 Apr 2021 02:07:56 GMT "x-ows-header": Leading and trailing whitespace. "x-obs-fold-header": Obsolete line folding. "cache-control": max-age=60, must-revalidate "example-dict": a=1, b=2;x=1;y=2, c=(a b c)

Les champs HTTP vides peuvent aussi être signés lorsqu'ils sont présents dans un message. La valeur canonisée est la chaîne vide. Cela signifie que le champ d'en-tête vide suivant, avec (SP) indiquant un seul caractère d'espace en fin avant la valeur de champ vide:

X-Empty-Header:(SP)

est sérialisé par l'algorithme de génération de la base de signature (Section 2.5) avec une chaîne vide après les deux-points et l'espace ajoutés après l'identifiant de composant.

"x-empty-header":(SP)

Tout identifiant de composant de champ HTTP PEUT comporter les paramètres suivants dans des circonstances précises, chacun étant détaillé dans sa propre section:

sf Un indicateur Boolean indiquant que la valeur de composant est sérialisée avec l'encodage strict de la valeur Structured Field (Section 2.1.1).

key Un paramètre String utilisé pour sélectionner une valeur de membre unique dans un Dictionary Structured Field (Section 2.1.2).

bs Un indicateur Boolean indiquant que les valeurs de champ individuelles sont encodées au moyen de structures Byte Sequence avant d'être fusionnées dans la valeur de composant (Section 2.1.3).

req Un indicateur Boolean pour les réponses signées indiquant que la valeur de composant est dérivée de la requête ayant déclenché cette réponse et non directement du message de réponse. Notez que ce paramètre peut aussi s'appliquer à tout identifiant de composant dérivé ciblant la requête (Section 2.4).

tr Un indicateur Boolean indiquant que la valeur de champ est tirée des fins de message (trailers) du message tel que défini à la Section 6.5 de [HTTP]. Si cet indicateur est absent, la valeur de champ est tirée des champs d'en-tête du message tel que défini à la Section 6.3 de [HTTP] (Section 2.1.4).

Plusieurs paramètres PEUVENT être spécifiés ensemble, bien que certaines combinaisons soient redondantes ou incompatibles. Par exemple, la fonctionnalité du paramètre sf est déjà couverte lorsque le paramètre key est utilisé sur un élément Dictionary, car key exige la sérialisation stricte de la valeur. Le paramètre bs, qui exige les octets bruts des valeurs de champ du message, n'est pas compatible avec l'usage des paramètres sf ou key, qui exigent les structures de données analysées des valeurs de champ après fusion.

Des paramètres supplémentaires peuvent être définis dans le registre « HTTP Signature Component Parameters » établi à la Section 6.5.