Redirection, changement d'URL ou redirection de HTTP vers HTTPS dans Apache - Tout ce que vous avez toujours voulu savoir sur les règles mod_rewrite sans jamais oser le demander

Ordre syntaxique du mod_rewrite

mod_rewrite a des règles d'ordonnancement spécifiques qui affectent le traitement. Avant que tout ne soit fait, le RewriteEngine On doit être donnée car elle active le traitement du mod_rewrite. Elle doit être placée avant toute autre directive de réécriture.

RewriteCond précédant RewriteRule rend cette règle unique soumise au conditionnel. Toutes les RewriteRules suivantes seront traitées comme si elles n'étaient pas soumises aux conditionnels.

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule $/blog/(.*)\.html        $/blog/$1.sf.html

Dans ce cas simple, si le référent HTTP est serverfault.com, redirigez les requêtes du blog vers des pages spéciales serverfault (nous sommes si spéciaux). Toutefois, si le bloc ci-dessus comportait une ligne RewriteRule supplémentaire :

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule $/blog/(.*)\.html        $/blog/$1.sf.html
RewriteRule $/blog/(.*)\.jpg         $/blog/$1.sf.jpg

Tous les fichiers .jpg iraient sur les pages spéciales de défaut de serveur, et pas seulement ceux dont le référent indique qu'ils viennent d'ici. Ce n'est clairement pas l'intention de la façon dont ces règles sont écrites. Cela pourrait être fait avec plusieurs règles RewriteCond :

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.html        /blog/$1.sf.html
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.jpg         /blog/$1.sf.jpg

Mais cela devrait probablement être fait avec une syntaxe de remplacement plus délicate.

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

La RewriteRule, plus complexe, contient les conditionnels à traiter. La dernière parenthèse, (html|jpg) indique à RewriteRule de correspondre à l'un ou l'autre des éléments suivants html o jpg et de représenter la chaîne correspondante comme étant $2 dans la chaîne réécrite. Ce bloc est logiquement identique au précédent, avec deux paires RewriteCond/RewriteRule, il le fait simplement sur deux lignes au lieu de quatre.

Les lignes RewriteCond multiples sont implicitement ANDées, et peuvent être explicitement ORées. Pour gérer les référents à la fois de ServerFault et de Super User (OR explicite) :

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)    [OR]
RewriteCond %{HTTP_REFERER}                ^https?://superuser\.com(/|$)
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

Pour servir les pages référencées ServerFault avec les navigateurs Chrome (ET implicite) :

RewriteEngine On
RewriteCond %{HTTP_REFERER}                ^https?://serverfault\.com(/|$)
RewriteCond %{HTTP_USER_AGENT}             ^Mozilla.*Chrome.*$
RewriteRule ^/blog/(.*)\.(html|jpg)        /blog/$1.sf.$2

RewriteBase est également spécifique à l'ordre puisqu'il précise comment RewriteRule se chargent de leur traitement. Elle est très utile dans les fichiers .htaccess. Si vous l'utilisez, elle doit être la première directive sous "RewriteEngine on" dans un fichier .htaccess. Prenons cet exemple :

RewriteEngine On
RewriteBase /blog
RewriteCond %{HTTP_REFERER}           ^https?://serverfault\.com(/|$)
RewriteRule ^(.*)\.(html|jpg)         $1.sf.$2

Cela indique au mod_rewrite que l'URL qu'il traite actuellement est arrivée par le biais de http://example.com/blog/ au lieu du chemin du répertoire physique (/home/$Username/public_html/blog) et de le traiter en conséquence. Pour cette raison, la méthode RewriteRule considère que le début de la chaîne doit se trouver après le "/blog" de l'URL. Voici la même chose écrite de deux manières différentes. L'une avec RewriteBase, l'autre sans :

RewriteEngine On

##Example 1: No RewriteBase##
RewriteCond %{HTTP_REFERER}                                   ^https?://serverfault\.com(/|$)
RewriteRule /home/assdr/public_html/blog/(.*)\.(html|jpg)     $1.sf.$2

##Example 2: With RewriteBase##
RewriteBase /blog
RewriteCond %{HTTP_REFERER}           ^https?://serverfault\.com(/|$)
RewriteRule ^(.*)\.(html|jpg)         $1.sf.$2

Comme vous pouvez le voir, RewriteBase permet aux règles de réécriture de s'appuyer sur le web- site chemin vers le contenu plutôt que le web- serveur ce qui peut les rendre plus intelligibles pour ceux qui éditent ces fichiers. De plus, ils peuvent rendre les directives plus courtes, ce qui présente un intérêt esthétique.

Syntaxe de la correspondance RewriteRule

RewriteRule a elle-même une syntaxe complexe pour faire correspondre les chaînes de caractères. Je couvrirai les drapeaux (des choses comme [PT]) dans une autre section. Parce que les administrateurs système apprennent par l'exemple plus souvent qu'en lisant un manuel de page de manuel Je vais donner des exemples et expliquer ce qu'ils font.

RewriteRule ^/blog/(.*)$    /newblog/$1

El .* correspond à tout caractère unique ( . ) zéro ou plusieurs fois ( * ). En la mettant entre parenthèses, on lui demande de fournir la chaîne qui a été trouvée comme variable $1.

RewriteRule ^/blog/.*/(.*)$  /newblog/$1

Dans ce cas, le premier .* n'était PAS entouré de parens et n'est donc pas fourni à la chaîne réécrite. Cette règle supprime un niveau de répertoire sur le site du nouveau blog. (/blog/2009/échantillon.html devient /newblog/échantillon.html).

RewriteRule ^/blog/(2008|2009)/(.*)$   /newblog/$2

Dans ce cas, la première expression entre parenthèses crée un groupe de correspondance. Celui-ci devient $1, qui n'est pas nécessaire et n'est donc pas utilisé dans la chaîne réécrite.

RewriteRule ^/blog/(2008|2009)/(.*)$   /newblog/$1/$2

Dans ce cas, nous utilisons $1 dans la chaîne réécrite.

RewriteRule ^/blog/(20[0-9][0-9])/(.*)$   /newblog/$1/$2

Cette règle utilise une syntaxe spéciale de parenthèses qui spécifie un caractère gamme . [0-9] correspond aux chiffres de 0 à 9. Cette règle spécifique traitera les années de 2000 à 2099.

RewriteRule ^/blog/(20[0-9]{2})/(.*)$  /newblog/$1/$2

Cette règle fait la même chose que la précédente, mais la partie {2} lui indique de faire correspondre le caractère précédent (une expression entre crochets dans ce cas) deux fois.

RewriteRule ^/blog/([0-9]{4})/([a-z]*)\.html   /newblog/$1/$2.shtml

Cette casse correspondra à toute lettre minuscule de la deuxième expression correspondante, et ce pour autant de caractères que possible. Le site \. indique que le point doit être traité comme un point réel, et non comme le caractère spécial qu'il est dans les exemples précédents. Cela ne fonctionnera pas si le nom du fichier contient des tirets.

RewriteRule ^/blog/([0-9]{4})/([-a-z]*)\.html  /newblog/$1/$2.shtml

Cela piège les noms de fichiers contenant des tirets. Cependant, comme - est un caractère spécial dans les expressions entre crochets, il doit s'agir du caractère premièrement dans l'expression.

RewriteRule ^/blog/([0-9]{4})/([-0-9a-zA-Z]*)\.html   /newblog/$1/$2.shtml

Cette version piège tout nom de fichier comportant des lettres, des chiffres ou le symbole - dans le nom du fichier. C'est ainsi que vous spécifiez plusieurs jeux de caractères dans une expression entre crochets.

Règle de réécriture des drapeaux

Les drapeaux sur les règles de réécriture ont une multitude de significations et de cas d'utilisation particuliers. .

RewriteRule ^/blog/([0-9]{4})/([-a-z]*).\html  /newblog/$1/$2.shtml  [L]

Le drapeau est le [L] à la fin de l'expression ci-dessus. Plusieurs drapeaux peuvent être utilisés, séparés par une virgule. La documentation liée décrit chacun d'eux, mais les voici quand même :

L \= Dernier. Arrêtez de traiter les RewriteRules une fois que celle-ci correspond. L'ordre compte !
C \= Chaîne. Continuez à traiter la RewriteRule suivante. Si cette règle ne correspond pas, alors la règle suivante ne sera pas exécutée. Nous y reviendrons plus tard.
E \= Définir une variable environnementale. Apache dispose de plusieurs variables environnementales qui peuvent affecter le comportement du serveur web.
F \= Interdit. Renvoie une erreur 403-Forbidden si cette règle correspond.
G \= Gone. Renvoie une erreur 410-Gone si cette règle correspond.
H \= Handler. Force la demande à être traitée comme s'il s'agissait du type MIME spécifié.
N \= Suivant. Force la règle à recommencer et à se recoupler. ATTENTION ! Des boucles peuvent en résulter.
NC \= Pas de cas. Autorise jpg pour correspondre à la fois à jpg et à JPG.
NE \= Pas d'échappement. Empêche la réécriture des caractères spéciaux (. ? # & etc) dans leurs équivalents en code hexadécimal.
NS \= Pas de sous-requêtes. Si vous utilisez des inclusions côté serveur, cela empêchera les correspondances avec les fichiers inclus.
P \= Proxy. Force la règle à être traitée par mod_proxy. Fournir de manière transparente du contenu provenant d'autres serveurs, car votre serveur web le récupère et le remet à disposition. C'est un drapeau dangereux, car s'il est mal écrit, votre serveur web deviendra un proxy ouvert, ce qui est mauvais.
PT \= Pass Through. Prendre en compte les déclarations Alias dans la correspondance RewriteRule.
QSA \= QSAppend. Lorsque la chaîne originale contient une requête ( http://example.com/thing?asp=foo ) ajoute la chaîne de requête originale à la chaîne réécrite. Normalement, elle devrait être rejetée. Important pour le contenu dynamique.
R \= Redirection. Fournit une redirection HTTP vers l'URL spécifiée. Peut également fournir le code de redirection exact [R=303]. Très similaire à RedirectMatch qui est plus rapide et devrait être utilisé lorsque cela est possible.
S \= Sauter. Ignorer cette règle.
T \= Type. Spécifiez le type de fichier mime du contenu renvoyé. Très similaire à l'option AddType directive.

Tu sais que j'ai dit que RewriteCond s'applique à une et une seule règle ? Eh bien, vous pouvez contourner cela en enchaînant.

RewriteEngine On
RewriteCond %{HTTP_REFERER}          ^https?://serverfault\.com(/|$)
RewriteRule ^/blog/(.*)\.html        /blog/$1.sf.html     [C]
RewriteRule ^/blog/(.*)\.jpg         /blog/$1.sf.jpg

Comme la première RewriteRule possède l'indicateur Chain, la seconde règle de réécriture s'exécutera lorsque la première le fera, c'est-à-dire lorsque la règle RewriteCond précédente sera satisfaite. Pratique si les expressions régulières d'Apache vous font mal au cerveau. Cependant, la méthode tout-en-un que j'ai indiquée dans la première section est plus rapide du point de vue de l'optimisation.

RewriteRule ^/blog/([0-9]{4})/([-0-9a-zA-Z]*)\.html   /newblog/$1/$2.shtml

Cela peut être simplifié grâce à des drapeaux :

RewriteRule ^/blog/([0-9]{4})/([-0-9a-z]*)\.html   /newblog/$1/$2.shtml   [NC]

De plus, certains drapeaux s'appliquent également à RewriteCond. Notamment, NoCase.

RewriteCond %{HTTP_REFERER}        ^https?://serverfault\.com(/|$)     [NC]

Correspond à "ServerFault.com"

Quel est le format fondamental et structure des règles mod_rewrite ?

Je m'en remets à l'excellente réponse de sysadmin1138 sur ces points.

Quelle forme/saveur de l'ordinaire régulière dois-je avoir une solide solide ?

En plus de l'ordre syntaxique, de la correspondance syntaxique/expressions régulières et des drapeaux RewriteRule décrits par sysadmin1138, je pense qu'il est utile de mentionner que mod_rewrite expose des variables d'environnement Apache basées sur les en-têtes de requête HTTP et la configuration d'Apache.

Je recommande Tutoriel de débogage du mod_rewrite d'AskApache pour une liste complète des variables qui peuvent être disponibles pour mod_rewrite.

Quels sont les erreurs et pièges les plus courants lors de la réécriture d'un texte. de réécriture ?

La plupart des problèmes rencontrés avec les RewriteRule proviennent d'une mauvaise compréhension de la syntaxe PCRE, de l'incapacité à échapper correctement les caractères spéciaux ou d'un manque de compréhension du contenu de la ou des variables utilisées pour la correspondance.

Problèmes typiques et dépannage recommandé :

• 500 - Erreur de serveur interne - Supprimer les contrôles de chariot de Windows dans le(s) fichier(s) de configuration s'il(s) est(sont) présent(s), assurez-vous que mod_rewrite est activé (les directives d'enveloppement dans le fichier IfModule conditionnel pour éviter ce scénario), vérifier la syntaxe des directives, commenter les directives jusqu'à ce que le problème soit identifié.
• Boucle de redirection - Utilisez RewriteLog et RewriteLogLevel, commentez les directives jusqu'à ce que le problème soit identifié.

Quelle est une bonne méthode pour tester et vérifier les règles mod_rewrite ?

Tout d'abord, vérifiez le contenu de la ou des variables d'environnement que vous souhaitez comparer. Si PHP est installé, il vous suffit d'ajouter le bloc suivant à votre application :

<?php
  var_dump($_SERVER);
?>

... puis rédigez vos règles (de préférence pour les tester sur un serveur de développement) et notez toute correspondance ou activité incohérente dans votre Apache. Journal des erreurs fichier.

Pour des règles plus complexes, utilisez le module mod_rewrite RewriteLog pour enregistrer l'activité dans un fichier et définir RewriteLogLevel 3

Existe-t-il un référencement ou des performances des règles du mod_rewrite dont je devrais-je connaître ?

AllowOverride all a un impact sur les performances du serveur car Apache doit vérifier que .htaccess et analysent les directives à chaque requête - si possible, conservez toutes les directives dans la configuration du VirtualHost de votre site ou activez la fonction .htaccess uniquement pour les répertoires qui en ont besoin.

Le site de Google Directives pour les webmasters déclarent explicitement : "Ne trompez pas vos utilisateurs et ne présentez pas aux moteurs de recherche un contenu différent de celui que vous affichez aux utilisateurs, ce que l'on appelle communément le "cloaking"." - évitez de créer des directives mod_rewrite qui filtrent pour les robots des moteurs de recherche.

Les robots des moteurs de recherche préfèrent une correspondance 1:1 entre le contenu et l'URI (c'est la base du classement des liens vers le contenu). Si vous utilisez mod_rewrite pour créer des redirections temporaires ou si vous diffusez le même contenu sous plusieurs URI, pensez à spécifier une valeur de URI canonique dans vos documents HTML.

Y a-t-il des situations courantes où mod_rewrite peut sembler être le bon outil pour le travail mais ne l'est pas ?

Il s'agit d'un sujet énorme (et potentiellement litigieux) en soi - il est préférable (IMHO) de traiter les utilisations au cas par cas et de laisser les demandeurs déterminer si les résolutions proposées sont appropriées à leurs besoins.

Quels sont les exemples les plus courants ?

Trucs et astuces sur le mod_rewrite d'AskApache couvre à peu près tous les cas d'utilisation courants, mais la solution "correcte" pour un utilisateur donné peut dépendre de la sophistication de la configuration de l'utilisateur et des directives existantes (c'est pourquoi il est généralement judicieux de voir quelles sont les solutions les plus appropriées pour l'utilisateur). autre qu'un utilisateur met en place chaque fois qu'une question relative au mod_rewrite se pose).

Comme de nombreux administrateurs/développeurs, je me bats depuis des années contre les subtilités des règles de réécriture et je ne suis pas satisfait de la documentation Apache existante. mod_rewrite fonctionne réellement et interagit avec le reste du noyau d'Apache, aussi, au cours des derniers mois, j'ai instrumenté des cas de test avec strace + de forer dans le code source pour avoir un aperçu de tout ça.

Voici quelques commentaires clés que les développeurs de règles de réécriture doivent prendre en compte :

• Certains aspects de la réécriture sont communs à la configuration du serveur, à l'hôte virtuel, au répertoire, au traitement des .htaccess. cependant
• Certains traitements sont très différents pour la configuration racine (configuration du serveur, hôte virtuel et répertoire) par rapport à la configuration PerDir ( .htaccess ) traitement.
• Pire encore, parce que le traitement PerDir peut presque indistinctement déclencher le cycle INTERNAL REDIRECT, les éléments de configuration de la racine doivent être écrits en sachant que ce traitement PerDir peut déclencher cela.

Je dirais même qu'à cause de cela, vous devez presque diviser les communautés d'utilisateurs de la réécriture en deux catégories et les traiter comme des entités totalement distinctes :

• Ceux qui ont un accès root à la configuration d'Apache . Il s'agit généralement d'administrateurs/développeurs disposant d'un serveur/VM dédié à une application, et le message à retenir ici est assez simple : évitez d'utiliser .htaccess si possible ; faites tout dans votre configuration de serveur ou de serveur virtuel. Le débogage est relativement facile puisque le développeur peut définir le débogage et a accès aux fichiers rewrite.log.

• Utilisateurs d'un service hébergé partagé (SHS) .

  • Ces utilisateurs ont à utiliser .htaccess / Traitement Perdir car il n'y a pas d'alternative disponible.
  • Pire encore, le niveau de compétence de ces utilisateurs (pour ce qui est de l'utilisation de la logique d'échelle de mod_rewrite basée sur les regexp) est généralement bien inférieur à celui des administrateurs expérimentés.
  • Apache et les fournisseurs d'hébergement n'offrent aucune aide au débogage ou au diagnostic. Les seules informations de diagnostic sont une redirection réussie, une redirection vers un mauvais URI ou un code d'état 404/500. Cela les laisse confus et impuissants.
  • Apache est extrêmement faible pour expliquer comment la réécriture fonctionne pour ce cas d'utilisation. Par exemple, il ne fournit pas d'explication claire de ce que PerDir .htaccess est sélectionné et pourquoi. Il n'explique pas les subtilités du cycle PerDir et la façon d'éviter cela.

Il existe peut-être une troisième communauté : le personnel administratif et de soutien des fournisseurs de services de santé et de sécurité qui se retrouve avec un pied dans les deux camps et doit subir les conséquences de ce qui précède.

J'ai écrit quelques billets de blog de type article (par ex. En savoir plus sur l'utilisation des règles de réécriture dans les fichiers .htaccess ) qui couvre un grand nombre de points détaillés que je ne répéterai pas ici pour que ce billet soit court. J'ai mon propre service partagé et je soutiens également quelques projets FLOSS dédiés et VM. J'ai commencé par utiliser une VM LAMP standard comme véhicule de test pour mon compte SHS, mais finalement j'ai trouvé qu'il était préférable de faire une VM miroir correcte (décrite dans le document ici ).

Cependant, en ce qui concerne la manière dont la communauté des administrateurs devrait soutenir .htaccess utilisateurs, je pense que nous devons nous développer et offrir :

• Une description cohérente de la façon dont le système de réécriture fonctionne réellement dans le traitement PerDir.
• Un ensemble de directives/meilleures pratiques sur la façon d'écrire. .htaccess règles de réécriture
• Un simple analyseur de réécriture de script basé sur le web, similaire aux analyseurs html du W3C, mais par lequel les utilisateurs peuvent entrer des URI de test ou des vecteurs de test de ceux-ci et obtenir un journal immédiat du flux logique de réécriture.

• Des conseils sur la façon d'obtenir des diagnostics intégrés à partir de vos règles (par ex.

  • Utilisez [E=VAR:EXPR] en exploitant le fait que EXPR développera les rétro-références ($N ou %N) pour les rendre disponibles comme diagnostics pour le script cible.

  • Si vous ordonnez vos règles de réécriture de manière topique en utilisant les drapeaux [OR], [C], [SKIP] et [L] afin que l'ensemble du schéma de réécriture fonctionne. sans si vous n'avez pas besoin d'exploiter la redirection interne, vous pouvez ajouter la règle suivante à la règle 1 pour éviter tout problème de bouclage :

    RewriteCond %{ENV:REDIRECT_STATUS} !=""
    RewriteRule .  -  [L]

Utilisation de rewritemap

Il y a beaucoup de choses que vous pouvez faire avec les rewritemaps. Les modèles de réécriture sont déclarés à l'aide de la directive Rewritemap et peuvent ensuite être utilisés dans les évaluations RewritCond et dans les substitutions RewriteRule.

La syntaxe générale de RewriteMap est :

RewriteMap MapName MapType:MapSource

Par exemple :

RewriteMap examplemap txt:/path/to/file/map.txt

Vous pouvez alors utiliser le nom de la carte pour des constructions comme celle-ci :

${examplemap:key}

La carte contient des paires clé/valeur. Si la clé est trouvée, la valeur est substituée. Les maps simples sont juste des fichiers texte, mais vous pouvez utiliser des maps de hachage, et même des requêtes SQL. Vous trouverez plus de détails dans la documentation :

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewritemap

Déchiffrage des chaînes de caractères.

Il existe quatre cartes internes que vous pouvez utiliser pour effectuer certaines manipulations. En particulier, le désencapsulage des chaînes de caractères peut s'avérer utile.

Par exemple : Je veux tester la présence de la chaîne "café" dans la chaîne de requête. Cependant, le navigateur l'échappera avant de l'envoyer à mon serveur, et je devrai donc trouver la version échappée de l'URL pour chaque chaîne que je souhaite faire correspondre, ou je peux simplement la déséchapper...

RewriteMap unescape int:unescape

RewriteCond %{QUERY_STRING}  (location|place)=(.*)
RewriteCond ${unescape:%2}   café
RewriteRule ^/find/$         /find/1234? [L,R]

Notez comment j'utilise un RewriteCond pour capturer l'argument du paramètre de la chaîne de requête, puis j'utilise la carte dans le second RewriteCond pour le désassembler. Le tout est ensuite comparé. Notez également que je dois utiliser %2 comme clé dans le plan de réécriture, car %1 contiendra soit "location", soit "place". Lorsque vous utilisez des parenthèses pour regrouper des motifs, elles sont également capturées, que vous ayez l'intention d'utiliser le résultat de la capture ou non...

Quels sont les les plus courantes lors de l'écriture de règles de réécriture de réécriture ?

Un piège très facile à éviter est celui de la réécriture d'URL qui modifie le chemin apparent, par exemple de /base/1234/index.html a /base/script.php?id=1234 . Toute image ou CSS avec des chemins relatifs à l'emplacement script ne sera pas trouvée par le client. Un certain nombre d'options pour résoudre ce problème peuvent être trouvées sur cette faq .