Apache: différence entre “Header always set” et “Header set”?

Des questions

Quelle est la différence entre les en- Header always set et les en- Header set dans Apache?
En d’autres termes, que change le mot-clé always dans les circonstances dans lesquelles l’en-tête est défini?
Dois-je toujours utiliser mes en-têtes?
Y a-t-il une raison de ne pas le faire?

Contexte

J’ai vu…

 Header always set X-Frame-Options DENY

…aussi bien que…

 Header always set Access-Control-Allow-Headers "*"

… et j’entends parfois que la présence du mot-clé always garantit que l’en-tête est correctement défini, ou qu’il vaut mieux simplement inclure le mot-clé always en général. Cependant, je n’ai jamais trouvé de réponse claire et définitive à la question de savoir pourquoi .

J’ai déjà vérifié les documents Apache pour mod_headers , qui ne mentionnent que brièvement:

Lorsque votre action est une fonction d’un en-tête existant, vous devrez peut-être spécifier une condition toujours, en fonction de la table interne dans laquelle l’entête d’origine a été définie. La table qui correspond à toujours est utilisée pour les réponses d’erreur générées localement les réponses Notez également que la répétition de cette directive avec les deux conditions est judicieuse dans certains scénarios car elle ne représente pas toujours un sur-succès par rapport aux en-têtes existants:

Vous ajoutez un en-tête à une réponse non réussie (non-2xx) générée localement, telle qu’une redirection, auquel cas seule la table correspondant à toujours est utilisée dans la réponse finale.

Vous modifiez ou supprimez un en-tête généré par un script CGI, auquel cas les scripts CGI se trouvent dans la table correspondant à toujours et non dans la table par défaut.

Vous modifiez ou supprimez un en-tête généré par une partie du serveur, mais cet en-tête n’est pas détecté par la condition de remplacement par défaut.

Autant que je sache, cela signifie que Header set always s’assure Header set always que l’en-tête est défini même sur des pages autres que 200. Cependant, mes en-têtes HTTP avec jeu d’en-têtes ont toujours semblé bien fonctionner sur mes pages 404 et autres. Est-ce que je comprends mal quelque chose ici?

FWIW, j’ai trouvé des messages SO comme Quelle est la différence entre “Toujours” et “Onsuccess” dans la configuration de l’en-tête d’Apache? , mais la seule réponse là-bas ne m’expliquait pas vraiment clairement.

Merci beaucoup,
Caleb

Quelle est la différence entre les en-têtes toujours définies et les en-têtes définies dans Apache?

Comme le dit le extrait du manuel, sans «toujours», vos ajouts ne donneront lieu à des réponses réussies.

Mais cela inclut également les erreurs de transfert “avec succès” via mod_proxy et peut-être d’autres gestionnaires similaires qui agissent approximativement comme des proxys. Qu’est-ce qui génère vos 404 que vous avez trouvé en désaccord avec le manuel? Un 404 sur un fichier local se comporte certainement comme décrit dans le bit cité.

En d’autres termes, que change le mot-clé toujours dans les circonstances dans lesquelles l’en-tête est défini?

L’API d’Apache conserve deux listes associées à chaque requête, en-têtes et err_headers. Le premier n’est pas utilisé si le serveur rencontre une erreur lors du traitement de la demande.

Dois-je toujours utiliser mes en-têtes?

Cela dépend de leur signification. Supposons que vous définissiez des en-têtes Cache-Control liés à ce que vous attendiez pour certaines ressources. Maintenant, disons que vous seriez en train de servir quelque chose comme un 400 ou un 502. Vous ne voudriez peut-être pas que ce cache soit disponible!

Y a-t-il une raison de ne pas le faire?

Voir au dessus.

– / –

Il y a aussi un peu dans le manuel que vous n’avez pas cité qui explique le proxy ou le CGI d’un code d’erreur, mais pas celui pour lequel Apache génère une réponse d’erreur pour:

L’argument conditionnel optionnel détermine la table interne des en-têtes de réponse sur laquelle cette directive va fonctionner. Malgré le nom, la valeur par défaut de onsuccess ne limite pas une action aux réponses avec un code d’état 2xx.

Les en-têtes définis dans cette condition sont toujours utilisés lorsque, par exemple, une requête est envoyée par proxy ou générée avec succès par CGI, même s’ils ont généré un code d’état défaillant.