7.2.4. Choisir les paramètres de signature et les composants dérivés plutôt que les champs HTTP

7.2.4. Choisir les paramètres de signature et les composants dérivés plutôt que les champs HTTP

Certains champs HTTP ont des valeurs et des interprétations proches des paramètres de signature HTTP ou des composants dérivés. Dans la plupart des cas, il est préférable de signer l’alternative qui n’est pas un champ. En particulier, les champs suivants ne devraient généralement pas être inclus dans la signature, sauf si l’application l’exige explicitement :

"date" La valeur du champ d’en-tête Date représente l’horodatage du message HTTP. Toutefois, l’heure de création de la signature elle-même est encodée dans le paramètre de signature created. Ces deux valeurs peuvent différer, selon la façon dont la signature et le message HTTP sont créés et sérialisés. Les applications qui traitent les signatures pour des fenêtres temporelles valides devraient utiliser le paramètre de signature created pour de tels calculs. Une application peut aussi limiter l’écart autorisé entre le champ Date et le paramètre de signature created, afin de restreindre l’application d’une signature générée à d’autres messages HTTP. Voir aussi les sections 7.2.2 et 7.2.1.

"host" Le champ d’en-tête Host est propre à HTTP/1.1, et sa fonction est absorbée par le composant dérivé @authority, défini à la section 2.2.3. Pour préserver la valeur d’une version HTTP à l’autre, les applications devraient toujours utiliser le composant dérivé @authority. Voir aussi la section 7.5.4.