2. Le champ HTTP Proxy-Status

Le champ de réponse HTTP Proxy-Status permet à un intermédiaire de transmettre des informations supplémentaires sur son traitement d'une réponse et de sa requête associée.

Sa valeur est une List (liste) (voir section 3.1 de [STRUCTURED-FIELDS]). Chaque membre de la liste représente un intermédiaire qui a traité la réponse. Le premier membre représente l'intermédiaire le plus proche du serveur d'origine, et le dernier membre représente l'intermédiaire le plus proche de l'agent utilisateur.

Par exemple:

Proxy-Status: revproxy1.example.net, ExampleCDN

indique que cette réponse a été traitée d'abord par revproxy1.example.net (un proxy inverse adjacent au serveur d'origine) puis par ExampleCDN.

Les intermédiaires déterminent quand il est approprié d'ajouter le champ Proxy-Status à une réponse. Certains peuvent décider de l'ajouter à toutes les réponses, tandis que d'autres peuvent ne le faire que lorsqu'ils sont spécifiquement configurés pour le faire ou lorsque la requête contient un champ d'en-tête qui active un mode de débogage.

Chaque membre de la liste identifie l'intermédiaire qui a inséré la valeur et DOIT avoir un type String (chaîne) ou Token (jeton). Selon le déploiement, cela peut être un nom de service (mais pas un nom de produit logiciel ou matériel; par exemple, "ExampleCDN" est approprié, mais "ExampleProxy" ne l'est pas car il n'identifie pas le déploiement), un nom d'hôte ("proxy-3.example.com"), une adresse IP ou une chaîne générée.

Les paramètres de chaque membre (selon la section 3.1.2 de [STRUCTURED-FIELDS]) transmettent des informations supplémentaires sur le traitement par cet intermédiaire de la réponse et de sa requête associée; voir section 2.1. Bien que tous ces paramètres soient OPTIONNELS, les intermédiaires sont encouragés à fournir autant d'informations que possible (mais voir section 4 pour les considérations de sécurité à cet égard).

Lors de l'ajout d'une valeur au champ Proxy-Status, les intermédiaires DEVRAIENT préserver les membres existants du champ pour permettre le débogage de l'ensemble de la chaîne d'intermédiaires traitant la requête, sauf s'ils sont explicitement configurés pour les supprimer (par exemple, pour empêcher la fuite de détails du réseau interne; voir section 4).

Les serveurs d'origine NE DOIVENT PAS générer le champ Proxy-Status.

Proxy-Status PEUT être envoyé comme un champ de trailer HTTP. Par exemple, si un intermédiaire diffuse une réponse en continu et que la connexion entrante se termine soudainement, Proxy-Status ne peut être ajouté qu'à la section de trailer du message sortant car la section d'en-tête a déjà été envoyée. Cependant, comme il peut être silencieusement rejeté le long du chemin vers l'agent utilisateur (comme c'est le cas pour tous les champs de trailer; voir section 6.5 de [HTTP]), Proxy-Status NE DEVRAIT PAS être envoyé comme un champ de trailer sauf s'il n'est pas possible de l'envoyer dans la section d'en-tête.

Pour permettre aux destinataires de reconstruire l'ordre relatif des membres Proxy-Status transmis dans les champs de trailer avec ceux transmis dans les champs d'en-tête, un intermédiaire NE DOIT PAS envoyer Proxy-Status comme un champ de trailer sauf s'il a également généré un champ d'en-tête Proxy-Status avec le même membre (bien que potentiellement avec des paramètres différents) dans ce message.

Par exemple, un proxy identifié comme 'ThisProxy' qui reçoit une réponse portant un champ d'en-tête:

Proxy-Status: SomeOtherProxy

ajouterait sa propre entrée au champ d'en-tête:

Proxy-Status: SomeOtherProxy, ThisProxy

lui permettant ainsi d'ajouter un champ de trailer:

Proxy-Status: ThisProxy; error=read_timeout

ce qui permettrait ainsi à un destinataire en aval de comprendre que le traitement par 'SomeOtherProxy' s'est produit avant 'ThisProxy'.

Un client PEUT promouvoir la valeur du champ de trailer Proxy-Status pour qu'elle soit dans la section d'en-tête à des fins de débogage ou autres (par exemple, pour faciliter l'accès).

2.1. Paramètres Proxy-Status

Chaque membre de la liste Proxy-Status peut avoir des paramètres qui décrivent le traitement de la réponse par le proxy. Cette section détaille ces paramètres.

2.1.1. error

Le paramètre "error" a une valeur de type Token qui est un Proxy Error Type (type d'erreur de proxy) (section 2.3); sa présence indique que l'intermédiaire a rencontré un problème lors de l'obtention d'une réponse pour la requête.

2.1.2. next-hop

Le paramètre "next-hop" a une valeur de type String ou Byte Sequence (séquence d'octets); sa présence indique le prochain saut que l'intermédiaire a utilisé pour transférer la requête. Cela peut être une adresse IP et un numéro de port, un nom d'hôte ou une autre forme d'identifiant.

2.1.3. next-protocol

Le paramètre "next-protocol" a une valeur de type Token ou Byte Sequence; sa présence indique l'identifiant de protocole ALPN [RFC7301] utilisé par l'intermédiaire pour se connecter au prochain saut.

2.1.4. received-status

Le paramètre "received-status" a une valeur de type Integer (entier); sa présence indique le code d'état HTTP reçu par l'intermédiaire du serveur du prochain saut. La valeur du paramètre DOIT être dans la plage 100-999 incluse.

Ce paramètre n'est applicable que lorsque le paramètre error n'est pas présent. Il est destiné à être utilisé lorsque l'intermédiaire génère sa propre réponse basée sur la réponse reçue du prochain saut, mais ne génère pas d'erreur.

2.1.5. details

Le paramètre "details" a une valeur de type String; sa présence permet au proxy de transmettre des informations supplémentaires qui sont spécifiques à cette réponse et qui n'ont pas de paramètre mieux adapté. Cela peut inclure des informations spécifiques à l'implémentation ou au déploiement.

2.2. Définition de nouveaux paramètres Proxy-Status

De nouveaux paramètres Proxy-Status peuvent être définis en les enregistrant dans le registre "HTTP Proxy-Status Parameters".

Les demandes d'enregistrement sont examinées et approuvées par Expert Review, selon [RFC8126], section 4.5. Un document de spécification est apprécié mais non requis.

L'expert ou les experts devraient considérer les facteurs suivants lors de l'évaluation des demandes:

Retour de la communauté
Si la valeur est suffisamment bien définie
Les paramètres génériques sont préférés aux valeurs spécifiques au fournisseur, à l'application ou au déploiement. Si une valeur générique ne peut être convenue dans la communauté, le nom du paramètre devrait être correspondant spécifique (par exemple, avec un préfixe qui identifie le fournisseur, l'application ou le déploiement).
Si le nom du paramètre entre en conflit ou crée une confusion avec d'autres paramètres Proxy-Status, des types d'erreurs nouveaux ou existants, ou a le potentiel de le faire à l'avenir.

Les demandes d'enregistrement devraient utiliser le modèle suivant:

Nom: [un nom pour le paramètre Proxy-Status qui est de type Token]

Description: [une description de la sémantique du paramètre]

Référence: [à une spécification définissant ce paramètre; optionnel]

Notes: [optionnel]

Voir le registre à https://www.iana.org/assignments/http-proxy-status pour plus de détails sur l'envoi des demandes d'enregistrement.