RewriteCond dans .htaccess avec la condition regex refusée ne fonctionne pas?
J'essaie d'empêcher, dans ce cas, WordPress de réécrire certaines URL. Dans ce cas, j'essaie de l'empêcher de traiter jamais une demande dans le répertoire de téléchargement et de laisser celles-ci sur la page 404 du serveur. Donc, je suppose que c'est aussi simple que d'ajouter la règle:
RewriteCond %{REQUEST_URI} !^/wp-content/uploads/
Cette règle doit être évaluée à false et faire échouer la chaîne de règles pour ces demandes, interrompant ainsi la réécriture. Mais non ... Peut-être dois-je faire correspondre la couverture à la chaîne complète de mon expression?
RewriteCond %{REQUEST_URI} !^/wp-content/uploads/.*$
Non, ce n'est pas ça non plus. Donc, après me gratter la tête, je fais un contrôle de santé mentale. Peut-être que quelque chose ne va pas avec le modèle actuel. Je fais donc un cas de test simple.
RewriteCond %{REQUEST_URI} ^/xyz/$
Dans ce cas, la réécriture se produit si et seulement si l'URL demandée est/xyz/et affiche la page 404 du serveur pour toute autre page. C'est exactement ce à quoi je m'attendais. Je vais donc rester dans un! pour nier ce modèle.
RewriteCond %{REQUEST_URI} !^/xyz/$
Maintenant, je m'attends à voir le contraire de la condition ci-dessus. La réécriture ne devrait pas se produire pour/xyz/mais pour toutes les autres URL possibles. Au lieu de cela, la réécriture se produit pour chaque URL, à la fois/xyz/et les autres.
Donc, soit l'utilisation de expressions rationnelles négatives dans RewriteConds est interrompue dans Apache, soit il y a quelque chose de fondamental que je ne comprends pas à ce sujet. Laquelle est-ce?
Le serveur est Apache2.
Le fichier dans son intégralité:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/wp-content/uploads/
RewriteRule . /index.php [L]
</IfModule>
Le fichier par défaut de WordPress plus ma règle.
Alors, après beaucoup d'irritation, j'ai compris le problème, en quelque sorte. Il s'est avéré que la règle de ma question initiale faisait exactement ce qu'elle était censée faire. Il en a été de même d'un certain nombre d'autres façons de faire la même chose, telles que
RewriteRule ^wp-content/uploads/.*$ - [L]
(Marquez la règle en dernier si le motif correspond) ou
RewriteRule ^wp-content/uploads/.*$ - [S=1]
(Ignorez la règle suivante si le motif correspond) ainsi que la règle annulée dans la question, comme indiqué. Toutes ces règles fonctionnaient parfaitement et rendaient le contrôle à Apache sans réécrire.
Le problème est survenu après le traitement de ces règles. Au lieu de cela, le problème était que j'ai supprimé les modèles par défaut 404.shtml, 403.shtml, etc. fournis par mon hôte. Si vous n'avez pas de réécritures .htaccess, cela fonctionne très bien; le serveur affichera sa propre page 404 par défaut et tout fonctionnera. (C'est du moins ce que je pensais, mais en réalité c'était la double erreur "De plus, une erreur 404 Not Found a été rencontrée lors de la tentative d'utilisation d'un ErrorDocument pour gérer la requête.")
Lorsque vous avez un .htaccess, par contre, il est exécuté une seconde fois pour la page 404. Si la page est là, elle sera utilisée, mais maintenant, la demande de 404.shtml a été interceptée par la règle générale et ensuite réécrite dans index.php. Pour cette raison, toutes les autres suggestions que j'ai reçues ici ou ailleurs ont toutes échoué, car la page 404 a finalement été réécrite dans index.php.
La solution consistait donc simplement à restaurer les modèles d'erreur. Rétrospectivement, il était assez stupide de les supprimer, mais j’ai cette mentalité de "partir de zéro". Ne veux rien traîner apparemment inutile. Au moins maintenant je comprends ce qui se passait, et c'est ce que je voulais.
Enfin, un commentaire à Cecil: Je n’ai jamais voulu interdire l’accès à quoi que ce soit, mais juste arrêter la réécriture. Ce n'est pas important, maintenant, mais je voulais juste clarifier ceci.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_URI} !^/wp-content/uploads/ [OR]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
Si /wp-content/uploads/ est vraiment le préfixe du chemin d'URI demandé, votre règle était censée fonctionner comme prévu.
Mais comme cela ne fonctionne évidemment pas, essayez de ne pas faire correspondre le préfixe du chemin complet de l'URI, mais uniquement le chemin restant sans le préfixe de chemin par répertoire contextuel, dans le cas du fichier .htaccess du répertoire racine du document sans le / initial:
RewriteCond $0 !^wp-content/uploads/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .+ /index.php [L]
Si cela ne fonctionne pas non plus, il serait certainement utile de mieux comprendre le processus de réécriture de mod_rewrite en utilisant sa fonctionnalité logging . Définissez donc RewriteLogLevel sur au moins 4, faites votre demande et examinez les entrées du fichier journal spécifié avec RewriteLog . Là, vous pouvez voir comment mod_rewrite traite votre requête et avec RewriteLogLevel supérieur ou égal à 4, vous verrez également les valeurs de variables comme %{REQUEST_URI}.
J'ai trouvé de nombreux exemples comme celui-ci lors de l'adoption d'une approche "WordPress First". Par exemple, ajouter:
ErrorDocument 404 /error-docs/404.html
le fichier .htaccess prend en charge le message ("En outre, une erreur 404 Introuvable ...").