Recherche d'explications sur le comportement d'Apache lors de la manipulation d'en-têtes
J'ai essayé d'obtenir une réponse à ServerFault - ils ne le savent pas, tous les vrais gourous sont assis ici.
Arrière-plan du problème: Googlebot crée des URL non existantes et tente de les analyser. Sur certaines URL, Apache déclenche 404 (correctement), sur d'autres URL - 403 (incorrect). Je ne parviens pas à saisir les URL avec RegEx, où Apache déclenche l'application 403, donc je ne peux pas les réécrire correctement pour forcer 404.
J'ai créé la solution suivante pour forcer 404 au lieu de 403:
j'ajoute à htaccess
ErrorDocument 403 /404.php
ErrorDocument 404 /404.php
aussi pour les deux cas le même fichier.
Et puis, pour forcer le bon en-tête, j'ajoute à 404.php, au début, <?php http_response_code(404); ?> De cette façon, je montre à Googlebot 404 même là où Apache tente de répondre avec 403.
La question est: quelqu'un pourrait-il m'expliquer, en quoi cette solution de contournement fonctionne-t-elle en détail? Comment je suis capable de manipuler en-tête de cette façon? Je pensais toujours, Apache décide quel code de réponse servir avant , il se penche sur htaccess ...
comment fonctionne cette solution de contournement
PHP s'exécute plus tard dans la requête, donc la plupart du temps vous pouvez simplement remplacer tous les en-têtes déjà définis par Apache dans votre code PHP. C'est à peu près tout.
(De plus, l'envoi de 403 via votre gestionnaire 404 de cette manière rend évidemment plus difficile le déclenchement d'un réel 403 à partir de votre configuration/.htaccess Apache, si vous en avez besoin.)
la plupart du temps
Cependant, si une erreur grave se produit (les choses ne fonctionnent pas normalement), le serveur peut répondre par une erreur 500 Internal Server - une erreur que vous ne pourrez peut-être pas capturer dans votre propre code.
En outre, par défaut, Apache est configuré pour renvoyer un 404 (généré par le système) pour les demandes contenant une barre oblique (%2F) - vous ne pouvez pas le remplacer (sans désactiver cette fonctionnalité).
Il existe d'autres situations dans lesquelles Apache prendra le relais (mod_security, etc.), mais sinon, si tout fonctionne normalement, vous devriez pouvoir manipuler l'intégralité des en-têtes de réponse.
Je pensais toujours, Apache décide quel code de réponse utiliser avant de regarder dans htaccess ...
C'est le cas, mais tout code dans .htaccess remplacera ceci. (Dans la mesure où il n'y a aucune restriction empêchant cela dans la configuration du serveur.)
Googlebot crée des URL non existantes et tente de les analyser.
Beaucoup de gens voient ce comportement. Cependant, je ne pense pas que Googlebot "crée" ces URL de nulle part. Il est plus probable que ces URL soient trouvées quelque part. (Ou ce n'est pas vraiment un vrai Googlebot.)
Sur certaines URL, Apache déclenche 404 (correctement), sur d'autres URL - 403 (incorrect). Je ne parviens pas à saisir les URL avec RegEx, où Apache déclenche l'application 403, donc je ne peux pas les réécrire correctement pour forcer 404.
Apache (mod_dir) déclenchera un message 403 lors de la demande d'un répertoire ne contenant pas de document d'index et où les index de répertoire générés par le serveur sont interdits (d'où la réponse "403 interdit"). mod_dir essaiera également de "réparer" ces URL en ajoutant une barre oblique finale (si omis) - vous ne pourrez pas faire correspondre l'URL à moins d'inclure la barre oblique finale dans votre motif (mod_dir se déclenche tôt) . Cela ressemble donc à un problème de mod_dir. Cependant, nous aurions besoin de voir les URL en question (et probablement poser plus de questions sur les fichiers config/.htaccess du serveur) pour vérifier cela.
Sauf si autre chose est en cours, vous devriez toujours pouvoir intercepter/réécrire ces URL. Changer toutes les 403 en 404 n'est pas une solution de contournement particulièrement souhaitable.