Question Redirection, modification d'URL ou redirection HTTP vers HTTPS dans Apache - Tout ce que vous avez toujours voulu savoir sur les règles Mod_Rewrite sans avoir peur de le demander


C'est un Question canonique sur le mod_rewrite d'Apache.

La modification d'une URL de demande ou la redirection d'utilisateurs vers une URL différente de celle demandée à l'origine est effectuée à l'aide de mod_rewrite. Cela inclut des choses telles que:

  • Changer HTTP en HTTPS (ou l'inverse)
  • Modification d'une demande pour une page qui n'existe plus pour un nouveau remplacement.
  • Modification d'un format d'URL (tel que? Id = 3433 en / id / 3433)
  • Présenter une page différente basée sur le navigateur, basée sur le référant, basée sur tout ce qui est possible sous la lune et le soleil.
  • Tout ce que vous voulez déranger avec une URL

Tout ce que vous avez toujours voulu savoir sur les règles Mod_Rewrite sans oser le demander!

Comment puis-je devenir un expert en écriture de règles mod_rewrite?

  • Quels sont le format et la structure fondamentaux des règles mod_rewrite?
  • De quelle forme / saveur d'expressions régulières ai-je besoin pour bien comprendre?
  • Quelles sont les erreurs / écueils les plus courants lors de l’écriture des règles de réécriture?
  • Quelle est la bonne méthode pour tester et vérifier les règles mod_rewrite?
  • Existe-t-il des implications des règles mod_rewrite sur le référencement ou les performances que je devrais connaître?
  • Existe-t-il des situations courantes dans lesquelles mod_rewrite peut sembler être le bon outil pour le travail mais ne l'est pas?
  • Quels sont quelques exemples courants?

Un endroit pour tester vos règles

le testeur htaccess Le site Web est un excellent endroit pour jouer avec vos règles et les tester. Il affiche même la sortie de débogage afin que vous puissiez voir ce qui correspond ou non.


257
2017-12-20 16:59


origine


L'idée derrière cette question est de donner un chemin serré à toutes les questions sans fin de mod_rewrite qui rendent fous nos utilisateurs plus habitués. Ceci est très similaire à ce qui a été fait avec les sous-réseaux à serverfault.com/questions/49765/how-does-subnetting-work . - Kyle Brandt♦
En outre, je ne veux pas vraiment trop de votes positifs à ce sujet question, ils devraient plutôt aller à la réponse. Je ne veux pas utiliser ceci parce que je veux être sûr que l’affiche obtienne tout le crédit pour ce que j’espère être le mod_rewrite répond pour mettre fin à toutes les questions mod_rewrite. - Kyle Brandt♦
Désolé, j'ai voté à la question. ;-) Je pense vraiment qu'il faut que ça apparaisse au sommet (ou presque) mod-rewrite balises de recherche / filtres. - Steven Monday
Quelqu'un d'autre (tm) devrait gérer les cas d'utilisation courants. Je ne les connais pas assez pour que justice soit faite. - sysadmin1138♦
Peut-être que cette question devrait être reliée au wiki de balise de modification de réécriture pour rendre le chemin encore plus court. - beldaz


Réponses:


ordre de syntaxe mod_rewrite

mod_rewrite a des règles de classement spécifiques qui affectent le traitement. Avant que rien ne soit fait, le RewriteEngine On directive doit être donnée car cela active le traitement mod_rewrite. Cela devrait être avant toute autre directive de réécriture.

RewriteCond précédent RewriteRule soumet la règle ONE au conditionnel. Toutes les RewriteRules suivantes seront traitées comme si elles n'étaient pas soumises à des conditions.

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 provient de serverfault.com, redirigez les demandes de blog vers des pages serverfault spéciales (nous sommes tout simplement spéciaux). Cependant, 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 aux pages spéciales serverfault, pas seulement à celles avec un référent indiquant qu'il venait 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 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

Le plus complexe RewriteRule contient les conditions pour le traitement. La dernière parenthèse, (html|jpg) indique à RewriteRule de correspondre pour soit html ou jpg, et pour représenter la chaîne correspondante sous forme de $ 2 dans la chaîne réécrite. Ceci est logiquement identique au bloc précédent, avec deux paires RewriteCond / RewriteRule, il le fait simplement sur deux lignes au lieu de quatre.

Plusieurs lignes RewriteCond sont implicitement AND, et peuvent être explicitement OR. Pour gérer les référents de ServerFault et de super utilisateur (OU 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 car il spécifie comment suivre RewriteRule les directives traitent leur traitement. C'est très utile dans les fichiers .htaccess. Si utilisé, il devrait s'agir de 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

Ceci indique à mod_rewrite que cette URL particulière qu’elle gère actuellement est arrivée par le biais de http://example.com/blog/ au lieu du chemin du répertoire physique (/ home / $ nom_utilisateur / public_html / blog) et de le traiter en conséquence. Pour cette raison, le RewriteRule considère que le début de chaîne se situe après le "/ blog" dans l'URL. Voici la même chose écrite de deux manières différentes. 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 tirer parti du Web.site chemin vers le contenu plutôt que sur le Webserveur, ce qui peut les rendre plus intelligibles pour ceux qui modifient de tels fichiers. En outre, ils peuvent raccourcir les directives, ce qui présente un attrait esthétique.


Syntaxe de correspondance RewriteRule

RewriteRule a lui-même une syntaxe complexe pour faire correspondre les chaînes. 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 page de manuel Je vais donner des exemples et expliquer ce qu’ils font.

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

le .* construire correspond à n'importe quel caractère unique (.) zéro fois ou plus (*). Le mettre entre parenthèses lui indique de fournir la chaîne qui correspondait à la variable $ 1.

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

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

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

Dans ce cas, la première expression entre parenthèses définit un groupe correspondant. Cela devient $ 1, ce 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 de crochet spéciale qui spécifie un caractère. intervalle. [0-9] correspond aux chiffres 0 à 9. Cette règle spécifique s’applique aux années 2000 à 2099.

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

Cela fait la même chose que la règle précédente, mais la partie {2} lui dit 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 à n'importe quelle lettre minuscule de la deuxième expression correspondante et le fera pour autant de caractères que possible. le \. construct lui dit de traiter la période comme une période réelle, et non comme le caractère spécial qu'il est dans les exemples précédents. Cela se brisera si le nom du fichier contient des tirets.

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

Cela intercepte les noms de fichiers contenant des tirets. Cependant, comme - est un caractère spécial dans les expressions entre crochets, il doit être le premier caractère dans l'expression.

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

Cette version intercepte tout nom de fichier avec des lettres, des chiffres ou le - caractère dans le nom du fichier. Voici comment spécifier plusieurs jeux de caractères dans une expression entre crochets.


Drapeaux RewriteRule

Les drapeaux sur les règles de réécriture ont une foule de significations et de cas d'utilisation spéciaux.

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, mais les voici quand même:

L = Dernier. Arrêtez le traitement de RewriteRules une fois que celui-ci correspond. L'ordre compte!
C = Chaîne. Continuer le traitement de la prochaine RewriteRule. Si cette règle ne correspond pas, la règle suivante ne sera pas exécutée. Plus sur cela plus tard.
E = Définir la variable environnementale. Apache a diverses variables d'environnement qui peuvent affecter le comportement du serveur Web.
F = Interdit. Retourne une erreur 403-Forbidden si cette règle correspond.
g = Disparu. Retourne une erreur 410-Gone si cette règle correspond.
H = Gestionnaire. Force la demande à être traitée comme s'il s'agissait du type MIME spécifié.
N = Suivant. Force la règle à recommencer et à correspondre à nouveau. FAITES ATTENTION! Des boucles peuvent en résulter.
Caroline du Nord = Aucun cas. Permet jpg pour correspondre à la fois jpg et JPG.
NE = Pas d'échappatoire. Empêche la réécriture des caractères spéciaux (.? # & Etc) en leurs équivalents de code hexadécimal.
NS = Pas de sous-demandes. Si vous utilisez des inclusions côté serveur, cela empêchera les correspondances avec les fichiers inclus.
P = Proxy. Force la règle à être manipulée par mod_proxy. Fournissez le contenu de manière transparente à partir d'autres serveurs, car votre serveur Web le récupère et le restaure. Il s’agit d’un indicateur dangereux, car un indicateur mal écrit transformera votre serveur Web en proxy ouvert et c’est mauvais.
PT = Passer à travers. Prendre en compte les instructions Alias ​​dans la correspondance RewriteRule.
QSA = QSAppend. Lorsque la chaîne d'origine contient une requête (http://example.com/thing?asp=foo) ajoute la chaîne de requête originale à la chaîne réécrite. Normalement, il serait jeté. Important pour le contenu dynamique.
R = Redirection. Fournissez une redirection HTTP vers l'URL spécifiée. Peut également fournir le code de redirection exact [R = 303]. Très semblable à RedirectMatch, qui est plus rapide et doit être utilisé lorsque cela est possible.
S = Passer. Passer cette règle.
T = Type. Spécifiez le type mime du contenu renvoyé. Très semblable à la AddType directif.

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

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

Étant donné que la première règle RewriteRule a l'indicateur Chain, la deuxième règle rewrite est exécutée lorsque la première le fait, c'est-à-dire lorsque la règle RewriteCond précédente correspond. Très pratique si les expressions régulières Apache vous font mal au cerveau. Cependant, la méthode tout-en-un-ligne que je pointe 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

Ceci peut être simplifié grâce aux drapeaux:

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

En outre, certains indicateurs s'appliquent également à RewriteCond. Notamment, NoCase.

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

Correspondra à "ServerFault.com"


219
2017-12-20 17:44



Bien joué. [remplisseur] - EEAA
Très agréable mod_rewrite et amorce de regex. +1 - Steven Monday
Il est parfois utile de savoir que le RewriteCond est effectivement traité après la RewriteRule est apparié. Vous voudrez peut-être dire "plus à ce sujet plus tard" près du sommet où vous dites "RewriteCond précédent à RewriteRule rend cette règle ONE soumise au conditionnel". Vous voudrez peut-être mentionner que les expressions rationnelles sont des expressions régulières compatibles Perl. Vous avez aussi une apostrophe étrangère dans "... le RewriteRule considère que c'est un début de chaîne ..." - Dennis Williamson
RewriteRule ^/blog/.*/(.*)$ /newblog/$1 ne correspond pas à la premier composant d'annuaire - les réécritures sont gloutonnes par défaut. /.*/(.*) correspond à la fois à / 1 / (2) / et / 1/2/3/4/5 / (6) /, vous avez donc besoin de / [^ /] * / pour correspondre uniquement au chemin FIRST composant. - adaptr
@ sysadmin1138, je pense que cette réponse est bonne mais qu'elle peut être meilleure si vous développez davantage les drapeaux E, N, NS, P, PT et S avec des exemples car ces drapeaux ne sont pas évidents leur fonctionnement, etc. - Pacerier


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

Je vais me reporter à l'excellente réponse de sysadmin1138 sur ces points.

Quelle forme / saveur de régulière   expressions dois-je avoir un solide   compréhension des?

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

je recommanderais Le tutoriel de débogage de mod_rewrite de AskApache pour une liste complète des variables pouvant être disponibles pour mod_rewrite.

Quels sont les plus communs   erreurs / pièges lors de l'écriture de réécriture   règles?

La plupart des problèmes avec RewriteRule proviennent d'une incompréhension de la syntaxe PCRE / d'un échec pour échapper correctement des 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 interne du serveur - Supprimer les contrôles de chariot Windows dans le (s) fichier (s) de configuration, le cas échéant, assurez-vous que mod_rewrite est activé (directives wrap dans IfModule conditionnel pour éviter ce scénario), vérifiez la syntaxe des directives, commentez les directives jusqu'à ce que le problème soit identifié
  • Rediriger la boucle - Utilisez RewriteLog et RewriteLogLevel, commentez les directives jusqu'à ce que le problème soit identifié

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

Tout d’abord, examinez le contenu de la ou des variables d’environnement avec lesquelles vous prévoyez de faire correspondre le code. Si vous avez installé PHP, il vous suffit d’ajouter le bloc suivant à votre application:

<?php
  var_dump($_SERVER);
?>

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

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

Y a-t-il SEO ou performance?   implications des règles mod_rewrite I   devrait être au courant?

AllowOverride all impact sur les performances du serveur, car Apache doit vérifier .htaccess fichiers et directives d’analyse avec chaque requête - si possible, conservez toutes les directives dans la configuration VirtualHost de votre site ou activez-les. .htaccess remplace uniquement pour les répertoires qui en ont besoin.

Google Directives pour les webmasters déclarez 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 qui est communément appelé" masquage ". - évitez de créer des directives mod_rewrite qui filtrent les robots des moteurs de recherche.

Les robots des moteurs de recherche préfèrent un contenu 1: 1: mappage d'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 adresses URI, envisagez de spécifier URI canonique au sein de vos documents HTML.

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

C'est un sujet énorme (et potentiellement litigieux) en soi - mieux (à mon humble avis) de traiter les utilisations au cas par cas et de laisser les demandeurs déterminer si les solutions suggérées répondent à leurs besoins.

Quels sont quelques exemples courants?

Astuces et astuces de mod_rewrite de AskApache couvre à peu près tous les cas d'utilisation courants qui apparaissent régulièrement, cependant, 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 conseillé de voir autre directives qu'un utilisateur a mises en place chaque fois qu'une question mod_rewrite est posée).


38
2017-12-21 01:00



Merci pour le lien AskApache. C'est ce que je cherchais! - sica07
Le clown AskApache est officiellement non pris en charge par ASF. Une grande partie de ce qu'il dit est discutable ou tout simplement faux. - adaptr
@adaptr S'il vous plaît partager les ressources supérieures que vous êtes apparemment au courant. - danlefree
"Les situations courantes où mod_rewrite peut sembler être le bon outil pour le travail mais ne le sont pas?" - simple redirections, où mod_rewrite n'est pas déjà utilisé. Utilisez mod_alias Redirect ou RedirectMatch au lieu. Voir aussi la documentation Apache: Quand ne pas utiliser mod_rewrite - MrWhite


Comme beaucoup d'administrateurs / développeurs, je lutte depuis des années contre la complexité des règles de réécriture et je suis mécontent de la documentation Apache existante. J'ai donc décidé en tant que projet personnel d'aller au fond des choses. mod_rewrite fonctionne et interagit avec le reste du noyau Apache. C’est pourquoi, au cours des derniers mois, j’ai instrumenté des cas de test avec strace + approfondir le code source pour avoir une idée de tout cela.

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 fichiers .htaccess. toutefois
  • Certains traitements sont très différents pour la configuration racine (configuration serveur, hôte virtuel et répertoire) par opposition à PerDir (.htaccess) En traitement.
  • Pire, car le traitement PerDir peut presque indistinctement déclencher le cycle INTERNAL REDIRECT, les éléments de configuration racine doivent être consignés de manière consciente qu'un tel traitement PerDir peut déclencher cela.

Je dirais aussi que, pour cette raison, il est presque nécessaire de diviser les communautés d’utilisateurs en deux catégories et de les traiter de manière totalement distincte:

  • Ceux qui ont un accès root à la configuration Apache. Il s’agit généralement d’administrateur / développeur avec un serveur / une machine dédié à l’application, et le message est simple: évitez .htaccess fichiers si possible; faire tout dans votre serveur ou confhost config. Le débogage est assez facile car 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 avoir utiliser .htaccess / Perdir en cours de traitement car il n’ya pas d’alternative disponible.
    • Pire encore, le niveau de compétence de ces utilisateurs (jusqu’à l’utilisation de la logique à relais ladder de mod_rewrite) est généralement bien inférieur à celui des administrateurs expérimentés.
    • Apache et les fournisseurs d'hébergement n'offrent aucune assistance de débogage / diagnostic. La seule information de diagnostic est une redirection réussie, une redirection vers le mauvais URI. ou un code d'état 404/500. Cela les laisse confus et impuissants.
    • Apache est extrêmement faible, expliquant comment fonctionne la réécriture pour ce cas d'utilisation. Par exemple, il n’explique pas clairement ce que PerDir .htaccessle fichier est sélectionné et pourquoi. Cela n'explique pas les subtilités du cyclisme PerDir et comment l'éviter.

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

J'ai écrit quelques articles de blog de type article (par exemple Plus d'informations 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 vais pas répéter ici pour que ce post soit court. J'ai mon propre service partagé et je soutiens des projets dédiés et VM FLOSS. J'ai commencé par utiliser une machine virtuelle LAMP standard en tant que véhicule test pour mon compte SHS, mais j'ai finalement trouvé préférable de créer une machine virtuelle en miroir appropriée (décrite ci-dessous). ici).

Cependant, en ce qui concerne la façon dont la communauté administrative devrait soutenir .htaccess utilisateurs, j’ai le sentiment que nous devons développer et proposer:

  • Description cohérente du fonctionnement réel du système de réécriture dans le traitement PerDir
  • Un ensemble de directives / meilleures pratiques sur la rédaction .htaccess réécrire les règles
  • Un analyseur de script de réécriture basé sur le Web, similaire à l’analyseur HTML du W3C, mais qui permet aux utilisateurs de saisir des URI de test ou des vecteurs de test identiques et d’obtenir un journal immédiat du flux logique de réécriture /
  • Conseils pour obtenir des diagnostics intégrés à partir de vos règles (par exemple,

    • Utilisation [E=VAR:EXPR] exploiter le fait que EXPR développera les références arrières ($ N ou% N) pour les rendre disponibles en tant que diagnostics pour le script cible.
    • Si vous ordonnez topiquement vos règles de réécriture en utilisant les indicateurs [OR], [C], [SKIP] et [L], de sorte que le schéma de réécriture complet fonctionne sans pour autant la nécessité d’exploiter la redirection interne, vous pouvez alors ajouter ce qui suit comme règle 1 pour éviter tout problème de boucle:

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

21
2018-01-14 16:50



Ceci est bien documenté. Pourquoi dites-vous que la documentation n'explique pas cela? - adaptr
Tout ce que vous avez à faire est de vous abonner au .htaccess sujets et vous verrez. La plupart des débutants sont désespérément confus - la plupart d'entre eux ont leur première expérience d'un service LAMP et de mod_rewrite sur un service partagé et n'ont donc pas d'accès root aux configurations system / vhost et doivent utiliser le traitement par répertoire via .htaccessdes dossiers. Il y a des différences importantes que le débutant doit "oublier". Je me considérerais comme un utilisateur puissant et je découvre encore des subtilités. Comme je le disais, j’ai dû utiliser le balayage strace et le code source pour résoudre certains aspects. Il n’était pas nécessaire. :-( - TerryE
Je suis entièrement d'accord. "Nous devons diviser les communautés d'utilisateurs de réécriture en deux catégories et les traiter de manière totalement distincte." Certains utilisateurs utilisent l'hébergement partagé et avoir besoin compter sur .htaccess, ce qui est terriblement fragile, compliqué et déroutant, même pour les experts. J'ai encore des problèmes. - Ryan


Utiliser rewritemap

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

La syntaxe générale pour RewriteMap est la suivante:

RewriteMap MapName MapType:MapSource

Par exemple:

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

Vous pouvez ensuite utiliser le nom de carte pour des constructions comme ceci:

${examplemap:key}

La carte contient des paires clé / valeur. Si la clé est trouvée, la valeur est remplacée. Les cartes simples ne sont que des fichiers de texte brut, mais vous pouvez utiliser des cartes de hachage et même des requêtes SQL. Plus de détails sont dans la documentation:

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

Des cordes sans faille.

Il existe quatre cartes internes que vous pouvez utiliser pour effectuer certaines manipulations. Les cordes particulièrement évasives peuvent être utiles.

Par exemple: je souhaite tester la chaîne "café" dans la chaîne de requête. Cependant, le navigateur échappera cela avant de l'envoyer à mon serveur. Je devrai donc déterminer quelle est la version échappée de l'URL pour chaque chaîne que je souhaite faire correspondre, ou je peux simplement la décompresser ...

RewriteMap unescape int:unescape

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

Notez que j'utilise un RewriteCond pour capturer simplement l'argument dans le paramètre de chaîne de requête, puis que j'utilise la carte dans le deuxième rewriteCond pour le décompresser. Ceci est ensuite comparé. Notez également que j'ai besoin de% 2 en tant que clé du rewritemap, car% 1 contiendra "emplacement" ou "lieu". Lorsque vous utilisez des parenthèses pour regrouper des motifs, ceux-ci seront également capturés, que vous souhaitiez utiliser le résultat de la capture ou non ...


15
2018-04-06 11:57



La dernière phrase n'est pas tout à fait vraie. le mod_rewrite Le moteur regexp prend en charge les groupes non capturés tels que (?:location|place) et cela n'aura qu'une capture dans l'exemple. - TerryE


Quels sont les plus communs   erreurs / pièges lors de l'écriture de réécriture   règles?

Un écueil très facile consiste à réécrire les URL qui modifient le chemin apparent, par exemple. de /base/1234/index.html à /base/script.php?id=1234. Le client ne trouvera aucune image ni CSS ayant un chemin relatif vers l'emplacement du script. Un certain nombre d’options pour résoudre ceci peuvent être trouvées sur cette faq.


12
2018-01-01 04:02



Merci pour le lien. En particulier lorsque je travaille avec d’autres membres de l’équipe qui ne sont pas habitués à la réécriture, j’ajoute un <base> tag pour être le plus facile à suivre tout en permettant les chemins relatifs. - kontur