En bref. Les actions des ensembles de règles Azure Front Door ne peuvent modifier ni les en-têtes réservés documentés ni les noms commençant par x-ec ou x-fd.
Définition : Les actions des ensembles de règles Azure Front Door ne peuvent modifier ni les en-têtes HTTP figurant dans une liste documentée d’en-têtes réservés, ni les en-têtes dont le nom commence par
x-ecoux-fd. Cette restriction s’applique aux actions de modification des en-têtes de requête et de réponse.
Points clés
- La documentation de référence des actions des ensembles de règles Azure Front Door de Microsoft applique la restriction sur les en-têtes réservés aux actions qui modifient les en-têtes de requête et de réponse.
- Les noms réservés comprennent
Host,Connection,Content-Length,Transfer-Encoding,TE,Upgrade,Range,ForwardedetVia. - La liste comprend aussi des champs propres à Azure et Front Door, comme
X-Ms-Via,X-Ms-Force-Refresh,X-MSEdge-Ref,X-Azure-FDIDetX-Azure-Ref. - Les deux préfixes réservés documentés par Microsoft sont
x-ecetx-fd. - La RFC 9110 précise que les noms de champs HTTP sont insensibles à la casse : une différence entre majuscules et minuscules ne constitue donc pas un nom de champ HTTP distinct.
Quels noms et préfixes sont réservés ?
La documentation de référence Azure Front Door indique que les actions du moteur de règles ne peuvent pas modifier les en-têtes réservés. Elle mentionne les actions sur les en-têtes de requête et de réponse, puis énumère les noms et préfixes suivants :
Accept-Ranges
Host
Connection
Content-Length
Transfer-Encoding
TE
Last-Modified
Keep-Alive
Expect
Upgrade
If-Modified-Since
If-Unmodified-Since
If-None-Match
If-Match
Range
If-Range
X-Ms-Via
X-Ms-Force-Refresh
X-MSEdge-Ref
Warning
Forwarded
Via
X-Forwarded-For
X-Forwarded-Proto
X-Forwarded-Host
X-Azure-RequestChain
X-Azure-FDID
X-Azure-RequestChainv2
X-Azure-Ref
x-ec*
x-fd*
L’astérisque des deux dernières lignes représente un préfixe de nom. La page écrit les préfixes en minuscules. La définition des noms de champs de la RFC 9110 précise que ces noms sont insensibles à la casse et devraient être inscrits au registre des noms de champs HTTP (HTTP Field Name Registry).
Que font les opérateurs de modification des en-têtes de réponse ?
La documentation de référence de Microsoft définit l’action de modification des en-têtes de réponse comme une modification des en-têtes présents dans les réponses avant leur renvoi aux clients. Elle prend en charge trois opérateurs. Append ajoute la valeur spécifiée et, si l’en-tête existe déjà, la concatène à la valeur existante sans ajouter de séparateur. Overwrite remplace la valeur existante lorsque l’en-tête est déjà présent. Delete supprime un en-tête présent.
Ces opérateurs décrivent l’action appliquée à un en-tête admissible. Ils ne prévoient aucune exception pour les noms réservés. Par exemple, le comportement documenté de Delete ne permet pas de supprimer Host, Content-Length ou X-Azure-FDID au moyen d’une action d’un ensemble de règles, car ces noms figurent dans la liste réservée.
La RFC 9110 explique pourquoi certains noms de la liste touchent au fonctionnement du protocole. Host contient l’autorité cible utilisée pour traiter les requêtes. Connection énumère les options de contrôle de la connexion en cours, et les intermédiaires le traitent avant de transmettre un message. Content-Length indique la longueur des données de la représentation associée et peut délimiter le contenu du message. Range et les champs conditionnels tels que If-Match et If-Modified-Since interviennent dans les conditions des requêtes et les transferts partiels.
Comment vérifier une règle ?
La documentation de référence des actions des ensembles de règles présente ModifyResponseHeader avec les propriétés headerAction et headerName. L’examen d’une configuration consiste donc à repérer le nom d’en-tête fourni à cette action et à le comparer à la liste des noms et préfixes réservés :
{
"name": "ModifyResponseHeader",
"parameters": {
"headerAction": "Delete",
"headerName": "X-Powered-By",
"typeName": "DeliveryRuleHeaderActionParameters"
}
}
L’exemple utilise X-Powered-By, qui ne figure pas dans la liste documentée des en-têtes réservés. Un nom correspondant à un champ de la liste ou commençant par x-ec ou x-fd fait partie des noms soumis à restriction pour les actions sur les en-têtes de requête et de réponse.
Termes associés
- Azure Front Door insère-t-il un séparateur lors de l’ajout d’une valeur à un en-tête de réponse ?
- Comment Azure Front Door peut-il ignorer certains paramètres de suivi dans sa clé de cache ?
- Comment Azure Front Door conserve-t-il le reste d’un chemin lors d’une réécriture ?
- Pourquoi un remplacement d’origine dans Azure Front Door peut-il désactiver la mise en cache ?
Questions fréquentes
Pouvez-vous supprimer un en-tête de réponse réservé avec une action Delete ?
Non. La documentation de référence de Microsoft inclut l’opérateur Delete dans l’action sur les en-têtes de réponse, tandis que sa note sur les en-têtes réservés exclut de toute modification les noms énumérés et les deux préfixes.
Append ajoute-t-il un séparateur entre les valeurs d’un en-tête ?
Non. Azure Front Door décrit Append comme une concaténation de chaînes et précise qu’aucun séparateur n’est ajouté lorsqu’un en-tête possède déjà une valeur.
Sources
- Microsoft, « Rule set actions - Azure Front Door », 19 juillet 2024
- Internet Engineering Task Force, « HTTP Semantics », juin 2022
Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO