From: Lucien Gentis Date: Sun, 12 Jul 2026 13:21:08 +0000 (+0000) Subject: fr doc rebuild. X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=88082938836147dd37554f26c944653d52d1a035;p=thirdparty%2Fapache%2Fhttpd.git fr doc rebuild. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1936087 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_dbd.html.fr.utf8 b/docs/manual/mod/mod_dbd.html.fr.utf8 index deb056dc48..e3846f65f6 100644 --- a/docs/manual/mod/mod_dbd.html.fr.utf8 +++ b/docs/manual/mod/mod_dbd.html.fr.utf8 @@ -29,8 +29,6 @@

Langues Disponibles:  en  |  fr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
diff --git a/docs/manual/mod/mod_dbd.xml.meta b/docs/manual/mod/mod_dbd.xml.meta index 9131911db2..bf4a2e0a23 100644 --- a/docs/manual/mod/mod_dbd.xml.meta +++ b/docs/manual/mod/mod_dbd.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/mod/mod_heartmonitor.html.fr.utf8 b/docs/manual/mod/mod_heartmonitor.html.fr.utf8 index 82dbb476af..ad744ade20 100644 --- a/docs/manual/mod/mod_heartmonitor.html.fr.utf8 +++ b/docs/manual/mod/mod_heartmonitor.html.fr.utf8 @@ -29,8 +29,6 @@

Langues Disponibles:  en  |  fr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
Description:Gestion des connexions à une base de données SQL
Statut:Extension
Identificateur de Module:dbd_module
@@ -111,10 +109,11 @@ serveur HTTP Apache contrôler la quantité de mémoire partagée allouée pour le stockage des données heartbeat lorsqu'on utilise mod_slotmem_shm.

-

Pour utiliser un stockage de type fichier bidimensionnel (flat-file) - lorque le module mod_slotmem_shm n'est pas chargé, cette - directive doit être définie à 0. La valeur doit être soit égale à 0, soit - supérieure ou égale à 10.

+ +

Définissez cette directive à 0 pour utiliser un stockage de + type fichier bidimensionnel (flat-file) au lieu de la mémoire partagée + (c’est-à-dire sans charger mod_slotmem_shm). Lorsqu’on + utilise la mémoire partagée, la valeur doit être supérieure ou égale à 10.

top
diff --git a/docs/manual/mod/mod_heartmonitor.xml.meta b/docs/manual/mod/mod_heartmonitor.xml.meta index d0c5b2fb35..269a7db489 100644 --- a/docs/manual/mod/mod_heartmonitor.xml.meta +++ b/docs/manual/mod/mod_heartmonitor.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/mod/mod_proxy.html.fr.utf8 b/docs/manual/mod/mod_proxy.html.fr.utf8 index 8a1846ec11..ac70b99605 100644 --- a/docs/manual/mod/mod_proxy.html.fr.utf8 +++ b/docs/manual/mod/mod_proxy.html.fr.utf8 @@ -30,8 +30,6 @@  fr  |  ja 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
Description:Moniteur centralisé pour les serveurs d'origine mod_heartbeat
Statut:Expérimental
Identificateur de Module:heartmonitor_module
diff --git a/docs/manual/mod/mod_proxy.xml.meta b/docs/manual/mod/mod_proxy.xml.meta index f0185375d4..38a79fdda7 100644 --- a/docs/manual/mod/mod_proxy.xml.meta +++ b/docs/manual/mod/mod_proxy.xml.meta @@ -8,7 +8,7 @@ en - fr + fr ja diff --git a/docs/manual/mod/mod_rewrite.html.fr.utf8 b/docs/manual/mod/mod_rewrite.html.fr.utf8 index a4ebd97eab..d0489ee8f9 100644 --- a/docs/manual/mod/mod_rewrite.html.fr.utf8 +++ b/docs/manual/mod/mod_rewrite.html.fr.utf8 @@ -29,8 +29,6 @@

Langues Disponibles:  en  |  fr 

-
Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
Description:Serveur mandataire/passerelle multi-protocole
Statut:Extension
Identificateur de Module:proxy_module
@@ -50,17 +48,20 @@ règles permettant de réécrire les URLs des requêtes

mod_rewrite fournit une méthode souple et puissante pour manipuler les URLs en utilisant un nombre illimité de règles. Chaque règle peut être associée à un nombre illimité de conditions, afin de vous - permettre de réécrire les URLs en fonction de variables du serveur, de - variables d'environnement, de cookies, d'en-têtes HTTP, ou de repères - temporels.

-

mod_rewrite agit sur la totalité de l'URL, ou de toute - partie de cette dernière, y compris PATH_INFO ou QUERY_STRING.

- + permettre de réécrire les URLs en fonction de variables du serveur (y compris les en-têtes + HTTP, les détails de la connexion et les horodatages), de + variables d'environnement ou d’autres propriétés de la requête. Les règles + peuvent agir sur le chemin d’URL + (y compris toute information en fin de + nom de chemin) et peut aussi modifier la chaîne de paramètres. +

+

Une règle de réécriture peut être invoquée dans les fichiers de - configuration globale du serveur ou dans un contexte de répertoire. Le chemin généré par - une règle de réécriture peut inclure une chaîne de paramètres, ou peut - renvoyer vers un traitement secondaire interne, une redirection vers une - requête externe ou vers le mandataire interne.

+ configuration globale du serveur ou dans un contexte de répertoire. La chaîne de + substitution d’une règle de réécriture peut comporter une chaîne de + paramètres et une règle peut renvoyer vers un traitement secondaire + interne, une redirection vers une requête externe ou vers le mandataire + interne.

Vous trouverez plus de détails, discussions et exemples dans le Guide détaillé sur mod_rewrite.

@@ -76,7 +77,10 @@ règles permettant de réécrire les URLs des requêtes
  • RewriteOptions
  • RewriteRule
    • -

    Traitement des bugs

    +

    Traitement des bugs

    Voir aussi

    +
    top

    Journalisation

    @@ -104,7 +108,7 @@ règles permettant de réécrire les URLs des requêtes mod_rewrite vont probablement rechercher en vain les directives RewriteLog et RewriteLogLevel. Depuis la sortie de httpd 2.4, ces directives ont en effet été remplacées par une - configuration de la journalisation par module à l'aide de la directive + configuration de la journalisation par module à l’aide de la directive LogLevel.

    Pour extraire les traces spécifiques à @@ -141,7 +145,7 @@ répertoire DocumentRoot (c'est à dire que pour y accéder, il n'est pas nécessaire d'utiliser une directive telle qu'Alias). -

  • Le chemin de répertoire auquel la RewriteRule s'applique, suffixé par +
  • Le chemin de répertoire auquel la RewriteRule s’applique, suffixé par la substitution relative est aussi valable en tant que chemin d'URL sur le serveur (ce qui est rare).
  • A partir de la version 2.4.16 du serveur HTTP Apache, @@ -160,7 +164,7 @@ répertoire la réécriture soit effectuée
    • + TestString [!]CondPattern [flags] @@ -174,39 +178,63 @@ la réécriture soit effectuée et si l'URI correspond au modèle spécifié dans la règle.

    +

    Si CondPattern est préfixé par un !, la condition + ne sera évaluée à vrai que si CondPattern ne correspond pas.

    + + + + + +

    TestString

    +

    TestString est une chaîne qui peut contenir les extensions suivantes en plus du texte simple :

    -
    Description:Ce module fournit un moteur de réécriture à base de règles permettant de réécrire les URLs des requêtes à la volée
    Syntaxe: RewriteCond - chaîne_de_test expression_de_comparaison [drapeaux]
    Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
    Surcharges autorisées:FileInfo
    Statut:Extension
    @@ -231,7 +259,7 @@ la réécriture soit effectuée CONTEXT_PREFIX
    CONTEXT_DOCUMENT_ROOT
    IPV6
    - PATH_INFO
    + PATH_INFO
    QUERY_STRING
    REMOTE_ADDR
    REMOTE_HOST
    @@ -292,12 +320,35 @@ la réécriture soit effectuée struct tm du système Unix. La plupart d'entre elles sont documentées dans la documentation des expressions, dans la documentation des variables - d'environnement ou dans la spécification de + d’environnement ou dans la spécification de CGI (RFC 3875).

    SERVER_NAME et SERVER_PORT dépendent respectivement des valeurs des directives UseCanonicalName et UseCanonicalPhysicalPort.

    +

    Les variables SCRIPT_FILENAME et REQUEST_FILENAME contiennent + la même valeur — la valeur du champ filename de la + structure interne request_rec du serveur HTTP + Apache. Le premier nom est plus connu en tant que nom de + variable CGI alors que le second est la contrepartie appropriée + de REQUEST_URI (qui contient la valeur du champ uri + de la structure request_rec).

    + +

    Si une substitution se produit et que la réécriture continue, + la valeur des deux variables sera mise à jour en conséquence.

    + +

    Si elles sont utilisées dans un contexte global au serveur + (c’est-à-dire avant que la requête ne soit mise en parallèle + avec le système de fichiers), SCRIPT_FILENAME et + REQUEST_FILENAME ne peuvent pas contenir le chemin complet du + système de fichiers local, car le chemin est inconnu à ce + stade du traitement. Dans ce cas, les deux variables + contiendront initialement la valeur de REQUEST_URI. Pour obtenir + le chemin complet du système de fichiers local correspondant à + la requête, Utilisez une projection vers l’avant à base d’URL + %{LA-U:REQUEST_FILENAME} pour déterminer la valeur + finale de REQUEST_FILENAME.

    +

    Parmi les variables spécifiques à mod_rewrite, ou trouve les suivantes :

    @@ -370,8 +421,8 @@ la réécriture soit effectuée recoder, passez-la à la fonction de mappage "escape". Notez que cette variable de serveur est distincte de la - variable d'environnement CGI de même nom : dans un contexte - CGI, REQUEST_URI contient l'URI original complet + variable d’environnement CGI de même nom : dans un contexte + CGI, REQUEST_URI contient l’URI original complet de la requête, y compris la chaîne de paramètres. Voir la directive CGIVar pour les détails. @@ -387,70 +438,36 @@ la réécriture soit effectuée différence de la plupart des variables suivantes. - - + -

    Si la chaîne_de_test contient la valeur spéciale - expr, expression_de_comparaison sera traité - en tant qu'expression rationnelle de type ap_expr. Si des en-têtes HTTP sont - référencés dans l'expression rationnelle, et si le drapeau - novary n'est pas activé, ils seront ajoutés à - l'en-tête Vary.

    +

    Consultation de variables préfixées

    + +

    En plus des variables de serveur ci-avant, la syntaxe + %{PREFIX:name} permet d’accéder à des + ressources supplémentaires :

    -

    Autres points à connaître ::

    -
      -
    1. -

      Les variables SCRIPT_FILENAME et - REQUEST_FILENAME contiennent toutes deux la valeur - du champ filename de la - structure interne request_recdu serveur HTTP Apache. - Le premier nom correspond au nom de variable bien connu CGI, - alors que le second est l'équivalent de REQUEST_URI (qui - contient la valeur du champ uri de - request_rec).

      -

      Si une substitution intervient et si la réécriture se - poursuit, la valeur des deux variables sera mise à jour en - conséquence.

      -

      Dans le contexte du serveur principal (c'est à dire avant que - la requête ne soit mise en correspondance avec le système de - fichiers), SCRIPT_FILENAME et REQUEST_FILENAME ne peuvent pas - contenir le chemin entier dans le système de fichiers local car - ce chemin b'est pas connu à ce stade du traitement. Dans ce cas, - les deux variables contiendront la valeur de REQUEST_URI. Pour - obtenir le chemin complet de la requête dans le système de - fichiers local dans le contexte du serveur principal, utilisez une - référence avant à base d'URL - %{LA-U:REQUEST_FILENAME} pour déterminer la valeur - finale de REQUEST_FILENAME.

      2. - - -
    2. - %{ENV:variable}, où variable peut - correspondre à une variable d'environnement quelconque.
      3. -
    3. - %{ENV:variable} est aussi disponible, où - variable peut correspondre à toute variable - d'environnement. Peut être consulté via des structures internes +
      +
      %{ENV:variable}
      +
      Où variable peut correspondre à n’importe quelle variable + d’environnement. Peut être consulté via des structures internes d'Apache httpd et (si on ne les trouve pas ici) via la fonction getenv() à partir du processus du serveur Apache - httpd.
      4. - -
    4. Que mod_ssl soit chargé ou non, on peut - utiliser %{SSL:variable}, où variable - peut être remplacé par le nom d'une - variable - d'environnement SSL . Si mod_ssl n'est pas - chargé, cette variable contiendra toujours une chaîne vide. + httpd. + +
      %{SSL:variable}
      +
      Où variable est le nom d’une variable d’environnement SSL. Cette + variable peut être utilisée que mod_ssl soit chargé ou + non, mais elle sera toujours développée en une chaîne vide si + mod_ssl n’est pas chargé. Exemple : %{SSL:SSL_CIPHER_USEKEYSIZE} pourra contenir la valeur 128. Ces variables sont disponibles même si l'option StdEnvVars de la directive SSLOptions n'a - pas été définie.
      5. + pas été définie. -
    5. - On peut utiliser %{HTTP:en-tête}, où - en-tête peut correspondre à tout nom d'en-tête MIME - HTTP, pour extraire la valeur d'un en-tête envoyé dans la +
      %{HTTP:header}
      +
      Où header peut correspondre à n’importe quel nom d’en-tête + MIME HTTP. Cette variable peut toujours être utilisée pour obtenir la valeur d'un en-tête envoyé dans la requête HTTP. Par exemple, %{HTTP:Proxy-Connection} contiendra la valeur de l'en-tête HTTP "Proxy-Connection:". @@ -464,105 +481,130 @@ la réécriture soit effectuée logique de cout-circuit si le drapeau 'ornext|OR' est utilisé, et que de ce fait, certaines d'entre elles ne seront pas évaluées.

      -
      6. - -
    6. A des fins de référence avant, on peut utiliser, - %{LA-U:variable}, qui - permet d'effectuer une sous-requête interne à base d'URL, afin - de déterminer la valeur finale de variable. Ceci permet - d'accéder à la valeur d'une variable pour la réécriture inconnue - à ce stade du traitement, mais qui sera définie au - cours d'une phase ultérieure. -

      Par exemple, pour effectuer une réécriture dépendant de la - variable REMOTE_USER dans le contexte du serveur - principal (fichier httpd.conf), vous devez utiliser - %{LA-U:REMOTE_USER} - cette variable est définie - par la phase d'autorisation qui intervient après la - phase de traduction d'URL (pendant laquelle mod_rewrite - opère).

      -

      Par contre, comme mod_rewrite implémente son - contexte de répertoire (fichier - .htaccess) via la phase Fixup de l'API, et comme la phase - d'autorisation intervient avant cette dernière, vous pouvez - vous contenter d'utiliser %{REMOTE_USER} dans ce - contexte.

      7. - -
    7. - %{LA-F:variable} peut être utilisée pour effectuer - une sous-requête interne (basée sur le nom de fichier), afin de - déterminer la valeur finale de variable. La plupart du - temps, elle est identique à LA-U (voir ci-dessus).
      8. -
    + + + + + +

    Sous-requêtes de projection vers l’avant

    +

    Ces formes génèrent une sous-requête interne pour déterminer la valeur + finale d’une variable qui n’est pas encore disponible à ce stade du + traitement :

    -

    expression_de_comparaison est une expression +

    +
    %{LA-U:variable}
    +
    Génère une sous-requête interne (à base d’URL) pour déterminer la + valeur finale de variable. Ceci permet d'accéder à la valeur + d'une variable pour la réécriture inconnue à ce stade du traitement, + mais qui sera définie au cours d'une phase ultérieure. +

    Par exemple, pour effectuer une réécriture dépendant de la variable + REMOTE_USER dans le contexte du serveur principal (fichier + httpd.conf), vous devez utiliser + %{LA-U:REMOTE_USER} - cette variable est définie par la + phase d'autorisation qui intervient après la phase de + traduction d'URL (pendant laquelle mod_rewrite + opère).

    +

    Par contre, comme mod_rewrite implémente + son contexte de répertoire + (fichier .htaccess) via la phase Fixup de l'API, et comme + la phase d'autorisation intervient avant cette dernière, vous + pouvez vous contenter d'utiliser %{REMOTE_USER} dans ce + contexte.

    + +
    %{LA-F:variable}
    +
    Génère une sous-requête interne (à base de nom de fichier) pour + déterminer la valeur finale de la variable. Identique la + plupart du temps à LA-U ci-dessus.
    +
    + + + +

    Syntaxe des expressions

    + +

    Si la chaîne TestString contient la valeur spéciale + expr, le motif CondPattern sera traité comme une + expression ap_expr. Les en-têtes HTTP + référencés dans l’expression seront ajoutés à l’en-tête Vary si le drapeau + novary n’a pas été spécifié.

    + + + + + +

    CondPattern

    + + +

    CondPattern est une expression rationnelle qui est appliquée à l'instance actuelle de - chaîne_de_test. chaîne_de_test est d'abord + TestString. TestString est d'abord évaluée, puis comparée à - l'expression_de_comparaison.

    + l'CondPattern.

    -

    expression_de_comparaison est en général une +

    CondPattern est en général une expression rationnelle, mais vous disposez des syntaxes supplémentaires suivantes pour effectuer - d'autres tests utiles sur chaîne_de_test : + d'autres tests utiles sur TestString :

    -
      -
    1. Vous pouvez préfixer l'expression avec un caractère + + +

      Vous pouvez préfixer l'expression avec un caractère '!' (point d'exclamation) pour inverser le résultat de la condition, quelle que soit l'expression de - comparaison utilisée.

      2. + comparaison utilisée.

      -
    2. Vous pouvez effectuer des comparaisons lexicographiques de - chaînes : + -
      +

      Comparaisons de chaînes

      + +
      <expression
      inférieur au sens lexicographique
      Traite l'expression comme une chaîne de caractères et la compare lexicographiquement à - chaîne_de_test. La condition est satisfaite si - chaîne_de_test est inférieure au sens + TestString. La condition est satisfaite si + TestString est inférieure au sens lexicographique à l'expression.
      >expression
      supérieur au sens lexicographique
      Traite l'expression comme une chaîne de caractères et la compare lexicographiquement à - chaîne_de_test. La condition est satisfaite si - chaîne_de_test est supérieure au sens + TestString. La condition est satisfaite si + TestString est supérieure au sens lexicographique à l'expression.
      =expression
      égal au sens lexicographique
      Traite l'expression comme une chaîne de caractères et la compare lexicographiquement à - chaîne_de_test. La condition est satisfaite si - chaîne_de_test est égale au sens + TestString. La condition est satisfaite si + TestString est égale au sens lexicographique à l'expression (les deux chaînes sont exactement identiques, caractère pour caractère). Si expression est "" (deux guillemets), - chaîne_de_test est comparée à la + TestString est comparée à la chaîne vide.
      <=expression de comparaison
      inférieur ou égal à au sens lexicographique
      - Considère l'expression_de_comparaison comme une + Considère la CondPattern comme une chaîne de caractères et la compare au sens lexicographique à - la chaîne_de_test. Vrai si chaîne_de_test - précède lexicographiquement expression_de_comparaison, ou est - égale à expression_de_comparaison (les deux chaînes + la TestString. Vrai si TestString + précède lexicographiquement CondPattern, ou est + égale à CondPattern (les deux chaînes sont identiques, caractère pour caractère).
      >=expression de comparaison
      supérieur ou égal à au sens lexicographique
      - Considère l'expression_de_comparaison comme une + Considère la CondPattern comme une chaîne de caractères et la compare au sens lexicographique à - la chaîne_de_test. Vrai si chaîne_de_test - suit lexicographiquement expression_de_comparaison, ou est - égale à expression_de_comparaison (les deux chaînes + la TestString. Vrai si TestString + suit lexicographiquement CondPattern, ou est + égale à CondPattern (les deux chaînes sont identiques, caractère pour caractère).
      -
      +

      Note

      L'opérateur de comparaison de chaînes fait partie des arguments de la CondPattern et doit par conséquent se trouver entre les @@ -572,53 +614,53 @@ la réécriture soit effectuée
      -
      3. -
    3. - Vous pouvez effectuer des comparaisons d'entiers : -
      + +

      Comparaisons d’entiers

      + +
      -eq
      est numériquement égal à
      - La chaîne_de_test est considérée comme un entier, + TestString est considérée comme un entier, et est comparée numériquement à l'expression de comparaison. Vrai si les deux expressions sont numériquement égales.
      -ge
      est numériquement supérieur ou égal à
      - La chaîne_de_test est considérée comme un entier, + TestString est considérée comme un entier, et est comparée numériquement à l'expression de - comparaison. Vrai si chaîne_de_test est + comparaison. Vrai si TestString est numériquement supérieure ou égale à - expression_de_comparaison.
      + CondPattern.
      -gt
      est numériquement supérieur à
      - La chaîne_de_test est considérée comme un entier, + TestString est considérée comme un entier, et est comparée numériquement à l'expression de - comparaison. Vrai si chaîne_de_test est + comparaison. Vrai si TestString est numériquement - supérieure à expression_de_comparaison.
      + supérieure à CondPattern.
      -le
      est numériquement inférieur ou égal à
      - La chaîne_de_test est considérée comme un entier, + TestString est considérée comme un entier, et est comparée numériquement à l'expression de - comparaison. Vrai si chaîne_de_test est + comparaison. Vrai si TestString est numériquement - inférieure ou égale à expression_de_comparaison. + inférieure ou égale à CondPattern. Attention à la confusion avec le drapeau -l en utilisant la variante the -L ou -h.
      -lt
      est numériquement inférieur à
      - La chaîne_de_test est considérée comme un entier, + TestString est considérée comme un entier, et est comparée numériquement à l'expression de - comparaison. Vrai si chaîne_de_test est + comparaison. Vrai si TestString est numériquement - inférieure à expression_de_comparaison. + inférieure à CondPattern. Attention à la confusion avec le drapeau -l en utilisant la variante the -L ou -h.
      @@ -630,39 +672,42 @@ la réécriture soit effectuée si les deux éléments comparés sont numériquement différents. Equivalent à !-eq. -
      -
      4. - -
    4. Vous pouvez effectuer différents tests sur les attributs de - fichier : -
      +
      + + +

      Tests des attributs de fichier

      + +
      -d
      est un répertoire
      - Traite chaîne_de_test comme un chemin et vérifie + Traite TestString comme un chemin et vérifie s'il existe ou pas, et s'il s'agit d'un répertoire.
      -f
      est un fichier régulier
      - Traite chaîne_de_test comme un chemin et vérifie - s'il existe ou pas, et s'il s'agit d'un fichier régulier.
      + Traite TestString comme un chemin et vérifie + s'il existe ou pas, et s'il s'agit d'un fichier régulier. +
      -F
      test de l'existence d'un fichier via une sous-requête
      - Vérifie si chaîne_de_test est un fichier valide, + Vérifie si TestString est un fichier valide, accessible à travers tous les contrôles d'accès du serveur actuellement configurés pour ce chemin. C'est une sous-requête interne qui effectue cette vérification - à utiliser avec précautions car les performances du serveur - peuvent s'en trouver affectées !
      + peuvent s'en trouver affectées ! +
      -h
      est un lien symbolique, selon la convention bash
      - Voir -l.
      + Voir -l. +
      -l
      est un lien symbolique
      - Considère la chaîne_de_test comme un chemin et + Considère la TestString comme un chemin et vérifie son existence et si elle est un lien symbolique. On peut aussi utiliser la convention bash -L ou -h lorsqu'il y a risque de confusion @@ -674,14 +719,14 @@ la réécriture soit effectuée
      -s
      est un fichier régulier d'une certaine taille
      - Considère la chaîne_de_test comme un chemin et + Considère la TestString comme un chemin et vérifie son existence et si elle est un fichier régulier d'une taille supérieure à zéro.
      -U

      test de l'existence d'une URL via une sous-requête
      - Vérifie si chaîne_de_test est une URL valide, + Vérifie si TestString est une URL valide, accessible à travers tous les contrôles d'accès du serveur actuellement configurés pour ce chemin. C'est une sous-requête interne qui effectue cette vérification - à @@ -696,23 +741,24 @@ la réécriture soit effectuée

      -x
      a l'attribut d'exécution positionné
      - Considère la chaîne_de_test comme un chemin et + Considère la TestString comme un chemin et vérifie son existence et si elle a son attribut d'exécution positionné. Ce positionnement est déterminé en fonction de l'OS sous-jacent.
      -
      + - Par exemple: +

      Par exemple :

      RewriteCond /var/www/%{REQUEST_URI} !-f
 RewriteRule ^(.+) /other/archive/$1 [R]
      -
      5. + + +

      Évaluation des expressions

      -
    5. -

      Si la chaîne_de_test contient la valeur spéciale +

      Si TestString contient la valeur spéciale expr, la chaîne de comparaison sera traitée en tant qu'expression rationnelle de type ap_expr.

      @@ -726,31 +772,34 @@ RewriteRule ^(.+) /other/archive/$1 [R] 
                 RewriteCond expr "! %{HTTP_REFERER} -strmatch '*://%{HTTP_HOST}/*'"
            RewriteRule "^/images" "-" [F]
      -
      6. -
    + + + + +

    Drapeaux

    Vous pouvez aussi définir certains drapeaux pour - l'expression_de_comparaison en ajoutant ces - [drapeaux] + la CondPattern en ajoutant ces + [flags] comme troisième argument de la directive - RewriteCond, où drapeaux est un + RewriteCond, où flags est un sous-ensemble séparé par des virgules des drapeaux suivants :

    - + + + + + -

    Exemple :

    +

    Exemple

    Pour réécrire la page d'accueil d'un site en fonction de l'en-tête ``User-Agent:'' de la requête, vous @@ -1135,7 +1187,7 @@ pour le moteur de réécriture

    + [!]PatternSubstitution [flags] @@ -1149,11 +1201,14 @@ pour le moteur de réécriture les règles seront appliquées au cours du processus de réécriture.

    -

    Modèle est une expression +

    Pattern est une expression rationnelle. Ce avec quoi ce modèle est comparé dépend de l'endroit où la directive RewriteRule est définie.

    +

    Si le motif est précédé d’un !, la substitution ne sera + effectuée que si le pattern ne correspond pas.

    +

    Qu'est-ce qui est comparé ?

    -

    Pour quelques conseils à propos des expressions rationnelles, voir le - document Introduction à - mod_rewrite.

    - -

    Dans mod_rewrite, on peut aussi utiliser le caractère - NOT ('!') comme préfixe de modèle. Ceci vous permet - d'inverser la signification d'un modèle, soit pour dire - ``si l'URL considérée ne correspond PAS à - ce modèle''. Le caractère NON peut donc être utilisé à - titre exceptionnel, lorsqu'il est plus simple d'effectuer une - comparaison avec le modèle inversé, ou dans la dernière règle - par défaut.

    - -

    Note

    -Si vous utilisez le caractère NON pour inverser la signification d'un -modèle, vous ne pouvez pas inclure de parties génériques groupées dans -le modèle. Ceci est dû au fait que, lorsque le modèle ne correspond -pas (autrement dit, sa négation correspond), les groupes sont vides. -Ainsi, si vous utilisez des modèles inversés, vous ne pouvez -pas vous référer aux groupes par $N dans la chaîne de -substitution ! -
    +

    Pour des informations à propos des expressions + rationnelles, y compris l’utilisation du préfixe ! + pour inverser un motif, voir la section Expressions rationnelles de + l’introduction à mod_rewrite.

    -

    Dans une règle de réécriture, - Substitution est la chaîne - de caractères qui remplace le chemin de l'URL original qui - correspondait au Modèle. Substitution peut - être :

    +

    Dans une règle de réécriture, Substitution est la chaîne de caractères qui + remplace le chemin de l'URL (voir "Qu’est-ce + qui est comparé ?" ci-avant) lorsque les conditions de la règle sont + satisfaites. Substitution peut être :

    @@ -1292,7 +1328,7 @@ substitution !
    Il indique alors la localisation dans le système de fichiers de la ressource qui doit être envoyée au client. Une substitution commençant - par / n'est traitée comme un chemin du système de fichiers + par / n’est traitée comme un chemin du système de fichiers que dans un contexte de serveur virtuel ou de serveur global, et seulement si le premier composant du chemin existe dans le système de fichiers. Dans un contexte de @@ -1304,7 +1340,7 @@ substitution ! doit être servie. Dans un contexte de serveur virtuel ou de serveur global, si le premier composant du chemin existe à la racine du système de fichiers, la substitution est traitée comme un chemin du système de - fichiers. Par exemple, /www/file.html est un chemin d'URL, + fichiers. Par exemple, /www/file.html est un chemin d’URL, sauf si un répertoire nommé www existe à la racine du système de fichiers. Si vous désirez que d'autres directives de correspondance d'URL (comme la directive Alias) soient appliquées au @@ -1337,23 +1373,23 @@ substitution !

    Comment sont interprétées les substitutions de chemin

    En fonction du contexte et si elle commence ou non par un slash, une substitution sera traitée comme un chemin du système de fichiers ou comme - un chemin d'URL :

    + un chemin d’URL :

    • Commence par un /, contexte de serveur virtuel ou de serveur global : Traitée comme un chemin du système de fichiers si le premier composant du - chemin existe sur disque ; sinon, traitée comme un chemin d'URL.
      • + chemin existe sur disque ; sinon, traitée comme un chemin d’URL.
    • Commence par un /, contexte de répertoire : - Toujours traitée comme un chemin d'URL. Pas de vérification sur le + Toujours traitée comme un chemin d’URL. Pas de vérification sur le système de fichiers.
    • Ne commence pas par un / (chemin relatif), contexte de serveur virtuel - ou de serveur global : Traitée comme un chemin d'URL relatif à - l'URI de la requête actuelle.
      • + ou de serveur global : Traitée comme un chemin d’URL relatif à + l’URI de la requête actuelle.
    • Ne commence pas par un / (chemin relatif), contexte de - répertoire : Traitée comme un chemin d'URL relatif + répertoire : Traitée comme un chemin d’URL relatif au chemin de répertoire auquel la directive Directory ou le fichier .htaccess - s'appliquent. Voir RewriteBase pour le contrôle + s’appliquent. Voir RewriteBase pour le contrôle du préfixe ajouté aux substitutions relatives.
    @@ -1372,7 +1408,7 @@ substitution ! condition d'une règle (%{VARNAME})
  • des appels de - fonctions de comparaison + fonctions de mappage (${nom correspondance:clé|défaut})
    • @@ -1421,10 +1457,10 @@ substitution !

    En outre, vous pouvez spécifier des actions spéciales à effectuer en ajoutant des - [drapeaux] + [flags] comme troisième argument de la directive RewriteRule. Séparés par des virgules au sein d'une - liste encadrée par des crochets, les drapeaux peuvent + liste encadrée par des crochets, les flags peuvent être choisis dans la table suivante. Vous trouverez plus de détails, et des exemples pour chaque drapeau dans le document à propos des drapeaux de réécriture.

    @@ -1582,7 +1618,7 @@ substitution !
    - @@ -1590,7 +1626,7 @@ substitution !
    Description:Définit les règles pour le moteur de réécriture
    Syntaxe:RewriteRule - Modèle Substitution [drapeaux]
    Contexte:configuration globale, serveur virtuel, répertoire, .htaccess
    Surcharges autorisées:FileInfo
    Statut:Extension
    UnsafeAllow3FAutorise les substitutions à partir d'URL potentiellement non + Autorise les substitutions à partir d’URL potentiellement non fiables. détails ...
    UnsafePrefixStat Autorise les substitutions potentiellement non fiables à partir - d'une variable de tête ou d'une référence arrière vers un chemin du + d’une variable de tête ou d’une référence arrière vers un chemin du système de fichiers. détails ...
    Disponible à partir de la version 2.5.1 du serveur HTTP Apache. diff --git a/docs/manual/mod/mod_rewrite.xml.meta b/docs/manual/mod/mod_rewrite.xml.meta index 0be21e86f4..decc0a7b1e 100644 --- a/docs/manual/mod/mod_rewrite.xml.meta +++ b/docs/manual/mod/mod_rewrite.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/mod/mod_unique_id.html.fr.utf8 b/docs/manual/mod/mod_unique_id.html.fr.utf8 index dd7ccbdcd2..4b651ddf27 100644 --- a/docs/manual/mod/mod_unique_id.html.fr.utf8 +++ b/docs/manual/mod/mod_unique_id.html.fr.utf8 @@ -31,8 +31,6 @@  ja  |  ko 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
    @@ -88,27 +86,30 @@ identifiant unique pour chaque requête
  • Les temps des machines sont synchronisés via NTP ou tout autre protocole de synchronisation du temps en réseau.
    • -
  • Les nom d'hôtes des machines sont tous différents, de façon à - ce que le module puisse recevoir une adresse IP différente pour - chaque machine du cluster en effectuant une recherche sur le nom - d'hôte.
    • +

    Changements à partir de la version 2.4.29

    +

    Dans les versions précédentes, l’unicité nécessitait aussi que chaque + machine ait une adresse IP distincte. Depuis la version 2.4.29, le module + utilise un générateur de nombres pseudo-aléatoires cryptographique (PRNG) + ensemencé au démarrage, tout en supprimant l’adresse IP et le PID de + l’identifiant et en ne nécessitant plus de noms d’hôte distincts ou de + délai au démarrage.

    +

    Au vu des caractéristiques actuelles du système d'exploitation, nous supposerons que les pids (identifiants processus) sont codés sur 32 bits. Si le système d'exploitation utilise plus de 32 bits pour un pid, la correction est triviale mais doit être effectuée dans le code.

    -

    Ces hypothèses posées, à un instant donné, nous pouvons - distinguer tout processus httpd sur toute machine du cluster de tous - les autres processus httpd. Pour ce faire, il suffit d'utiliser - l'adresse IP de la machine et le pid du processus httpd. Un - processus httpd peut traiter plusieurs requêtes simultanément si - vous utilisez un module MPM multi-threadé. Pour identifier les - threads, Apache httpd utilise en interne un index de threads. Ainsi, - afin de générer des identifiants uniques pour chaque requête, il - suffit d'effectuer une distinction en fonction du temps.

    +

    Ces hypothèses posées, à un instant donné, nous pouvons distinguer tout + processus httpd sur toute machine du cluster de tous les autres processus + httpd. La valeur racine générée par PRNG et l’index des threads permettent + d’accomplir cette tâche. Un processus httpd peut traiter plusieurs requêtes + simultanément si vous utilisez un module MPM multi-threadé. Pour identifier + les threads, Apache httpd utilise en interne un index de threads. Ainsi, + afin de générer des identifiants uniques pour chaque requête, il suffit + d'effectuer une distinction en fonction du temps.

    Pour déterminer le temps, nous utiliserons un repère de temps Unix (les secondes écoulées depuis le 1er janvier 1970 UTC), et un @@ -190,21 +191,21 @@ identifiant unique pour chaque requête redémarrage.

    -

    La variable d'environnement UNIQUE_ID est construite - par codage du quadruplet de 144 bits (adresse IP sur 32 bits, pid - sur 32 bits, repère de temps sur 32 bits, compteur 16 bits et index - de threads sur 32 bits) en +

    Depuis la version 2.4.29, la variable d'environnement UNIQUE_ID est construite + par codage d’une valeur de 160 bits (32 bits pour l’horodatage, 80 bits pour + la racine PRNG, 16 bits pour le compteur et 32 bits pour l’index des + threads)) en utilisant l'alphabet [A-Za-z0-9_-] d'une manière similaire à celle du codage MIME base64, et sa valeur se présente - sous la forme d'une chaîne de 24 caractères. L'alphabet MIME base64 + sous la forme d'une chaîne de 27 caractères. L'alphabet MIME base64 est en fait [A-Za-z0-9+/] ; cependant, les caractères + et / nécessitent un codage particulier dans les URLs, ce qui rend leur utilisation peu commode. Toutes les valeurs sont codées dans l'ordre des octets d'une adresse réseau de façon à ce que le codage soit comparable entre des architectures où l'ordre des - octets est différent. L'ordre réel de codage est : repère de temps, - adresse IP, pid, compteur. Cet ordre de codage possède un but + octets est différent. L'ordre réel de codage est : horodatage, racine, + compteur, index des threads. Cet ordre de codage possède un but précis, mais il faut souligner que les applications n'ont aucun intérêt à entrer dans les détails de ce codage. Les applications doivent se contenter de traiter la variable UNIQUE_ID @@ -232,12 +233,7 @@ identifiant unique pour chaque requête machines du cluster (seule la synchronisation NTP est requise, ce qui représente une charge très faible), et aucune communication entre les processus httpd n'est nécessaire (la communication est - implicite et incluse dans le pid assigné par le noyau). Dans des - situations très spécifiques, l'identifiant peut être raccourci, mais - dans ce cas, d'avantage d'informations doivent être admises (par - exemple, les 32 bits de l'adresse IP sont excessifs pour la plupart - des sites, mais il n'existe pas de valeur de remplacement portable - plus courte).

    + implicite dans la graine PRNG assignée au démarrage)..

    diff --git a/docs/manual/mod/mod_unique_id.xml.meta b/docs/manual/mod/mod_unique_id.xml.meta index 433c4753bb..c5e950d875 100644 --- a/docs/manual/mod/mod_unique_id.xml.meta +++ b/docs/manual/mod/mod_unique_id.xml.meta @@ -8,7 +8,7 @@ en - fr + fr ja ko diff --git a/docs/manual/mod/quickreference.html.fr.utf8 b/docs/manual/mod/quickreference.html.fr.utf8 index f5c289ba5f..b719241676 100644 --- a/docs/manual/mod/quickreference.html.fr.utf8 +++ b/docs/manual/mod/quickreference.html.fr.utf8 @@ -1350,7 +1350,7 @@ pas.
    + [!]PatternSubstitution [flags]
    Description:Fournit une variable d'environnement contenant un identifiant unique pour chaque requête
    Statut:Extension
    RewriteBase chemin_URLdhE
    Définit l'URL de base pour les réécritures au niveau répertoire
    RewriteCond - chaîne_de_test expression_de_comparaison [drapeaux]svdhE
    Définit une condition qui devra être satisfaite pour que + TestString [!]CondPattern [flags]svdhE
    Définit une condition qui devra être satisfaite pour que la réécriture soit effectuée
    RewriteEngine on|off off svdhE
    Active ou désactive l'exécution du @@ -1361,7 +1361,7 @@ recherche de mots-clés
    RewriteOptions OptionssvdhE
    Configure certaines options spéciales pour le moteur de réécriture
    RewriteRule - Modèle Substitution [drapeaux]svdhE
    Définit les règles pour le moteur de réécriture
    svdhE
    Définit les règles pour le moteur de réécriture
    RLimitCPU secondes|max [secondes|max]svdhC
    Limite le temps CPU alloué aux processus initiés par les processus enfants d'Apache httpd
    RLimitMEM octets|max [octets|max]svdhC
    Limite la mémoire allouée aux processus initiés par les diff --git a/docs/manual/rewrite/avoid.html.fr.utf8 b/docs/manual/rewrite/avoid.html.fr.utf8 index d743e7bd08..b61ab411a5 100644 --- a/docs/manual/rewrite/avoid.html.fr.utf8 +++ b/docs/manual/rewrite/avoid.html.fr.utf8 @@ -32,8 +32,6 @@  tr  |  zh-cn 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    Ce document est un complément à la Documentation de référence de @@ -64,11 +62,19 @@ vous tourner vers mod_rew

    +correspondance
  • Réécritures par répertoire
  • Drapeaux de RewriteRule
  • Serveurs virtuels
  • Utilisation de RewriteMap
  • Détails techniques
    • top

    Redirection simple

    @@ -108,44 +114,31 @@ rediriger toutes les URLs de niveaux inférieurs comme example.com vers www.example.com, voir la méthode Noms d'hôtes canoniques.

    -

    Pour rediriger les URLs http vers https, -utilisez cette définition :

    - -
    <VirtualHost *:80>
-    ServerName www.example.com
-    Redirect "/" "https://www.example.com/"
-</VirtualHost>
-
-<VirtualHost *:443>
-    ServerName www.example.com
-    # ... insérer ici la configuration SSL
-</VirtualHost>
    - - -

    L'utilisation de la directive RewriteRule pour accomplir -cette tâche peut se justifier s'il existe d'autres directives -RewriteRule dans la même portée. En effet, lorsque des -directives Redirect et RewriteRule se trouvent -dans la même portée, les directives RewriteRule sont -exécutées en premier, sans tenir compte de leur ordre d'apparition dans -le fichier de configuration.

    - -

    Dans le cas de la redirection http-vers-https, l'utilisation -de règles RewriteRule se justifie si vous n'avez pas accès -au fichier de configuration principal, et devez donc accomplir cette -tâche au sein d'un fichier .htaccess.

    +

    Pour rediriger les URLs http vers https, une +directive Redirect dans un serveur +virtuel HTTP dédié est l’approche la plus propre. Voir la recette Forcer HTTPS pour la configuration +recommandée et l’alternative de mod_rewrite pour l’utilisation +des fichiers .htaccess.

    + +

    Ordre de traitement

    +

    Si vous mélangez des directives Redirect et RewriteRule dans le même contexte, sachez + que leur ordre d’exécution dépend de l’emplacement où elles apparaissent. + Dans un contexte de serveur virtuel ou global, c’est + mod_rewrite qui agit en premier, alors que dans un contexte + de répertoire (fichiers .htaccess), c’est + mod_alias. Voir Ordre de + traitement des modules pour les détails.

    +
    top

    Alias d'URL

    -

    La directive Alias permet -de mettre en correspondance un URI avec un répertoire, ce dernier étant -en général situé en dehors de l'arborescence définie par la directive -DocumentRoot. Bien qu'il soit -possible d'effectuer cette mise en correspondance avec -mod_rewrite, il est préférable d'utiliser la directive -Alias pour des raisons de simplicité -et de performances.

    +

    La directive Alias permet de mettre +en correspondance un chemin d’URL avec un répertoire, ce dernier étant en +général situé en dehors de l'arborescence définie par la directive DocumentRoot. Bien qu'il soit possible d'effectuer +cette mise en correspondance avec mod_rewrite, il est +préférable d'utiliser la directive Alias pour des raisons de simplicité et de +performances.

    Utilisation de la directive Alias

    Alias "/cats" "/var/www/virtualhosts/felines/htdocs"
    @@ -161,31 +154,6 @@ serveur principal ou de serveur virtuel.

    En outre, vous pouvez arriver au même résultat avec les liens symboliques, pourvu que Options FollowSymLinks soit activé sur votre serveur.

    -
    top
    -
    -

    Hébergement virtuel

    -

    Bien qu'il soit possible de gérer les serveurs -virtuels avec mod_rewrite, il s'agit rarement de la bonne méthode. -Il est pratiquement toujours préférable de créer des blocs -<VirtualHost> individuels. -Dans l'éventualité où vous devez gérer -un grand nombre de serveurs virtuels, vous devez vous tourner vers -mod_vhost_alias pour créer ces serveurs -automatiquement.

    - -

    Il est aussi possible d'utiliser des modules comme mod_macro pour -créer un grand nombre de serveurs virtuels dynamiquement.

    - -

    L'utilisation de mod_rewrite pour la création de -serveurs virtuels peut se révéler appropriée si votre service -d'hébergement ne vous permet pas d'accéder aux fichiers de configuration -du serveur, et que vous soyez par conséquent obligé de passer par les -fichiers .htaccess.

    - -

    Voir le document création de serveurs virtuels -avec mod_rewrite pour plus de détails sur la manière d'y parvenir si -cela semble être tout de même la meilleure approche.

    -
    top

    Mandat simple

    @@ -217,6 +185,23 @@ lorsque d'autres RewriteRules se trouvent dans la même port&e car elles agissent en général avant les directives ProxyPass, et peuvent ainsi les court-circuiter.

    +

    RewriteRule s’avère vraiment +utile pour ne mandater les requêtes que si le contenu n’existe pas localement +— par exemple, lors de la migration d’un serveur vers un autre :

    + +
    RewriteCond "%{REQUEST_FILENAME}"       !-f
+RewriteCond "%{REQUEST_FILENAME}"       !-d
+RewriteRule "^/(.*)"                    "http://old.example.com/$1" [P]
+ProxyPassReverse "/" "http://old.example.com/"
    + + +

    Dans cet exemple, les requêtes pour des ressources qui n’ont pas encore été +migrées sont mandatées silencieusement vers l’ancien serveur. Lors de la +migration du contenu, les fichiers locaux ont la priorité. N’oubliez pas de +toujours inclure une directive ProxyPassReverse pour être sûr que toute +redirection effectuée par le serveur dorsal est correctement transmise au +client.

    +
    top

    Test de variables d'environnement

    @@ -248,6 +233,324 @@ l'évaluation des expressions pour une vue d'ensemble des types d'expressions que vous pouvez utiliser dans les sections <If>, ainsi que dans certaines directives.

    +
    top
    +
    +

    Contrôleur frontal / Routage des +ressources

    + +

    Une utilisation très courante de mod_rewrite consiste à +router toutes les requêtes pour des ressources non existantes vers un seul +script de contrôle frontal (par exemple index.php). Il s’agit de la +base du routage dans le cadre de la plus grande partie du web moderne.

    + +

    L’approche typique avec mod_rewrite est :

    + +
    RewriteEngine On
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteRule "^(.*)$" "/index.php" [L]
    + + +

    Cette opération peut être effectuée beaucoup plus simplement avec la +directive FallbackResource :

    + +
    FallbackResource /index.php
    + + +

    La directive FallbackResource fait la +même chose — les requêtes pour des fichiers et répertoires existants sont +traitées normalement, toutes les autres étant routées vers la ressource +spécifiée — mais sans la surcharge de travail et la complexité du moteur de +réécriture. Elle fonctionne dans les deux contextes de configuration globale du +serveur et des fichiers .htaccess.

    + +

    Pour désactiver une FallbackResource définie dans un répertoire +parent :

    + +
    FallbackResource disabled
    + + +
    top
    +
    +

    Configuration conditionnelle avec des +expressions rationnelles

    + +

    Dans de nombreux cas, l’utilisation de RewriteCond peut être remplacée par la +directive <If> qui prend en +charge une syntaxe des expressions riche et s’intègre +parfaitement avec les autres directives de httpd.

    + +

    Redirection basée sur un élément de la chaîne de paramètres :

    + +
    <If "%{QUERY_STRING} =~ /lang=fr/">
+    Redirect "/welcome" "/bienvenue"
+</If>
    + + +

    Restriction d’accès en fonction de la méthode de la requête :

    + +
    <If "%{REQUEST_METHOD} IN {'DELETE', 'PUT', 'PATCH'}">
+    Require ip 10.0.0.0/8
+</If>
    + + +

    Blocage des requêtes qui ne comportent pas d’en-tête Host (clients +HTTP/1.0) :

    + +
    <If "-z req('Host')">
+    Require all denied
+</If>
    + + +

    Voir la documentation sur l’évaluation des +expressions pour une description complète de la syntaxe disponible dans les +blocs <If>.

    + +
    top
    +
    +

    Blocage du référencement à chaud (Hotlinking) d'images

    + + + +
    +
    Description :
    + +
    +

    Le référencement à chaud consiste pour les autres sites à inclure + directement vos images dans leurs pages en utilisant votre bande + passante pour servir des contenus pour le site de quelqu'un d'autre. + Vous pouvez empêcher cela sans utiliser + mod_rewrite.

    +
    + +
    Solution :
    + +
    +

    Utilisez la directive SetEnvIf avec la directive Require :

    + + 
    SetEnvIf Referer example\.com localreferer
+<FilesMatch "\.(jpg|png|gif)$">
+    Require env localreferer
+</FilesMatch>
    + +
    + +
    Discussion :
    + +
    +

    Si vous avez besoin d’une logique plus complexe — comme servir une + autre image aux référenceurs à chaud au lieu de rejeter la requête — vous + aurez peut-être besoin de mod_rewrite. Les exemples + suivants s’appuient sur l’en-tête HTTP_REFERER qui est + facultatif et peut être usurpé. La condition !^$ autorise les + requêtes qui ne comportent aucun en-tête Referer, de sorte que les + utilisateurs qui saisissent l’URL directement, ou dont les navigateurs + suppriment cet en-tête ne soient pas bloqués.

    + +

    Rejeter purement et simplement la requête :

    + +
    RewriteCond "%{HTTP_REFERER}"  "!^$"
+RewriteCond "%{HTTP_REFERER}"  "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$" "-"                [F,NC]
    + + +

    Servir une image alternative :

    + +
    RewriteCond "%{HTTP_REFERER}"  "!^$"
+RewriteCond "%{HTTP_REFERER}"  "!www.example.com"      [NC]
+RewriteRule "\.(gif|jpg|png)$" "/images/go-away.png"   [R,NC]
    + + +
    +
    + +
    top
    +
    +

    Blocage des robots

    + + + +
    +
    Description :
    + +
    +

    Vous voulez bloquer les requêtes persistantes d’un robot particulier ou + d’un agent utilisateur qui ignore votre /robots.txt.

    +
    + +
    Solution :
    + +
    +

    Utilisez la directive SetEnvIfNoCase avec la directive + Require :

    + + 
    SetEnvIfNoCase User-Agent ^NameOfBadRobot goaway
+<Location "/secret/files">
+    <RequireAll>
+        Require all granted
+        Require not env goaway
+    </RequireAll>
+</Location>
    + +
    + +
    Discussion :
    + +
    +

    Toute technique qui s’appuie sur la chaîne USER_AGENT peut + être facilement contournée, car cette chaîne peut être modifiée par le + client. Si vous subissez une attaque soutenue, vous devez la traiter à un + niveau supérieur, par exemple au niveau de votre pare-feu.

    + +

    Si vous devez combiner la recherche de correspondance par agent + utilisateur et par adresse IP, mod_rewrite peut être + utilisé en remplacement :

    + +
    RewriteCond "%{HTTP_USER_AGENT}"   "^NameOfBadRobot"
+RewriteCond "%{REMOTE_ADDR}"       "=123\.45\.67\.[8-9]"
+RewriteRule "^/secret/files/"      "-"                   [F]
    + + +
    +
    + +
    top
    +
    +

    Interdire des hôtes dans une liste de rejets

    + + + +
    +
    Description :
    + +
    +

    Nous souhaitons établir une liste des hôtes auxquels nous voulons + interdire l’accès à notre serveur.

    +
    + +
    Solution :
    + +
    +

    Pour un simple blocage basé sur l’adresse IP, utilisez la directive + Require directement :

    + + 
    <Location "/">
+    Require all granted
+    Require not ip 193.102.180.41
+    Require not ip 192.76.162.40
+</Location>
    + +
    + +
    Discussion :
    + +
    +

    Si vous avez besoin d’une liste d’interdiction dynamique basée sur un + fichier (plutôt que d’énumérer des adresses IP dans la configuration), + vous pouvez utiliser mod_rewrite et sa directive + RewriteMap :

    + +
    RewriteEngine on
+RewriteMap    hosts-deny  "txt:/path/to/hosts.deny"
+RewriteCond   "${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}" "!=NOT-FOUND" [OR]
+RewriteCond   "${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}" "!=NOT-FOUND"
+RewriteRule   "^"                                      "-"           [F]
    + + +

    Le fichier de mappage contient une entrée par ligne, avec une adresse + IP ou un nom d’hôte comme clé et une valeur factice (parce que la + directive RewriteMap requiert + des paires clé/valeur) :

    + +

    +## hosts.deny
    +193.102.180.41 -
    +192.76.162.40 -
    +

    + +

    La seconde directive RewriteCond présuppose que + HostnameLookups est activé. Dans le cas contraire, + supprimer-la, ainsi que le drapeau [OR] de la première + condition.

    +
    +
    + +
    top
    +
    +

    Serveurs virtuels

    +

    Bien qu’il soit possible de gérer les serveurs virtuels +avec mod_rewrite, il s’agit rarement de la bonne méthode. Le bon choix +consiste pratiquement toujours à créer des blocs <VirtualHost> individuels. Si vous devez gérer un très +grand nombre de serveurs virtuels, choisissez plutôt d’utiliser +mod_vhost_alias pour créer ces hôtes automatiquement.

    + +

    Des modules tels que mod_macro permettent aussi de créer un +grand nombre de serveurs virtuels dynamiquement.

    + +

    Utiliser mod_rewrite pour la création de serveurs virtuels +peut convenir si vous utilisez un service d’hébergement qui ne vous permet pas +d’accéder aux fichiers de configuration du serveur, et que vous soyez par +conséquent contraint d’utiliser des fichiers .htaccess.

    + +

    Voir le document les serveurs virtuels avec +mod_rewrite pour plus de détails sur la manière de procéder si cette +approche vous semble encore être la bonne.

    + +
    top
    +
    +

    Répartition de charge

    + + + +
    +
    Description :
    + +
    +

    Nous souhaitons répartir la charge entre plusieurs serveurs dorsaux.

    +
    + +
    Solution :
    + +
    +

    Utilisez le module mod_proxy_balancer qui fournit une + solution de répartition de charge flexible et totalement fonctionnelle. Il + prend en charge plusieurs algorithmes de répartition, la persistance de + session, les contrôles de bon fonctionnement et une configuration + dynamique avec le gestionnaire de répartition de charge (Balancer Manager) + — toutes choses impossibles avec l’approche de + mod_rewrite.

    + +
    <Proxy "balancer://mycluster">
+    BalancerMember "http://one.example.com"
+    BalancerMember "http://two.example.com"
+    BalancerMember "http://three.example.com"
+</Proxy>
+ProxyPass        "/"  "balancer://mycluster/"
+ProxyPassReverse "/"  "balancer://mycluster/"
    + + +
    + +
    Discussion :
    +
    + +

    Il est possible de mettre en œuvre une répartition de charge aléatoire +rudimentaire en utilisant mod_rewrite et une directive +RewriteMap de type +rnd :

    + +
    RewriteEngine on
+RewriteMap  lb       "rnd:/path/to/serverlist.txt"
+RewriteRule "^/(.*)" "http://${lb:servers}/$1"     [P,L]
    + + +

    mod_proxy_balancer est cependant beaucoup plus flexible et +fonctionnel que tout ce que vous pourrez « bricoler » en utilisant +mod_rewrite, et correspond à l’approche recommandée.

    + +
    +
    +

    Langues Disponibles:  de  | diff --git a/docs/manual/rewrite/avoid.xml.meta b/docs/manual/rewrite/avoid.xml.meta index 2199f87ca2..a496ea22d0 100644 --- a/docs/manual/rewrite/avoid.xml.meta +++ b/docs/manual/rewrite/avoid.xml.meta @@ -10,7 +10,7 @@ de en es - fr + fr ja ko tr diff --git a/docs/manual/rewrite/flags.html.fr.utf8 b/docs/manual/rewrite/flags.html.fr.utf8 index 0400b8d938..88fd09d4fe 100644 --- a/docs/manual/rewrite/flags.html.fr.utf8 +++ b/docs/manual/rewrite/flags.html.fr.utf8 @@ -32,14 +32,13 @@  tr  |  zh-cn 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    Ce document décrit les drapeaux disponibles dans la directive RewriteRule, en fournissant des explications détaillées et des exemples.

    +correspondance
  • Réécritures par répertoire
  • Serveurs virtuels
  • Utilisation de RewriteMap
  • Quand ne pas utiliser mod_rewrite
  • Détails techniques
    • top

    Introduction

    @@ -89,14 +88,146 @@ bien mémoriser ce que chaque drapeau est supposé faire. Certains drapeaux acceptent un ou plusieurs arguments. Les drapeaux ne sont pas sensibles à la casse.

    -

    Les drapeaux qui modifient les métadonnées associées à la requête -(T=, H=, E=) n'ont aucun effet dans un contexte de répertoire ou de -fichier htaccess, lorsqu'une substitution (autre que '-') est effectuée -au cours de la même passe du processus de réécriture. -

    +

    Les drapeaux qui modifient les métadonnées associées à la requête (T=, H=, +E=) n'ont aucun effet dans un contexte de +répertoire ou de fichier htaccess, lorsqu'une substitution (autre que +'-') est effectuée au cours de la même passe du processus de réécriture.

    Chaque drapeau disponible est présenté ici, avec un exemple d'utilisation.

    +
    top
    +
    +

    Référence rapide des drapeaux

    + +

    Les drapeaux peuvent être combinés : [R=301,L], [P,QSA], +[E=VAR:val,L]. Cette table les groupe par fonction et les trie +selon la fréquence de leur utilisation.

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    DrapeauFonctionEffetCombinaisons courantes
    Contrôle de flux
    [L]Dernière règleArrête le traitement des règles (pour cette passe)[R=301,L] [F] [G]
    [END]Arrêt completArrête tout le processus de réécriture (pas de réentrance dans .htaccess)[R=301,END]
    [S=N]SautSauter les N prochaines règles (logique if/else)
    [N]Instance suivante de la boucleRedémarrer le traitement du jeu de règles à partir de la première + (attention : risque de boucle infinie)
    [C]ChaînageChaîner la règle actuelle à la prochaine ; si la règle actuelle échoue, + sauter les règles chaînées
    Redirection et mandatement
    [R=code]RedirectionRedirection externe (par défaut 302). Utilisez Redirect/RedirectMatch pour + les cas simple[R=301,L] [R=302,L]
    [P]MandatementMandatement inverse vers une cible (nécessite mod_proxy)[P,QSA]
    Contrôle d’accès
    [F]InterdictionRenvoie 403 (implique [L])
    [G]PartiRenvoie 410 (implique [L])
    URL / chaîne de paramètres
    [QSA]Ajout de la chaîne de paramètresAjout de la chaîne de paramètres originelle à la substitution[QSA,L] [P,QSA]
    [QSD]Suppression de la chaîne de paramètresSupprime entièrement la chaîne de paramètres[R=301,QSD,L]
    [B]Échappement des références arrièresRéencode les caractères spéciaux dans les références arrières[B,PT]
    [NE]Pas d’échappementPas d’échappement des caractères spéciaux dans la sortie (pass #, ? through)[R=301,NE,L]
    Metadonnées et gestionnaires
    [E]Définition d’une variable d’environnementDéfinit une variable d’environnement[E=VAR:val,L]
    [T]Type MIMEForçage du type de contenu
    [H]GestionnaireForçage d’un gestionnaire de contenu
    [PT]Transmission résultatTransmission du résultat au gestionnaire suivant (requis pour Alias/ScriptAlias)[PT,L]
    Cookie
    [CO]Définir un cookieDéfinir un cookie HTTP pour la réponse[CO=name:val:.domain,R=302,L]
    +
    top

    B (échappement dans les références arrières)

    @@ -164,6 +295,10 @@ RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]"

    Pour définir la liste des caractères à échapper de cette manière, voir #flag_bne et #flag_bctls

    +

    Voir Encodage et décodage des URLs pour une +explication détaillée de la manière dont httpd décode les URIs avant la mise en +correspondance des motifs.

    +
    top

    BNP|backrefnoplus (ne pas échapper @@ -181,6 +316,10 @@ RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]"

    Ce drapeau est disponible à partir de la version 2.4.26 du serveur HTTP Apache.

    +

    Voir Encodage et décodage des URLs pour +découvrir la manière dont l’encodage est géré dans le tube (pipeline) de +réécriture.

    +

    top

    BCTLS

    @@ -193,7 +332,7 @@ rejetés lorsqu'ils sont copiés dans la chaîne de param&egrav RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]" -

    Ce drapeau est disponible à partir de la version 2.5.1 du serveur HTTP +

    Ce drapeau est disponible à partir de la version 2.4.57 du serveur HTTP Apache.

    top
    @@ -207,7 +346,7 @@ correspondant aux drapeaux [B] ou [BCTLS]. Ils ne seront donc pas échapp& RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]" -

    Ce drapeau est disponible à partir de la version 2.5.1 du serveur HTTP +

    Ce drapeau est disponible à partir de la version 2.4.57 du serveur HTTP Apache.

    top
    @@ -219,6 +358,18 @@ normalement et passe le contrôle à la règle suivante. Par co elle ne s'applique pas, la règle suivante, ainsi que toutes les règles chaînées qui suivent, seront sautées.

    +
    # Réécrire les URLs des anciens produits vers la nouvelle application du
+# catalogue, et ajouter un paramètre de traçage — mais seulement pour ceux qui
+# sont réécrits.
+RewriteRule "^/products/([0-9]+)$" "/catalog/item/$1" [C]
+RewriteRule "^/catalog/(.*)$" "/catalog/$1?via=legacy" [QSA]
    + + +

    Sans le drapeau [C], la seconde règle s’appliquerait aux requêtes qui +arrivent directement à /catalog/. Le chaînage des deux règles +permet de s’assurer que la seconde règle ne s’appliquera que si la première +s’applique.

    +
    top

    CO|cookie

    @@ -262,7 +413,7 @@ ce style de cookie est interdit par le modèle de sécurité d
    Lifetime
    La durée de vie du cookie, en minutes.
    -
    Une valeur de 0 indique une durée de vie correspondant à la session +
    Une valeur de 0 indique une durée de vie correspondant à lasession courante du navigateur. Il s'agit de la valeur par défaut.
    Une valeur négative indique que la définition du cookie doit être annulée dans le navigateur.
    @@ -311,24 +462,26 @@ pour tous les URIs.

    top

    DPI|discardpath

    -

    Avec le drapeau DPI, la partie PATH_INFO de l'URI -réécrit est supprimée.

    -

    Ce drapeau est disponible dans les versions 2.2.12 et supérieures.

    -

    Dans un contexte de répertoire, l'URI mis en comparaison par chaque -règle RewriteRule est la concaténation des -valeurs courantes de l'URI et de PATH_INFO.

    - -

    L'URI courant peut être l'URI initial tel qu'il a été fourni par le +

    Avec le drapeau DPI, la partie PATH_INFO +qui a été ajoutée au chemin d’URL réécrit est +supprimée.

    + +

    Dans un contexte de répertoire, le +chemin d’URL que compare chaque +RewriteRule est la concaténation des valeurs courantes du +chemin d’URL et de PATH_INFO.

    + +

    Le chemin d’URL actuel peut être le chemin initial tel qu'il a été fourni par le client, le résultat d'une passe précédente du processus de réécriture, -ou le résultat de la règle précédente dans le processus courant de +ou le résultat de la règle précédente de la passe actuelle du processus de réécriture.

    -

    Par contre, la partie PATH_INFO ajoutée à l'URI avant chaque règle ne -reflète que la valeur de PATH_INFO avant la passe courante du processus -de réécriture. En conséquence, si de larges portions de l'URI -correspondent et sont traduites via plusieurs directives +

    Par contre, la partie PATH_INFO ajoutée au chemin d’URL avant chaque règle ne +reflète que la valeur de PATH_INFO avant la passe actuelle du processus +de réécriture. En conséquence, si de larges portions du chemin d’URL +correspondent et sont copiées dans une substitution via plusieurs directives RewriteRule, sans prendre en compte -quelles parties de l'URI provenaient du PATH_INFO courant, l'URI final +quelles parties du chemin d’URL provenaient du PATH_INFO actuel, le chemin d’URL final pourra se voir ajouter plusieurs copies de PATH_INFO.

    Utilisez ce drapeau pour toute substitution où la présence du PATH_INFO qui @@ -339,6 +492,17 @@ débute est oublié. PATH_INFO ne sera pas recalculé tant que courante du processus de réécriture ne sera pas achevée. Les règles suivantes de cette passe ne verront que le résultat direct des substitutions, sans aucun PATH_INFO ajouté.

    + +
    # Requête : /app/script.php/extra/path (PATH_INFO contient /extra/path)
+# Sans le drapeau DPI, la substitution serait "script.php/extra/path" et
+# pourrait par accident copier PATH_INFO dans le résultat.
+RewriteRule "^script\.php(.*)$" "/new-app/handler$1" [DPI]
    + + +

    Le drapeau DPI supprime /extra/path, de sorte que seul le +résultat de la substitution est transmis aux règles suivantes ou à la requête +finale.

    +
    top

    E|env

    @@ -379,7 +543,7 @@ comme les programmes CGI, d'autres directives RewriteRule, ou des directives CustomLog.

    L'exemple suivant définit une variable d'environnement nommée 'image' -avec une valeur de '1' si l'URI de la requête correspond à un fichier +avec une valeur de '1' si le chemin d’URL de la requête correspond à un fichier image. Cette variable d'environnement est ensuite utilisée pour exclure une telle requête du journal des accès.

    @@ -390,16 +554,83 @@ CustomLog "logs/access_log" combined env=!image

    Notez que le même effet peut être obtenu à l'aide de la directive SetEnvIf. Cette technique est présentée à titre d'exemple et non de recommandation.

    + + +

    Définir des variables d’environnement pour tracer les réécritures

    + +

    Parfois, nous souhaitons être au courant de l’état de la situation lorsque +nous effectuons une réécriture. Par exemple, vous voudriez prendre note +que vous avez effectué cette réécriture, de sorte que vous pourriez +ultérieurement voir si une requête est arrivée par l’intermédaire de cette +réécriture. Une solution pour y parvenir est la définition d’une variable +d’environnement.

    + +
    RewriteEngine on
+RewriteRule   "^/horse/(.*)"   "/pony/$1" [E=rewritten:1]
    + + +

    Dans la suite de votre jeu de règles, vous pouvez consulter cette variable +d’environnement en utilisant une RewriteCond :

    + +
    RewriteCond "%{ENV:rewritten}"  =1
    + + +

    Notez que les variables d’environnements ne survivent pas à une redirection +externe. Vous devez alors utiliser le drapeau [CO] pour définir un cookie.

    + +

    Préfixe REDIRECT_ après une redirection interne

    +

    Dans un contexte de répertoire, + une substitution réussie déclenche une redirection interne. Lorsque cela se + produit, toutes les variables d’environnement définies au cours de la passe + précédente — y compris celles créées avec [E=VAR:VAL] — sont + renommées par l’ajout du préfixe REDIRECT_. Une variable que + vous avez nommée rewritten devient ainsi + REDIRECT_rewritten dans la requête redirigée.

    + +

    Pour tester la variable renommée, référencez-la avec le préfixe :

    +
    + +
    RewriteRule   "^/horses/(.*)" "/ponies/$1" [E=rewritten:1]
+
+# À la passe suivante, la variable a été renommée :
+RewriteCond "%{ENV:REDIRECT_rewritten}" =1
+RewriteRule "^/ponies/(.*)" "-" [E=seen_redirect:1,L]
    + + +

    Si la requête est redirigée plusieurs fois, le préfixe est empilé : + REDIRECT_REDIRECT_rewritten, et ainsi de suite. Voir Variables REDIRECT_ pour la description + complète de ce mécanisme.

    +
    top

    END

    L'utilisation du drapeau [END] permet non seulement de terminer le processus de réécriture en cours (comme [L]), mais aussi d'empêcher tout -processus de réécriture ultérieur dans un contexte de répertoire -(htaccess).

    +processus de réécriture ultérieur dans un contexte +de répertoire, ce qui en fait le drapeau préféré pour la plupart des +règles de niveau répertoire.

    + +

    Dans un contexte de serveur virtuel ou global, [END] et [L] se comportent de +manière identique. La différence entre les deux se situe dans un contexte de +répertoire où [L] interrompt la passe actuelle, mais où le jeu de règles est à +nouveau appliqué à l’URL réécrit. Cela peut provoquer des boucles infinies. +[END] empêche tout processus de réécriture ultérieur en interrompant le cycle.

    + +
    # Dans .htaccess : routage de toutes les requêtes vers un contrôleur frontal
+# ici, [L] proquerait une boucle infine, pas [END]
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteRule "^(.*)$" "/index.php" [END]
    +

    Ceci ne s'applique pas aux nouvelles requêtes résultant d'une redirection externe.

    + +

    Voir la discussion Réécritures dans un contexte +de répertoire pour une explication détaillée de la raison pour laquelle [L] +se comporte différemment dans un contexte de répertoire, et des cas où [END] +constitue le bon choix.

    +
    top

    F|forbidden

    @@ -415,9 +646,9 @@ Forbidden.

    RewriteRule "\.exe" "-" [F]
    -

    Cet exemple utilise la syntaxe "-" pour la cible de réécriture, ce -qui signifie que l'URI de la requête n'est pas modifié. Il n'y a aucune -raison de réécrire un URI, si vous avez l'intention d'interdire la +

    Cet exemple utilise la syntaxe "-" pour la cible de réécriture, ce qui +signifie que le chemin d’URL de la requête n'est pas modifié. Il n'y a aucune +raison de réécrire un chemin d’URL, si vous avez l'intention d'interdire la requête.

    Lorsqu'on utilise [F], [L] est implicite - c'est à dire que la @@ -484,30 +715,11 @@ traitée. Ce drapeau correspond à la commande Perl last -

    Si vous utilisez des règles RewriteRule dans des fichiers -.htaccess ou des sections <Directory>, il est important d'avoir quelques -notions sur la manière dont les règles sont traitées. Pour simplifier, -une fois les règles traitées, la requête réécrite est passée à nouveau -au moteur d'interprétation des URLs afin que ce dernier puisse la -traiter. Il est possible qu'au cours du traitement de la requête -réécrite, le fichier .htaccess ou la section <Directory> soient à nouveau -rencontrés, entraînant un nouveau traitement du jeu de règles depuis le -début. Cette situation se présente le plus souvent lorsqu'une des règles -provoque une redirection - interne ou externe - ce qui réinitialise le -traitement de la requête.

    - -

    Si vous utilisez des directives RewriteRule dans un de ces contextes, -il importe par conséquent de prévoir explicitement des étapes permettant -d'éviter un bouclage infini sur les règles, -et de ne pas compter seulement sur -le drapeau [L] pour terminer l'exécution d'une série de règles, comme -décrit ci-dessous.

    - -

    Un autre drapeau, [END], permet non seulement d'interrompre le cycle -courant du processus de réécriture, mais aussi d'empêcher toute -réécriture ultérieure dans le contexte de répertoire (htaccess). Ceci ne -s'applique pas aux nouvelles requêtes résultant de redirections -externes.

    +

    Dans un contexte de répertoire, [L] +arrête la passe actuelle du jeu de règles, mais la requête réécrite peut être +traitée à nouveau depuis le début du jeu de règles — ce qui peut provoquer des +boucles infinies. Pour éviter ce problème, utilisez le drapeau [END], ou consultez le document Réécritures au niveau répertoire pour une +description détaillée du problème et des solutions alternatives.

    Dans l'exemple donné ici, toute requête est réécrite en index.php, la requête originale étant ajoutée comme chaîne @@ -540,7 +752,7 @@ ceci jusqu'il n'y ait plus de A à remplacer.

    Vous pouvez vous représenter ce traitement comme une boucle while : tant que le modèle de la règle correspond (c'est à -dire, tant que l'URI contient un A), +dire, tant que le chemin d’URL contient un A), effectuer la substitution (c'est à dire, remplacer le A par un B).

    @@ -558,7 +770,7 @@ RewriteRule "(.+)[><;]$" "$1" [N=10]

    NC|nocase

    Avec le drapeau [NC], le modèle de la règle RewriteRule est comparé à la requête de manière insensible à la casse. C'est à dire que cette comparaison -s'effectue sans tenir compte des majuscules/minuscules dans l'URI +s'effectue sans tenir compte des majuscules/minuscules dans le chemin URL comparé.

    Dans l'exemple suivant, toute requête pour un fichier image sera @@ -600,6 +812,10 @@ aurait été converti en son équivalent hexadécimal, < qui aurait provoqué un code d'erreur "404 Not Found".

    +

    Voir Encodage et décodage des URLs pour une +description complète de la manière dont httpd encode et décode les URLs lors de +la réécriture.

    +
    top

    NS|nosubreq

    @@ -627,6 +843,14 @@ Les images, scripts java, ou fichiers css, chargés en tant que partie d'une page html, ne sont pas des sous-requêtes - le navigateur les appelle sous forme de requêtes HTTP à part entière.

    + +
    # Ne réécrire que les requêtes directes vers le contrôleur frontal, pas les
+# sous-requêtes des inclusions SSI ou de mod_dir.
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteRule "^(.*)$" "/app/index.php?page=$1" [NS,L]
    + +
    top

    P|proxy

    @@ -644,7 +868,7 @@ autrement dit, la requête est immédiatement envoyée au manda toute règle ultérieure sera ignorée.

    -Vous devez vous assurer que la chaîne de substitution soit un URI valide +Vous devez vous assurer que la chaîne de substitution soit un URL valide (commençant typiquement par http://nom-serveur) qui puisse être traitée par le module mod_proxy. Dans le cas contraire, le module mandataire vous renverra une erreur. @@ -655,12 +879,17 @@ local.

    Avertissement à propos de la sécurité

    -

    Lors de la construction de l'URL cible de la règle, il convient - de prendre en compte l'impact en matière de sécurité qu'aura le - fait de permettre au client d'influencer le jeu d'URLs pour - lesquelles votre serveur agira en tant que mandataire. - Assurez-vous que la partie protocole://nom-serveur de l'URL soit - fixe, ou ne permette pas au client de l'influencer induement.

    +

    Lors de la construction de l'URL cible de la règle, il convient de + prendre en compte l'impact en matière de sécurité qu'aura le fait de + permettre au client d'influencer le jeu d'URLs pour lesquelles votre + serveur agira en tant que mandataire. Si une partie de l’URL cible est + dérivée de l’entrée de l’utilisateur (références arrières, chaînes de + paramètres, etc.), un attaquant pourra être capable de faire que votre + serveur génère des requêtes vers des hôtes internes ou externes + arbitraires. Cette vulnérabilité est connue sous le nom de falsification + de requête côté serveur (Server-Side Request Forgery — SSRF). Assurez-vous + que la partie protocole://nom-serveur de l'URL soit fixe, ou ne permette + pas au client de l'influencer indument.

    @@ -687,7 +916,7 @@ utiliser ce drapeau.

    Par défaut, la cible (ou chaîne de substitution) d'une règle RewriteRule est sensée être un chemin de fichier. Avec le drapeau [PT], -par contre, elle est traitée comme un URI. Autrement dit, avec le +par contre, elle est traitée comme un chemin URL. Autrement dit, avec le drapeau [PT], le résultat de la règle RewriteRule est passé à nouveau au système de mise en correspondance des URLs avec le système de fichiers, de façon à ce que les systèmes de mise en correspondance basés sur les @@ -722,7 +951,7 @@ réécrire vers -.

    QSA|qsappend

    -Quand l'URI de remplacement contient une chaîne de requête, le +Quand l'URL de remplacement contient une chaîne de requête, le comportement par défaut de la règle RewriteRule est de supprimer la query string (il s'agit des paramètres éventuellement passés dans l'URL après le caractère ?, usuellement pour les formulaires traités par la @@ -745,10 +974,10 @@ autrement dit, la chaîne de requête (query string) exis

    QSD|qsdiscard

    -Lorsque l'URI de la requête contient une chaîne de paramètres, et si +Lorsque l'URL de la requête contient une chaîne de paramètres, et si l'URI cible n'en contient pas, le comportement par défaut de la directive RewriteRule consiste à copier cette -chaîne de paramètres dans l'URI cible. Avec le drapeau [QSD], la chaîne +chaîne de paramètres dans l'URL cible. Avec le drapeau [QSD], la chaîne de paramètres est supprimée.

    @@ -760,12 +989,18 @@ drapeau [QSD] qui l'emporte.

    -Si l'URI cible possède une chaîne de paramètres, le comportement par +Si l'URL cible possède une chaîne de paramètres, le comportement par défaut sera respecté - c'est à dire que la chaîne de paramètres originale sera supprimée et remplacée par la chaîne de paramètres de -l'URI cible. +l'URL cible.

    +
    # Redirection des anciens URLs « search » vers le nouveau chemin en supprimant
+# la chaîne de paramètres. /search?q=term&page=2 devient /find (chaîne de
+# paramètres supprimée)
+RewriteRule "^/search" "/find" [QSD,R=301,L]
    + +
    top

    QSL|qslast

    @@ -781,6 +1016,20 @@ points d'interrogation. Si aucune chaîne de paramètre n'est pr&eacu substitution, il est alors possible d'ajouter un point d'interrogation à la fin et d'utiliser ce drapeau.

    +

    Par exemple, si une application patrimoniale attend une chaîne de paramètres +qui contient elle-même un point d’interrogation :

    + +
    # Associe /lookup/foo?bar à /app?type=foo?bar
+# Sans [QSL], le premier ? dans la substitution couperait le chemin, en
+# produisant incorrectement /app avec la chaîne de paramètres type=foo?bar.
+# Avec [QSL], le DERNIER ? est utilisé comme délimiteur.
+RewriteRule "^/lookup/(.*)" "/app?type=$1" [QSL,PT]
    + + +

    Sans [QSL], la substitution /app?type=foo?bar serait coupée au +premier ?, perdant de ce fait le point d’interrogation littéral de +la valeur.

    +

    Ce drapeau est disponible à partir de la version 2.4.19 du serveur HTTP Apache.

    @@ -812,7 +1061,7 @@ codes de redirection en utilisant leurs noms symboliques :

    Vous utiliserez presque toujours [R] en conjonction avec [L] (c'est à -dire [R,L]), car employé seul, le drapeau [R] préfixe l'URI avec +dire [R,L]), car employé seul, le drapeau [R] préfixe le chemin URL avec http://cet-hôte[:ce-port], mais passe ensuite cette adresse à la règle suivante, ce qui provoquera le plus souvent des avertissements 'Invalid URI in request'. @@ -822,19 +1071,32 @@ avertissements 'Invalid URI in request'. spécification de HTTP. Utiliser un code d'état non reconnu provoquera une erreur 500 et l'enregistrement d'un message dans le journal des erreurs.

    +

    [R=4xx] ne sert pas la substitution

    +

    Lorsqu’un code d’état en dehors de l’intervalle 300-399 est spécifié (par +exemple [R=403] ou [R=410]), la chaîne de substitution +est ignorée. L’URL que vous avez saisi comme cible n’est pas servi au client. À +la place, httpd renvoie le code d’état spécifié et le traite de la manière +habituelle pour les réponses d'erreur (entre autres tout ErrorDocument configuré). Si vous souhaitez interdire +l’accès, les drapeaux [F] et [G] +sont des solutions plus adaptées pour exprimer la même intention.

    +
    + +
    # Redirection des requêtes pour l’ancien chemin de la documentation vers le
+# nouvel emplacement.
+RewriteRule "^/docs/(.*)$" "http://docs.example.com/$1" [R=301,L]
    + +
    top

    S|skip

    -

    Le drapeau [S] sert à sauter des règles que vous ne voulez pas voir -exécuter. La syntaxe du drapeau [S] est [S=N], où -N correspond au nombre de règles à sauter (sous -réserve que la règle RewriteRule corresponde et qu'au moins -une condition RewriteCond -préalable soit vérifiée). -Ceci peut s'interpréter comme une instruction -goto dans votre jeu de règles de réécriture. Dans -l'exemple suivant, nous ne voulons exécuter la règle RewriteRule que si l'URI demandé ne -correspond pas à un fichier existant.

    +

    Le drapeau [S] sert à sauter des règles que vous ne voulez pas voir exécuter. +La syntaxe du drapeau [S] est [S=N], où N correspond au nombre +de règles à sauter (sous réserve que la règle RewriteRule corresponde et qu'au moins une +condition RewriteCond préalable soit +vérifiée). Ceci peut s'interpréter comme une instruction goto +dans votre jeu de règles de réécriture. Dans l'exemple suivant, nous ne voulons +exécuter la règle RewriteRule que si +le chemin URL demandé ne correspond pas à un fichier existant.

    # La requête concerne-t-elle un fichier qui n'existe pas ?
 RewriteCond "%{REQUEST_FILENAME}" !-f
 RewriteCond "%{REQUEST_FILENAME}" !-d
@@ -845,8 +1107,6 @@ RewriteRule "(.*\.gif)" "images.php?$1"
 RewriteRule "(.*\.html)" "docs.php?$1"
    - -

    Cette technique trouve son utilité dans le fait qu'une directive RewriteCond ne s'applique qu'à la règle qui la suit immédiatement. Ainsi, si vous voulez @@ -917,9 +1177,31 @@ utiliser le drapeau L pour terminer la séquence

    UnsafeAllow3F

    Il est nécessaire de définir ce drapeau pour permettre à une réécriture - de continuer si la requête HTTP en cours d'écriture possède un point d'interrogation encodé, « %3f », et si le résultat réécrit contient un « ? » dans - la substitution. Cela protège d'une URL malveillante tirant avantage d'une - capture et d'une resubstitution du point d'interrogation encodé.

    + de continuer si la requête HTTP en cours d'écriture possède un point + d'interrogation encodé, « %3f », et si le résultat réécrit + contient un « ? » dans la substitution. Cela protège d'une URL + malveillante tirant avantage d'une capture et d'une resubstitution du point + d'interrogation encodé.

    + +
    # Un contrôleur frontal PHP qui route toutes les requêtes via un élément de la
+# chaîne de paramètres.
+# Sans UnsafeAllow3F, une requête comme /page%3Fname=test renverrait 403 Forbidden,
+# car le substitution réécrite contient '?' alors que la requête originelle
+# contient un caractère encodé '%3F'.
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteRule "(.+)" "index.php?route=$1" [L,QSA,UnsafeAllow3F]
    + + +
    +L’existence de ce drapeau est due à CVE-2024-38474. Ne +l’utilisez que dans les règles pour lesquelles vous êtes certain qu’un +%3F saisi par l’utilisateur dans la requête ne peut pas être +exploité pour manipuler la chaîne de paramètres de la cible de substitution. +Préférez autant que possible la restructuration des URLs pour éviter les points +d’interrogation encodés. +
    +
    top

    UnsafePrefixStat

    @@ -927,11 +1209,29 @@ utiliser le drapeau L pour terminer la séquence l'échelle du serveur qui commencent par une variable ou une référence arrière et se résolvent en un chemin du système de fichiers. Ces substitutions ne sont pas préfixées par la racine des documents. Cela protège - d'une URL malveillante faisant correspondre la substitution expansée à un + d'un URL malveillant faisant correspondre la substitution développée à un emplacement non souhaité du système de fichiers.

    Disponible à partir de la version 2.5.1 du serveur HTTP Apache.

    -
    top
    + +
    # Cette règle lance la substitution avec une référence arrière.
+# Depuis la version 2.4.60, cette opération est rejetée par défaut pour empêcher
+# le chemin développé de s’échapper de la racine des documents (CVE-2024-38475).
+# N’ajoutez UnsafePrefixStat qu’après avoir vérifié que la substitution ne peut
+# pas se résoudre en un chemin du système de fichiers en dehors de la racine des
+# documents de votre site.
+RewriteRule "^/mirror/(.+)$" "$1" [PT,UnsafePrefixStat]
    + + +
    +L’existence de ce drapeau est due à CVE-2024-38475. Sans +lui, une substitution commençant par une référence arrière ou une variable qui +correspond à un chemin existant du système de fichiers pourrait permettre à des +requêtes de s’échapper de la racine des documents. N’utilisez ce drapeau +qu’après avoir confirmé que la substitution est contrainte de manière adéquate. +
    + +
    top

    UNC

    Définir ce drapeau empêche la fusion des slashes de début multiples tels @@ -940,6 +1240,21 @@ utiliser le drapeau L pour terminer la séquence multiples littéraux.

    Disponible à partir de la version 2.5.1 du serveur HTTP Apache.

    + +
    # Sous Windows, réécriture vers un partage de fichiers UNC
+# en utilisant une variable
+# Sans [UNC], les barres obliques de tête dans la substitution seraient
+# fusionnées (//server/share deviendrait /server/share).
+RewriteCond "%{HTTP_HOST}" "^(.+)\.internal$"
+RewriteRule "^/shared/(.*)$" "//%1/fileshare/$1" [UNC]
    + + +

    Ce drapeau n’est pertinent que sous Windows. Il empêche httpd de fusionner +les doubles barres obliques de tête (//) qui sont présentes dans un +chemin UNC lorsque ce dernier a été construit à partir d’une référence arrière +ou d’une variable. Si la substitution commence par des doubles barres obliques +littérales, aucun drapeau n’est nécessaire.

    +

    Langues Disponibles:  de  | diff --git a/docs/manual/rewrite/flags.xml.meta b/docs/manual/rewrite/flags.xml.meta index 8a295bb16f..5e5fcb10d9 100644 --- a/docs/manual/rewrite/flags.xml.meta +++ b/docs/manual/rewrite/flags.xml.meta @@ -10,7 +10,7 @@ de en es - fr + fr ja ko tr diff --git a/docs/manual/rewrite/htaccess.html.fr.utf8 b/docs/manual/rewrite/htaccess.html.fr.utf8 index 0a9f65e009..755c036e89 100644 --- a/docs/manual/rewrite/htaccess.html.fr.utf8 +++ b/docs/manual/rewrite/htaccess.html.fr.utf8 @@ -6,7 +6,7 @@ This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --> -mod_rewrite et les fichiers .htaccess - Serveur HTTP Apache Version 2.5 +Réécritures au niveau répertoire - Serveur HTTP Apache Version 2.5 @@ -20,7 +20,7 @@

    <-

    mod_rewrite et les fichiers .htaccess

    +Apache > Serveur HTTP > Documentation > Version 2.5 > Rewrite

    Réécritures au niveau répertoire

    Langues Disponibles:  de  | @@ -32,19 +32,410 @@  tr  |  zh-cn 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.
    -

    Ce document est un complément de la documentation de référence du module -mod_rewrite. Il décrit les changements apportés aux règles -lorsqu'on utilise mod_rewrite dans les fichiers .htaccess, et -comment travailler avec ces changements.

    +

    Utiliser mod_rewrite dans les fichiers +.htaccess est une des configurations dans un contexte de répertoire les plus courantes — et les +plus sujettes à confusion. Ce document expose les principales différences entre +l’utilisation de règles de réécriture dans un contexte global au serveur et leur +utilisation dans les fichiers .htaccess, et fournit un guide +pratique pour éviter les pièges les plus courants.

    + +

    Pour des détails techniques de bas niveau à propos de la manière dont +mod_rewrite traite les règles dans un contexte de répertoire, +voir le document Détails techniques.

    - + +
    top
    +
    +

    Prérequis : AllowOverride

    + +

    Pour que des directives de mod_rewrite dans un fichier +.htaccess puissent être traitées, la configuration du serveur doit +tout d’abord les autoriser de la manière suivante :

    + +
    <Directory "/var/www/htdocs">
+    AllowOverride FileInfo
+</Directory>
    + + +

    Si au minimum AllowOverride FileInfo (ou AllowOverride +All) n’est pas présente, toute directive de mod_rewrite +dans les fichiers .htaccess sera silencieusement ignorée. Si vos +règles semblent ne pas fonctionner, il s’agit de la première chose à vérifier.

    + +

    En outre, soit Options FollowSymLinks, soit Options +SymLinksIfOwnerMatch doit être activée pour le répertoire en question. +Comme une règle RewriteRule peut +associer un URL à un chemin arbitraire du système de fichiers +— fonctionnellement équivalent à un lien symbolique +— mod_rewrite refusera d’opérer dans un contexte de répertoire +si aucune de ces options n’est définie. Vous verrez alors l’erreur suivante :

    + +

    +AH00670: Options FollowSymLinks and SymLinksIfOwnerMatch are both off, +so the RewriteRule directive is also forbidden due to its similar +ability to circumvent directory restrictions +

    + +

    Cette restriction s’applique aux fichiers .htaccess et aux +sections <Directory>.

    + +
    top
    +
    +

    Quel URL la règle voit-elle ?

    + +

    Dans un contexte de serveur virtuel ou global au serveur, le motif de la +règle RewriteRule est comparé à +l’ensemble du chemin d’URL, en commençant par une barre oblique. Dans un +contexte de fichier .htaccess, le préfixe du répertoire est +supprimé.

    + +

    Par exemple, si votre fichier .htaccess est dans +/var/www/htdocs/app/ et si une requête arrive pour +/app/products/widget, la règle RewriteRule ne voit que +products/widget — pas de barre oblique en tête, pas de préfixe +/app/.

    + +

    + Organigramme montrant la suppression du chemin, la substitution et le pipeline de RewriteBase dans un contexte de répertoire, avec trois résultats : un chemin relatif (préfixé par RewriteBase), un chemin absolu (utilisé tel quel) et un URI absolu (redirection externe)
    + Figure : Suppression du chemin dans un contexte de répertoire + et pipeline de RewriteBase +

    + +

    Cela signifie que vous devez écrire vos motifs différemment en fonction de +l’emplacement des règles :

    + + + + + + + + + + + + + + +
    Emplacement de la règleRègle
    Section VirtualHostRewriteRule "^/app/products/(.+)$" "/app/shop.php?item=$1"
    .htaccess dans /var/www/htdocs/app/RewriteRule "^products/(.+)$" "shop.php?item=$1"
    + +

    Notez que la version pour .htaccess n’a de barre oblique de tête +ni dans le motif, ni dans la substitution. Il s’agit de la source de confusion +la plus courante avec la réécriture dans un contexte de répertoire.

    + +

    Lorsqu’une substitution est effectuée dans un contexte de répertoire, httpd +génère une nouvelle sous-requête interne avec l’URL réécrit en redémarrant le +traitement de la requête depuis le début. Si la substitution est un chemin +relatif, la directive RewriteBase +détermine le préfixe à ajouter au chemin d’URL. Ce mécanisme de sous-requête +peut aussi être à l’origine d’un bouclage infini des règles — voir ci-après.

    + + +

    Ne faites pas commencer vos motifs de .htaccess avec +une barre oblique

    +

    Étant donné que le préfixe du répertoire (y compris la barre oblique de fin) +est supprimé avant la mise en correspondance, les motifs dans un contexte de répertoire ne correspondront +jamais avec une adresse commençant par une barre oblique. Un motif +commençant par ^/ ne correspondra jamais dans ce contexte. Une +règle telle que RewriteRule "^/foo" ... placée dans un fichier +.htaccess échouera silencieusement à s’appliquer à quelque requête +que ce soit.

    + +

    Si vous devez faire une recherche de correspondance avec le chemin d’URL +original complet (y compris le préfixe de répertoire), utilisez +%{REQUEST_URI} dans une directive RewriteCond :

    + +
    RewriteCond "%{REQUEST_URI}" "^/admin/"
+RewriteRule "^.*$" "-" [F]
    + + +
    top
    +
    +

    Quand avez-vous besoin de RewriteBase ?

    + +

    Quand mod_rewrite effectue une substitution dans un fichier +.htaccess, il doit retransformer le résultat relatif en un chemin +d’URL complet. La directive RewriteBase lui indique quel préfixe il doit +ajouter.

    + +

    Par défaut, RewriteBase est +définie avec le chemin physique du fichier .htaccess. Dans la +plupart des cas, cela correspond aux attentes, et vous n’avez pas besoin de la +définir explicitement. Il y a cependant des situations où vous devrez le faire :

    + +
      +
    • Alias ou lien symbolique : Si le répertoire est atteint via +une directive Alias ou un lien +symbolique, le chemin d’URL et le chemin du système de fichiers diffèrent, et la +directive RewriteBase doit être +définie avec le chemin d’URL.
      • + +
    • Applications de sous-répertoire : Avec les cadriciels PHP, +il est courant de placer un fichier .htaccess dans un +sous-répertoire (par exemple /var/www/htdocs/myapp/) et de router +toutes les requêtes vers un contrôleur frontal :
      • +
    + +
    # Dans /var/www/htdocs/myapp/.htaccess
+RewriteEngine On
+RewriteBase "/myapp/"
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteRule "^(.*)$" "index.php" [L]
    + + +
    Dans ce cas particulier — routage de toutes les requêtes qui ne +correspondent pas vers un contrôleur frontal — la directive FallbackResource est une alternative à +mod_rewrite plus simple et plus efficace.
    + +

    Sans la ligne RewriteBase "/myapp/", l’URL réécrit risque de se +résoudre incorrectement, car mod_rewrite ajouterait comme +préfixe le chemin du système de fichiers au lieu du chemin d’URL.

    + +

    Si vous utilisez des URLs absolus (commençant par / ou +http://) dans vos substitutions, RewriteBase n’aura aucun effet, car elle ne +s’applique qu’aux substitutions relatives.

    + +
    top
    +
    +

    Le drapeau [L] et les boucles infinies

    + +

    Dans le contexte global du serveur, le drapeau [L] signifie +« arrêter le traitement du jeu de règles ». Dans le contexte des fichiers +.htaccess, il a une signification subtilement différente : +« arrêter le traitement du jeu de règles pour cette passe ». Une fois +la substitution effectuée, httpd traite à nouveau la requête depuis le début du +jeu de règles — tout en appliquant à nouveau les règles du fichier +.htaccess. Cela peut provoquer des boucles infinies.

    + +

    + Organigramme montrant la manière dont le drapeau [L] provoque une boucle infinie dans un contexte de répertoire en déclenchant une sous-requête qui réexécute le jeu de règles
    + Figure: Risque de boucle infinie avec le drapeau [L] dans un + contexte de répertoire +

    + +

    Considérez cette règle :

    + +
    # Dans .htaccess - risque de boucle infinie !
+RewriteRule "^(.*)$" "/index.php?q=$1" [L]
    + + +

    À la première passe, une requête pour /hello est réécrite en +/index.php?q=hello. Puis la requête est traitée à nouveau, et +là, index.php correspond encore à ^(.*)$, et la +requête est réécrite en /index.php?q=index.php. Ce processus +continue jusqu’à ce que httpd atteigne sa limite de redirections internes et +renvoie une erreur 500. Le message suivant sera alors enregistré dans le journal +des erreurs :

    + +

    +AH00124: Request exceeded the limit of 10 internal redirects due to +probable configuration error. Use 'LimitInternalRecursion' to increase +the limit if necessary. Use 'LogLevel debug' to get a backtrace. +

    + +

    Il existe plusieurs méthodes pour interrompre la boucle infinie :

    + +

    Option 1 : utiliser le drapeau [END] (recommandé)

    + +
    RewriteRule "^(.*)$" "/index.php?q=$1" [END]
    + + +

    Le drapeau [END] (disponible depuis la version 2.3.9 de httpd) +arrête tout processus de réécriture ultérieur, y compris les passes +suivantes. Il s’agit de la méthode la plus propre pour prévenir les boucles +infinies.

    + +

    Option 2 : ajouter une condition pour empêcher le traitement des URLs déjà réécrits

    + +
    RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteRule "^(.*)$" "/index.php?q=$1" [L]
    + + +

    Étant donné que index.php existe en tant que fichier, la +condition !-f fait que la règle est sautée à la seconde passe.

    + +

    Option 3 : vérifier la variable THE_REQUEST

    + +
    RewriteCond "%{THE_REQUEST}" "!index\.php"
+RewriteRule "^(.*)$" "/index.php?q=$1" [L]
    + + +

    La variable %{THE_REQUEST} contient la requête originelle telle +qu’elle a été envoyée par le client et non modifiée par +mod_rewrite. Sa vérification empêche la règle de s’appliquer aux +URLs réécrits.

    + +
    top
    +
    +

    RewriteMap ne peut pas être déclarée +dans un fichier .htaccess

    + +

    La directive RewriteMap ne peut +être déclarée que dans un contexte de serveur virtuel ou global au serveur, pas +dans les fichiers .htaccess ou les sections <Directory>. Cependant, lorsqu’un mappage +est déclaré dans la configuration globale du serveur, vous pouvez +l’utiliser dans un fichier .htaccess :

    + +
    # Dans httpd.conf ou dans un VirtualHost
+RewriteMap product2id "txt:/etc/apache2/productmap.txt"
    + + +
    # Dans .htaccess - utilisation du mappage déclaré ci-avant
+RewriteEngine On
+RewriteRule "^product/(.+)$" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
    + + +

    Cette restriction existe, car les fichiers .htaccess sont +analysés pour chaque requête, et la répétition de l’initialisation du mappage +(en particulier pour les types de mappage dbm:, dbd: +et prg:) serait d’un coût prohibitif en ressources.

    + +
    top
    +
    +

    Quels contextes peuvent accueillir des +règles de réécriture ?

    + +

    Les règles de réécriture sont prises en charge dans les contextes de répertoire (fichiers .htaccess et sections <Directory> et <If>).

    + +

    Bien que les règles de réécriture soient syntaxiquement autorisées dans les +sections <Location> et +<Files> (et dans leurs +équivalents avec expressions rationnelles), cela n’est pas pris en charge et ne +devrait jamais être nécessaire. Les substitutions relatives, en particulier, +sont susceptibles d’échouer dans ces contextes.

    + +

    Ces conteneurs modifient silencieusement le +comportement des réécritures

    +

    Placer une règle RewriteRule dans +une section <Directory>, +<If> ou <Location> — même dans un +<VirtualHost> dans la +configuration globale du serveur — fait silencieusement adopter un +comportement de contexte de répertoire. +Cela signifie que la barre oblique de tête est supprimée de l’URL avant la +comparaison avec le motif, que les substitutions déclenchent une redirection +interne (avec risque de boucle infinie), et que le drapeau [L] n’arrête plus strictement le +traitement — utilisez plutôt le drapeau [END].

    +
    + +
    top
    +
    +

    Héritage des règles avec RewriteOptions

    + +

    Par défaut, les règles de mod_rewrite ne sont pas +héritées par les sous-répertoires. Si vous définissez des règles dans +/var/www/htdocs/.htaccess, elles ne s’appliqueront qu’au +répertoire correspondant. Un fichier .htaccess dans un +sous-répertoire contient initial un jeu de règles initial vide, à moins que vous +n’activiez explicitement l’héritage.

    + +

    La directive RewriteOptions +permet d’effectuer cette activation :

    + +
    +
    RewriteOptions Inherit
    +
    Les règles du contexte parent sont ajoutées à la fin du jeu de règles de +l’enfant. Le traitement des règles de l’enfant est effectué en premier, suivi du +traitement des règles du parent. Utilisez cette fonctionnalité lorsqu’un +sous-répertoire doit ajouter ses propre règles, tout en gardant actives les +règles du parent.
    + +
    RewriteOptions InheritBefore
    +
    Identique à Inherit, excepté que les règles du parent sont +traitées avant celles de l’enfant. Cela s’avère utile lorsque le parent définit +un motif de contrôleur frontal et que l’enfant doit ajouter des exceptions. +Disponible depuis la version 2.4.8 de httpd.
    + + +
    RewriteOptions InheritDown
    +
    Spécifiez cette option dans le parent pour que tous les contextes enfant +héritent des règles du parent sans avoir à spécifier Inherit. +Disponible depuis la version 2.4.8 de httpd.
    + +
    RewriteOptions InheritDownBefore
    +
    Identique à InheritDown, excepté que les règles du parent sont +traitées avant celles des enfants. Disponible depuis la version 2.4.8 de httpd.
    + +
    RewriteOptions IgnoreInherit
    +
    Spécifiez cette option dans le contexte d’un enfant pour que ce dernier +renonce à l’héritage qui avait été forcé par l’option InheritDown +d’un parent. Disponible depuis la version 2.4.8 de httpd.
    + +
    RewriteOptions MergeBase
    +
    Quand l’héritage est activé, la directive RewriteBase de chaque +contexte s’applique aux règles définies dans ce contexte, au lieu que la +directive RewriteBase de l’enfant s’applique à toutes les règles +héritées. Disponible depuis la version 2.4.26 de httpd.
    +
    + +
    top
    +
    +

    Débogage des règles de réécriture dans les +fichiers .htaccess

    + +

    Lorsque les règles de réécriture dans les fichiers .htaccess ne +fonctionnent pas comme vous le souhaitez, le journal des réécritures est votre +meilleur ami. Activez-le avec le niveau approprié :

    + +
    LogLevel alert rewrite:trace3
    + + +

    Avec cette directive, le journal des erreurs montre exactement comment chaque +règle est traitée — à quoi les motifs ont été comparés, les conditions ont-elles +été satisfaites ou non et quelles substitutions ont été effectuées. Le +comportement du contexte de répertoire et la suppression d’une partie du +chemin sera visible dans ces entrées du journal.

    + +
    ne conservez pas à « trace » le niveau de journalisation sur un +serveur en production. Il génère en effet un grand volume de données en sortie +et affecte les performances.
    + +
    top
    +
    +

    Mise en cache des « 301 redirects » au niveau du +navigateur

    + +

    Quand vous renvoyez une redirection 301 Moved Permanently (via +[R=301] ou Redirect permanent), le navigateur est autorisé à mettre en cache +cette réponse indéfiniment. Cela signifie que même lorsque vous aurez corrigé +une règle de redirection incorrecte dans votre configuration, les clients qui +font à nouveau la même requête pourront se voir redirigés vers l’ancienne +destination (incorrecte) sans jamais contacter à nouveau votre serveur.

    + +

    Lors d’un débogage de règles de redirection, utilisez [R=302] +(redirection temporaire) à la place de [R=301]. Ne repassez à 301 +que lorsque vous avez confirmé que la règle est correcte. Si vous avez déjà +renvoyé un code 301, les clients affectés devront vider le cache de leur +navigateur (ou utiliser une fenêtre privée/incognito) pour voir un comportement +correct.

    + +
    Les moteurs de recherche mettent aussi en cache les redirections 301. Un +code 301 incorrect peut prendre des jours ou des semaines avant d’être +réexploré, même après que la configuration a été corrigée. C’est une autre +raison pour laquelle il vaut mieux faire ses tests avec un code 302.
    + +

    Langues Disponibles:  de  |  en  | diff --git a/docs/manual/rewrite/htaccess.xml.meta b/docs/manual/rewrite/htaccess.xml.meta index 33b091c226..ce306bb9a3 100644 --- a/docs/manual/rewrite/htaccess.xml.meta +++ b/docs/manual/rewrite/htaccess.xml.meta @@ -10,7 +10,7 @@ de en es - fr + fr ja ko tr diff --git a/docs/manual/rewrite/remapping.html.fr.utf8 b/docs/manual/rewrite/remapping.html.fr.utf8 index da2d207467..cf3662023d 100644 --- a/docs/manual/rewrite/remapping.html.fr.utf8 +++ b/docs/manual/rewrite/remapping.html.fr.utf8 @@ -32,8 +32,6 @@  tr  |  zh-cn 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    Ce document est un complément à la Documentation de référence de @@ -43,26 +41,26 @@ correspondance une requête. Il contient de nombreux exemples d'utilisation courante de mod_rewrite avec une description détaillée de leur fonctionnement.

    -
    Vous devez vous attacher à comprendre le -fonctionnement des exemples, car la plupart d'entre eux ne -fonctionneront pas sur votre système si vous vous contentez de les -copier/coller dans vos fichiers de configuration.
    -
    +
  • Répertoires utilisateur structurés
    • +
  • Redirection vers une ancre
    • +
  • Réécriture dépendant du temps
    • +
  • Régénération du contenu à la volée
    • +

    Voir aussi

    top

    De l'ancienne à la nouvelle URL (en interne)

    @@ -90,9 +88,224 @@ copier/coller dans vos fichiers de configuration.
    RewriteEngine  on
 RewriteRule    "^/foo\.html$" "/bar.html" [PT]
    + + + +
    top
    +
    +

    Forcer HTTPS

    + + + +
    +
    Description :
    + +
    +

    Rediriger toutes les requêtes HTTP vers HTTPS. C’est un des + emplois les plus courants de mod_rewrite, mais dans la + plupart des cas, on y parvient d’une meilleur façon sans lui.

    +
    + +
    Solution :
    + +
    + +

    L’approche préférée utilise une directive Redirect dans un serveur virtuel HTTP + dédié :

    + +
    <VirtualHost *:80>
+    ServerName www.example.com
+    Redirect permanent "/" "https://www.example.com/"
+</VirtualHost>
+
+<VirtualHost *:443>
+    ServerName www.example.com
+    # ... emplacement de la configuration SSL
+</VirtualHost>
    + + +
    + +
    Explication :
    + +
    +

    Si vous n’avez pas accès à la configuration du serveur et devez + utiliser un fichier .htaccess, mod_rewrite + sera l’outil approprié :

    + +
    RewriteEngine On
+RewriteCond "%{HTTPS}" !=on
+RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]
    + + +

    La variable %{HTTPS} est définie à on si + la connexion utilise SSL/TLS, et est vide ou à off dans le + cas contraire. Utiliser R=301 produit une redirection + permanente qui signale aux moteurs de recherche qu’ils doivent mettre + leur index à jour.

    + +

    Voir aussi le document Quand ne pas + utiliser mod_rewrite pour plus de discussions à propos de l’approche + Redirect.

    + +

    Derrière un répartiteur de charge ou un terminateur SSL

    +

    La variable %{HTTPS} n’est pas une variable + d’environnement à usage général — elle interroge directement + mod_ssl. Si la terminaison SSL/TLS est effectuée au + niveau d'un répartiteur de charge ou d'un mandataire inverse en amont, + mod_ssl ne gère pas la connexion et %{HTTPS} + indiquera toujours off, même si le client originel s’est + connecté en HTTPS.

    + +

    Dans cette situation, il faut plutôt consulter l’en-tête défini par le + mandataire en amont. La plupart des répartiteurs de charge définissent + X-Forwarded-Proto :

    +
    + +
    RewriteEngine On
+RewriteCond "%{HTTP:X-Forwarded-Proto}" =http [NC]
+RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]
    + + +
    +

    Ne faites confiance à X-Forwarded-Proto que si vous + contrôlez le mandataire en amont et qu'il écrase l'en-tête à chaque + requête. Un attaquant pourrait corrompre cet en-tête en se connectant + directement à votre serveur. Assurez-vous de restreindre l’accès de façon + que seul votre répartiteur de charge puisse atteindre le serveur dorsal, + ou utilisez mod_remoteip pour valider la source.

    +
    + +
    +
    + +
    top
    +
    +

    Exempter les requêtes de défi ACME de la redirection HTTPS

    + + + +
    +
    Description :
    + +
    +

    Vous avez forcé tout le trafic à s’effectuer en HTTPS (comme ci-avant), + mais votre client ACME (Let's Encrypt, Certbot, etc.) nécessite un accès + en HTTP à /.well-known/acme-challenge/ pour achever la + validation du domaine.

    +
    + +
    Solution :
    + +
    +

    Placer une exception avant la règle de redirection HTTPS :

    + +
    RewriteEngine On
+RewriteRule "^/\.well-known/acme-challenge/" - [L]
+RewriteCond "%{HTTPS}" !=on
+RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]
    + +
    + +
    Explication :
    + +
    +

    La substitution matérialisée par un tiret (-) signifie + « ne pas réécrire ». En combinaison avec le drapeau [L], elle + arrête le traitement des règles pour toute requête correspondant au chemin + du défi ACME, permettant à cette dernière d’être servie en HTTP. Le + traitement de toutes les autres requêtes continue avec la règle suivante + et les redirige vers HTTPS de la manière habituelle.

    + +

    Si vous adoptez l’approche par la directive Redirect dans un serveur virtuel dédié au + port 80, utilisez les directives Alias et RedirectMatch à la place :

    + +
    <VirtualHost *:80>
+    ServerName www.example.com
+
+    # Permettre les défis ACME sur HTTP
+    Alias "/.well-known/acme-challenge/" "/var/www/acme/.well-known/acme-challenge/"
+    <Directory "/var/www/acme/.well-known/acme-challenge">
+        Require all granted
+    </Directory>
+
+    # Tout le reste est redirigé vers HTTPS
+    RedirectMatch permanent "^/(?!\.well-known/acme-challenge/)(.*)$" "https://www.example.com/$1"
+</VirtualHost>
    + +
    +
    top
    +
    +

    Normalisation de la barre oblique de fin

    + + + +
    +
    Description :
    + +
    +

    Vous souhaitez que les URLs pour des répertoires se terminent toujours + par une barre oblique ou, au contraire, que ce ne soit jamais le cas. + Il s’agit d’un prérequis courant pour SEO et pour la gestion cohérente des + URLs par les applications web.

    +
    + +
    Solution :
    + +
    +

    Pour ajouter une barre oblique de fin aux URLs qui correspondent à des + répertoires :

    + +
    RewriteCond "%{REQUEST_FILENAME}" -d
+RewriteCond "%{REQUEST_URI}" "!/$"
+RewriteRule "^(.*)$" "$1/" [R=301,L]
    + + +

    Pour supprimer la barre oblique de fin (sauf pour les véritables + répertoires) :

    + +
    RewriteCond "%{REQUEST_FILENAME}" !-d
+RewriteCond "%{REQUEST_URI}" "(.+)/$"
+RewriteRule "^" "%1" [R=301,L]
    + + +
    + +
    Explication :
    + +
    +

    Le module mod_dir de httpd gère déjà les redirections + de barre oblique de fin pour les véritables répertoires lorsque la + directive DirectorySlash est + activée (elle l’est par défaut). Vous n’avez besoin que d’une règle de + mod_rewrite si vous souhaitez imposer un comportement + pour les barres obliques de fin pour les URLs qui ne correspondent pas à + de véritables répertoires sur disque, ou si vous voulez supprimer des + barres obliques de fin.

    +
    +
    + +
    top
    +
    +

    Contrôleur frontal / Routage d’pplication

    + + + +

    La plupart des cadriciels web modernes routent toutes les requêtes vers un + seul point d’entrée : le contrôleur frontal (« front controller »). La + directive FallbackResource gère cela + plus simplement et efficacement que mod_rewrite. Voir le + document Quand ne pas utiliser + mod_rewrite pour l’approche recommandée.

    + +

    Si vous avez réellement besoin de mod_rewrite pour cela + (par exemple, pour ajouter des conditions plus complexes que « fichier non + existant »), consultez le document Réécritures par répertoire pour un + exemple annoté qui illustre aussi l’utilisation de la directive RewriteBase.

    +
    top

    De l'ancien au nouveau (en externe)

    @@ -124,7 +337,7 @@ RewriteRule "^foo\.html$" "bar.html" [ -
    Discussion
    +
    Explication

    Dans l'exemple interne, on a utilisé mod_rewrite afin @@ -173,38 +386,12 @@ RedirectMatch "^/docs/(.*)" "http://nouveau.example.com/docs/$1" Redirect "/docs/" "http://nouveau.example.com/docs/"

    - - -
    top
    -
    -

    De statique à dynamique

    - - - -
    -
    Description :
    - -
    -

    Comment transformer une page statique foo.html - en sa variante dynamique foo.cgi de manière - transparente, c'est à dire sans en avertir le - navigateur/utilisateur.

    -
    - -
    Solution :
    - +
    Explication :
    -

    On réécrit simplement l'URL en script CGI et force le - gestionnaire de contenu à cgi-script de façon - à ce que le script s'exécute en tant que programme CGI. - Ainsi, une requête vers /~quux/foo.html conduit - en interne à l'invocation de - /~quux/foo.cgi.

    - -
    RewriteEngine  on
-RewriteBase    "/~quux/"
-RewriteRule    "^foo\.html$"  "foo.cgi"  [H=cgi-script]
    +

    Pour une simple redirection vers un autre serveur, il est préférable + d’utiliser les directives Redirect ou RedirectMatch, car elles sont plus simples + et plus efficaces.

    @@ -230,10 +417,10 @@ RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script]
    Solution :
    -

    L'URL n'est réécrite en remplaçant l'ancienne extension par la +

    L’URL n’est réécrite en remplaçant l’ancienne extension par la nouvelle que si le fichier cible avec la nouvelle extension existe et - si le fichier originel avec l'ancienne extension n'existe pas. Sinon, - l'URL reste inchangée.

    + si le fichier originel avec l’ancienne extension n’existe pas. Sinon, + l’URL reste inchangée.

    #   jeu de règles assurant une compatibilité ascendante en réécrivant
    
@@ -250,7 +437,7 @@ RewriteRule    "^foo\.html$"  "foo.cgi"  [H=cgi-script]
    -
    Discussion
    +
    Explication

    Cet exemple utilise une fonctionnalité souvent méconnue de mod_rewrite, en tirant avantage de l'ordre d'exécution du jeu de @@ -346,6 +533,15 @@ RewriteRule "^/?(.*)" "http://www.example.com/$1" [L,R,NE] possibles de example.com, vous pouvez utiliser le jeu de règles suivants :

    +

    Pour faire l’inverse — supprimer le préfixe www. — inversez la +condition :

    + +
    RewriteCond "%{HTTP_HOST}" "^www\.(.+)$"              [NC]
+RewriteRule "^(.*)"        "http://%1/$1"             [L,R,NE]
    + + +

    Pour ajouter de manière générique www. à tout nom d’hôte :

    + 
    RewriteCond "%{HTTP_HOST}" "!^www\." [NC]
 RewriteCond "%{HTTP_HOST}" "!^$"
 RewriteRule "^/?(.*)" "http://www.%{HTTP_HOST}/$1" [L,R,NE]
    @@ -355,9 +551,24 @@ RewriteRule "^/?(.*)" "http://www.%{HTTP_HOST}/$1" [L,R,NE] de configuration de votre serveur principal que dans un fichier .htaccess placé dans le répertoire défini par la directive DocumentRoot du serveur.

    -
    - + + +
    Explication :
    + +
    +

    Si vous avez accès à la configuration globale du serveur, une directive + Redirect dans un <serveur virtuel> dédié constitue + l’approche la plus propre. Mettre sous forme canonique le nom d’hôte + permet de s’assurer que les moteurs de recherche traiterons votre site + comme une seule entité, et évite les problèmes de portée de cookie qui + surviennent lorsqu’un même site est accessible sous plusieurs noms.

    +

    N’utilisez la directive <If> et mod_rewrite comme + compromis que si vous êtes contraint d’utiliser un fichier + .htaccess.

    +
    + +
    top

    Recherche de pages dans plus d'un répertoire

    @@ -400,60 +611,13 @@ RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir2/$1" [L] RewriteRule "^" "-" [PT] - - -
    top
    -
    -

    Redirection vers des serveurs géographiquement distribués

    - - - -
    -
    Description :
    - -
    -

    Notre site web possède de nombreux miroirs, et nous voulons - rediriger les utilisateurs vers celui qui se situe dans le pays où - ils se trouvent.

    -
    -
    Solution :
    - -
    -

    En consultant le nom d'hôte du client demandeur, on détermine le - pays dans lequel il se trouve. S'il est impossible d'effectuer une - recherche sur leur adresse IP, on se rabat sur un serveur par - défaut.

    -

    Nous allons utiliser une directive RewriteMap afin de construire une - liste des serveurs que nous voulons utiliser.

    - -
    HostnameLookups on
-RewriteEngine on
-RewriteMap    multiplex         "txt:/path/to/map.mirrors"
-RewriteCond  "%{REMOTE_HOST}"     "([a-z]+)$ [NC]"
-RewriteRule   "^/(.*)$"  "${multiplex:%1|http://www.example.com/}$1"  [R,L]
    - - -

    -## liste_miroirs -- Table de correspondance pays - serveurs
    -
    -de http://www.exemple.de/
    -uk http://www.exemple.uk/
    -com http://www.example.com/
    -##EOF## -

    -
    +
    Explication :
    -
    Discussion
    -
    Ce jeu de règles nécessite la définition à - on de la directive HostNameLookups, ce qui peut induire une - baisse de performance significative.
    - -

    La directive RewriteCond extrait la dernière - partie du nom d'hôte du client demandeur - le code du pays - et la - règle de réécriture qui suit utilise cette valeur pour rechercher le - serveur miroir approprié dans le fichier de correspondances.

    +

    Ce qui précède s’avère utile pendant les migrations lorsque le contenu + est déplacé d’un répertoire vers un autre. Pour une configuration + permanente, utilisez plutôt la directive Alias ou des liens symboliques.

    @@ -545,56 +709,6 @@ de réécrire les URLs.

    -
    top
    -
    -

    Ressource par défaut

    - - -
    -
    Description :
    -
    Vous voulez qu'une seule ressource (disons un certain fichier tel -que index.php) soit servie pour toutes les requêtes à destination d'un -certain répertoire, sauf pour celles qui concernent une ressource -existant effectivement comme une image, ou un fichier css.
    - -
    Solution :
    -
    -

    Depuis la version 2.2.16, vous pouvez y parvenir via la directive -FallbackResource :

    - -
    <Directory "/var/www/my_blog">
-  FallbackResource index.php
-</Directory>
    - - -

    Cependant, si vos besoins étaient plus complexes, vous pouviez, dans -les versions plus anciennes d'Apache, utiliser un jeu de règles du style -:

    - -
    <Directory "/var/www/my_blog">
-  RewriteBase "/my_blog"
-
-  RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-f
-  RewriteCond "/var/www/my_blog/%{REQUEST_FILENAME}" !-d
-  RewriteRule "^" "index.php" [PT]
-</Directory>
    - - -

    D'autre part, si vous voulez transmettre l'URI de la requête en tant -que chaîne de paramètres à index.php, vous pouvez remplacer cette règle -de réécriture par :

    - -
    RewriteRule "(.*)" "index.php?$1" [PT,QSA]
    - - -

    Notez que l'on peut utiliser ces jeux de règles aussi bien dans un -fichier .htaccess que dans une section -<Directory>.

    - -
    - -
    -
    top

    Rewrite query string

    @@ -641,19 +755,203 @@ RewriteRule "(.*)" - [F] -
  • Cette solution produit l'effet inverse des précédentes ; elle - copie des composantes du chemin (peut-être PATH_INFO) depuis l'URL - vers sa chaîne de paramètres : -
    # The desired URL might be /products/kitchen-sink, and the script expects 
+  
  • Cette solution produit l'effet inverse des précédentes ; elle copie des
+  composantes du chemin (peut-être PATH_INFO) depuis l'URL vers sa chaîne de paramètres
+  : 
    # The desired URL might be /products/kitchen-sink, and the script expects
 # /path?products=kitchen-sink.
 RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]
    
-
+ 
   
    • 
 
 
 
 
+
    Explication :
    
+
+
    
+
    Voir aussi les drapeaux [QSA] et [QSD] qui permettent de contrôler si la chaîne de
+paramètres originelle est ajoutée à la fin de la substitution ou supprimée de
+cette dernière.
    
+
    
+
+
 
+
    • top
    +
    +

    Répertoires utilisateur structurés

    + + + +
    +
    Description :
    + +
    +

    Certains sites avec plusieurs milliers d’utilisateurs possèdent une + organisation structurée des répertoires utilisateur, c’est-à-dire que + chaque répertoire utilisateur est dans un sous-répertoire qui commence + (par exemple) par le premier caractère du nom de l’utilisateur. Ainsi, + /~larry/anypath correspond à + /home/l/larry/public_html/anypath et + /~waldo/anypath à + /home/w/waldo/public_html/anypath.

    +
    + +
    Solution :
    + +
    +

    Nous utilisons le jeu de règles suivant pour développer les URLs avec + tilde selon l’organisation ci-dessus.

    + +
    RewriteEngine on
+RewriteRule   "^/~(([a-z])[a-z0-9]+)(.*)"  "/home/$2/$1/public_html$3"
    + +
    + +
    Explication :
    + +
    +

    Cette technique est principalement utile pour les environnements + d’hébergement de grande capacité avec plusieurs milliers d’utilisateurs. + Pour la plupart des sites, mod_userdir gère les URLs + utilisateur avec tilde sans avoir besoin de mod_rewrite.

    +
    +
    + +
    top
    +
    +

    Redirection vers une ancre

    + + + +
    +
    Description :
    + +
    +

    Par défaut, la redirection vers une ancre HTML ne fonctionne pas, car + mod_rewrite échappe le caractère # en le + remplaçant par %23, ce qui casse la redirection.

    +
    + +
    Solution :
    + +
    +

    Utiliser le drapeau [NE] dans la règle + RewriteRule. NE signifie « No Escape ». +

    +
    + +
    Explication :
    +
    Bien entendu, cette technique fonctionne aussi pour d’autres caractères + spéciaux que mod_rewrite encode par défaut pour les URLs.
    +
    + +
    top
    +
    +

    Réécriture dépendant du temps

    + + + +
    +
    Description :
    + +
    +

    Nous voulons utiliser mod_rewrite pour servir des + contenus différents en fonction de l’heure du jour.

    +
    + +
    Solution :
    + +
    +

    Il esixte de nombreuses variables nommées TIME_xxx à + utiliser dans les conditions de réécriture. En combinaison avec les motifs + de comparaison lexicographique spéciaux <STRING, + >STRING et =STRING, nous pouvons configurer + des redirections dépendant du temps :

    + +
    RewriteEngine on
+RewriteCond   "%{TIME_HOUR}%{TIME_MIN}" >0700
+RewriteCond   "%{TIME_HOUR}%{TIME_MIN}" <1900
+RewriteRule   "^foo\.html$"             "foo.day.html" [L]
+RewriteRule   "^foo\.html$"             "foo.night.html"
    + + +

    Cette configuration sert le contenu de foo.day.html sous + l’URL foo.html de 07:01 à 18:59 et + le contenu de foo.night.html pendant le temps restant.

    + +
    mod_cache, les mandataires + intermédiaires et les navigateurs peuvent chacun mettre en cache les + réponses et provoquer de ce fait l’affichage d’une page en dehors de la + fenêtre de temps configurée. mod_expires permet de + contrôler cet effet. Il est bien entendu préférable de simplement servir + le contenu de manière dynamique et de le personnaliser en fonction de + l’heure du jour.
    + +
    + +
    Explication :
    + +
    +

    Servir du contenu dynamique par l’intermédiaire de votre application + constitue pratiquement toujours une meilleure approche. La mise en cache + par les navigateurs, les mandataires et mod_cache rend la + réécriture en fonction du temps non fiable en pratique.

    +
    +
    + +
    top
    +
    +

    Régénération du contenu à la volée

    + + + +
    +
    Description :
    + +
    +

    Nous voulons générer dynamiquement du contenu, mais le stocker ensuite + statiquement. La règle suivante va vérifier si le fichier + statique existe, et le générer dans le cas contraire. Les fichiers + statiques peuvent être supprimés périodiquement, si souhaité (par exemple + via cron) et seront régénérés à la demande.

    +
    + +
    Solution :
    + +
    + Pour ce faire, on utilise le jeu de règles suivant : + +
    # Cet exemple n’est valable que dans un contexte de répertoire
+RewriteCond "%{REQUEST_URI}"   !-U
+RewriteRule "^(.+)\.html$"     "/regenerate_page.cgi"   [PT,L]
    + + +

    L’opérateur -U détermine si la chaîne de test (dans ce cas + REQUEST_URI) est un URL valable. Il effectue cette opération + via une sous-requête. Si cette sous-requête échoue — autrement dit, si la + ressource demandée n’existe pas — cette règle invoque le programme CGI + /regenerate_page.cgi qui va générer la ressource demandée et la + sauvegarder dans le répertoire des documents de sorte qu’une copie statique + puissent en être servie la prochaine fois qu’elle sera demandée.

    + +

    Ainsi, les documents qui ne sont pas souvent mis à jour peuvent être + servis sous forme statique. Si ces documents doivent être rafraîchis, ils + peuvent être supprimés du répertoire des documents ; ils seront alors + régénérés la prochaine fois qu’ils seront demandés.

    +
    + +
    Explication :
    + +
    +

    Les approches modernes telles que mod_cache, les + couches de mise en cache CDN ou la mise en cache au niveau de + l’application fournissent des solutions plus robustes et configurables + pour servir du contenu statique pré-généré. Le test de la sous-requête de + l’opérateur -U utilisé ici induit un coût en performance à + chaque requête.

    +
    +
    +

    Langues Disponibles:  de  | diff --git a/docs/manual/rewrite/remapping.xml.meta b/docs/manual/rewrite/remapping.xml.meta index 21c834aac4..8f8e6ccac4 100644 --- a/docs/manual/rewrite/remapping.xml.meta +++ b/docs/manual/rewrite/remapping.xml.meta @@ -10,7 +10,7 @@ de en es - fr + fr ja ko tr diff --git a/docs/manual/rewrite/rewritemap.html.fr.utf8 b/docs/manual/rewrite/rewritemap.html.fr.utf8 index a6290e24ba..d186016a77 100644 --- a/docs/manual/rewrite/rewritemap.html.fr.utf8 +++ b/docs/manual/rewrite/rewritemap.html.fr.utf8 @@ -32,8 +32,6 @@  tr  |  zh-cn 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    Ce document est un complément à la documentation de référence du @@ -42,13 +40,7 @@ fournit des exemples pour chacun des différents types de RewriteMap.

    -
    Notez que la plupart de ces exemples ne - fonctionneront pas en l'état dans le contexte de votre configuration - particulière ; vous devez donc vous attacher à les - comprendre, plutôt que de simplement les insérer dans votre - configuration par copier/coller.
    - - + + mod_rewrite
  • Introduction à mod_rewrite
  • Redirection et remise en correspondance
  • Drapeaux des règles de réécriture
  • Serveurs virtuels
  • Réécritures par répertoire
  • Quand ne pas utiliser mod_rewrite
  • Détails techniques
    • top

    Introduction

    @@ -168,7 +160,7 @@ exemples pour chacun d'entre eux.

    fonction interne, et insérez-la dans votre RewriteRule :

    -

    Redirection d'un URI vers une version en minuscules +

    Redirection d'un chemin d’URL vers une version en minuscules d'elle-même

    RewriteMap lc int:tolower
 RewriteRule "(.*)" "${lc:$1}" [R]
    @@ -418,7 +410,7 @@ directive R directive Mutex.

    Voici un exemple simple qui remplace tous les tirets par des - caractères de soulignement dans l'URI de la requête.

    + caractères de soulignement dans le chemin d’URL de la requête.

    Configuration de la réécriture

    RewriteMap d2u "prg:/www/bin/dash2under.py" apache:apache
@@ -433,16 +425,49 @@ for line in sys.stdin:
     print(line.strip().replace('-', '_'), flush=True)
    +

    Un exemple plus complet montre un motif typique pour qu’un programme de + correspondance prg: lise une ligne, recherche le résultat et l’affiche. La + sortie de diagnostic est écrite sur STDERR et termine sa course + dans le journal des erreurs de httpd.

    + +

    Configuration de la réécriture

    + 
    RewriteMap vhost2docroot "prg:/www/bin/vhost_lookup.py"
+RewriteRule "^/(.*)$" "${vhost2docroot:%{HTTP_HOST}}/$1"
    + + +

    vhost_lookup.py

    + 
    #!/usr/bin/env python3
+"""Associer un nom d’hôte au répertoire racine de ses documents."""
+import sys
+
+VHOSTS = {
+    "example.com": "/srv/www/example",
+    "blog.example.com": "/srv/www/blog",
+}
+
+for line in sys.stdin:
+    host = line.strip().lower()
+    docroot = VHOSTS.get(host)
+    if docroot:
+        print(docroot, flush=True)
+    else:
+        # "NULL" indique à mod_rewrite que la recherche a échoué
+        print("NULL", flush=True)
+        print(f"vhost_lookup: no match for {host!r}", file=sys.stderr)
    + +

    Mises en garde !

      -
    • Votre programme doit être le plus -simple possible. Si le programme se bloque, httpd va attendre -indéfiniment une réponse de sa part, et par conséquent ne répondra plus -aux requêtes.
      • -
    • Assurez-vous de bien désactiver la mise en tampon dans votre -programme. Dans l'exemple en Python ci-avant, cette opération s'effectue en -passant flush=True à print(). Si les entrées/sorties sont mises en tampon, httpd va -attendre une sortie, et va par conséquent se bloquer.
      • +
    • Votre programme doit être le plus simple possible. Si le programme se +bloque, httpd va attendre indéfiniment une réponse de sa part, et par conséquent +ne répondra plus aux requêtes.
      • +
    • Assurez-vous de bien désactiver la mise en tampon dans votre programme. Dans +l'exemple en Python ci-avant, cette opération s'effectue en passant +flush=True à print(). Si les entrées/sorties sont +mises en tampon, httpd va attendre une sortie, et va par conséquent se bloquer. +Il s’agit de la cause la plus courante pour laquelle le mappage prg: semble ne +rien faire — le programme a la réponse mais httpd ne la verra jamais, car +elle est prisonnière d’un tampon.
    • Rappelez-vous qu'il n'existe qu'une copie du programme lancé au démarrage du serveur, et que toutes les requêtes vont devoir passer par ce goulot d'étranglement. Ceci peut provoquer des ralentissements @@ -493,6 +518,75 @@ est envoyé au programme ; s'il ne s'arrête pas dans les 3 secondes,
    top
    +

    Distribution de la charge (sharding) basée sur l'URL entre plusieurs serveurs dorsaux

    + + + +
    +
    Description :
    + +
    +

    Le « sharding » est une technique courante de distribution de la charge + de travail ou de l’espace de stockage. Lorsqu’on utilise cette méthode, un + serveur frontal va utiliser l’URL pour distribuer les utilisateurs ou + objets à des serveurs dorsaux de manière cohérente.

    +
    + +
    Solution :
    + +
    +

    Un mappage entre les utilisateurs et les serveurs cible est entretenu + dans des fichiers de mappage. Ces derniers sont sous la forme :

    + +

    +utilisateur1 serveur_physique_de_utilisateur1
    +utilisateur2 serveur_physique_de_utilisateur2
    +# ... et ainsi de suite +

    + +

    Nous inscrivons ceci dans un fichier + mappage.utilisateur-vers-serveur. Le but est d’associer

    + +

    +/u/utilisateur1/chemin +

    + +

    à

    + +

    +http://serveur_physique_de_utilisateur1/u/utilisateur/chemin +

    + +

    de sorte que tous les chemins d’URL n’ont pas besoin d’être valables + sur chaque serveur dorsal physique. Le jeu de règles suivant fait cela + pour nous avec l’aide des fichiers de mappage, en supposant que server0 + est un serveur par défaut qui sera utilisé si un utilisateur n’a pas + d’entrée dans le mappage :

    + +
    RewriteEngine on
+RewriteMap    users-to-hosts      "txt:/path/to/map.users-to-hosts"
+RewriteRule   "^/u/([^/]+)/?(.*)" "http://${users-to-hosts:$1|server0}/u/$1/$2"
    + +
    + +
    Discussion :
    + +
    +

    Pour distribuer les requêtes aux différents serveurs dorsaux, + mod_proxy_balancer constitue une approche plus robuste et + configurable, avec la prise en charge d’un bilan de santé, d’une + pondération des charges et de la persistance des sessions. L’approche + basée sur un mappage txt: présentée ici est plus simple mais ne prend pas + en charge ces fonctionnalités.

    +
    +
    + +

    Voir la documentation de RewriteMap pour une description plus complète + de la syntaxe de cette directive. +

    + +
    top
    +

    Résumé

    diff --git a/docs/manual/rewrite/rewritemap.xml.meta b/docs/manual/rewrite/rewritemap.xml.meta index 2c27274f55..eca3342996 100644 --- a/docs/manual/rewrite/rewritemap.xml.meta +++ b/docs/manual/rewrite/rewritemap.xml.meta @@ -10,7 +10,7 @@ de en es - fr + fr ja ko tr diff --git a/docs/manual/rewrite/tech.html.fr.utf8 b/docs/manual/rewrite/tech.html.fr.utf8 index abe4b35546..19f28caa31 100644 --- a/docs/manual/rewrite/tech.html.fr.utf8 +++ b/docs/manual/rewrite/tech.html.fr.utf8 @@ -32,13 +32,13 @@  tr  |  zh-cn 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    Ce document passe en revue certains détails techniques à propos du module mod_rewrite et de la mise en correspondance des URLs

    @@ -80,48 +80,171 @@ correspondance
  • Drapeaux de réécri s'exécute au cours de la phase Fixup.

    Dans tous ces cas, mod_rewrite réécrit le - REQUEST_URI soit vers une nouvelle URL, soit vers un + REQUEST_URI soit vers un nouvel URL, soit vers un nom de fichier.

    Dans un contexte de répertoire, - les règles sont appliquées durant la phase "Fixup" après que l'URL a été - traduite en nom de fichier. Cela modifie ce à quoi correspond le motif et la + les règles sont appliquées durant la phase "Fixup" après que l’URL a été + traduit en nom de fichier. Cela modifie ce à quoi correspond le motif et la manière dont les substitutions sont gérées. Voir le document Réécritures en fonction du répertoire pour des détails pratiques à propos de la suppression du - chemin, de RewriteBase et de la manière d'éviter un bouclage.

    + chemin, de RewriteBase et de la manière d’éviter un bouclage.

    + +
    top
    +
    +

    Module Processing Order

    + +

    mod_rewrite et mod_alias agissent tous + les deux au cours de la phase de traduction de l’URL en nom de fichier, mais + mod_rewrite opère en premier, quel que soit l’ordre + d’apparition des directives dans le fichier de configuration. Ce + comportement est déterminé par la priorité des points d’accroche + qu’enregistre chaque module, pas par l’ordre du code source.

    + +

    La conséquence pratique : lorsque des directives RewriteRule et Redirect (ou RedirectMatch) sont présentent simultanément + dans le même contexte de serveur virtuel ou global au serveur, les règles de + réécriture sont évaluées en premier. Si une règle RewriteRule + correspond et réécrit le chemin d’URL (ou renvoie une redirection), + Redirect ne verra jamais la requête.

    + +

    + Comparaison côte-à-côte des ordres d’opération des modules : dans un contexte global au serveur, mod_rewrite opère en premier lors de la phase de traduction du chemin d’URL en nom de fichier, mod_alias opèrant en second ; dans un contexte de répertoire, mod_alias opère en premier lors de la phase de traduction du chemin d’URL en nom de fichier, mod_rewrite opérant plus tard lors de la phase de correction
    + Figure : Inversion de l’ordre d’opération des modules entre les + contextes global au serveur et de répertoire +

    + + 
    # Dans cette configuration, le Redirect n’est jamais atteint pour /old,
+# car la règle RewriteRule s’applique en premier — même si
+# Redirect apparaît plus tôt dans le fichier.
+Redirect "/old" "http://example.com/new"
+RewriteRule "^/old" "/other" [L]
    + + +

    Le contexte de répertoire inverse l’ordre

    +

    Dans un contexte de répertoire, + la situation est différente. Les directives de mod_alias + comme Redirect s’appliquent encore dans la phase de traduction + de l’URL en nom de fichier, mais les directives de + mod_rewrite s’appliquent plus tard, lors de la phase de + correction. Cela signifie que dans un contexte de répertoire, + Redirect est évaluée avant l’application des + règles RewriteRule.

    +
    + +

    Du fait de l’incohérence entre les contextes, mélanger des directives de + mod_rewrite et de mod_alias dans la même + portée est une source courante de confusion. Un conseil simple : choisissez + un module pour une tâche donnée. Si vous avez besoin de conditions de + réécritures ou de comparaison de motif, utilisez exclusivement + RewriteRule. Si une simple redirection de préfixe suffit, + utilisez la directive Redirect et n’ajoutez pas de règles de + réécritures qui pourraient interagir avec elle.

    + +
    top
    +
    +

    Encodage et décodage des URLs

    + +

    Apache httpd supprime l’échappement des caractères encodés pour l’URL + dans le chemin d’URL de la requête avant que toute comparaison de motif de + directive RewriteRule ne soit + effectuée. Une requête pour /my%20page/cats%3Fdogs est décodée + en /my page/cats?dogs, et c’est à cette chaîne décodée qu’est + comparé le motif de la directive RewriteRule.

    + +

    Cela signifie que vous ne pouvez pas écrire un motif correspondant à la + forme littérale de l’URL encodé. Si vous devez distinguer + /horses%2Fponies de /horses/ponies, utilisez la + variable %{THE_REQUEST} dans une directive RewriteCond — cette variable conserve la + requête originelle telle qu’elle a été envoyée par le client, avant tout + décodage :

    + +
    # Ne correspond qu’au caractère encodé littéral %2F, 
+# pas au séparateur de chemin réel
+RewriteCond "%{THE_REQUEST}" "/horses%2F"
+RewriteRule "^/horses/ponies$" "/special-handler" [L]
    + + +

    Après la substitution, mod_rewrite réencode le chemin + d’URL résultant en sortie. Plusieurs drapeaux permettent de contrôler ce + comportement :

    + +
      +
    • [B] : rétablit l’échappement des + références arrières de façon que les caractères spéciaux capturés dans le + chemin d’URL décodé ne soient pas interprétés comme des délimiteurs dans + la substitution.
      • + +
    • [BNP] : si [B] est actif, ce drapeau + encode les espaces en %20 au lieu de + (convient + pour les éléments du chemin, pas pour la chaîne de paramètres).
      • + +
    • [NE] : ce drapeau supprime + l’échappement par défaut des caractères spéciaux dans le résultat de la + substitution, permettant la transmission sans modification des littéraux + #, ? et d’autres caractères lors des + redirections externes.
      • +
    + +

    Directive AllowEncodedSlashes

    + + +

    Par défaut, httpd renvoie un code 404 pour tout URL contenant une barre + oblique encodée (%2F). La directive AllowEncodedSlashes permet de modifier ce + comportement :

    + +
      +
    • Off (valeur par défaut) : rejette %2F avec + un code 404.
      • +
    • On : autorise %2F et le décode en + / avant de le transmettre aux gestionnaires.
      • +
    • NoDecode : autorise %2F, mais le conserve + sous sa forme encodée de façon que l’application dorsale le distingue d’un + séparateur de chemin réel.
      • +
    + +

    Lorsqu’on utilise le drapeau [B] avec des + URLs qui peuvent contenir des barres obliques encodées, il est en général + nécessaire d’utiliser AllowEncodedSlashes NoDecode pour éviter + que httpd ne rejette le résultat réencodé.

    + +
    top

    Traitement du jeu de règles

    -

    Maintenant, quand mod_rewrite se lance dans ces deux phases de - l'API, il lit le jeu de règles configurées depuis la structure - contenant sa configuration (qui a été elle-même créée soit au - démarrage d'Apache pour le contexte du serveur, soit lors du - parcours des répertoires par le noyau d'Apache pour le contexte de - répertoire). Puis le moteur de réécriture est démarré avec le jeu - de règles contenu (une ou plusieurs règles associées à leurs - conditions). En lui-même, le mode opératoire du moteur de - réécriture d'URLs est exactement le même dans les deux contextes - de configuration. Seul le traitement du résultat final diffère.

    - -

    L'ordre dans lequel les règles sont définies est important car - le moteur de réécriture les traite selon une chronologie - particulière (et pas très évidente). Le principe est le suivant : - le moteur de réécriture traite les règles (les directives RewriteRule) les unes - à la suite des autres, et lorsqu'une règle s'applique, il parcourt - les éventuelles conditions (directives - RewriteConddirectives) associées. - Pour des raisons historiques, les - conditions précèdent les règles, si bien que le déroulement du - contrôle est un peu compliqué. Voir la figure 1 pour plus de - détails.

    +

    Maintenant, quand mod_rewrite se lance dans ces deux + phases de l'API, il lit le jeu de règles configuré depuis la structure + contenant sa configuration (qui a été elle-même créée soit au démarrage + d'Apache httpd pour le contexte du serveur, soit lors du parcours des + répertoires par le noyau d'Apache httpd pour le contexte de répertoire). + Puis le moteur de réécriture est démarré avec le jeu de règles contenu + (une ou plusieurs règles associées à leurs conditions). En lui-même, le + mode opératoire du moteur de réécriture d'URLs est exactement le même dans + les deux contextes de configuration. Seul le traitement du résultat final + diffère.

    +

    - Flux des comparaisons des directives RewriteRule et RewriteCond
    - Figure 1:Déroulement du contrôle à travers le jeu de - règles de réécriture + Survol du processus de réécriture par requête lors des phases par serveur et par répertoire
    + Figure 1 :Le processus de réécriture par requête montrant les + deux phases du traitement des règles (par serveur et par répertoire)

    -

    L'URL est tout d'abord comparée au + +

    L'ordre dans lequel les règles sont définies est important car le + moteur de réécriture les traite selon une chronologie particulière (et pas + très évidente). Le principe est le suivant : le moteur de réécriture + traite les règles (les directives RewriteRule) les unes à la suite des + autres, et lorsqu'une règle s'applique, il parcourt les éventuelles + conditions (directives RewriteConddirectives) associées. + Pour des raisons historiques, les conditions précèdent les règles, si bien + que le déroulement du contrôle est un peu compliqué. Voir la figure 2 pour + plus de détails.

    +

    + Organigramme montrant le flux de contrôle par règle : pour chaque règle, comparaison du motif avec l’URL, évaluation des conditions RewriteCond, application de la substitution si les deux opérations précédentes ont réussi, puis consultation des drapeaux pour déterminer si l’on doit arrêter le traitement ou continuer avec la règle suivante
    + Figure 2 :Le flux de contrôle en parcourant le jeu de règles de + réécriture +

    +

    L'URL est tout d'abord comparé au Modèle de chaque règle. Lorsqu'une règle ne s'applique pas, mod_rewrite stoppe immédiatement le traitement de cette règle et passe à la règle suivante. Si l'URL correspond au @@ -146,6 +269,15 @@ correspondance

  • Drapeaux de réécri satisfaites, le traitement de la règle en cours se poursuit avec le remplacement de l'URL par la chaîne de Substitution.

    +

    + Flux des références arrières entre les directives RewriteRule et RewriteCond
    + Figure 3 :Le flux des références arrières dans une règle + Tout d’abord, le motif de la règle RewriteRule est comparé ; ses captures + ($1...$9) sont disponibles dans toutes les chaînes de test des conditions + RewriteCond. Les dernières captures du motif de la condition qui + correspondent (%1...%9) sont disponibles dans la substitution. +

    +

    Langues Disponibles:  de  | diff --git a/docs/manual/rewrite/tech.xml.meta b/docs/manual/rewrite/tech.xml.meta index 417d90cca9..fcd5837843 100644 --- a/docs/manual/rewrite/tech.xml.meta +++ b/docs/manual/rewrite/tech.xml.meta @@ -10,7 +10,7 @@ de en es - fr + fr ja ko tr diff --git a/docs/manual/rewrite/vhosts.html.fr.utf8 b/docs/manual/rewrite/vhosts.html.fr.utf8 index 49d08f2823..2a55ce2173 100644 --- a/docs/manual/rewrite/vhosts.html.fr.utf8 +++ b/docs/manual/rewrite/vhosts.html.fr.utf8 @@ -32,8 +32,6 @@  tr  |  zh-cn 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    Ce document est un complément à la documentation de référence du module @@ -55,7 +53,7 @@ virtuels via mod_rewrite<

  • Utilisation d'un fichier de configuration du serveur virtuel séparé

    • Voir aussi

    +correspondance
  • Réécritures dans un contexte de répertoire
  • Drapeaux de la règle RewriteRule
  • Utilisation de RewriteMap
  • Quand ne pas utiliser mod_rewrite
  • Détails techniques
    • top

    Serveurs virtuels pour des noms d'hôtes arbitraires

    diff --git a/docs/manual/rewrite/vhosts.xml.meta b/docs/manual/rewrite/vhosts.xml.meta index b54e21cb34..3850862b00 100644 --- a/docs/manual/rewrite/vhosts.xml.meta +++ b/docs/manual/rewrite/vhosts.xml.meta @@ -10,7 +10,7 @@ de en es - fr + fr ja ko tr diff --git a/docs/manual/suexec.html.fr.utf8 b/docs/manual/suexec.html.fr.utf8 index 5adf99314d..c21251fe96 100644 --- a/docs/manual/suexec.html.fr.utf8 +++ b/docs/manual/suexec.html.fr.utf8 @@ -29,8 +29,6 @@  ko  |  tr 

    -
    Cette traduction peut être périmée. Vérifiez la version - anglaise pour les changements récents.

    La fonctionnalité suEXEC permet l'exécution des programmes CGI et diff --git a/docs/manual/suexec.xml.meta b/docs/manual/suexec.xml.meta index 57a8173940..3b7b1e8915 100644 --- a/docs/manual/suexec.xml.meta +++ b/docs/manual/suexec.xml.meta @@ -8,7 +8,7 @@ en - fr + fr ja ko tr