5. Demander des signatures

5. Demander des signatures

Bien qu'un signataire soit libre d'attacher une signature à une requête ou une réponse sans sollicitation, il est souvent souhaitable qu'un vérificateur potentiel signale qu'il attend une signature d'un signataire potentiel au moyen du champ Accept-Signature.

Lorsque le champ Accept-Signature est envoyé dans un message de requête HTTP, le champ indique que le client souhaite que le serveur signe la réponse en utilisant les paramètres identifiés, et le message cible est la réponse à cette requête. Toutes les réponses des ressources qui prennent en charge une telle négociation de signature DEVRAIENT être non mises en cache ou contenir un champ d'en-tête Vary qui liste Accept-Signature, afin d'empêcher un cache de renvoyer une réponse avec une signature destinée à une autre requête.

Lorsque le champ Accept-Signature est utilisé dans un message de réponse HTTP, le champ indique que le serveur souhaite que le client signe sa prochaine requête vers le serveur avec les paramètres identifiés, et le message cible est la prochaine requête du client. Le client peut choisir de continuer à signer les requêtes futures vers le même serveur de la même manière.

Le message cible d'un champ Accept-Signature DOIT inclure toutes les signatures étiquetées indiquées dans le champ Accept-Signature, chacune couvrant les mêmes composants identifiés que le champ Accept-Signature.

L'émetteur d'un champ Accept-Signature DOIT n'inclure que des identifiants appropriés au type du message cible. Par exemple, si le message cible est une requête, les composants couverts ne peuvent pas inclure l'identifiant de composant @status.