From 6beeb1b708550be0d4a53b272283e17e5e35fe17 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 7 Apr 2024 17:01:30 +0200 Subject: Adding upstream version 2.4.57. Signed-off-by: Daniel Baumann --- docs/manual/rewrite/access.html | 9 + docs/manual/rewrite/access.html.en | 323 ++++++++++ docs/manual/rewrite/access.html.fr.utf8 | 331 ++++++++++ docs/manual/rewrite/advanced.html | 9 + docs/manual/rewrite/advanced.html.en | 370 ++++++++++++ docs/manual/rewrite/advanced.html.fr.utf8 | 390 ++++++++++++ docs/manual/rewrite/avoid.html | 9 + docs/manual/rewrite/avoid.html.en | 254 ++++++++ docs/manual/rewrite/avoid.html.fr.utf8 | 271 +++++++++ docs/manual/rewrite/flags.html | 9 + docs/manual/rewrite/flags.html.en | 842 ++++++++++++++++++++++++++ docs/manual/rewrite/flags.html.fr.utf8 | 904 ++++++++++++++++++++++++++++ docs/manual/rewrite/htaccess.html | 9 + docs/manual/rewrite/htaccess.html.en | 66 ++ docs/manual/rewrite/htaccess.html.fr.utf8 | 67 +++ docs/manual/rewrite/index.html | 17 + docs/manual/rewrite/index.html.en | 96 +++ docs/manual/rewrite/index.html.fr.utf8 | 110 ++++ docs/manual/rewrite/index.html.tr.utf8 | 91 +++ docs/manual/rewrite/index.html.zh-cn.utf8 | 80 +++ docs/manual/rewrite/intro.html | 9 + docs/manual/rewrite/intro.html.en | 400 ++++++++++++ docs/manual/rewrite/intro.html.fr.utf8 | 426 +++++++++++++ docs/manual/rewrite/proxy.html | 9 + docs/manual/rewrite/proxy.html.en | 119 ++++ docs/manual/rewrite/proxy.html.fr.utf8 | 124 ++++ docs/manual/rewrite/remapping.html | 9 + docs/manual/rewrite/remapping.html.en | 697 +++++++++++++++++++++ docs/manual/rewrite/remapping.html.fr.utf8 | 717 ++++++++++++++++++++++ docs/manual/rewrite/rewritemap.html | 9 + docs/manual/rewrite/rewritemap.html.en | 481 +++++++++++++++ docs/manual/rewrite/rewritemap.html.fr.utf8 | 511 ++++++++++++++++ docs/manual/rewrite/tech.html | 9 + docs/manual/rewrite/tech.html.en | 205 +++++++ docs/manual/rewrite/tech.html.fr.utf8 | 223 +++++++ docs/manual/rewrite/vhosts.html | 9 + docs/manual/rewrite/vhosts.html.en | 228 +++++++ docs/manual/rewrite/vhosts.html.fr.utf8 | 239 ++++++++ 38 files changed, 8681 insertions(+) create mode 100644 docs/manual/rewrite/access.html create mode 100644 docs/manual/rewrite/access.html.en create mode 100644 docs/manual/rewrite/access.html.fr.utf8 create mode 100644 docs/manual/rewrite/advanced.html create mode 100644 docs/manual/rewrite/advanced.html.en create mode 100644 docs/manual/rewrite/advanced.html.fr.utf8 create mode 100644 docs/manual/rewrite/avoid.html create mode 100644 docs/manual/rewrite/avoid.html.en create mode 100644 docs/manual/rewrite/avoid.html.fr.utf8 create mode 100644 docs/manual/rewrite/flags.html create mode 100644 docs/manual/rewrite/flags.html.en create mode 100644 docs/manual/rewrite/flags.html.fr.utf8 create mode 100644 docs/manual/rewrite/htaccess.html create mode 100644 docs/manual/rewrite/htaccess.html.en create mode 100644 docs/manual/rewrite/htaccess.html.fr.utf8 create mode 100644 docs/manual/rewrite/index.html create mode 100644 docs/manual/rewrite/index.html.en create mode 100644 docs/manual/rewrite/index.html.fr.utf8 create mode 100644 docs/manual/rewrite/index.html.tr.utf8 create mode 100644 docs/manual/rewrite/index.html.zh-cn.utf8 create mode 100644 docs/manual/rewrite/intro.html create mode 100644 docs/manual/rewrite/intro.html.en create mode 100644 docs/manual/rewrite/intro.html.fr.utf8 create mode 100644 docs/manual/rewrite/proxy.html create mode 100644 docs/manual/rewrite/proxy.html.en create mode 100644 docs/manual/rewrite/proxy.html.fr.utf8 create mode 100644 docs/manual/rewrite/remapping.html create mode 100644 docs/manual/rewrite/remapping.html.en create mode 100644 docs/manual/rewrite/remapping.html.fr.utf8 create mode 100644 docs/manual/rewrite/rewritemap.html create mode 100644 docs/manual/rewrite/rewritemap.html.en create mode 100644 docs/manual/rewrite/rewritemap.html.fr.utf8 create mode 100644 docs/manual/rewrite/tech.html create mode 100644 docs/manual/rewrite/tech.html.en create mode 100644 docs/manual/rewrite/tech.html.fr.utf8 create mode 100644 docs/manual/rewrite/vhosts.html create mode 100644 docs/manual/rewrite/vhosts.html.en create mode 100644 docs/manual/rewrite/vhosts.html.fr.utf8 (limited to 'docs/manual/rewrite') diff --git a/docs/manual/rewrite/access.html b/docs/manual/rewrite/access.html new file mode 100644 index 0000000..8f93fdb --- /dev/null +++ b/docs/manual/rewrite/access.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: access.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: access.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/access.html.en b/docs/manual/rewrite/access.html.en new file mode 100644 index 0000000..3dd731b --- /dev/null +++ b/docs/manual/rewrite/access.html.en @@ -0,0 +1,323 @@ + + + + + +Using mod_rewrite to control access - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Using mod_rewrite to control access

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It describes +how you can use mod_rewrite to control access to +various resources, and other related techniques. +This includes many examples of common uses of mod_rewrite, +including detailed descriptions of how each works.

+ +
Note that many of these examples won't work unchanged in your +particular server configuration, so it's important that you understand +them, rather than merely cutting and pasting the examples into your +configuration.
+ +
+ +
top
+
+

Forbidding Image "Hotlinking"

+ + + +
+
Description:
+ +
+

The following technique forbids the practice of other sites + including your images inline in their pages. This practice is + often referred to as "hotlinking", and results in + your bandwidth being used to serve content for someone else's + site.

+
+ +
Solution:
+ +
+

This technique relies on the value of the + HTTP_REFERER variable, which is optional. As + such, it's possible for some people to circumvent this + limitation. However, most users will experience the failed + request, which should, over time, result in the image being + removed from that other site.

+

There are several ways that you can handle this + situation.

+ +

In this first example, we simply deny the request, if it didn't + initiate from a page on our site. For the purpose of this example, + we assume that our site is www.example.com.

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

In this second example, instead of failing the request, we display + an alternate image instead.

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

In the third example, we redirect the request to an image on some + other site.

+ +
RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$" "http://other.example.com/image.gif"   [R,NC]
+ + +

Of these techniques, the last two tend to be the most effective + in getting people to stop hotlinking your images, because they will + simply not see the image that they expected to see.

+ +
+ +
Discussion:
+ +
+

If all you wish to do is deny access to the resource, rather + than redirecting that request elsewhere, this can be + accomplished without the use of mod_rewrite:

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

Blocking of Robots

+ + + +
+
Description:
+ +
+

+ In this recipe, we discuss how to block persistent requests from + a particular robot, or user agent.

+ +

The standard for robot exclusion defines a file, + /robots.txt that specifies those portions of your + website where you wish to exclude robots. However, some robots + do not honor these files. +

+ +

Note that there are methods of accomplishing this which do + not use mod_rewrite. Note also that any technique that relies on + the clients USER_AGENT string can be circumvented + very easily, since that string can be changed.

+
+ +
Solution:
+ +
+

We use a ruleset that specifies the directory to be + protected, and the client USER_AGENT that + identifies the malicious or persistent robot.

+ +

In this example, we are blocking a robot called + NameOfBadRobot from a location + /secret/files. You may also specify an IP address + range, if you are trying to block that user agent only from the + particular source.

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

+ Rather than using mod_rewrite for this, you can accomplish the + same end using alternate means, as illustrated here: +

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

+ As noted above, this technique is trivial to circumvent, by simply + modifying the USER_AGENT request header. If you + are experiencing a sustained attack, you should consider blocking + it at a higher level, such as at your firewall. +

+ +
+ +
+ +
top
+
+

Denying Hosts in a Reject List

+ + + +
+
Description:
+ +
+

We wish to maintain a list of hosts, rather like + hosts.deny, and have those hosts blocked from + accessing our server.

+
+ +
Solution:
+ +
+
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]
+ + +

+##
+## hosts.deny
+##
+## ATTENTION! This is a map, not a list, even when we treat it as such.
+## mod_rewrite parses it for key/value pairs, so at least a
+## dummy value "-" must be present for each entry.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+

+
+ +
Discussion:
+
+

+ The second RewriteCond assumes that you have HostNameLookups turned + on, so that client IP addresses will be resolved. If that's not the + case, you should drop the second RewriteCond, and drop the + [OR] flag from the first RewriteCond. +

+
+
+ +
top
+
+

Referer-based Deflector

+ + + +
+
Description:
+ +
+

Redirect requests based on the Referer from which the request + came, with different targets per Referer.

+
+ +
Solution:
+ +
+

The following ruleset uses a map file to associate each Referer + with a redirection target.

+ +
RewriteMap  deflector "txt:/path/to/deflector.map"
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}}" "=-"
+RewriteRule "^" "%{HTTP_REFERER}" [R,L]
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}|NOT-FOUND}" "!=NOT-FOUND"
+RewriteRule "^" "${deflector:%{HTTP_REFERER}}" [R,L]
+ + +

The map file lists redirection targets for each referer, or, if + we just wish to redirect back to where they came from, a "-" is + placed in the map:

+ +
##
+##  deflector.map
+##
+
+http://badguys.example.com/bad/index.html    -
+http://badguys.example.com/bad/index2.html   -
+http://badguys.example.com/bad/index3.html   http://somewhere.example.com/
+ + +
+
+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/access.html.fr.utf8 b/docs/manual/rewrite/access.html.fr.utf8 new file mode 100644 index 0000000..e3f9258 --- /dev/null +++ b/docs/manual/rewrite/access.html.fr.utf8 @@ -0,0 +1,331 @@ + + + + + +Utiliser mod_rewrite pour le contrôle d'accès - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Utiliser mod_rewrite pour le contrôle d'accès

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la documentation de référence de +mod_rewrite. Il explique comment utiliser +mod_rewrite pour contrôler l'accès à diverses +ressources, ainsi que d'autres techniques en rapport. 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.
+ +
+ +
top
+
+

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

+ + + +
+
Description :
+ +
+

Cette technique vous permet d'interdire à d'autres sites + d'inclure directement vos images dans leurs pages. On fait + souvent référence à cette pratique sous le nom de + référencement à chaud (Hotlinking) qui entraîne l'utilisation + de votre bande passante pour servir des contenus faisant + partie du site de quelqu'un d'autre.

+
+ +
Solution :
+ +
+

Cette technique repose sur la valeur de la variable + optionnelle HTTP_REFERER. Certaines personnes + pourront donc contourner cette limitation. Pour la plupart des + utilisateurs cependant, la requête échouera, en ce sens que + l'image ne sera pas affichée depuis le site tiers.

+

Il y a plusieurs manières de gérer cette situation.

+ +

Dans le premier exemple, nous rejetons tout simplement la + requête si elle ne provenait pas d'une page appartenant à notre + site. Pour les besoins de cet exemple, nous supposons que le nom + de votre site est www.example.com.

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

Dans le second exemple, plutôt que de rejeter la requête, + nous affichons une autre image à la place.

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

Dans le troisième exemple, nous redirigeons la requête vers + une image appartenant à un autre site.

+ +
RewriteCond "%{HTTP_REFERER}" "!^$"
+RewriteCond "%{HTTP_REFERER}" "!www.example.com" [NC]
+RewriteRule "\.(gif|jpg|png)$" "http://other.example.com/image.gif"   [R,NC]
+ + +

De tous ces exemples, les deux derniers semblent les plus + efficaces pour faire en sorte que les gens arrêtent de + référencer vos images à chaud, car il ne verront pas les images + qu'ils s'attendent à voir.

+ +
+ +
Discussion :
+ +
+

Si vous ne voulez pas rediriger la requête, mais + simplement interdire l'accès à la ressource, vous pouvez y + parvenir sans utiliser mod_rewrite :

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

Blocage des robots

+ + + +
+
Description :
+ +
+

+ Dans cet exemple, nous allons discuter d'une méthode permettant + de bloquer les requêtes persistentes en provenance d'un robot + particulier, ou d'un navigateur.

+ +

La méthode classique pour exclure un robot consiste à définir + un fichier, /robots.txt qui spécifie les parties de + votre site web pour lesquelles vous voulez exclure les robots. + Malheureusement, certains robots ne tiennent pas compte de ces + fichiers. +

+ +

Notez qu'il existe des méthodes d'exclusion qui n'utilisent + pas mod_rewrite. Notez aussi que toute technique qui repose sur + le contenu de la chaîne client USER_AGENT peut être + contournée très facilement car cette chaîne peut être modifiée.

+
+ +
Solution :
+ +
+

On utilise un jeu de règles qui spécifie le répertoire à + protéger, ainsi que la chaîne client USER_AGENT qui + identifie le robot malin ou envahissant.

+ +

Dans cet exemple, nous bloquons un robot nommé + Vilain_Robot pour le répertoire + /secret/fichiers. Si vous voulez bloquer ce client + seulement depuis une source particulière, vous pouvez aussi + spécifier un intervalle d'adresses IP.

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

+ Vous pouvez cependant parvenir au même résultat sans utiliser + mod_rewrite via la méthode alternative suivante : +

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

+ Comme indiqué plus haut, il est aisé de contourner cette + technique, simplement en modifiant le contenu de l'en-tête + USER_AGENT. Si vous subissez une attaque en règle, + vous allez devoir réfléchir à un blocage à un niveau supérieur, + par exemple une règle de filtrage de votre pare-feu. +

+ +
+ +
+ +
top
+
+

Rejet des clients contenus dans une liste de proscrits

+ + + +
+
Description :
+ +
+

Nous voulons interdire l'accès à notre serveur aux clients + contenus dans une liste de proscrits similaire à + hosts.deny.

+
+ +
Solution :
+ +
+
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]
+ + +

+##
+## hosts.deny
+##
+## ATTENTION! Ceci est une table de correspondances, non une liste,
+## même si elle est traitée comme telle. mod_rewrite
+## l'interprète comme une liste de paires clé/valeur, et
+## chaque entrée doit au moins posséder une valeur par
+## défaut "-".
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+

+
+ +
Discussion :
+
+

+ La seconde condition RewriteCond présuppose que HostNameLookups est + défini à On, de façon à ce que les adresses IP des clients puissent + être résolues. Dans le cas contraire, vous devez supprimer la + seconde condition, ainsi que le drapeau [OR] de la + première. +

+
+
+ +
top
+
+

Aiguillage basé sur l'en-tête Referer

+ + + +
+
Description :
+ +
+

Redirige les requêtes en fonction du Referer de provenance de + la requête, avec des cibles différentes pour chaque Referer.

+
+ +
Solution :
+ +
+

Le jeu de règles suivant utilise un fichier de correspondances pour + associer chaque Referer à une cible de redirection.

+ +
RewriteMap  deflector "txt:/path/to/deflector.map"
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}}" "=-"
+RewriteRule "^" "%{HTTP_REFERER}" [R,L]
+
+RewriteCond "%{HTTP_REFERER}" !=""
+RewriteCond "${deflector:%{HTTP_REFERER}|NOT-FOUND}" "!=NOT-FOUND"
+RewriteRule "^" "${deflector:%{HTTP_REFERER}}" [R,L]
+ + +

Le fichier de correspondances contient les cibles de + redirection associées à chaque Referer, ou, si nous voulons + simplement rediriger les requêtes vers leur Referer, un "-" est + inscrit dans le fichier de correspondances :

+ +
##
+##  deflector.map
+##
+
+http://badguys.example.com/bad/index.html    -
+http://badguys.example.com/bad/index2.html   -
+http://badguys.example.com/bad/index3.html   http://somewhere.example.com/
+ + +
+
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/advanced.html b/docs/manual/rewrite/advanced.html new file mode 100644 index 0000000..8e5e94f --- /dev/null +++ b/docs/manual/rewrite/advanced.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: advanced.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: advanced.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/advanced.html.en b/docs/manual/rewrite/advanced.html.en new file mode 100644 index 0000000..c2ad1c0 --- /dev/null +++ b/docs/manual/rewrite/advanced.html.en @@ -0,0 +1,370 @@ + + + + + +Advanced Techniques with mod_rewrite - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Advanced Techniques with mod_rewrite

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It provides +a few advanced techniques using mod_rewrite.

+ +
Note that many of these examples won't work unchanged in your +particular server configuration, so it's important that you understand +them, rather than merely cutting and pasting the examples into your +configuration.
+ +
+ +
top
+
+

URL-based sharding across multiple backends

+ + + +
+
Description:
+ +
+

A common technique for distributing the burden of + server load or storage space is called "sharding". + When using this method, a front-end server will use the + url to consistently "shard" users or objects to separate + backend servers.

+
+ +
Solution:
+ +
+

A mapping is maintained, from users to target servers, in + external map files. They look like:

+ +

+user1 physical_host_of_user1
+user2 physical_host_of_user2
+# ... and so on +

+ +

We put this into a map.users-to-hosts file. The + aim is to map;

+ +

+/u/user1/anypath +

+ +

to

+ +

+http://physical_host_of_user1/u/user/anypath +

+ +

thus every URL path need not be valid on every backend physical + host. The following ruleset does this for us with the help of the map + files assuming that server0 is a default server which will be used if + a user has no entry in the map:

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

See the RewriteMap + documentation and the RewriteMap HowTo + for more discussion of the syntax of this directive.

+ +
top
+
+

On-the-fly Content-Regeneration

+ + + +
+
Description:
+ +
+

We wish to dynamically generate content, but store it + statically once it is generated. This rule will check for the + existence of the static file, and if it's not there, generate + it. The static files can be removed periodically, if desired (say, + via cron) and will be regenerated on demand.

+
+ +
Solution:
+ +
+ This is done via the following ruleset: + +
# This example is valid in per-directory context only
+RewriteCond "%{REQUEST_URI}"   "!-U"
+RewriteRule "^(.+)\.html$"     "/regenerate_page.cgi"   [PT,L]
+ + +

The -U operator determines whether the test string + (in this case, REQUEST_URI) is a valid URL. It does + this via a subrequest. In the event that this subrequest fails - + that is, the requested resource doesn't exist - this rule invokes + the CGI program /regenerate_page.cgi, which generates + the requested resource and saves it into the document directory, so + that the next time it is requested, a static copy can be served.

+ +

In this way, documents that are infrequently updated can be served in + static form. if documents need to be refreshed, they can be deleted + from the document directory, and they will then be regenerated the + next time they are requested.

+
+
+ +
top
+
+

Load Balancing

+ + + +
+
Description:
+ +
+

We wish to randomly distribute load across several servers + using mod_rewrite.

+
+ +
Solution:
+ +
+

We'll use RewriteMap and a list of servers + to accomplish this.

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

serverlist.txt will contain a list of the servers:

+ +

+## serverlist.txt
+
+servers one.example.com|two.example.com|three.example.com
+

+ +

If you want one particular server to get more of the load than the +others, add it more times to the list.

+ +
+ +
Discussion
+
+

Apache comes with a load-balancing module - +mod_proxy_balancer - which is far more flexible and +featureful than anything you can cobble together using mod_rewrite.

+
+
+ +
top
+
+

Structured Userdirs

+ + + +
+
Description:
+ +
+

Some sites with thousands of users use a + structured homedir layout, i.e. each homedir is in a + subdirectory which begins (for instance) with the first + character of the username. So, /~larry/anypath + is /home/l/larry/public_html/anypath + while /~waldo/anypath is + /home/w/waldo/public_html/anypath.

+
+ +
Solution:
+ +
+

We use the following ruleset to expand the tilde URLs + into the above layout.

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

Redirecting Anchors

+ + + +
+
Description:
+ +
+

By default, redirecting to an HTML anchor doesn't work, + because mod_rewrite escapes the # character, + turning it into %23. This, in turn, breaks the + redirection.

+
+ +
Solution:
+ +
+

Use the [NE] flag on the + RewriteRule. NE stands for No Escape. +

+
+ +
Discussion:
+
This technique will of course also work with other + special characters that mod_rewrite, by default, URL-encodes.
+
+ +
top
+
+

Time-Dependent Rewriting

+ + + +
+
Description:
+ +
+

We wish to use mod_rewrite to serve different content based on + the time of day.

+
+ +
Solution:
+ +
+

There are a lot of variables named TIME_xxx + for rewrite conditions. In conjunction with the special + lexicographic comparison patterns <STRING, + >STRING and =STRING we can + do time-dependent redirects:

+ +
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"
+ + +

This provides the content of foo.day.html + under the URL foo.html from + 07:01-18:59 and at the remaining time the + contents of foo.night.html.

+ +
mod_cache, intermediate proxies + and browsers may each cache responses and cause the either page to be + shown outside of the time-window configured. + mod_expires may be used to control this + effect. You are, of course, much better off simply serving the + content dynamically, and customizing it based on the time of day.
+ +
+
+ +
top
+
+

Set Environment Variables Based On URL Parts

+ + + +
+
Description:
+ +
+

At times, we want to maintain some kind of status when we + perform a rewrite. For example, you want to make a note that + you've done that rewrite, so that you can check later to see if a + request came via that rewrite. One way to do this is by setting an + environment variable.

+
+ +
Solution:
+ +
+

Use the [E] flag to set an environment variable.

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

Later in your ruleset you might check for this environment + variable using a RewriteCond:

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

Note that environment variables do not survive an external + redirect. You might consider using the [CO] flag to set a + cookie. For per-directory and htaccess rewrites, where the final + substitution is processed as an internal redirect, environment + variables from the previous round of rewriting are prefixed with + "REDIRECT_".

+ +
+
+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/advanced.html.fr.utf8 b/docs/manual/rewrite/advanced.html.fr.utf8 new file mode 100644 index 0000000..250db5d --- /dev/null +++ b/docs/manual/rewrite/advanced.html.fr.utf8 @@ -0,0 +1,390 @@ + + + + + +Advanced Techniques with mod_rewrite - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Advanced Techniques with mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document complète la documentation de référence du + module mod_rewrite. Il présente un certain nombre + de techniques avancées quant à + l'utilisation de mod_rewrite.

+ +
Notez que la plupart des exemples ne fonctionneront +pas en l'état dans la configuration particulière de votre serveur ; il +est donc important de bien comprendre leur fonctionnement, plutôt que de +simplement les copier/coller dans votre configuration.
+ +
+ +
top
+
+

Distribution de la charge entre plusieurs serveurs + d'arrière-plan en fonction de l'adresse IP

+ + + +
+
Description :
+ +
+

La fragmentation ou "sharding" est une technique courante de + distribution de la charge du serveur ou de l'espace de stockage. + Quand on utilise cette méthode, un serveur frontal utilise l'URL + pour répartir de manière appropriée les utilisateurs et objets + entre différents serveurs d'arrière-plan.

+
+ +
Solution :
+ +
+

On maintient une table de correspondance entre utilisateurs et + serveurs cibles dans des fichiers externes. Ces derniers se + présentent comme suit :

+ +

+utilisateur1 serveur_physique_utilisateur1
+utilisateur2 serveur_physique_utilisateur2
+# etc ... +

+ +

Tout ceci est enregistré dans un fichier + correspondances-utilisateurs-serveurs. Le but est de + faire correspondre

+ +

+/u/utilisateur1/chemin +

+ +

avec

+ +

+http://serveur_physique_utilisateur1/u/utilisateur/chemin +

+ +

il n'est ainsi pas nécessaire que tous les chemins URL soient + valides sur tous les serveurs physiques d'arrière-plan. Le jeu de + règles suivant fait tout ceci pour nous, en s'appuyant sur les + fichiers de correspondances, en supposant que serveur0 est un + serveur par défaut qui sera utilisé lorsqu'un utilisateur ne + possèdera pas d'entrée dans la table de correspondances :

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

Voir la documentation de RewriteMap et le RewriteMap HowTo pour une description plus + approfondie de la syntaxe de cette directive.

+ +
top
+
+

Régéneration de contenu à la volée

+ + + +
+
Description :
+ +
+

Nous voulons générer du contenu de manière dynamique, mais le + conserver de manière statique lorsqu'il a été généré. La règle + suivante vérifie l'existence du fichier statique, et le génère + s'il est absent. Les fichiers statiques peuvent être supprimés + périodiquement si on le désire (par exemple via cron), et seront + régénérés à la demande.

+
+ +
Solution :
+ +
+ A cet effet, 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 permet de déterminer si la chaîne + de test (dans ce cas REQUEST_URI) est une URL valide. + Pour ce faire, il utilise une sous-requête. Si cette sous-requête + échoue, ou en d'autres termes, si la ressource demandée n'existe pas, + cette règle invoque le programme CGI + /regenerate_page.cgi qui génère la ressource + demandée et la sauvegarde dans le répertoire des documents, de + façon à ce qu'une copie statique puisse être servie lors d'une + demande ultérieure.

+ +

De cette façon, les documents qui ne sont pas mis à jour + régulièrement peuvent être servis sous une forme statique. Si ces + documents doivent être réactualisés, on peut les supprimer du + répertoire des documents, et ils seront ainsi régénérés à la + prochaine demande.

+
+
+ +
top
+
+

Répartition de charge

+ + + +
+
Description :
+ +
+

Nous voulons répartir la charge de manière aléatoire entre + plusieurs serveurs en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Pour y parvenir, nous allons utiliser la directive RewriteMap et une liste de + serveurs.

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

liste-serveurs.txt contiendra la liste des serveurs :

+ +

+## liste-serveurs.txt
+
+serveurs un.example.com|deux.example.com|trois.example.com
+

+ +

Si vous voulez qu'un serveur se voit confier d'avantage de charge que +les autres, faites le figurer plusieurs fois dans la liste.

+ +
+ +
Discussion
+
+

Apache possède un module de répartition de charge - +mod_proxy_balancer - beaucoup plus souple et présentant +plus de fonctionnalités dans ce domaine que mod_rewrite.

+
+
+ +
top
+
+

Répertoires Home structurés

+ + + +
+
Description :
+ +
+

Certains sites avec des milliers d'utilisateurs organisent + les répertoires utilisateurs de manière structurée, c'est à + dire que chaque répertoire utilisateur se trouve dans un + sous-répertoire dont le nom commence (par exemple) par le + premier caractère du nom de l'utilisateur. Ainsi, + /~larry/chemin correspond à + /home/l/larry/public_html/chemin, alors + que /~waldo/chemin correspond à + /home/w/waldo/public_html/chemin.

+
+ +
Solution :
+ +
+

On utilise le jeu de règles suivant pour développer les + URLs avec tilde selon l'organisation structurée précédente.

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

Redirection des ancrages

+ + + +
+
Description :
+ +
+

Par défaut, la redirection vers un ancrage HTML ne fonctionne + pas, car mod_rewrite échappe le caractère # en le + transformant en %23, ce qui rend la redirection + inopérante.

+
+ +
Solution :
+ +
+

On utilise le drapeau [NE] dans la règle + RewriteRule. NE signifie "No Escape". +

+
+ +
Discussion :
+
Cette technique fonctionne bien entendu pour tout autre + caractère spécial que mod_rewrite, par défaut, code pour insertion + dans une URL.
+
+ +
top
+
+

Réécriture dépendant de l'heure

+ + + +
+
Description :
+ +
+

Nous voulons servir des contenus différents selon l'heure du + jour en utilisant mod_rewrite.

+
+ +
Solution :
+ +
+

Il existe de nombreuses variables nommées + TIME_xxx utilisables dans les conditions de + réécriture. Utilisées en conjonction avec les modèles de + comparaison lexicographique spéciaux <STRING, + >STRING et =STRING, elles + permettent d'effectuer des redirections dépendant de + l'heure :

+ +
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"
+ + +

Avec cet exemple, l'URL foo.html renvoie + le contenu de foo.jour.html durant le + créneau horaire 07:01-18:59, et le contenu de + foo.nuit.html le reste du temps.

+ +
mod_cache, les mandataires + intermédiaires et les navigateurs peuvent chacun mettre en cache + les réponses et ainsi afficher une des deux pages en dehors de + la fenêtre de temps configurée. On peut utiliser + mod_expires pour contourner ce problème. Il est + cependant bien plus commode de servir un contenu dynamique, et + de le personnaliser en fonction de l'heure du jour.
+
+ +
top
+
+

Définir des variables d'environnement en fonction de + certaines parties de l'URL

+ + + +
+
Description :
+ +
+

Nous voulons parfois conserver une certaine forme de statut + lorsqu'une réécriture a eu lieu. Par exemple, vous souhaitez + consigner le fait que cette réécriture a eu lieu, et vous servir + plus tard de cette information pour déterminer si une requête était + concernée par cette réécriture. Pour ce faire, on peut utiliser + une variable d'environnement.

+
+ +
Solution :
+ +
+

Utiliser le drapeau [E] pour définir une variable + d'environnement.

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

Plus loin dans votre jeu de règles, vous pouvez vérifier le + contenu de cette variable d'environnement via une directive + RewriteCond :

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

Notez que les variables d'environnement ne survivent pas à une + redirection externe. Vous devez alors utiliser le drapeau [CO] pour définir + un cookie. Pour les redirections de niveau répertoire et htaccess où la + substitution finale est traitée en tant que redirection interne, les + variables d'environnement du tour de réécriture précédent sont préfixées par + "REDIRECT_".

+ +
+
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/avoid.html b/docs/manual/rewrite/avoid.html new file mode 100644 index 0000000..92bbe36 --- /dev/null +++ b/docs/manual/rewrite/avoid.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: avoid.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: avoid.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/avoid.html.en b/docs/manual/rewrite/avoid.html.en new file mode 100644 index 0000000..b572a2a --- /dev/null +++ b/docs/manual/rewrite/avoid.html.en @@ -0,0 +1,254 @@ + + + + + +When not to use mod_rewrite - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

When not to use mod_rewrite

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It describes +perhaps one of the most important concepts about mod_rewrite - namely, +when to avoid using it.

+ +

mod_rewrite should be considered a last resort, when other +alternatives are found wanting. Using it when there are simpler +alternatives leads to configurations which are confusing, fragile, and +hard to maintain. Understanding what other alternatives are available is +a very important step towards mod_rewrite mastery.

+ +

Note that many of these examples won't work unchanged in your +particular server configuration, so it's important that you understand +them, rather than merely cutting and pasting the examples into your +configuration.

+ +

The most common situation in which mod_rewrite is +the right tool is when the very best solution requires access to the +server configuration files, and you don't have that access. Some +configuration directives are only available in the server configuration +file. So if you are in a hosting situation where you only have .htaccess +files to work with, you may need to resort to +mod_rewrite.

+ +
+ +
top
+
+

Simple Redirection

+ + +

mod_alias provides the Redirect and RedirectMatch directives, which provide a +means to redirect one URL to another. This kind of simple redirection of +one URL, or a class of URLs, to somewhere else, should be accomplished +using these directives rather than RewriteRule. RedirectMatch +allows you to include a regular expression in your redirection criteria, +providing many of the benefits of using RewriteRule.

+ +

A common use for RewriteRule is to redirect an entire +class of URLs. For example, all URLs in the /one directory +must be redirected to http://one.example.com/, or perhaps +all http requests must be redirected to +https.

+ +

These situations are better handled by the Redirect +directive. Remember that Redirect preserves path +information. That is to say, a redirect for a URL /one will +also redirect all URLs under that, such as /one/two.html +and /one/three/four.html.

+ +

To redirect URLs under /one to +http://one.example.com, do the following:

+ +
Redirect "/one/" "http://one.example.com/"
+ + +

To redirect one hostname to another, for example +example.com to www.example.com, see the +Canonical Hostnames +recipe.

+ +

To redirect http URLs to https, do the +following:

+ +
<VirtualHost *:80>
+    ServerName www.example.com
+    Redirect "/" "https://www.example.com/"
+</VirtualHost>
+
+<VirtualHost *:443>
+    ServerName www.example.com
+    # ... SSL configuration goes here
+</VirtualHost>
+ + +

The use of RewriteRule to perform this task may be +appropriate if there are other RewriteRule directives in +the same scope. This is because, when there are Redirect +and RewriteRule directives in the same scope, the +RewriteRule directives will run first, regardless of the +order of appearance in the configuration file.

+ +

In the case of the http-to-https redirection, the use of +RewriteRule would be appropriate if you don't have access +to the main server configuration file, and are obliged to perform this +task in a .htaccess file instead.

+ +
top
+
+

URL Aliasing

+

The Alias directive +provides mapping from a URI to a directory - usually a directory outside +of your DocumentRoot. Although it +is possible to perform this mapping with mod_rewrite, +Alias is the preferred method, for +reasons of simplicity and performance.

+ +

Using Alias

Alias "/cats" "/var/www/virtualhosts/felines/htdocs"
+
+ +

+The use of mod_rewrite to perform this mapping may be +appropriate when you do not have access to the server configuration +files. Alias may only be used in server or virtualhost context, and not +in a .htaccess file. +

+ +

Symbolic links would be another way to accomplish the same thing, if +you have Options FollowSymLinks enabled on your +server.

+
top
+
+

Virtual Hosting

+

Although it is possible to handle virtual hosts +with mod_rewrite, it is seldom the right way. Creating individual +<VirtualHost> blocks is +almost always the right way to go. In the +event that you have an enormous number of virtual hosts, consider using +mod_vhost_alias to create these hosts automatically.

+ +

Modules such as mod_macro are +also useful for creating a large number of virtual hosts dynamically.

+ +

Using mod_rewrite for vitualhost creation may be +appropriate if you are using a hosting service that does not provide +you access to the server configuration files, and you are therefore +restricted to configuration using .htaccess files.

+ +

See the virtual hosts with mod_rewrite +document for more details on how you might accomplish this if it still +seems like the right approach.

+ +
top
+
+

Simple Proxying

+ +

RewriteRule provides the [P] flag to pass rewritten URIs through +mod_proxy.

+ +
RewriteRule "^/?images(.*)" "http://imageserver.local/images$1" [P]
+ + +

However, in many cases, when there is no actual pattern matching +needed, as in the example shown above, the ProxyPass directive is a better choice. +The example here could be rendered as:

+ +
ProxyPass "/images/" "http://imageserver.local/images/"
+ + +

Note that whether you use RewriteRule or ProxyPass, you'll still need to use the +ProxyPassReverse directive to +catch redirects issued from the back-end server:

+ +
ProxyPassReverse "/images/" "http://imageserver.local/images/"
+ + +

You may need to use RewriteRule instead when there are +other RewriteRules in effect in the same scope, as a +RewriteRule will usually take effect before a +ProxyPass, and so may preempt what you're trying to +accomplish.

+ +
top
+
+

Environment Variable Testing

+ +

mod_rewrite is frequently used to take a particular +action based on the presence or absence of a particular environment +variable or request header. This can be done more efficiently using the +<If> directive.

+ +

Consider, for example, the common scenario where +RewriteRule is used to enforce a canonical +hostname, such as www.example.com instead of +example.com. This can be done using the <If> directive, as shown here:

+ +
<If "req('Host') != 'www.example.com'">
+    Redirect "/" "http://www.example.com/"
+</If>
+ + +

This technique can be used to take actions based on any request +header, response header, or environment variable, replacing +mod_rewrite in many common scenarios.

+ +

See especially the expression evaluation +documentation for a overview of what types of expressions you can +use in <If> sections, +and in certain other directives.

+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/avoid.html.fr.utf8 b/docs/manual/rewrite/avoid.html.fr.utf8 new file mode 100644 index 0000000..627777a --- /dev/null +++ b/docs/manual/rewrite/avoid.html.fr.utf8 @@ -0,0 +1,271 @@ + + + + + +Quand ne pas utiliser mod_rewrite - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Quand ne pas utiliser mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la Documentation de référence de +mod_rewrite. Il décrit peut-être un des concepts les +plus importants à propos de mod_rewrite - à savoir, quand doit-on éviter +de l'utiliser.

+ +

mod_rewrite doit être considéré comme un dernier recours, +lorsqu'aucune alternative n'est possible. Utiliser mod_rewrite lorsqu'il +existe des alternatives plus simples conduit à des configurations +confuses, fragiles, et difficiles à maintenir. La compréhension des +autres alternatives disponibles est une étape très importante sur le +chemin de la maîtrise de mod_rewrite.

+ +

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.

+ +

Le cas le plus courant dans lequel mod_rewrite est +l'outil approprié est la situation où la seule solution envisageable +nécessite l'accès aux fichiers de configuration du serveur, alors que +cet accès ne vous est pas accordé. Certaines directives de configuration +ne sont disponibles que dans le fichier de configuration du serveur. Si +vous ne pouvez agir que sur les fichiers .htaccess, vous devrez donc +vous tourner vers mod_rewrite.

+ +
+ +
top
+
+

Redirection simple

+ + +

mod_alias fournit les directives Redirect et RedirectMatch qui permettent de +rediriger une URL vers une autre. Plutôt que d'utiliser la directive +RewriteRule pour ce genre de +redirection simple d'une URL ou d'une classe d'URLs vers une autre, on +préfèrera l'utilisation de ces directives. En outre, avec +RedirectMatch, vous pouvez inclure une expression +rationnelle dans votre critère de redirection, ce qui vous permet de +bénéficier de nombreux avantages de la directive +RewriteRule.

+ +

Une utilisation courante de la directive RewriteRule est +la redirection de toute une classe d'URLs. Par exemple, toutes les URLs +faisant référence au répertoire /un doivent être +redirigées vers http://un.example.com/, ou toutes les +requêtes http doivent être redirigées vers +https.

+ +

Pour ce faire, il est préférable d'utiliser la directive +Redirect. Souvenez-vous que la directive +Redirect conserve les informations relatives au chemin. En +d'autres termes, la redirection d'une URL /un va aussi +rediriger toutes les URLs de niveaux inférieurs comme +/un/deux.html et /un/trois/quatre.html.

+ +

Pour rediriger les URLs sous /un vers +http://un.example.com/, utilisez cette définition :

+ +
Redirect /one/ http://one.example.com/
+ + +

Pour rediriger un nom d'hôte vers un autre nom d'hôte, par exemple +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.

+ +
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.

+ +

Utilisation de la directive Alias

Alias "/cats" "/var/www/virtualhosts/felines/htdocs"
+
+ +

+Pour effectuer cette mise en correspondance, mod_rewrite +s'impose si vous n'avez pas accès aux fichiers de configuration du +serveur. En effet, la directive Alias ne peut pas être utilisée dans un +fichier .htaccess, mais seulement dans un contexte de +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

+ +

La directive RewriteRule fournit +le drapeau [P] qui permet de faire passer les URIs +réécrits par mod_proxy.

+ +
RewriteRule "^/?images(.*)" "http://serveur-images.local/images$1" [P]
+ + +

Cependant, dans les nombreux cas où aucune correspondance au modèle +n'est vraiment nécessaire, comme dans l'exemple ci-dessus, il est +préférable d'utiliser la directive ProxyPass. L'exemple précédent pourrait +être remplacé par :

+ +
ProxyPass "/images/" "http://serveur-images.local/images/"
+ + +

Que vous utilisiez RewriteRule ou ProxyPass, vous devrez dans tous les cas +utiliser aussi la directive ProxyPassReverse pour intercepter les +redirections en provenance du serveur d'arrière-plan :

+ +
ProxyPassReverse "/images/" "http://serveur-images.local/images/"
+ + +

Vous devrez cependant tout de même utiliser RewriteRule +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.

+ +
top
+
+

Test de variables d'environnement

+ +

mod_rewrite est souvent utilisé pour effectuer une +action en fonction de la présence ou de l'absence d'une variable +d'environnement particulière ou d'un en-tête de requête, ce qui peut +être accompli de manière plus efficace via la directive <If>.

+ +

Considérons par exemple le scénario courant où la directive +RewriteRule est utilisée pour forcer un nom +d'hôte canonique, tel que www.example.com au lieu de +example.com. Il est possible d'utiliser à la place la +directive <If> comme +suit :

+ +
<If "req('Host') != 'www.example.com'">
+    Redirect "/" "http://www.example.com"
+</If>
+ + +

On peut utiliser cette technique dans de nombreux scénarios courant +pour remplacer mod_rewrite pour effectuer des actions +en fonction d'en-têtes de requêtes ou de réponses, ou de variables +d'environnement.

+ +

Voir en particulier la documentation sur +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.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/flags.html b/docs/manual/rewrite/flags.html new file mode 100644 index 0000000..e74abb3 --- /dev/null +++ b/docs/manual/rewrite/flags.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: flags.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: flags.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/flags.html.en b/docs/manual/rewrite/flags.html.en new file mode 100644 index 0000000..5e175f1 --- /dev/null +++ b/docs/manual/rewrite/flags.html.en @@ -0,0 +1,842 @@ + + + + + +RewriteRule Flags - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

RewriteRule Flags

+
+

Available Languages:  en  | + fr 

+
+ +

This document discusses the flags which are available to the +RewriteRule directive, +providing detailed explanations and examples.

+
+ +
top
+
+

Introduction

+

A RewriteRule can have +its behavior modified by one or more flags. Flags are included in +square brackets at the end of the rule, and multiple flags are separated +by commas.

+
RewriteRule pattern target [Flag1,Flag2,Flag3]
+ + +

Each flag (with a few exceptions) has a short form, such as +CO, as well as a longer form, such as cookie. +While it is most common to use +the short form, it is recommended that you familiarize yourself with the +long form, so that you remember what each flag is supposed to do. +Some flags take one or more arguments. Flags are not case sensitive.

+ +

Flags that alter metadata associated with the request (T=, H=, E=) +have no affect in per-directory and htaccess context, when a substitution +(other than '-') is performed during the same round of rewrite processing. +

+ +

Presented here are each of the available flags, along with an example +of how you might use them.

+
top
+
+

B (escape backreferences)

+

The [B] flag instructs RewriteRule to escape non-alphanumeric +characters before applying the transformation.

+ +

mod_rewrite has to unescape URLs before mapping them, +so backreferences are unescaped at the time they are applied. +Using the B flag, non-alphanumeric characters in backreferences +will be escaped. For example, consider the rule:

+ +
RewriteRule "^search/(.*)$" "/search.php?term=$1"
+ + +

Given a search term of 'x & y/z', a browser will encode it as +'x%20%26%20y%2Fz', making the request 'search/x%20%26%20y%2Fz'. Without the B +flag, this rewrite rule will map to 'search.php?term=x & y/z', which +isn't a valid URL, and so would be encoded as +search.php?term=x%20&y%2Fz=, which is not what was intended.

+ +

With the B flag set on this same rule, the parameters are re-encoded +before being passed on to the output URL, resulting in a correct mapping to +/search.php?term=x%20%26%20y%2Fz.

+ +
RewriteRule "^search/(.*)$" "/search.php?term=$1" [B,PT]
+ + +

Note that you may also need to set AllowEncodedSlashes to On to get this +particular example to work, as httpd does not allow encoded slashes in URLs, and +returns a 404 if it sees one.

+ +

This escaping is particularly necessary in a proxy situation, +when the backend may break if presented with an unescaped URL.

+ +

An alternative to this flag is using a RewriteCond to capture against %{THE_REQUEST} which will capture +strings in the encoded form.

+ +

In 2.4.26 and later, you can limit the escaping to specific characters +in backreferences by listing them: [B=#?;]. Note: The space +character can be used in the list of characters to escape, but you must quote +the entire third argument of RewriteRule +and the space must not be the last character in the list.

+ +
# Escape spaces and question marks.  The quotes around the final argument 
+# are required when a space is included.
+RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]"
+ + +

To limit the characters escaped this way, see flag_bne +and flag_bctls

+
top
+
+

BNP|backrefnoplus (don't escape space to +)

+

The [BNP] flag instructs RewriteRule to escape the space character +in a backreference to %20 rather than '+'. Useful when the backreference +will be used in the path component rather than the query string.

+ +
# Escape spaces to %20 in the path instead of + as used in form submission via
+# the query string
+RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]"
+ + + +

This flag is available in version 2.4.26 and later.

+
top
+
+

BCTLS

+

The [BCTLS] flag is similar to the [B] flag, but only escapes +control characters and the space character. This is the same set of +characters rejected when they are copied into the query string unencoded. +

+ +
# Escape control characters and spaces
+RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]"
+ + +

This flag is available in version 2.4.57 and later.

+ +
top
+
+

BNE

+

The list of characters in [BNE=...] are treated as exclusions to the +characters of the [B] or [BCTLS] flags. The listed characters will not be +escaped. +

+ +
# Escape the default characters, but leave /
+RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]"
+ + +

This flag is available in version 2.4.57 and later.

+
top
+
+

C|chain

+

The [C] or [chain] flag indicates that the RewriteRule is chained to the next +rule. That is, if the rule matches, then it is processed as usual and +control moves on to the next rule. However, if it does not match, then +the next rule, and any other rules that are chained together, are +skipped.

+ +
top
+
+

CO|cookie

+

The [CO], or [cookie] flag, allows you to set a cookie when a +particular RewriteRule +matches. The argument consists of three required fields and five optional +fields.

+ +

The full syntax for the flag, including all attributes, is as +follows:

+ +

+[CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly:samesite] +

+ +

If a literal ':' character is needed in any of the cookie fields, an +alternate syntax is available. To opt-in to the alternate syntax, the cookie +"Name" should be preceded with a ';' character, and field separators should be +specified as ';'.

+ +

+[CO=;NAME;VALUE:MOREVALUE;DOMAIN;lifetime;path;secure;httponly;samesite] +

+ +

You must declare a name, a value, and a domain for the cookie to be set.

+ +
+
Domain
+
The domain for which you want the cookie to be valid. This may be a +hostname, such as www.example.com, or it may be a domain, +such as .example.com. It must be at least two parts +separated by a dot. That is, it may not be merely .com or +.net. Cookies of that kind are forbidden by the cookie +security model.
+
+ +

You may optionally also set the following values:

+ +
+
Lifetime
+
The time for which the cookie will persist, in minutes.
+
A value of 0 indicates that the cookie will persist only for the +current browser session. This is the default value if none is +specified.
+ +
Path
+
The path, on the current website, for which the cookie is valid, +such as /customers/ or /files/download/.
+
By default, this is set to / - that is, the entire +website.
+ +
Secure
+
If set to secure, true, or 1, +the cookie will only be permitted to be translated via secure (https) +connections.
+ +
httponly
+
If set to HttpOnly, true, or +1, the cookie will have the HttpOnly flag set, +which means that the cookie is inaccessible to JavaScript code on +browsers that support this feature.
+ +
samesite
+
If set to anything other than false or 0, the SameSite +attribute is set to the specified value. Typical values are None, +Lax, and Strict. Available in 2.4.47 and later.
+
+ + +

Consider this example:

+ +
RewriteEngine On
+RewriteRule   "^/index\.html"   "-" [CO=frontdoor:yes:.example.com:1440:/]
+ + +

In the example give, the rule doesn't rewrite the request. +The "-" rewrite target tells mod_rewrite to pass the request +through unchanged. Instead, it sets a cookie +called 'frontdoor' to a value of 'yes'. The cookie is valid for any host +in the .example.com domain. It is set to expire in 1440 +minutes (24 hours) and is returned for all URIs.

+ +
top
+
+

DPI|discardpath

+

The DPI flag causes the PATH_INFO portion of the rewritten URI to be +discarded.

+

This flag is available in version 2.2.12 and later.

+

In per-directory context, the URI each RewriteRule +compares against is the concatenation of the current values of the URI +and PATH_INFO.

+ +

The current URI can be the initial URI as requested by the client, the +result of a previous round of mod_rewrite processing, or the result of +a prior rule in the current round of mod_rewrite processing.

+ +

In contrast, the PATH_INFO that is appended to the URI before each +rule reflects only the value of PATH_INFO before this round of +mod_rewrite processing. As a consequence, if large portions +of the URI are matched and copied into a substitution in multiple +RewriteRule directives, without regard for +which parts of the URI came from the current PATH_INFO, the final +URI may have multiple copies of PATH_INFO appended to it.

+ +

Use this flag on any substitution where the PATH_INFO that resulted +from the previous mapping of this request to the filesystem is not of +interest. This flag permanently forgets the PATH_INFO established +before this round of mod_rewrite processing began. PATH_INFO will +not be recalculated until the current round of mod_rewrite processing +completes. Subsequent rules during this round of processing will see +only the direct result of substitutions, without any PATH_INFO +appended.

+
top
+
+

E|env

+

With the [E], or [env] flag, you can set the value of an environment +variable. Note that some environment variables may be set after the rule +is run, thus unsetting what you have set. See the +Environment Variables document for more details on how Environment +variables work.

+ +

The full syntax for this flag is:

+ +
[E=VAR:VAL]
+[E=!VAR]
+ + +

VAL may contain backreferences ($N or +%N) which are expanded.

+ +

Using the short form

+ +

+[E=VAR] +

+ +

you can set the environment variable named VAR to an +empty value.

+ +

The form

+ +

+[E=!VAR] +

+ +

allows to unset a previously set environment variable named +VAR.

+ +

Environment variables can then be used in a variety of +contexts, including CGI programs, other RewriteRule directives, or +CustomLog directives.

+ +

The following example sets an environment variable called 'image' to a +value of '1' if the requested URI is an image file. Then, that +environment variable is used to exclude those requests from the access +log.

+ +
RewriteRule "\.(png|gif|jpg)$"   "-" [E=image:1]
+CustomLog   "logs/access_log"    combined env=!image
+ + +

Note that this same effect can be obtained using SetEnvIf. This technique is offered as +an example, not as a recommendation.

+
top
+
+

END

+

Using the [END] flag terminates not only the current round of rewrite +processing (like [L]) but also prevents any subsequent rewrite +processing from occurring in per-directory (htaccess) context.

+ +

This does not apply to new requests resulting from external +redirects.

+
top
+
+

F|forbidden

+

Using the [F] flag causes the server to return a 403 Forbidden status +code to the client. While the same behavior can be accomplished using +the Deny directive, this +allows more flexibility in assigning a Forbidden status.

+ +

The following rule will forbid .exe files from being +downloaded from your server.

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

This example uses the "-" syntax for the rewrite target, which means +that the requested URI is not modified. There's no reason to rewrite to +another URI, if you're going to forbid the request.

+ +

When using [F], an [L] is implied - that is, the response is returned +immediately, and no further rules are evaluated.

+ +
top
+
+

G|gone

+

The [G] flag forces the server to return a 410 Gone status with the +response. This indicates that a resource used to be available, but is no +longer available.

+ +

As with the [F] flag, you will typically use the "-" syntax for the +rewrite target when using the [G] flag:

+ +
RewriteRule "oldproduct"   "-" [G,NC]
+ + +

When using [G], an [L] is implied - that is, the response is returned +immediately, and no further rules are evaluated.

+ +
top
+
+

H|handler

+

Forces the resulting request to be handled with the specified +handler. For example, one might use this to force all files without a +file extension to be parsed by the php handler:

+ +
RewriteRule "!\."  "-" [H=application/x-httpd-php]
+ + +

+The regular expression above - !\. - will match any request +that does not contain the literal . character. +

+ +

This can be also used to force the handler based on some conditions. +For example, the following snippet used in per-server context allows +.php files to be displayed by mod_php +if they are requested with the .phps extension:

+ +
RewriteRule "^(/source/.+\.php)s$" "$1" [H=application/x-httpd-php-source]
+ + +

The regular expression above - ^(/source/.+\.php)s$ - will +match any request that starts with /source/ followed by 1 or +n characters followed by .phps literally. The backreference +$1 referrers to the captured match within parenthesis of the regular +expression.

+
top
+
+

L|last

+

The [L] flag causes mod_rewrite to stop processing +the rule set. In most contexts, this means that if the rule matches, no +further rules will be processed. This corresponds to the +last command in Perl, or the break command in +C. Use this flag to indicate that the current rule should be applied +immediately without considering further rules.

+ +

If you are using RewriteRule in either +.htaccess files or in +<Directory> sections, +it is important to have some understanding of how the rules are +processed. The simplified form of this is that once the rules have been +processed, the rewritten request is handed back to the URL parsing +engine to do what it may with it. It is possible that as the rewritten +request is handled, the .htaccess file or +<Directory> section +may be encountered again, and thus the ruleset may be run again from the +start. Most commonly this will happen if one of the rules causes a +redirect - either internal or external - causing the request process to +start over.

+ +

It is therefore important, if you are using RewriteRule directives in one of these +contexts, that you take explicit steps to avoid rules looping, and not +count solely on the [L] flag to terminate execution of a series of +rules, as shown below.

+ +

An alternative flag, [END], can be used to terminate not only the +current round of rewrite processing but prevent any subsequent +rewrite processing from occurring in per-directory (htaccess) +context. This does not apply to new requests resulting from external +redirects.

+ +

The example given here will rewrite any request to +index.php, giving the original request as a query string +argument to index.php, however, the RewriteCond ensures that if the request +is already for index.php, the RewriteRule will be skipped.

+ +
RewriteBase "/"
+RewriteCond "%{REQUEST_URI}" !=/index.php
+RewriteRule "^(.*)"          "/index.php?req=$1" [L,PT]
+ +
top
+
+

N|next

+

+The [N] flag causes the ruleset to start over again from the top, using +the result of the ruleset so far as a starting point. Use +with extreme caution, as it may result in loop. +

+

+The [Next] flag could be used, for example, if you wished to replace a +certain string or letter repeatedly in a request. The example shown here +will replace A with B everywhere in a request, and will continue doing +so until there are no more As to be replaced. +

+
RewriteRule "(.*)A(.*)" "$1B$2" [N]
+ +

You can think of this as a while loop: While this +pattern still matches (i.e., while the URI still contains an +A), perform this substitution (i.e., replace the +A with a B).

+ +

In 2.4.8 and later, this module returns an error after 10,000 iterations to +protect against unintended looping. An alternative maximum number of +iterations can be specified by adding to the N flag.

+
# Be willing to replace 1 character in each pass of the loop
+RewriteRule "(.+)[><;]$" "$1" [N=32000]
+# ... or, give up if after 10 loops
+RewriteRule "(.+)[><;]$" "$1" [N=10]
+ + +
top
+
+

NC|nocase

+

Use of the [NC] flag causes the RewriteRule to be matched in a +case-insensitive manner. That is, it doesn't care whether letters appear +as upper-case or lower-case in the matched URI.

+ +

In the example below, any request for an image file will be proxied +to your dedicated image server. The match is case-insensitive, so that +.jpg and .JPG files are both acceptable, for +example.

+ +
RewriteRule "(.*\.(jpg|gif|png))$" "http://images.example.com$1" [P,NC]
+ +
top
+
+

NE|noescape

+

By default, special characters, such as & and +?, for example, will be converted to their hexcode +equivalent for rules that result in external redirects. +Using the [NE] flag prevents that from happening. +

+ +
RewriteRule "^/anchor/(.+)" "/bigpage.html#$1" [NE,R]
+ + +

+The above example will redirect /anchor/xyz to +/bigpage.html#xyz. Omitting the [NE] will result in the # +being converted to its hexcode equivalent, %23, which will +then result in a 404 Not Found error condition. +

+ +
top
+
+

NS|nosubreq

+

Use of the [NS] flag prevents the rule from being used on +subrequests. For example, a page which is included using an SSI (Server +Side Include) is a subrequest, and you may want to avoid rewrites +happening on those subrequests. Also, when mod_dir +tries to find out information about possible directory default files +(such as index.html files), this is an internal +subrequest, and you often want to avoid rewrites on such subrequests. +On subrequests, it is not always useful, and can even cause errors, if +the complete set of rules are applied. Use this flag to exclude +problematic rules.

+ +

To decide whether or not to use this rule: if you prefix URLs with +CGI-scripts, to force them to be processed by the CGI-script, it's +likely that you will run into problems (or significant overhead) +on sub-requests. In these cases, use this flag.

+ +

+Images, javascript files, or css files, loaded as part of an HTML page, +are not subrequests - the browser requests them as separate HTTP +requests. +

+
top
+
+

P|proxy

+

Use of the [P] flag causes the request to be handled by +mod_proxy, and handled via a proxy request. For +example, if you wanted all image requests to be handled by a back-end +image server, you might do something like the following:

+ +
RewriteRule "/(.*)\.(jpg|gif|png)$" "http://images.example.com/$1.$2" [P]
+ + +

Use of the [P] flag implies [L] - that is, the request is immediately +pushed through the proxy, and any following rules will not be +considered.

+ +

+You must make sure that the substitution string is a valid URI +(typically starting with http://hostname) which can be +handled by the mod_proxy. If not, you will get an +error from the proxy module. Use this flag to achieve a +more powerful implementation of the ProxyPass directive, +to map remote content into the namespace of the local server.

+ +
+

Security Warning

+

Take care when constructing the target URL of the rule, considering +the security impact from allowing the client influence over the set of +URLs to which your server will act as a proxy. Ensure that the scheme +and hostname part of the URL is either fixed, or does not allow the +client undue influence.

+
+ +
+

Performance warning

+

Using this flag triggers the use of mod_proxy, without handling of persistent connections. This +means the performance of your proxy will be better if you set it up with ProxyPass or +ProxyPassMatch

+

This is because this flag triggers the use of the default worker, which does not handle connection pooling/reuse.

+

Avoid using this flag and prefer those directives, whenever you can.

+
+ +

Note: mod_proxy must be enabled in order +to use this flag.

+ +
top
+
+

PT|passthrough

+ +

+The target (or substitution string) in a RewriteRule is assumed to be a +file path, by default. The use of the [PT] flag causes it to be treated +as a URI instead. That is to say, the +use of the [PT] flag causes the result of the RewriteRule to be passed back through +URL mapping, so that location-based mappings, such as Alias, Redirect, or ScriptAlias, for example, might have a +chance to take effect. +

+ +

+If, for example, you have an +Alias +for /icons, and have a RewriteRule pointing there, you should +use the [PT] flag to ensure that the +Alias is evaluated. +

+ +
Alias "/icons" "/usr/local/apache/icons"
+RewriteRule "/pics/(.+)\.jpg$" "/icons/$1.gif" [PT]
+ + +

+Omission of the [PT] flag in this case will cause the Alias to be +ignored, resulting in a 'File not found' error being returned. +

+ +

The PT flag implies the L flag: +rewriting will be stopped in order to pass the request to +the next phase of processing.

+ +

Note that the PT flag is implied in per-directory +contexts such as +<Directory> sections +or in .htaccess files. The only way to circumvent that +is to rewrite to -.

+ +
top
+
+

QSA|qsappend

+

+When the replacement URI contains a query string, the default behavior +of RewriteRule is to discard +the existing query string, and replace it with the newly generated one. +Using the [QSA] flag causes the query strings to be combined. +

+ +

Consider the following rule:

+ +
RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]
+ + +

With the [QSA] flag, a request for /pages/123?one=two will be +mapped to /page.php?page=123&one=two. Without the [QSA] +flag, that same request will be mapped to +/page.php?page=123 - that is, the existing query string +will be discarded. +

+
top
+
+

QSD|qsdiscard

+

+When the requested URI contains a query string, and the target URI does +not, the default behavior of RewriteRule is to copy that query +string to the target URI. Using the [QSD] flag causes the query string +to be discarded. +

+ +

This flag is available in version 2.4.0 and later.

+ +

+Using [QSD] and [QSA] together will result in [QSD] taking precedence. +

+ +

+If the target URI has a query string, the default behavior will be +observed - that is, the original query string will be discarded and +replaced with the query string in the RewriteRule target +URI. +

+ +
top
+
+

QSL|qslast

+

+By default, the first (left-most) question mark in the substitution +delimits the path from the query string. Using the [QSL] flag instructs +RewriteRule to instead split +the two components using the last (right-most) question mark.

+ +

+This is useful when mapping to files that have literal question marks in +their filename. If no query string is used in the substitution, +a question mark can be appended to it in combination with this flag.

+ +

This flag is available in version 2.4.19 and later.

+ +
top
+
+

R|redirect

+

+Use of the [R] flag causes a HTTP redirect to be issued to the browser. +If a fully-qualified URL is specified (that is, including +http://servername/) then a redirect will be issued to that +location. Otherwise, the current protocol, servername, and port number +will be used to generate the URL sent with the redirect. +

+ +

+Any valid HTTP response status code may be specified, +using the syntax [R=305], with a 302 status code being used by +default if none is specified. The status code specified need not +necessarily be a redirect (3xx) status code. However, +if a status code is outside the redirect range (300-399) then the +substitution string is dropped entirely, and rewriting is stopped as if +the L were used.

+ +

In addition to response status codes, you may also specify redirect +status using their symbolic names: temp (default), +permanent, or seeother.

+ +

+You will almost always want to use [R] in conjunction with [L] (that is, +use [R,L]) because on its own, the [R] flag prepends +http://thishost[:thisport] to the URI, but then passes this +on to the next rule in the ruleset, which can often result in 'Invalid +URI in request' warnings. +

+ +
top
+
+

S|skip

+

The [S] flag is used to skip rules that you don't want to run. The +syntax of the skip flag is [S=N], where N signifies +the number of rules to skip (provided the +RewriteRule and any preceding +RewriteCond directives match). This can be thought of as a +goto statement in your rewrite ruleset. In the following +example, we only want to run the +RewriteRule if the requested URI doesn't correspond with an +actual file.

+ +
# Is the request for a non-existent file?
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+# If so, skip these two RewriteRules
+RewriteRule ".?"                  "-" [S=2]
+
+RewriteRule "(.*\.gif)"           "images.php?$1"
+RewriteRule "(.*\.html)"          "docs.php?$1"
+ + +

This technique is useful because a RewriteCond only applies to the +RewriteRule immediately +following it. Thus, if you want to make a RewriteCond apply +to several RewriteRules, one possible technique is to +negate those conditions and add a RewriteRule with a [Skip] flag. You can +use this to make pseudo if-then-else constructs: The last rule of +the then-clause becomes skip=N, where N is the +number of rules in the else-clause:

+
# Does the file exist?
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+# Create an if-then-else construct by skipping 3 lines if we meant to go to the "else" stanza.
+RewriteRule ".?"                  "-" [S=3]
+
+# IF the file exists, then:
+    RewriteRule "(.*\.gif)"  "images.php?$1"
+    RewriteRule "(.*\.html)" "docs.php?$1"
+    # Skip past the "else" stanza.
+    RewriteRule ".?"         "-" [S=1]
+# ELSE...
+    RewriteRule "(.*)"       "404.php?file=$1"
+# END
+ + +

It is probably easier to accomplish this kind of configuration using +the <If>, <ElseIf>, and <Else> directives instead.

+ +
top
+
+

T|type

+

Sets the MIME type with which the resulting response will be +sent. This has the same effect as the AddType directive.

+ +

For example, you might use the following technique to serve Perl +source code as plain text, if requested in a particular way:

+ +
# Serve .pl files as plain text
+RewriteRule "\.pl$"  "-" [T=text/plain]
+ + +

Or, perhaps, if you have a camera that produces jpeg images without +file extensions, you could force those images to be served with the +correct MIME type by virtue of their file names:

+ +
# Files with 'IMG' in the name are jpg images.
+RewriteRule "IMG"  "-" [T=image/jpg]
+ + +

Please note that this is a trivial example, and could be better done +using <FilesMatch> +instead. Always consider the alternate +solutions to a problem before resorting to rewrite, which will +invariably be a less efficient solution than the alternatives.

+ +

+If used in per-directory context, use only - (dash) +as the substitution for the entire round of mod_rewrite processing, +otherwise the MIME-type set with this flag is lost due to an internal +re-processing (including subsequent rounds of mod_rewrite processing). +The L flag can be useful in this context to end the +current round of mod_rewrite processing.

+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/flags.html.fr.utf8 b/docs/manual/rewrite/flags.html.fr.utf8 new file mode 100644 index 0000000..4c3e486 --- /dev/null +++ b/docs/manual/rewrite/flags.html.fr.utf8 @@ -0,0 +1,904 @@ + + + + + +Les drapeaux de réécriture - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Les drapeaux de réécriture

+
+

Langues Disponibles:  en  | + fr 

+
+ +

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

+
+ +
top
+
+

Introduction

+

Le comportement d'une directive RewriteRule peut être modifié par un ou +plusieurs drapeaux. Les drapeaux sont situés en fin de règle, entourés +de crochets, et séparés le cas échéant par des virgules.

+
RewriteRule pattern target [Flag1,Flag2,Flag3]
+ + +

Chaque drapeau (à quelques exceptions près) +possède une forme courte, comme CO, ainsi qu'une forme longue, +comme cookie. Bien que +la forme courte soit la plus couramment utilisée, nous vous recommandons +de vous familiariser avec les drapeaux sous leur forme longue, afin de +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. +

+ +

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

+
top
+
+

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

+

Avec le drapeau [B], la directive RewriteRule échappe les caractères +non-alphanumériques avant d'appliquer la transformation.

+ +

mod_rewrite doit supprimer les séquences d'échappement +des URLs avant leur +mise en correspondance avec le système de fichiers ; les séquences +d'échappement sont donc supprimées des références arrières au moment où +ces dernières sont appliquées. Avec le drapeau B, les caractères +non-alphanumériques des références arrières seront échappés. Considérons +par exemple cette règle :

+ +
RewriteRule "^search/(.*)$" "/search.php?term=$1"
+ + +

Soit le terme de recherche 'x & y/z' ; un navigateur va le coder +en 'x%20%26%20y%2Fz', transformant la requête en +'search/x%20%26%20y%2Fz'. Sans le drapeau B, cette règle de réécriture +va réécrire la requête en 'search.php?term=x & y/z', ce qui ne +correspond pas à une URL valide et cette dernière sera encodée en +search.php?term=x%20&y%2Fz=, ce qui ne correspond pas à +ce que l'on souhaitait.

+ +

Avec le drapeau B, les paramètres sont réencodés avant d'être passés +à l'URL résultante, ce qui fournit une réécriture correcte en +/search.php?term=x%20%26%20y%2Fz.

+ +
RewriteRule "^search/(.*)$" "/search.php?term=$1" [B,PT]
+ + +

Notez que vous devrez peut-être aussi définir la +directive AllowEncodedSlashes +à On pour +que cet exemple particulier fonctionne, car httpd ne permet pas les +slashes encodés dans les URLs, et renvoie une erreur 404 s'il en +rencontre un.

+ +

Ce processus d'échappement est en particulier nécessaire dans le +contexte d'un mandataire, où l'accès au serveur d'arrière-plan échouera +si on présente à ce dernier une URL non échappée.

+ +

Une alternative à ce drapeau consiste à utiliser une directive +RewriteCond pour capturer +%{THE_REQUEST}, les chaînes capturées se présentant +alors sous la forme codée.

+ +

A partir +de la version 2.4.26, vous pouvez limiter l'échappement dans les +références arrières à une liste de caractères que vous pouvez spécifiez comme +dans cet exemple : [B=#?;]. Notez que l'espace peut faire +partie de la liste des caractères à échapper, mais que vous devez mettre entre +guillemets le troisième argument de la directive RewriteRule et que l'espace ne doit pas +être le dernier caractère de cette liste. +

+ +
# Échappement des espaces et des points d'interrogation. Les guillemets autour
+# du dernier argument sont obligatoires lorsque l'espace est inclus.
+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

+ +
top
+
+

BNP|backrefnoplus (ne pas échapper +l'espace en +)

+

Si le drapeau [BNP] est spécifié, la directive RewriteRule échappera le caractère +espace en %20 au lieu de '+' dans les références arrières. Ceci s'avère +utile lorsque la référence arrière est utilisée dans la partie chemin, +et non dans les paramètres de la requête.

+ +
# Échappe le caractère espace en %20 dans le chemin au lieu de + comme dans la
+# soumission de formulaire à l'aide de la chaîne de paramètres
+RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]"
+ + +

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

+ +

BCTLS

+

Le drapeau [BCTLS] est similaire à [B], à la différence que seuls les espaces +et les caractères de contrôle sont échappés. Il s'agit du même jeu de caractères +rejetés lorsqu'ils sont copiés dans la chaîne de paramètres non codée. +

+ +
# Échappe les espaces et les caractères de contrôle
+RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]"
+ + +

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

+ + + +

BNE

+

Les caractères listés dans [BNE=...] sont exclus des listes de caractères +correspondant aux drapeaux [B] ou [BCTLS]. Ils ne seront donc pas échappés. +

+ +
# Échappe les caractères par défaut, sauf /
+RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]"
+ + +

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

+ + + +
top
+
+

C|chain

+

Le drapeau [C] ou [chain] indique que la règle RewriteRule est chaînée avec la +suivante. Autrement dit, si la règle s'applique, elle est traitée +normalement et passe le contrôle à la règle suivante. Par contre, si +elle ne s'applique pas, la règle suivante, ainsi que toutes les règles +chaînées qui suivent, seront sautées.

+ +
top
+
+

CO|cookie

+

Le drapeau [CO], ou [cookie], vous permet de définir un cookie +lorsqu'une règle RewriteRule +s'applique. Il possède trois arguments obligatoires et +cinq arguments optionnels.

+ +

La syntaxe complète de ce drapeau, avec tous ses attributs, est la +suivante :

+ +

+[CO=NAME:VALUE:DOMAIN:lifetime:path:secure:httponly:samesite] +

+ +

Si un caractère littéral ':' doit être insérer dans un des champs du +cookie, une autre syntaxe est disponible. Pour utiliser cette syntaxe +alternative, le contenu du champ "Name" doit être précédé du caractère +';', et les sépateurs de champs deviendront des ';'.

+ +

+[CO=;NAME;VALUE:MOREVALUE;DOMAIN;lifetime;path;secure;httponly;samesite] +

+ +

Vous devez déclarer un nom, une valeur et un domaine pour que +le cookie puisse être défini.

+ + +
+
Domain
+
Le domaine pour lequel vous souhaitez que le cookie soit valide. Ce +peut être un nom de serveur, comme www.example.com, ou un +domaine, comme .example.com. Il doit comporter au moins +deux parties séparées par un point. C'est à dire que vous ne pouvez pas +utiliser les valeurs .com ou .net. En effet, +ce style de cookie est interdit par le modèle de sécurité des cookies.
+
+ +

Vous pouvez aussi définir les valeurs suivantes :

+ +
+
Lifetime
+
La durée de vie du cookie, en minutes.
+
Une valeur de 0 indique une durée de vie correspondant à la session +courante du navigateur. Il s'agit de la valeur par défaut.
+ +
Path
+
Le chemin, sur le site web concerné, pour lequel le cookie est +valide, du style /clients/ or +/fichiers/telechargement/.
+
La valeur par défaut est / - c'est à dire l'ensemble du +site web.
+ +
Secure
+
Si cet argument a pour valeur secure, +true, ou 1, le cookie ne pourra être transmis +que dans le cadre d'une connexion sécurisée (https).
+ +
httponly
+
Si cet argument a pour valeur HttpOnly, +true, ou 1, le cookie aura son drapeau +HttpOnly activé, ce qui signifie qu'il sera inaccessible au +code JavaScript pour les navigateurs qui supportent cette +fonctionnalité.
+ +
samesite
+
S'il est différent de false ou 0, l'attribut +SameSite est défini à la valeur spécifiée. Les valeurs typiques +sont None, Lax et Strict. Disponible à +partir de la version 2.4.47 du serveur HTTP Apache.
+
+ +

Voici un exemple :

+ +
RewriteEngine On
+RewriteRule   "^/index\.html"   "-" [CO=frontdoor:yes:.example.com:1440:/]
+ + +

Dans l'exemple ci-dessus, la règle ne réécrit +pas la requête. La cible de réécriture "-" +indique à mod_rewrite de transmettre la requête sans +modification. Par contre, il +définit un cookie nommé 'frontdoor' avec une valeur 'yes'. Le cookie est +valide pour tout hôte situé dans le domaine .example.org. Sa +durée de vie est limitée à 1440 minutes (24 heures), et il sera renvoyé +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 +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 +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 +RewriteRule, sans prendre en compte +quelles parties de l'URI provenaient du PATH_INFO courant, l'URI final +pourra se voir ajouter plusieurs copies de PATH_INFO.

+ +

Utilisez ce drapeau pour toute substitution où la présence du PATH_INFO qui +résultait de la mise en correspondance précédente de cette requête avec +le système de fichier n'est pas nécessaire. Avec ce drapeau, le +PATH_INFO établi avant que cette passe du processus de réécriture ne +débute est oublié. PATH_INFO ne sera pas recalculé tant que la passe +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é.

+
top
+
+

E|env

+

Avec le drapeau [E], ou [env], vous pouvez définir la valeur d'une +variable d'environnement. Notez que certaines variables d'environnement +peuvent être définies après le traitement de la règle, annulant par +la-même ce que vous avez défini. Voir le document +sur les variables d'environnement pour plus de détails sur le +fonctionnement des variables d'environnement.

+ +

La syntaxe complète pour ce drapeau est :

+ +
[E=!VAR]
+ + +

VAL peut comporter des références arrières +($N ou %N) qui seront développées.

+ +

En utilisant la version courte

+ +

+[E=VAR] +

+ +

vous pouvez définir la variable d'environnement nommée +VAR avec une valeur vide.

+ +

La forme

+ +

+[E=!VAR] +

+ +

permet d'annuler la définition de la variable VAR.

+ +

Les variables d'environnement s'emploient dans différents contextes, +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 +image. Cette variable d'environnement est ensuite utilisée pour exclure +une telle requête du journal des accès.

+ +
RewriteRule "\.(png|gif|jpg)$"   "-" [E=image:1]
+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.

+
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).

+ +

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

+
top
+
+

F|forbidden

+

L'utilisation du drapeau [F] permet de faire envoyer par le serveur au +client un code de statut "403 Forbidden". Le même effet peut être obtenu à +l'aide de la directive Deny, +mais ce drapeau offre plus de souplesse dans l'attribution d'un statut +Forbidden.

+ +

La règle suivante va interdire la téléchargement de fichiers +.exe depuis votre serveur.

+ +
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 +requête.

+ +

Lorsqu'on utilise [F], [L] est implicite - c'est à dire que la +réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.

+ +
top
+
+

G|gone

+

Le drapeau [G] permet de faire envoyer par le serveur un code de statut +"410 Gone" avec la réponse. Ce code indique qu'une ressource qui était +disponible auparavant ne l'est plus actuellement.

+ +

Comme dans le cas du drapeau [F], on utilise en général la syntaxe +"-" pour la cible de réécriture lorsqu'on utilise le drapeau [G] :

+ +
RewriteRule "oldproduct"   "-" [G,NC]
+ + +

Lorsqu'on utilise [G], [L] est implicite - c'est à dire que la +réponse est renvoyée immédiatement, et aucune autre règle n'est évaluée.

+ +
top
+
+

H|handler

+

Force le traitement de la requête résultante par le gestionnaire +spécifié. Par exemple, on peut utiliser ce drapeau pour forcer +l'interprétation de tous les fichiers sans extension par le gestionnaire +php :

+ +
RewriteRule "!\."  "-" [H=application/x-httpd-php]
+ + +

+L'expression rationnelle ci-dessus - !\. - correspond à +toute requête qui ne contient pas le caractère .. +

+

On peut aussi utiliser ce drapeau pour forcer l'utilisation d'un +certain gestionnaire en fonction de certaines conditions. Par exemple, +l'extrait suivant utilisé dans un contexte de niveau serveur permet de +faire en sorte que les fichiers .php soient +affichés par mod_php dans le cas où ils font +l'objet d'une requête avec l'extension .phps :

+ +
RewriteRule "^(/source/.+\.php)s$" "$1" [H=application/x-httpd-php-source]
+ + + +

L'expression rationnelle ci-dessus - +^(/source/.+\.php)s$ - va correspondre à toute requête qui +débutera par /source/, continuera par 1 ou n caractères +puis par .phps. La référence arrière $1 fait référence à la +correspondance capturée entre parenthèses de l'expression +rationnelle.

+ + +
top
+
+

L|last

+

Lorsque le drapeau [L] est présent, mod_rewrite +arrête le traitement du jeu de règles. Cela signifie dans la plupart des +situations que si la règle s'applique, aucune autre règle ne sera +traitée. Ce drapeau correspond à la commande Perl last, ou +à la commande break en C. Utilisez ce drapeau pour indiquer +que la règle courante doit être appliquée immédiatement, sans tenir +compte des règles ultérieures.

+ +

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 l'exemple donné ici, toute requête est réécrite en +index.php, la requête originale étant ajoutée comme chaîne +de requête en argument à index.php ; cependant, la +directive RewriteCond permet de s'assurer que si +la requête concerne déjà index.php, la directive RewriteRule sera sautée.

+ +
RewriteBase "/"
+RewriteCond "%{REQUEST_URI}" !=/index.php
+RewriteRule "^(.*)"          "/index.php?req=$1" [L,PT]
+ +
top
+
+

N|next

+

Le drapeau [N] provoque un redémarrage du traitement des règles +depuis le début, en utilisant le résultat du jeu de règles, sous +réserve qu'il existe un point de démarrage ; à utiliser avec précautions +car il peut provoquer un bouclage infini. +

+

+Le drapeau [Next] peut servir, par exemple, +à remplacer de manière répétitive +une chaîne de caractère ou une lettre dans une requête. Dans l'exemple +suivant, chaque occurence de A sera remplacée par B dans la requête, et +ceci jusqu'il n'y ait plus de A à remplacer. +

+ +
RewriteRule "(.*)A(.*)" "$1B$2" [N]
+ + +

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), +effectuer la substitution (c'est à dire, remplacer le A par +un B).

+ +

A partir de la version 2.4.8, ce module renvoie une erreur après +10000 itérations afin d'éviter les boucles infinies. Ce nombre maximum +d'itération peut être modifié via le drapeau N.

+
# On veut remplacer 1 caractère à chaque itération de la boucle
+RewriteRule "(.+)[><;]$" "$1" [N=32000]
+# ... ou s'arrêter après 10 itérations
+RewriteRule "(.+)[><;]$" "$1" [N=10]
+ + +
top
+
+

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 +comparé.

+ +

Dans l'exemple suivant, toute requête pour un fichier image sera +transmise par Apache à votre serveur d'images dédié. La correspondance est +insensible à la casse, si bien que par exemple, .jpg aussi +bien que .JPG seront acceptés.

+ +
RewriteRule "(.*\.(jpg|gif|png))$" "http://images.example.com$1" [P,NC]
+ +
top
+
+

NE|noescape

+

Par défaut, les caractères spéciaux, comme & et +?, sont convertis en leur équivalent hexadécimal pour les règles +qui génèrent des redirections externes. Le drapeau [NE] permet d'éviter cette +conversion.

+ +
RewriteRule "^/anchor/(.+)" "/bigpage.html#$1" [NE,R]
+ + +

+Dans l'exemple ci-dessus, /anchor/xyz est réécrit en +/bigpage.html#xyz. En l'absence du drapeau [NE], le # +aurait été converti en son équivalent hexadécimal, %23, ce +qui aurait provoqué un code d'erreur "404 Not Found". +

+ +
top
+
+

NS|nosubreq

+

Le drapeau [NS] empêche la règle de s'appliquer aux sous-requêtes. +Par exemple, une page incluse au moyen d'une SSI (Server +Side Include) est une sous-requête, et vous ne voudrez probablement pas que +la réécriture s'applique à ces sous-requêtes. Ainsi, lorsque +mod_dir recherche des informations à propos des +fichiers par défaut du répertoire (comme les fichiers +index.html), il s'agit d'une sous-requête interne, et vous +ne désirez en général pas que ces sous-requêtes soient réécrites. Cette +réécriture +n'est pas toujours utile pour les sous-requêtes, et peut même causer des +erreurs si l'ensemble du jeu de règles est appliqué. L'utilisation de +ce drapeau permet d'exclure les règles qui peuvent poser problème.

+ +

Comment déterminer si vous devez utiliser cette règle ou non : si +vous préfixez les URLs avec des scripts CGI, afin de forcer leur +traitement par le script CGI, vous vous exposez à des problèmes (ou du +moins à une surcharge significative) avec les sous-requêtes. Dans ces +cas, vous devez utiliser ce drapeau.

+ +

+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. +

+
top
+
+

P|proxy

+

L'utilisation du drapeau [P] entraîne le traitement de la requête par +le module mod_proxy, et ceci via une requête de +mandataire. Par exemple, si vous voulez que toutes les requêtes d'images +soient traitées par un serveur d'images annexe, vous pouvez utiliser +une règle de ce style :

+ +
RewriteRule "/(.*)\.(jpg|gif|png)$" "http://images.example.com/$1.$2" [P]
+ + +

L'utilisation du drapeau [P] provoque aussi l'effet du drapeau [L] - +autrement dit, la requête est immédiatement envoyée au mandataire, et +toute règle ultérieure sera ignorée.

+ +

+Vous devez vous assurer que la chaîne de substitution soit un URI 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. +L'utilisation de ce drapeau implémente de manière plus puissante la +directive ProxyPass, pour +faire correspondre le contenu distant à l'espace de nommage du serveur +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.

+
+ +
+

Avertissement au sujet des performances

+

Utiliser ce drapeau fait intervenir mod_proxy sans la gestion des connexions + persistantes, ce qui signifie que vous obtiendrez des performances meilleurs si vous utilisez + ProxyPass ou ProxyPassMatch.

+

Ceci est du au fait que ce drapeau induit l'utilisation du worker par défaut, qui + ne gère pas la mise en commun et la réutilisation des connexions.

+

Partout où cela est possible, préférez l'utilisation de ces directives.

+
+ +

Note: mod_proxy doit être activé pour pouvoir +utiliser ce drapeau.

+ +
top
+
+

PT|passthrough

+ +

+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 +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 +chemins de fichiers, comme la directive Alias, Redirect, ou ScriptAlias, par exemple, puissent avoir une +chance d'accomplir leur tâche. +

+ +

+Si par exemple, vous avez un Alias pour /icons, et une règle RewriteRule qui renvoie vers /icons, +vous devez utiliser le drapeau [PT] pour être sûr que l'Alias sera bien évalué. +

+ +
Alias "/icons" "/usr/local/apache/icons"
+RewriteRule "/pics/(.+)\.jpg$" "/icons/$1.gif" [PT]
+ + +

+Dans l'exemple précédent, en l'absence du drapeau [PT], l'Alias aurait +été ignoré, ce qui aurait provoqué une erreur 'File not found'. +

+ +

Avec le drapeau PT, le drapeau L est +implicite : la réécriture s'arrêtera afin de transmettre la requête à la +phase suivante du traitement.

+ +

Notez que le drapeau PT est implicite dans des contextes +de répertoire comme les sections <Directory> ou les fichiers +.htaccess. Le seul moyen de contourner ceci consiste à +réécrire vers -.

+ +
top
+
+

QSA|qsappend

+

+Quand l'URI 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 +méthode HTTP GET) existante, et de la remplacer par celle nouvellement créée. +Avec le drapeau [QSA], les chaînes de requête peuvent être combinées. +

+ +

Considérons la règle suivante :

+ +
RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]
+ + +

Avec le drapeau [QSA], une requête pour +/pages/123?one=two sera réécrite en +/page.php?page=123&one=two. Sans le drapeau [QSA], la +même requête sera réécrite en /page.php?page=123 - +autrement dit, la chaîne de requête (query string) existante sera supprimée. +

+
top
+
+

QSD|qsdiscard

+

+Lorsque l'URI 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 +de paramètres est supprimée. +

+ +

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

+ +

+Lorsque les drapeaux [QSD] et [QSA] sont utilisés ensemble, c'est le +drapeau [QSD] qui l'emporte. +

+ +

+Si l'URI 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. +

+ +
top
+
+

QSL|qslast

+

+Par défaut, le premier (le plus à gauche) point d'interrogation de la +substitution sépare le chemin de la requête de sa chaîne de paramètres. Avec le +drapeau [QSL] au contraire, les deux composants seront séparés en utilisant le +dernier (le plus à droite) point d'interrogation.

+ +

+Cela peut s'avérer utile lorsqu'on recherche un fichier dont le nom contient des +points d'interrogation. Si aucune chaîne de paramètre n'est présente dans la +substitution, il est alors possible d'ajouter un point d'interrogation à la fin +et d'utiliser ce drapeau.

+ +

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

+ +
top
+
+

R|redirect

+

+L'utilisation du drapeau [R] provoque l'envoi d'une redirection au +navigateur. Si une URL pleinement qualifiée (FQDN - fully qualified domain name) + est spécifiée (c'est à dire incluant http://nom-du-serveur/), + une redirection sera effectuée vers cette adresse. Dans le cas contraire, + le protocole courant, le nom du serveur et le numéro de port seront + utilisés pour générer l'URL envoyée avec la redirection. +

+ +

Tout code de statut de réponse HTTP valide peut être +spécifié, en utilisant la syntaxe [R=305], le code de statut 302 étant +utilisé par défaut si aucun code n'est spécifié. Le code de statut +spécifié n'est pas nécessairement un code de statut +de redirection (3xx). Cependant, si le code de statut est en dehors de la plage des codes de +redirection (300-399), la chaîne de substitution est entièrement +supprimée, et la réécriture s'arrête comme si le drapeau L +était utilisé.

+ +

En plus des codes de statut de réponse, vous pouvez spécifier les +codes de redirection en utilisant leurs noms symboliques : +temp (défaut), permanent, ou +seeother.

+ +

+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 +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'. +

+ +
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.

+
# La requête concerne-t-elle un fichier qui n'existe pas ?
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+# Si c'est la cas, on saute les deux règles de réécriture suivantes
+RewriteRule ".?"                  "-" [S=2]
+
+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 +qu'une directive RewriteCond s'applique à plusieurs règles +RewriteRule, une technique possible consiste à inverser ces +conditions et ajouter une RewriteRule avec le drapeau [Skip]. Cette technique permet +d'élaborer des pseudo-constructions if-then-else : la dernière règle du +bloc then contiendra skip=N, où N est le nombre de règles +contenues dans le bloc else :

+
# Est-ce que le fichier existe ?
+RewriteCond "%{REQUEST_FILENAME}" !-f
+RewriteCond "%{REQUEST_FILENAME}" !-d
+# Créer une structure conditionnelle if-then-else en sautant 3 lignes si nous
+# avions l'intention d'aller au bloc "else".
+RewriteRule ".?"                  "-" [S=3]
+
+# Si le fichier existe, alors :
+    RewriteRule "(.*\.gif)"  "images.php?$1"
+    RewriteRule "(.*\.html)" "docs.php?$1"
+    # Passer le bloc "else".
+    RewriteRule ".?"         "-" [S=1]
+# ELSE...
+    RewriteRule "(.*)"       "404.php?file=$1"
+# END
+ + +

Il est probablement plus aisé de définir ce genre de configuration +via les directives <If>, <ElseIf>, et <Else>.

+ +
top
+
+

T|type

+

Définit le type MIME de la réponse résultante renvoyée. L'effet est +identique à celui de la directive AddType.

+ +

Par exemple, vous pouvez utiliser la technique suivante pour servir +du code source Perl en tant que plein texte, s'il est requis d'une +certaine manière :

+ +
# Sert les fichier .pl en tant que plein texte
+RewriteRule "\.pl$"  "-" [T=text/plain]
+ + +

Ou encore, si vous possédez une caméra qui produit des fichiers +images jpeg sans extension, vous pouvez forcer le renvoi de ces images +avec le type MIME correct en se basant sur le nom du fichier :

+ +
# Les fichiers dont le nom contient 'IMG' sont des images jpg.
+RewriteRule "IMG"  "-" [T=image/jpg]
+ + +

Notez cependant qu'il s'agit d'un exemple trivial, et que le problème +aurait pu être résolu en utilisant à la place la directive <FilesMatch>. Il faut toujours +envisager la possibilité d'une solution alternative à un problème avant +d'avoir recours à la réécriture, qui sera toujours moins efficace qu'une +solution alternative.

+ +

+Dans un contexte de niveau répertoire, n'utilisez que - +(tiret) comme substitution, dans toute la séquence de réécriture de +mod_rewrite, sinon le type MIME défini avec ce drapeau +sera perdu suite à un retraitement interne (y compris les séquences de +réécriture suivantes de mod_rewrite). Dans ce contexte, vous pouvez +utiliser le drapeau L pour terminer la séquence +courante de réécriture de mod_rewrite.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/htaccess.html b/docs/manual/rewrite/htaccess.html new file mode 100644 index 0000000..848460b --- /dev/null +++ b/docs/manual/rewrite/htaccess.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: htaccess.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: htaccess.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/htaccess.html.en b/docs/manual/rewrite/htaccess.html.en new file mode 100644 index 0000000..82ba78c --- /dev/null +++ b/docs/manual/rewrite/htaccess.html.en @@ -0,0 +1,66 @@ + + + + + +mod_rewrite and .htaccess files - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

mod_rewrite and .htaccess files

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It describes +the way that the rules change when you use mod_rewrite in .htaccess files, +and how to deal with these changes.

+ +
+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/htaccess.html.fr.utf8 b/docs/manual/rewrite/htaccess.html.fr.utf8 new file mode 100644 index 0000000..c44d1cb --- /dev/null +++ b/docs/manual/rewrite/htaccess.html.fr.utf8 @@ -0,0 +1,67 @@ + + + + + +mod_rewrite et les fichiers .htaccess - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

mod_rewrite et les fichiers .htaccess

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

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.

+ +
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/index.html b/docs/manual/rewrite/index.html new file mode 100644 index 0000000..fa23ff6 --- /dev/null +++ b/docs/manual/rewrite/index.html @@ -0,0 +1,17 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: index.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: index.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 + +URI: index.html.tr.utf8 +Content-Language: tr +Content-type: text/html; charset=UTF-8 + +URI: index.html.zh-cn.utf8 +Content-Language: zh-cn +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/index.html.en b/docs/manual/rewrite/index.html.en new file mode 100644 index 0000000..fb6fc6a --- /dev/null +++ b/docs/manual/rewrite/index.html.en @@ -0,0 +1,96 @@ + + + + + +Apache mod_rewrite - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache mod_rewrite

+
+

Available Languages:  en  | + fr  | + tr  | + zh-cn 

+
+ + +

mod_rewrite provides a way to modify incoming + URL requests, dynamically, based on regular + expression rules. This allows you to map arbitrary URLs onto + your internal URL structure in any way you like.

+ +

It supports an unlimited number of rules and an + unlimited number of attached rule conditions for each rule to + provide a really flexible and powerful URL manipulation + mechanism. The URL manipulations can depend on various tests: + server variables, environment variables, HTTP + headers, time stamps, external database lookups, and various other + external programs or handlers, can be used to achieve granular URL + matching.

+ +

Rewrite rules can operate on the full URLs, including the path-info + and query string portions, and may be used in per-server context + (httpd.conf), per-virtualhost context (<VirtualHost> blocks), or + per-directory context (.htaccess files and <Directory> blocks). The + rewritten result can lead to further rules, internal + sub-processing, external request redirection, or proxy + passthrough, depending on what flags you + attach to the rules.

+ +

Since mod_rewrite is so powerful, it can indeed be rather + complex. This document supplements the reference documentation, and + attempts to allay some of that complexity, and provide highly + annotated examples of common scenarios that you may handle with + mod_rewrite. But we also attempt to show you when you should not + use mod_rewrite, and use other standard Apache features instead, + thus avoiding this unnecessary complexity.

+ + + +
+ +
+
+

Available Languages:  en  | + fr  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/index.html.fr.utf8 b/docs/manual/rewrite/index.html.fr.utf8 new file mode 100644 index 0000000..a180a6d --- /dev/null +++ b/docs/manual/rewrite/index.html.fr.utf8 @@ -0,0 +1,110 @@ + + + + + +Le module Apache mod_rewrite - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Le module Apache mod_rewrite

+
+

Langues Disponibles:  en  | + fr  | + tr  | + zh-cn 

+
+ + +

mod_rewrite permet de modifier les requêtes + entrantes dynamiquement, en fonction de règles manipulant des expressions rationnelles. Vous pouvez + ainsi relier des URLs arbitraires à votre propre structure d'URLs + interne comme vous le souhaitez.

+ +

Il fournit un + mécanisme de manipulation d'URL particulièrement souple et + puissant en supportant un nombre illimité de règles et de + conditions attachées à chaque règle. Les manipulations d'URLs + peuvent dépendre de tests variés : les URLs peuvent + être finement caractérisées en fonction de variables du serveur, + de variables d'environnement, d'en-têtes HTTP, de repères + temporels, de recherches dans des bases de données + externes, ou même de requêtes vers des bases de données externes + et de différents gestionnaires ou programmes externes.

+ +

Les règles de réécriture peuvent agir sur l'ensemble des URLs (la partie chemin + et la chaîne de paramètres) et peuvent être utilisées dans le contexte du serveur principal + (httpd.conf), mais aussi dans le contexte des + serveurs virtuels (sections <VirtualHost>), ou dans le + contexte des + répertoires (fichiers .htaccess et blocs + <Directory>. Le résultat + réécrit peut conduire vers d'autres règles à un + traitement secondaire interne, une redirection vers une requête + externe ou même l'envoi vers un serveur mandataire, en fonction + des drapeaux que vous attachez aux + règles

+ +

mod_rewrite étant très puissant, il peut par + conséquent être très complexe. Ce document + complète la documentation de + référence du module mod_rewrite, et est sensé alléger un + peu cette complexité, et présenter des exemples largement + commentés, ainsi que des situations courantes que vous + pourrez traiter avec mod_rewrite. Mais nous voulons aussi vous + montrer des situations où vous ne devrez pas utiliser + mod_rewrite, et lui préférer d'autres + fonctionnalités standard d'Apache, évitant ainsi + d'entrer dans une complexité inutile.

+ + +
+ +
+
+

Langues Disponibles:  en  | + fr  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/index.html.tr.utf8 b/docs/manual/rewrite/index.html.tr.utf8 new file mode 100644 index 0000000..ddbe388 --- /dev/null +++ b/docs/manual/rewrite/index.html.tr.utf8 @@ -0,0 +1,91 @@ + + + + + +Apache mod_rewrite - Apache HTTP Sunucusu Sürüm 2.4 + + + + + + +
+

Modüller | Yönergeler | SSS | Terimler | Site Haritası

+

Apache HTTP Sunucusu Sürüm 2.4

+
+
<-
+

Apache mod_rewrite

+
+

Mevcut Diller:  en  | + fr  | + tr  | + zh-cn 

+
+ +

mod_rewrite modülü gelen URL isteklerinde değişiklik + yapabilmek için düzenli ifade kurallarına + dayalı, devingen bir yol sunar. Böylece, keyfi URL'leri dahili URL + yapınızla kolayca eşleyebilirsiniz.

+ +

Gerçekten esnek ve güçlü bir URL kurgulama mekanizması oluşturmak için + sınısız sayıda kural ve her kural için de sınırsız sayıda koşul destekler. + URL değişiklikleri çeşitli sınamalara dayanır; sunucu değişkenleri, HTTP + başlıkları, ortam değişkenleri, zaman damgaları hatta çeşitli biçimlerde + harici veritabanı sorguları bile bu amaçla kullanılabilir.

+ +

Yeniden yazma kuralları URL’lerin tamamında (path-info kısmı ve sorgu + dizgesi dahil) hem sunucu bağlamında (httpd.conf) hem sanal + konaklar bağlamında (<VirtualHost> bölümleri), hem de dizin bağlamında + (.htaccess dosyaları ve <Directory> + bölümleri) çalışır ve URL üzerinde sorgu dizgesi bölümleri bile + oluşturabilir. Kurallara atadığınız seçeneklere + bağlı olarak, yeniden yazılan URL sonuçta dahili işlemlerde, harici + yönlendirmelerde ve vekalet işlemlerinde kullanılabilir.

+ +

mod_rewrite modülü çok güçlü olduğundan, gerçekten çok + karmaşık olabilir. Bu belge, başvuru + belgelerinin tamamlayıcısı olup karmaşıklığı biraz azaltmaya çalışır + ve mod_rewrite ile elde edilebilen ortak senaryoların + oldukça açıklamalı örneklerini sağlar. Fakat ayrıca, + mod_rewrite modülünü kullanmamanız, yerine standart + Apache özelliklerini kullanmanız gereken durumları da göstermeye, + böylece gereksiz karmaşıklıktan kurtulmanızı sağlamaya çalıştık.

+ + +
+ +
+
+

Mevcut Diller:  en  | + fr  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/index.html.zh-cn.utf8 b/docs/manual/rewrite/index.html.zh-cn.utf8 new file mode 100644 index 0000000..2191a4d --- /dev/null +++ b/docs/manual/rewrite/index.html.zh-cn.utf8 @@ -0,0 +1,80 @@ + + + + + +Apache mod_rewrite - Apache HTTP 服务器 版本 2.4 + + + + + + +
+

模块 | 指令 | 常见问题 | 术语 | 网站导航

+

Apache HTTP 服务器版本 2.4

+
+
<-
+

Apache mod_rewrite

+
+

可用语言:  en  | + fr  | + tr  | + zh-cn 

+
+
此翻译可能过期。要了解最近的更改，请阅读英文版。
+ +

mod_rewrite 提供了基于正则表达式规则动态修改传入的请求的 URL 的方法。 + 这允许你以自己喜欢的任意方法映射任意 URL 到你的内部 URL 结构。

+ +

它支持无限的规则，以及为每个规则附加条件，从而提供了一个真正灵活且强大的 URL + 操作机制。URL 操作可以依赖于各种测试，例如服务器变量，环境变量，HTTP + 头，时戳，甚至外部数据库查询等，以便完成 URL 单元匹配。

+ +

这个模块在服务器上下文 (httpd.conf)，虚拟主机上下文 (<VirtualHost> 指令块)，目录上下文 + (.htaccess 文件和 <Directory> + 指令块) 对完整的 URL (包含目录信息部分和查询字符串部分) 操作。 + 重写结果可以导致新的规则处理，内部的后续处理，外部请求重定向，甚至透过内部代理， + 这取决于你为规则附加的标志。

+ +

既然 mod_rewrite 这么强大，它当然是相当复杂。这篇文档作为参考手册的补充，试图减轻一些复杂性， + 提供你可能使用 mod_rewrite 的常见场景的有充分注释的例子。 + 但是，我们也试图告诉你，在什么时候你不应当使用 mod_rewrite， + 可以使用其它标准的 Apache 特性来达到目的，以避免无谓的复杂性。

+ + +
+ +
+
+

可用语言:  en  | + fr  | + tr  | + zh-cn 

+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/intro.html b/docs/manual/rewrite/intro.html new file mode 100644 index 0000000..53af197 --- /dev/null +++ b/docs/manual/rewrite/intro.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: intro.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: intro.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/intro.html.en b/docs/manual/rewrite/intro.html.en new file mode 100644 index 0000000..a612af9 --- /dev/null +++ b/docs/manual/rewrite/intro.html.en @@ -0,0 +1,400 @@ + + + + + +Apache mod_rewrite Introduction - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache mod_rewrite Introduction

+
+

Available Languages:  en  | + fr 

+
+ +

This document supplements the mod_rewrite +reference documentation. It +describes the basic concepts necessary for use of +mod_rewrite. Other documents go into greater detail, +but this doc should help the beginner get their feet wet. +

+
+ +
top
+
+

Introduction

+

The Apache module mod_rewrite is a very powerful and +sophisticated module which provides a way to do URL manipulations. With +it, you can do nearly all types of URL rewriting that you may need. It +is, however, somewhat complex, and may be intimidating to the beginner. +There is also a tendency to treat rewrite rules as magic incantation, +using them without actually understanding what they do.

+ +

This document attempts to give sufficient background so that what +follows is understood, rather than just copied blindly. +

+ +

Remember that many common URL-manipulation tasks don't require the +full power and complexity of mod_rewrite. For simple +tasks, see mod_alias and the documentation +on mapping URLs to the +filesystem.

+ +

Finally, before proceeding, be sure to configure +mod_rewrite's log level to one of the trace levels using +the LogLevel directive. Although this +can give an overwhelming amount of information, it is indispensable in +debugging problems with mod_rewrite configuration, since +it will tell you exactly how each rule is processed.

+ +
top
+
+

Regular Expressions

+ +

mod_rewrite uses the Perl Compatible +Regular Expression vocabulary. In this document, we do not attempt +to provide a detailed reference to regular expressions. For that, we +recommend the PCRE man pages, the +Perl regular +expression man page, and Mastering +Regular Expressions, by Jeffrey Friedl.

+ +

In this document, we attempt to provide enough of a regex vocabulary +to get you started, without being overwhelming, in the hope that +RewriteRules will be scientific +formulae, rather than magical incantations.

+ +

Regex vocabulary

+ +

The following are the minimal building blocks you will need, in order +to write regular expressions and RewriteRules. They certainly do not +represent a complete regular expression vocabulary, but they are a good +place to start, and should help you read basic regular expressions, as +well as write your own.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CharacterMeaningExample
.Matches any single characterc.t will match cat, cot, + cut, etc
+Repeats the previous match one or more timesa+ matches a, aa, + aaa, etc
*Repeats the previous match zero or more timesa* matches all the same things a+ matches, + but will also match an empty string
?Makes the match optionalcolou?r will match color and + colour
\Escape the next character\. will match . (dot) and not any single + character as explain above
^Called an anchor, matches the beginning of the string^a matches a string that begins with a
$The other anchor, this matches the end of the stringa$ matches a string that ends with a
( )Groups several characters into a single unit, and captures a match + for use in a backreference(ab)+ matches ababab - that is, the + + applies to the group. For more on backreferences see + below
[ ]A character class - matches one of the charactersc[uoa]t matches cut, cot or + cat
[^ ]Negative character class - matches any character not specifiedc[^/]t matches cat or c=t but + not c/t
+ +

In mod_rewrite the ! character can be +used before a regular expression to negate it. This is, a string will +be considered to have matched only if it does not match the rest of +the expression.

+ + + +

Regex Back-Reference Availability

+ +

One important thing here has to be remembered: Whenever you + use parentheses in Pattern or in one of the + CondPattern, back-references are internally created + which can be used with the strings $N and + %N (see below). These are available for creating + the Substitution parameter of a + RewriteRule or + the TestString parameter of a + RewriteCond.

+

Captures in the RewriteRule patterns are (counterintuitively) available to + all preceding + RewriteCond directives, + because the RewriteRule + expression is evaluated before the individual conditions.

+ +

Figure 1 shows to which + locations the back-references are transferred for expansion as + well as illustrating the flow of the RewriteRule, RewriteCond + matching. In the next chapters, we will be exploring how to use + these back-references, so do not fret if it seems a bit alien + to you at first. +

+ +

+ Flow of RewriteRule and RewriteCond matching
+ Figure 1: The back-reference flow through a rule.
+ In this example, a request for /test/1234 would be transformed into /admin.foo?page=test&id=1234&host=admin.example.com. +

+ + +
top
+
+

RewriteRule Basics

+

A RewriteRule consists +of three arguments separated by spaces. The arguments are

+
    +
  1. Pattern: which incoming URLs should be affected by the rule;
    2. +
  2. Substitution: where should the matching requests be sent;
    3. +
  3. [flags]: options affecting the rewritten request.
    4. +
+ +

The Pattern is a regular expression. +It is initially (for the first rewrite rule or until a substitution occurs) +matched against the URL-path of the incoming request (the part after the +hostname but before any question mark indicating the beginning of a query +string) or, in per-directory context, against the request's path relative +to the directory for which the rule is defined. Once a substitution has +occurred, the rules that follow are matched against the substituted +value. +

+ +

+ Syntax of the RewriteRule directive
+ Figure 2: Syntax of the RewriteRule directive. +

+ + +

The Substitution can itself be one of three things:

+ +
+
1. A full filesystem path to a resource
+
+
RewriteRule "^/games" "/usr/local/games/web/puzzles.html"
+ +

This maps a request to an arbitrary location on your filesystem, much +like the Alias directive.

+
+ +
2. A web-path to a resource
+
+
RewriteRule "^/games$" "/puzzles.html"
+ +

If DocumentRoot is set +to /usr/local/apache2/htdocs, then this directive would +map requests for http://example.com/games to the +path /usr/local/apache2/htdocs/puzzles.html.

+ +
+ +
3. An absolute URL
+
+
RewriteRule "^/product/view$" "http://site2.example.com/seeproduct.html" [R]
+ +

This tells the client to make a new request for the specified URL.

+
+
+ +
Note that 1 and 2 have exactly the same syntax. The difference between them is that in the case of 1, the top level of the target path (i.e., /usr/) exists on the filesystem, where as in the case of 2, it does not. (i.e., there's no /bar/ as a root-level directory in the filesystem.)
+ +

The Substitution can also +contain back-references to parts of the incoming URL-path +matched by the Pattern. Consider the following:

+
RewriteRule "^/product/(.*)/view$" "/var/web/productdb/$1"
+ +

The variable $1 will be replaced with whatever text +was matched by the expression inside the parenthesis in +the Pattern. For example, a request +for http://example.com/product/r14df/view will be mapped +to the path /var/web/productdb/r14df.

+ +

If there is more than one expression in parenthesis, they are +available in order in the +variables $1, $2, $3, and so +on.

+ + +
top
+
+

Rewrite Flags

+

The behavior of a RewriteRule can be modified by the +application of one or more flags to the end of the rule. For example, the +matching behavior of a rule can be made case-insensitive by the +application of the [NC] flag: +

+
RewriteRule "^puppy.html" "smalldog.html" [NC]
+ + +

For more details on the available flags, their meanings, and +examples, see the Rewrite Flags document.

+ +
top
+
+

Rewrite Conditions

+

One or more RewriteCond +directives can be used to restrict the types of requests that will be +subject to the +following RewriteRule. The +first argument is a variable describing a characteristic of the +request, the second argument is a regular +expression that must match the variable, and a third optional +argument is a list of flags that modify how the match is evaluated.

+ +

+ Syntax of the RewriteCond directive
+ Figure 3: Syntax of the RewriteCond directive +

+ +

For example, to send all requests from a particular IP range to a +different server, you could use:

+
RewriteCond "%{REMOTE_ADDR}" "^10\.2\."
+RewriteRule "(.*)"           "http://intranet.example.com$1"
+ + +

When more than +one RewriteCond is +specified, they must all match for +the RewriteRule to be +applied. For example, to deny requests that contain the word "hack" in +their query string, unless they also contain a cookie containing +the word "go", you could use:

+
RewriteCond "%{QUERY_STRING}" "hack"
+RewriteCond "%{HTTP_COOKIE}"  !go
+RewriteRule "."               "-"   [F]
+ +

Notice that the exclamation mark specifies a negative match, so the rule is only applied if the cookie does not contain "go".

+ +

Matches in the regular expressions contained in +the RewriteConds can be +used as part of the Substitution in +the RewriteRule using the +variables %1, %2, etc. For example, this +will direct the request to a different directory depending on the +hostname used to access the site:

+
RewriteCond "%{HTTP_HOST}" "(.*)"
+RewriteRule "^/(.*)"       "/sites/%1/$1"
+ +

If the request was for http://example.com/foo/bar, +then %1 would contain example.com +and $1 would contain foo/bar.

+ + + +
top
+
+

Rewrite maps

+ +

The RewriteMap directive +provides a way to call an external function, so to speak, to do your +rewriting for you. This is discussed in greater detail in the RewriteMap supplementary documentation.

+
top
+
+

.htaccess files

+ +

Rewriting is typically configured in the main server configuration +setting (outside any <Directory> section) or +inside <VirtualHost> +containers. This is the easiest way to do rewriting and is +recommended. It is possible, however, to do rewriting +inside <Directory> +sections or .htaccess +files at the expense of some additional complexity. This technique +is called per-directory rewrites.

+ +

The main difference with per-server rewrites is that the path +prefix of the directory containing the .htaccess file is +stripped before matching in +the RewriteRule. In addition, the RewriteBase should be used to assure the request is properly mapped.

+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/intro.html.fr.utf8 b/docs/manual/rewrite/intro.html.fr.utf8 new file mode 100644 index 0000000..6497b7a --- /dev/null +++ b/docs/manual/rewrite/intro.html.fr.utf8 @@ -0,0 +1,426 @@ + + + + + +Introduction au module Apache mod_rewrite - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Introduction au module Apache mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ +

Ce document est un complément à la documentation de référence du module +mod_rewrite. Il décrit les concepts de base dont la +connaissance est nécessaire pour l'utilisation de +mod_rewrite. D'autres documents entrent d'avantage dans +les détails, mais celui-ci devrait aider le débutant à se mouiller les +pieds. +

+
+ +
top
+
+

Introduction

+

Le module Apache mod_rewrite est un module puissant +et sophistiqué qui permet la réécriture des URLs. Grâce à lui, vous +pouvez effectuer quasiment tous les types de réécriture d'URLs dont vous +avez besoin. Il est cependant assez complexe, et peut paraître +intimidant au débutant. Certains ont aussi tendance à traiter les +règles de réécriture comme des incantations magiques, et à les utiliser +sans vraiment comprendre leur manière d'agir.

+ +

Ce document a pour ambition d'être suffisamment explicite pour +permettre la compréhension, et non la copie en aveugle, de ce qui suit. +

+ +

Gardez à l'esprit que de nombreuses tâches de manipulation d'URLs +courantes n'ont pas besoin de la puissance et de la complexité de +mod_rewrite. Pour les tâches simples, voir +mod_alias et la documentation sur la Mise en correspondance des URLs avec le +système de fichiers.

+ +

Enfin, avant de procéder, assurez-vous d'avoir configuré le niveau de +journalisation de mod_rewrite à un des niveaux de trace +via la directive LogLevel. Bien que +ceci risque de vous submerger sous une énorme quantité d'informations, +le débogage des problèmes avec la configuration de +mod_rewrite est à ce prix car vous verrez alors +exactement comment chaque règle est traitée.

+ +
top
+
+

Expressions rationnelles

+ +

mod_rewrite utilise le vocabulaire des Expressions rationnelles compatibles Perl. +Ce document n'a pas pour prétention d'être une référence détaillée des +expressions rationnelles. A cet effet, nous recommandons les pages de manuel de PCRE, la page de manuel des +expressions rationnelles Perl, et l'ouvrage Mastering +Regular Expressions, by Jeffrey Friedl.

+ +

Dans ce document, nous avons pour but de vous fournir suffisamment de +vocabulaire des expressions rationnelles pour vous mettre le pied à +l'étrier, sans être dépassé, en espérant que les directives RewriteRule vous apparaîtront comme des +formules scientifiques, plutôt que comme des incantations magiques.

+ +

Vocabulaire des expressions rationnelles

+ +

Vous trouverez dans ce qui suit le minimum à connaître pour être en +mesure d'écrire des expressions rationnelles et des règles RewriteRule. Ceci ne représente +certainement pas un vocabulaire des expressions rationnelles complet, +mais constitue un bon point de départ, et devrait vous aider à +déchiffrer les expressions rationnelles simples, et à écrire vos propres +expressions.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MotifSignificationExemple
.Correspond à tout caractère uniquec.t correspondra à cat, + cot, cut, etc.
+Répète le caractère de correspondance précédent une ou plusieurs foisa+ correspond à a, aa, + aaa, etc.
*Répète le caractère de correspondance + précédent zéro ou plusieurs foisa* correspond à tout ce à quoi correspond + a+, mais correspond aussi à la chaîne vide.
?Rend la correspondance optionnelle.colou?r correspondra à color et colour.
\Echappe le caractère suivant\. correspondra à . (le point) et non à + tout caractère unique comme expliqué plus haut
^Appelé ancrage, correspond au début de la + chaîne^a correspond à une chaîne qui commence par + a
$L'autre ancrage, correspond à la fin de + la chaîne.a$ correspond à une chaîne qui se termine par + a.
( )Regroupe plusieurs caractères en une + seule entité, et conserve une correspondance à des fins d'utilisation + dans une référence arrière.(ab)+ + correspond à ababab - à savoir, le + + s'applique au groupe. + Pour plus de détails sur les références arrières, voir ci-dessous.
[ ]Une classe de caractères - correspond à + un des caractères de la classec[uoa]t correspond à cut, + cot ou cat.
[^ ]Négation de la classe de caractères - + correspond à tout caractère ne faisant pas partie de la classec[^/]t correspond à cat ou + c=t mais pas à c/t
+ +

Avec mod_rewrite, le caractère ! peut +préfixer une expression rationnelle afin d'en exprimer la négation. +Autrement dit, une chaîne ne correspondra que si elle ne correspond pas +à l'expression située après le !.

+ + + +

Disponibilité des références +arrières dans les expressions rationnelles

+ +

Vous devez vous souvenir d'une chose importante : chaque fois + que vous utilisez des parenthèses dans un Modèle ou dans + un des modèles de conditions, des références arrières + sont créées en interne et peuvent être rappelées via les chaînes + $N et %N (voir ci-dessous). Ces + références sont disponibles lors de la + création de la chaîne de substitution d'une directive + RewriteRule ou de la + chaîne de test d'une directive RewriteCond.

+

Les captures dans les modèles de directives RewriteRule sont paradoxalement + disponibles dans toutes les directives RewriteCond qui précèdent, car + les expressions des directives RewriteRule sont évaluées avant + les conditions individuelles.

+ +

La figure 1 montre à quels endroits les + références arrières sont suceptibles + d'être développées, et illustre le flux des comparaisons + effectuées par les règles RewriteRule et + RewriteCond. Dans les chapitres suivants, nous examinerons comment + utiliser ces références arrières, donc ne vous affolez pas si + elles vous paraissent un peu exotiques au premier abord.

+ +

+ Flux des comparaisons effectuées par les règles RewriteRule et RewriteCond
+ Figure 1 : Le cheminement d'une référence arrière à + travers une règle.
+ Dans cet exemple, une requête pour /test/1234 serait + transformée en + /admin.foo?page=test&id=1234&host=admin.example.com. +

+ + +
top
+
+

Les bases des règles de réécriture

+

Une règle de réécriture RewriteRule est constituée de trois +arguments séparés par des espaces. Les arguments sont :

+
    +
  1. Modèle: le modèle des URLs auxquelles la règle doit +s'appliquer;
    2. +
  2. Substitution: vers quoi la requête correspondante doit être +transformée;
    3. +
  3. [drapeaux]: options affectant la requête réécrite.
    4. +
+ +

Le Modèle est une expression +rationnelle. Au sein de la première règle de réécriture, ou jusqu'à +ce qu'une substitution survienne, elle est comparée au chemin de +l'URL de la requête entrante (la +partie située après le nom d'hôte mais avant tout point d'interrogation +qui indique le début d'une chaîne de paramètres de +requête) ou, dans un contexte de répertoire, au chemin de la +requête relativement au répertoire pour lequel la +règle est définie. Lorsqu'une substitution a eu lieu, les +règles suivantes effectuent leurs comparaisons par rapport à la valeur +substituée.

+ +

+ Syntaxe de la directive RewriteRule
+ Figure 2 : Syntaxe de la directive RewriteRule. +

+ +

La chaîne de Substitution peut, quant à elle, être de +trois types :

+ +
+
1. Un chemin complet du système de fichiers vers une ressource
+
+
RewriteRule "^/games" "/usr/local/games/web/puzzles.html"
+ +

Ceci peut faire correspondre une requête à toute localisation voulue de +votre système de fichiers, un peu comme la directive Alias.

+
+ +
2. Un chemin web vers une ressource
+
+
RewriteRule "^/games$" "/puzzles.html"
+ +

Si la directive DocumentRoot a +pour valeur /usr/local/apache2/htdocs, cette règle va faire +correspondre les requêtes pour http://example.com/games au +chemin /usr/local/apache2/htdocs/puzzles.html.

+
+ +
3. Une URL absolue
+
+
RewriteRule "^/produits/vues$" "http://site2.example.com/voirproduits.html" [R]
+ +

Ceci informe le client qu'il doit effectuer une nouvelle requête vers +l'URL spécifiée.

+
+
+ +
Notez que 1 et 2 +possèdent exactement la même syntaxe. Par contre, dans le cas de +1, le niveau racine du chemin cible (par exemple +/usr/) existe dans le système de fichiers, alors que ce n'est pas +le cas avec 2 (par exemple, il n'y a pas de répertoire +/bar/ au niveau de la racine du système de fichiers).
+ +

La chaîne de Substitution peut aussi contenir des +références arrières vers des parties du chemin d'URL entrant +correspondant au Modèle. Considérons ce qui suit :

+
RewriteRule "^/produits/(.*)/view$" "/var/web/produitsdb/$1"
+ +

La variable $1 sera remplacée par tout texte +correspondant à l'expression située entre les parenthèses dans le +Modèle. Par exemple, une requête pour +http://example.com/produits/r14df/vue correspondra au +chemin /var/web/produitsdb/r14df.

+ +

S'il y a plus d'une expression entre parenthèses, elle seront +accessibles selon leur ordre d'apparition via les variables +$1, $2, $3, etc...

+ + +
top
+
+

Drapeaux de réécriture

+

Le comportement d'une règle RewriteRule peut être modifié par la +présence d'un ou plusieurs drapeaux en fin de règle. Par exemple, les +conditions de correspondance d'une règle peuvent être rendues +insensibles à la casse par la présence du drapeau [NC] : +

+
RewriteRule "^puppy.html" "petitchien.html" [NC]
+ + +

Pour une liste des drapeaux disponibles, leurs significations, et des +exemples, voir le document Drapeaux de +réécriture.

+ +
top
+
+

Conditions de réécriture

+

Il est possible d'utiliser une ou plusieurs directives RewriteCond pour restreindre les types +de requêtes auxquelles devra s'appliquer la règle RewriteRule suivante. Le premier +argument est une variable décrivant une caractéristique de la requête, +le second argument est une expression rationnelle +qui doit correspondre à la variable, et un troisième argument optionnel +est une liste de drapeaux qui modifient la manière dont la +correspondance est évaluée.

+ +

+ Syntaxe de la directive RewriteCond
+ Figure 3 : Syntaxe de la directive RewriteCond +

+ + +

Par exemple, pour renvoyer toutes les requêtes en provenance d'une +certaine tranche d'adresses IP vers un autre serveur, vous pouvez +utiliser :

+
RewriteCond "%{REMOTE_ADDR}" "^10\.2\."
+RewriteRule "(.*)"           "http://intranet.example.com$1"
+ + +

Si vous spécifiez plus d'une directive RewriteCond, ces directives +doivent toutes être satisfaites pour que la règle RewriteRule suivante s'applique. Par exemple, +pour interdire les requêtes qui contiennent le mot "hack" dans la chaîne +de requête, sauf si elles contiennent aussi un cookie contenant le mot +"go", vous pouvez utiliser :

+
RewriteCond "%{QUERY_STRING}" "hack"
+RewriteCond "%{HTTP_COOKIE}"  !go
+RewriteRule "."               "-"   [F]
+ +

Notez que le point d'exclamation indique une correspondance négative +; ainsi, la règle n'est appliquée que si le cookie ne contient pas "go"

+ +

Les correspondances dans les expressions rationnelles contenues dans +les directives RewriteCond +peuvent constituer des parties de la chaîne de Substitution +de la règle RewriteRule via +les variables %1, %2, etc... Par +exemple, ce qui suit va diriger la requête vers un répertoire différent +en fonction du nom d'hôte utilisé pour accéder au site :

+
RewriteCond "%{HTTP_HOST}" "(.*)"
+RewriteRule "^/(.*)"       "/sites/%1/$1"
+ +

Si la requête concernait http://example.com/foo/bar, +alors %1 contiendrait example.com et +$1 contiendrait foo/bar.

+ + + +
top
+
+

Tables de réécriture

+ +

La directive RewriteMap +permet en quelque sorte de faire appel à une fonction externe pour +effectuer la réécriture à votre place. Tout ceci est décrit plus en +détails dans la Documentation +supplémentaire sur RewriteMap.

+
top
+
+

Fichiers .htaccess

+ +

La réécriture est en général définie au niveau de la configuration du +serveur principal (en dehors de toute section <Directory>) ou dans une section <VirtualHost>. Il s'agit là de la +manière la plus simple de mettre en oeuvre la réécriture et nous la +recommandons. Il est possible, cependant, de mettre en oeuvre la +réécriture au sein d'une section <Directory> ou d'un fichier .htaccess ; ce type de +configuration est cependant plus complexe. Cette technique est appelée +réécriture par répertoire.

+ +

La principale différence avec les réécritures au niveau du serveur réside +dans le fait que le préfixe du chemin du répertoire contenant le fichier +.htaccess est supprimé avant la mise en correspondance dans +la règle RewriteRule. De +plus, on doit utiliser la directive RewriteBase pour s'assurer que la +requête est correctement mise en correspondance.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/proxy.html b/docs/manual/rewrite/proxy.html new file mode 100644 index 0000000..7e5a578 --- /dev/null +++ b/docs/manual/rewrite/proxy.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: proxy.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: proxy.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/proxy.html.en b/docs/manual/rewrite/proxy.html.en new file mode 100644 index 0000000..a32b9ed --- /dev/null +++ b/docs/manual/rewrite/proxy.html.en @@ -0,0 +1,119 @@ + + + + + +Using mod_rewrite for Proxying - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Using mod_rewrite for Proxying

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It describes +how to use the RewriteRule's [P] flag to proxy content to another server. +A number of recipes are provided that describe common scenarios.

+ +
+ +
top
+
+

Proxying Content with mod_rewrite

+ + + +
+
Description:
+ +
+

+ mod_rewrite provides the [P] flag, which allows URLs to be passed, + via mod_proxy, to another server. Two examples are given here. In + one example, a URL is passed directly to another server, and served + as though it were a local URL. In the other example, we proxy + missing content to a back-end server.

+
+ +
Solution:
+ +
+

To simply map a URL to another server, we use the [P] flag, as + follows:

+ +
RewriteEngine  on
+RewriteBase    "/products/"
+RewriteRule    "^widget/(.*)$"  "http://product.example.com/widget/$1"  [P]
+ProxyPassReverse "/products/widget/" "http://product.example.com/widget/"
+ + +

In the second example, we proxy the request only if we can't find + the resource locally. This can be very useful when you're migrating + from one server to another, and you're not sure if all the content + has been migrated yet.

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

In each case, we add a ProxyPassReverse directive to ensure + that any redirects issued by the backend are correctly passed on to + the client.

+ +

Consider using either ProxyPass or ProxyPassMatch whenever possible in + preference to mod_rewrite.

+
+
+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/proxy.html.fr.utf8 b/docs/manual/rewrite/proxy.html.fr.utf8 new file mode 100644 index 0000000..db74411 --- /dev/null +++ b/docs/manual/rewrite/proxy.html.fr.utf8 @@ -0,0 +1,124 @@ + + + + + +Utilisation de mod_rewrite comme mandataire - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Utilisation de mod_rewrite comme mandataire

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément de la documentation de référence du module +mod_rewrite. Il décrit comment utiliser le drapeau [P] +de la directive RewriteRule pour mandater un contenu vers un autre +serveur. Plusieurs recettes décrivant des scénarios courants sont +fournies.

+ +
+ +
top
+
+

Mandater du contenu avec mod_rewrite

+ + + +
+
Description :
+ +
+

+ mod_rewrite implémente le drapeau [P] qui permet de passer des URLs, + via mod_proxy, à un autre serveur. Deux exemples sont fournis ici. + Dans le premier, une URL est passée directement à un autre serveur, + et servie comme si c'était une URL locale. Dans le deuxième, nous + mandatons un contenu manquant vers un serveur d'arrière-plan.

+
+ +
Solution :
+ +
+

Pour passer une URL à un autre serveur, on utilise le drapeau + [P] comme suit :

+ +
RewriteEngine  on
+RewriteBase    "/produits/"
+RewriteRule    "^widget/(.*)$"  "http://produits.example.com/widget/$1"  [P]
+ProxyPassReverse "/produits/objet/" "http://produits.example.com/objet/"
+ + +

Dans le deuxième exemple, nous ne mandatons la requête que si nous + ne trouvons pas la ressource localement. Ceci peut s'avérer très + utile lorsque vous effectuez une migration d'un serveur vers un + autre, et que vous n'êtes pas certain que tout le contenu a déjà été + migré.

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

Dans les deux cas, on ajoute une directive ProxyPassReverse afin de s'assurer + que toute redirection en provenance du serveur d'arrière-plan est + renvoyée correctement au client.

+ +

Chaque fois que cela est possible, préférez l'utilisation de la + directive ProxyPass ou + ProxyPassMatch à + mod_rewrite.

+
+
+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/remapping.html b/docs/manual/rewrite/remapping.html new file mode 100644 index 0000000..c60c397 --- /dev/null +++ b/docs/manual/rewrite/remapping.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: remapping.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: remapping.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/remapping.html.en b/docs/manual/rewrite/remapping.html.en new file mode 100644 index 0000000..9b8670d --- /dev/null +++ b/docs/manual/rewrite/remapping.html.en @@ -0,0 +1,697 @@ + + + + + +Redirecting and Remapping with mod_rewrite - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Redirecting and Remapping with mod_rewrite

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It describes +how you can use mod_rewrite to redirect and remap +request. This includes many examples of common uses of mod_rewrite, +including detailed descriptions of how each works.

+ +
Note that many of these examples won't work unchanged in your +particular server configuration, so it's important that you understand +them, rather than merely cutting and pasting the examples into your +configuration.
+ +
+ +
top
+
+

From Old to New (internal)

+ + + +
+
Description:
+ +
+

Assume we have recently renamed the page + foo.html to bar.html and now want + to provide the old URL for backward compatibility. However, + we want that users of the old URL even not recognize that + the pages was renamed - that is, we don't want the address to + change in their browser.

+
+ +
Solution:
+ +
+

We rewrite the old URL to the new one internally via the + following rule:

+ +
RewriteEngine  on
+RewriteRule    "^/foo\.html$"  "/bar.html" [PT]
+ +
+
+ +
top
+
+

Rewriting From Old to New (external)

+ + + +
+
Description:
+ +
+

Assume again that we have recently renamed the page + foo.html to bar.html and now want + to provide the old URL for backward compatibility. But this + time we want that the users of the old URL get hinted to + the new one, i.e. their browsers Location field should + change, too.

+
+ +
Solution:
+ +
+

We force a HTTP redirect to the new URL which leads to a + change of the browsers and thus the users view:

+ +
RewriteEngine  on
+RewriteRule    "^/foo\.html$"  "bar.html"  [R]
+ +
+ +
Discussion
+ +
+

In this example, as contrasted to the internal example above, we can simply + use the Redirect directive. mod_rewrite was used in that earlier + example in order to hide the redirect from the client:

+ + 
Redirect "/foo.html" "/bar.html"
+ + +
+
+ +
top
+
+

Resource Moved to Another Server

+ + + +
+
Description:
+ +
+

If a resource has moved to another server, you may wish to have + URLs continue to work for a time on the old server while people + update their bookmarks.

+
+ +
Solution:
+ +
+

You can use mod_rewrite to redirect these URLs + to the new server, but you might also consider using the Redirect + or RedirectMatch directive.

+ +
#With mod_rewrite
+RewriteEngine on
+RewriteRule   "^/docs/(.+)"  "http://new.example.com/docs/$1"  [R,L]
+ + +
#With RedirectMatch
+RedirectMatch "^/docs/(.*)" "http://new.example.com/docs/$1"
+ + +
#With Redirect
+Redirect "/docs/" "http://new.example.com/docs/"
+ +
+
+ +
top
+
+

From Static to Dynamic

+ + + +
+
Description:
+ +
+

How can we transform a static page + foo.html into a dynamic variant + foo.cgi in a seamless way, i.e. without notice + by the browser/user.

+
+ +
Solution:
+ +
+

We just rewrite the URL to the CGI-script and force the + handler to be cgi-script so that it is + executed as a CGI program. + This way a request to /~quux/foo.html + internally leads to the invocation of + /~quux/foo.cgi.

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

Backward Compatibility for file extension change

+ + + +
+
Description:
+ +
+

How can we make URLs backward compatible (still + existing virtually) after migrating document.YYYY + to document.XXXX, e.g. after translating a + bunch of .html files to .php?

+
+ +
Solution:
+ +
+

We rewrite the name to its basename and test for + existence of the new extension. If it exists, we take + that name, else we rewrite the URL to its original state.

+ +
#   backward compatibility ruleset for
+#   rewriting document.html to document.php
+#   when and only when document.php exists
+<Directory "/var/www/htdocs">
+    RewriteEngine on
+    RewriteBase "/var/www/htdocs"
+
+    RewriteCond "$1.php" -f
+    RewriteCond "$1.html" !-f
+    RewriteRule "^(.*).html$" "$1.php"
+</Directory>
+ +
+ +
Discussion
+
+

This example uses an often-overlooked feature of mod_rewrite, + by taking advantage of the order of execution of the ruleset. In + particular, mod_rewrite evaluates the left-hand-side of the + RewriteRule before it evaluates the RewriteCond directives. + Consequently, $1 is already defined by the time the RewriteCond + directives are evaluated. This allows us to test for the existence + of the original (document.html) and target + (document.php) files using the same base filename.

+ +

This ruleset is designed to use in a per-directory context (In a + <Directory> block or in a .htaccess file), so that the + -f checks are looking at the correct directory path. + You may need to set a RewriteBase directive to specify the + directory base that you're working in.

+
+
+ +
top
+
+

Canonical Hostnames

+ + + +
+
Description:
+ +
The goal of this rule is to force the use of a particular + hostname, in preference to other hostnames which may be used to + reach the same site. For example, if you wish to force the use + of www.example.com instead of + example.com, you might use a variant of the + following recipe.
+ +
Solution:
+ +
+ +

The very best way to solve this doesn't involve mod_rewrite at all, +but rather uses the Redirect +directive placed in a virtual host for the non-canonical +hostname(s).

+ +
<VirtualHost *:80>
+  ServerName undesired.example.com
+  ServerAlias example.com notthis.example.com
+
+  Redirect "/" "http://www.example.com/"
+</VirtualHost>
+
+<VirtualHost *:80>
+  ServerName www.example.com
+</VirtualHost>
+ + +

You can alternatively accomplish this using the +<If> +directive:

+ +
<If "%{HTTP_HOST} != 'www.example.com'">
+    Redirect "/" "http://www.example.com/"
+</If>
+ + +

Or, for example, to redirect a portion of your site to HTTPS, you +might do the following:

+ +
<If "%{SERVER_PROTOCOL} != 'HTTPS'">
+    Redirect "/admin/" "https://www.example.com/admin/"
+</If>
+ + +

If, for whatever reason, you still want to use mod_rewrite +- if, for example, you need this to work with a larger set of RewriteRules - +you might use one of the recipes below.

+ +

For sites running on a port other than 80:

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

And for a site running on port 80

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

+ If you wanted to do this generically for all domain names - that + is, if you want to redirect example.com to + www.example.com for all possible values of + example.com, you could use the following + recipe:

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

These rulesets will work either in your main server configuration + file, or in a .htaccess file placed in the DocumentRoot of the server.

+
+
+ +
top
+
+

Search for pages in more than one directory

+ + + +
+
Description:
+ +
+

A particular resource might exist in one of several places, and + we want to look in those places for the resource when it is + requested. Perhaps we've recently rearranged our directory + structure, dividing content into several locations.

+
+ +
Solution:
+ +
+

The following ruleset searches in two directories to find the + resource, and, if not finding it in either place, will attempt to + just serve it out of the location requested.

+ +
RewriteEngine on
+
+#   first try to find it in dir1/...
+#   ...and if found stop and be happy:
+RewriteCond         "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}"  -f
+RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir1/$1"  [L]
+
+#   second try to find it in dir2/...
+#   ...and if found stop and be happy:
+RewriteCond         "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}"  -f
+RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir2/$1"  [L]
+
+#   else go on for other Alias or ScriptAlias directives,
+#   etc.
+RewriteRule   "^"  "-"  [PT]
+ +
+
+ +
top
+
+

Redirecting to Geographically Distributed Servers

+ + + +
+
Description:
+ +
+

We have numerous mirrors of our website, and want to redirect + people to the one that is located in the country where they are + located.

+
+ +
Solution:
+ +
+

Looking at the hostname of the requesting client, we determine + which country they are coming from. If we can't do a lookup on their + IP address, we fall back to a default server.

+

We'll use a RewriteMap + directive to build a list of servers that we wish to use.

+ +
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]
+ + +

+## map.mirrors -- Multiplexing Map
+
+de http://www.example.de/
+uk http://www.example.uk/
+com http://www.example.com/
+##EOF## +

+
+ +
Discussion
+
+
This ruleset relies on + HostNameLookups + being set on, which can be + a significant performance hit.
+ +

The RewriteCond + directive captures the last portion of the hostname of the + requesting client - the country code - and the following RewriteRule + uses that value to look up the appropriate mirror host in the map + file.

+
+
+ +
top
+
+

Browser Dependent Content

+ + + +
+
Description:
+ +
+

We wish to provide different content based on the browser, or + user-agent, which is requesting the content.

+
+ +
Solution:
+ +
+

We have to decide, based on the HTTP header "User-Agent", + which content to serve. The following config + does the following: If the HTTP header "User-Agent" + contains "Mozilla/3", the page foo.html + is rewritten to foo.NS.html and the + rewriting stops. If the browser is "Lynx" or "Mozilla" of + version 1 or 2, the URL becomes foo.20.html. + All other browsers receive page foo.32.html. + This is done with the following ruleset:

+ +
RewriteCond "%{HTTP_USER_AGENT}"  "^Mozilla/3.*"
+RewriteRule "^foo\.html$"         "foo.NS.html"          [L]
+
+RewriteCond "%{HTTP_USER_AGENT}"  "^Lynx/" [OR]
+RewriteCond "%{HTTP_USER_AGENT}"  "^Mozilla/[12]"
+RewriteRule "^foo\.html$"         "foo.20.html"          [L]
+
+RewriteRule "^foo\.html$"         "foo.32.html"          [L]
+ +
+
+ +
top
+
+

Canonical URLs

+ + + +
+
Description:
+ +
+

On some webservers there is more than one URL for a + resource. Usually there are canonical URLs (which are be + actually used and distributed) and those which are just + shortcuts, internal ones, and so on. Independent of which URL the + user supplied with the request, they should finally see the + canonical one in their browser address bar.

+
+ +
Solution:
+ +
+

We do an external HTTP redirect for all non-canonical + URLs to fix them in the location view of the Browser and + for all subsequent requests. In the example ruleset below + we replace /puppies and /canines + by the canonical /dogs.

+ +
RewriteRule   "^/(puppies|canines)/(.*)"    "/dogs/$2"  [R]
+ +
+ +
Discussion:
+
+ This should really be accomplished with Redirect or RedirectMatch + directives: + + 
RedirectMatch "^/(puppies|canines)/(.*)" "/dogs/$2"
+ +
+
+ +
top
+
+

Moved DocumentRoot

+ + + +
+
Description:
+ +
+

Usually the DocumentRoot +of the webserver directly relates to the URL "/". +But often this data is not really of top-level priority. For example, +you may wish for visitors, on first entering a site, to go to a +particular subdirectory /about/. This may be accomplished +using the following ruleset:

+
+ +
Solution:
+ +
+

We redirect the URL / to + /about/: +

+ +
RewriteEngine on
+RewriteRule   "^/$"  "/about/"  [R]
+ + +

Note that this can also be handled using the RedirectMatch directive:

+ +
RedirectMatch "^/$" "http://example.com/about/"
+ + +

Note also that the example rewrites only the root URL. That is, it +rewrites a request for http://example.com/, but not a +request for http://example.com/page.html. If you have in +fact changed your document root - that is, if all of +your content is in fact in that subdirectory, it is greatly preferable +to simply change your DocumentRoot +directive, or move all of the content up one directory, +rather than rewriting URLs.

+
+
+ +
top
+
+

Fallback Resource

+ + +
+
Description:
+
You want a single resource (say, a certain file, like index.php) to +handle all requests that come to a particular directory, except those +that should go to an existing resource such as an image, or a css file.
+ +
Solution:
+
+

As of version 2.2.16, you should use the FallbackResource directive for this:

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

However, in earlier versions of Apache, or if your needs are more +complicated than this, you can use a variation of the following rewrite +set to accomplish the same thing:

+ +
<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>
+ + +

If, on the other hand, you wish to pass the requested URI as a query +string argument to index.php, you can replace that RewriteRule with:

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

Note that these rulesets can be used in a .htaccess +file, as well as in a <Directory> block.

+ +
+ +
+ +
top
+
+

Rewrite query string

+ + +
+
Description:
+
You want to capture a particular value from a query string +and either replace it or incorporate it into another component +of the URL.
+ +
Solutions:
+
+

Many of the solutions in this section will all use the same condition, +which leaves the matched value in the %2 backreference. %1 is the beginining +of the query string (up to the key of intererest), and %3 is the remainder. This +condition is a bit complex for flexibility and to avoid double '&&' in the +substitutions.

+
    +
  • This solution removes the matching key and value: + +
    # Remove mykey=???
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1?%1%3"
    + +
    • + +
  • This solution uses the captured value in the URL substitution, + discarding the rest of the original query by appending a '?': + +
    # Copy from query string to PATH_INFO
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1/products/%2/?" [PT]
    + +
    • + +
  • This solution checks the captured value in a subsequent condition: + +
    # Capture the value of mykey in the query string
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteCond "%2" !=not-so-secret-value 
+RewriteRule "(.*)" - [F]
    + +
    • + +
  • This solution shows the reverse of the previous ones, copying + path components (perhaps PATH_INFO) from the URL into the query string. +
    # The desired URL might be /products/kitchen-sink, and the script expects
+# /path?products=kitchen-sink.
+RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]
    + +
    • +
+ +
+ +
+
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/remapping.html.fr.utf8 b/docs/manual/rewrite/remapping.html.fr.utf8 new file mode 100644 index 0000000..7b0bf03 --- /dev/null +++ b/docs/manual/rewrite/remapping.html.fr.utf8 @@ -0,0 +1,717 @@ + + + + + +Redirection et remise en correspondance avec mod_rewrite - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Redirection et remise en correspondance avec mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la Documentation de référence de +mod_rewrite. Il montre comment utiliser +mod_rewrite pour rediriger et remettre en +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.
+ +
+ +
top
+
+

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

+ + + +
+
Description :
+ +
+

Supposons que nous ayons récemment renommé la page + foo.html en bar.html, et voulions + maintenant que l'ancienne URL soit toujours valide à des fins + de compatibilité ascendante. En fait, on voudrait que le + changement de nom soit transparent aux utilisateurs de + l'ancienne URL.

+
+ +
Solution :
+ +
+

On réécrit l'ancienne URL en interne vers la nouvelle via + la règle suivante :

+ +
RewriteEngine  on
+RewriteRule    "^/foo\.html$" "/bar.html" [PT]
+ +
+
+ +
top
+
+

De l'ancien au nouveau (en externe)

+ + + +
+
Description :
+ +
+

Supposons toujours que nous ayons récemment renommé la page + foo.html en bar.html, et voulions + maintenant que l'ancienne URL soit toujours valide à des fins + de compatibilité ascendante. En revanche, nous voulons cette + fois que la nouvelle URL soit suggérée aux utilisateurs de + l'ancienne URL, c'est à dire que l'adresse vue depuis leur + navigateur doit également être modifiée.

+
+ +
Solution :
+ +
+

On force une redirection HTTP vers la nouvelle URL, ce qui + entraîne une modification de celle du navigateur et aussi de ce + que voit l'utilisateur :

+ +
RewriteEngine  on
+RewriteRule    "^foo\.html$"  "bar.html"  [R]
+ +
+ +
Discussion
+ +
+

Dans l'exemple interne, on a utilisé mod_rewrite afin + de dissimuler la redirection au client. Dans cet exemple, en + revanche, on aurait pu se contenter d'une directive Redirect :

+ + 
Redirect "/foo.html" "/bar.html"
+ + +
+
+ +
top
+
+

Ressource déplacée vers un autre serveur

+ + + +
+
Description :
+ +
+

Si une ressource a été déplacée vers un autre serveur, vous + pouvez faire en sorte que les URLs de l'ancien serveur continuent + de fonctionner pendant un certain temps, afin de laisser au + utilisateurs le temps de modifier leurs favoris.

+
+ +
Solution :
+ +
+

Vous pouvez utiliser mod_rewrite pour + rediriger ces URLs vers le nouveau serveur, mais vous pouvez aussi + utiliser les directives Redirect ou RedirectMatch.

+ +
#Avec mod_rewrite
+RewriteEngine on
+RewriteRule   "^/docs/(.+)"  "http://nouveau.example.com/docs/$1"  [R,L]
+ + +
#Avec RedirectMatch
+RedirectMatch "^/docs/(.*)" "http://nouveau.example.com/docs/$1"
+ + +
#Avec Redirect
+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 :
+ +
+

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]
+ +
+
+ +
top
+
+

Compatibilité ascendante dans le cadre d'une modification + d'extension de nom de fichier

+ + + +
+
Description :
+ +
+

Comment conférer une compatibilité ascendante aux URLs + (existant encore virtuellement) après avoir migré + document.YYYY vers document.XXXX, + c'est à dire après avoir par exemple traduit un lot de + fichiers .html en fichiers .php + ?

+
+ +
Solution :
+ +
+

On réécrit simplement le nom du fichier en son nom + de base et vérifie s'il existe aussi avec la nouvelle + extension. Si c'est le cas, on utilise ce nom, sinon on + réécrit l'URL sous sa forme originale.

+ + +
#   jeu de règles assurant une compatibilité ascendante en réécrivant

+#   document.html en document.php si et seulement si document.php

+#   existe
+<Directory "/var/www/htdocs">
+    RewriteEngine on
+    RewriteBase "/var/www/htdocs"
+
+    RewriteCond "$1.php" -f
+    RewriteCond "$1.html" !-f
+    RewriteRule "^(.*).html$" "$1.php"
+</Directory>
+ +
+ +
Discussion
+
+

Cet exemple utilise une fonctionnalité souvent méconnue de + mod_rewrite, en tirant avantage de l'ordre d'exécution du jeu de + règles. En particulier, mod_rewrite évalue la partie gauche des + règles de réécriture avant d'évaluer les directives RewriteCond. En + conséquence, $1 est déjà défini au moment où les directives + RewriteCond sont évaluées. Ceci nous permet de tester l'existence du + fichier original (document.html) et du fichier cible + (document.php) en utilisant le même nom de base.

+ +

Ce jeu de règles est conçu pour une utilisation dans un contexte + de répertoire (au sein d'une section <Directory> ou d'un + fichier .htaccess), de façon à ce que les vérifications + -f effectuent leurs recherches dans le bon répertoire. + Vous serez peut-être amené à définir une directive RewriteBase pour spécifier le + répertoire de base à partir duquel vous travaillez.

+
+
+ +
top
+
+

Noms d'hôtes canoniques

+ + + +
+
Description :
+ +
Le but de cette règle est de préférer l'utilisation d'un nom + d'hôte particulier à d'autres noms d'hôte utilisables + pour atteindre le même site. Par exemple, si vous voulez + utiliser www.example.com à la place de + example.com, vous pouvez utiliser une solution + du style :
+ +
Solution :
+ +
+ +

Pour y parvenir, il vaut mieux se passer de mod_rewrite, et utiliser +plutôt la directive Redirect dans +une section de serveur virtuel pour le/les noms d'hôte non canoniques.

+ +
<VirtualHost *:80>
+  ServerName undesired.example.com
+  ServerAlias example.com notthis.example.com
+
+  Redirect "/" "http://www.example.com/"
+</VirtualHost>
+
+<VirtualHost *:80>
+  ServerName www.example.com
+</VirtualHost>
+ + +

Vous pouvez aussi utiliser la directive <If> :

+ +
<If "%{HTTP_HOST} != 'www.example.com'">
+	Redirect "/" "http://www.example.com/"
+</If>
+ + +

Ou, par exemple, pour rediriger une portion de votre site vers HTTPS +:

+ +
<If "%{SERVER_PROTOCOL} != 'HTTPS'">
+	Redirect "/admin/" "https://www.example.com/admin/"
+</If>
+ + +

Si, pour une raison particulière, vous voulez tout de même utiliser +mod_rewrite - dans le cas, par exemple, où vous avez besoin +d'un jeu plus important de règles de réécritures - vous pouvez utiliser +la recette suivante :

+ +

Pour les sites écoutant sur un port autre que 80:

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

Et pour un site écoutant sur le port 80

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

+ Si vous souhaitez que cette règle s'applique à tous les noms de + domaine - en d'autres termes, si vous voulez rediriger + example.com vers + www.example.com pour toutes les valeurs + possibles de example.com, vous pouvez utiliser + le jeu de règles suivants :

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

+ Vous pouvez utiliser ce jeu de règles aussi bien dans le fichier + de configuration de votre serveur principal que dans un fichier + .htaccess placé dans le répertoire défini par la + directive DocumentRoot du serveur.

+
+
+ +
top
+
+

Recherche de pages dans plus d'un répertoire

+ + + +
+
Description:
+ +
+

Une ressource peut exister dans plusieurs répertoires, et nous + voulons rechercher cette ressource dans ces répertoires + lorsqu'elle fait l'objet d'une requête. Il est possible que nous + ayons récemment réorganisé la structure de notre site en + répartissant son contenu dans plusieurs répertoires.

+
+ +
Solution :
+ +
+

Le jeu de règles suivant recherche la ressource dans deux + répertoires, et s'il ne la trouve dans aucun des deux, il tentera + simplement de la servir à partir de l'adresse fournie dans la + requête.

+ +
RewriteEngine on
+
+#   on cherche tout d'abord dans dir1/...
+#   ... et si on trouve, on est content et on arrête :
+RewriteCond         "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}"  -f
+RewriteRule  "^(.+)"  "%{DOCUMENT_ROOT}/dir1/$1"  [L]
+
+#   on cherche ensuite dans dir2/...
+#   ... et si on trouve, on est content et on arrête :
+RewriteCond         "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}"  -f
+RewriteRule  "^(.+)"  "%{DOCUMENT_ROOT}/dir2/$1"  [L]
+
+#   sinon, on continue la recherche avec d'autres directives Alias
+#   ou ScriptAlias, etc...
+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## +

+
+ +
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.

+
+
+ +
top
+
+

Contenu dépendant du navigateur

+ + + +
+
Description :
+ +
+

Nous voulons fournir des contenus différents en fonction du + navigateur (user-agent) qui effectue la requête.

+
+ +
Solution :
+ +
+

Nous devons déterminer quel contenu servir, en nous basant + sur l'en-tête HTTP "User-Agent". La + configuration suivante effectue ceci : si l'en-tête HTTP + "User-Agent" commence par "Mozilla/3", le nom de la page + foo.html est réécrit en foo.NS.html + et la réécriture s'arrête. Si le navigateur est "Lynx" ou + "Mozilla" version 1 ou 2, l'URL devient + foo.20.html. Tous les autres navigateurs + reçoivent la page foo.32.html. Tout ceci est + effectué par le jeu de règles suivant :

+
RewriteCond "%{HTTP_USER_AGENT}"  "^Mozilla/3.*"
+RewriteRule "^foo\.html$"         "foo.NS.html"          [L]
+
+RewriteCond "%{HTTP_USER_AGENT}"  "^Lynx/" [OR]
+RewriteCond "%{HTTP_USER_AGENT}"  "^Mozilla/[12]"
+RewriteRule "^foo\.html$"         "foo.20.html"          [L]
+
+RewriteRule "^foo\.html$"         "foo.32.html"          [L]
+ +
+
+ +
top
+
+

URLs canoniques

+ + + +
+
Description :
+ +
+

Sur certains serveurs, une ressource peut posséder plusieurs + URLs. Il y a en général les URLs canoniques (celles qui sont + réellement distribuées et utilisées), et celles qui correspondent à + des raccourcis, les URLs internes, etc... Quelle que soit l'adresse + que l'utilisateur fournit dans la requête, il devrait finalement + voir l'URL canonique dans la barre d'adresse de son navigateur.

+
+ +
Solution :
+ +
+

Nous effectuons une redirection HTTP externe pour toutes les + URLs non canoniques afin de les corriger dans la barre d'adresse + du navigateur, et ceci pour toutes les requêtes futures. Dans le + jeu de règles suivant, nous remplaçons /matous et + /minettes par le canonique /chats.

+ + 
RewriteRule   "^/(matous|minettes)/(.*)"    "/chats/$2"  [R]
+ +
+ +
Discussion :
+
On serait mieux inspiré d'utiliser ici les directives Redirect ou + RedirectMatch : + + 
RedirectMatch "^/(matous|minettes)/(.*)" "/chats/$2"
+ +
+
+ +
top
+
+

Déplacement du répertoire DocumentRoot

+ + + +
+
Description :
+ +
+

En général, le répertoire DocumentRoot du serveur web correspond à l'URL +"/". Ce répertoire ne contient cependant pas forcément des +ressources de première importance pour l'utilisateur. Par exemple, vous +préférerez peut-être que le répertoire d'accueil d'un visiteur accédant +pour la première fois à votre site soit un répertoire particulier +/a-propos-de/. Pour y parvenir, utilisez le jeu de règles +suivant :

+
+ +
Solution :
+ +
+

On redirige l'URL / vers + /a-propos-de/ : +

+ +
RewriteEngine on
+RewriteRule   "^/$"  "/a-propos-de/"  [R]
+ + +

Notez que l'on peut aussi y parvenir en utilisant la directive +RedirectMatch :

+ +
RedirectMatch "^/$" "http://example.com/a-propos-de/"
+ + +

Notez aussi que cet exemple ne réécrit que l'URL racine. En d'autres +termes, il réécrit une requête pour http://example.com/, +mais pas pour une requête http://example.com/page.html. Si +vous avez effectivement modifié la racine de vos documents - c'est à dire +si tous vos contenus se trouvent dans un +sous-répertoire, il est largement préférable de modifier simplement +votre directive DocumentRoot, ou de +déplacer l'ensemble du contenu vers le répertoire supérieur, plutôt que +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

+ + +
+
Description :
+
Vous voulez extraire une valeur particulière d'une chaîne de +paramètres d'une URL, et soit la remplacer, soit l'incorporer dans un +autre composant de l'URL.
+ +
Solutions :
+
+

Dans la plupart des solutions de cette section, on utilise la même +condition qui stocke la valeur recherchée dans la référence arrière %2. +%1 est le début de la requête, et %3 ce qui reste. Cette condition est +un peu complexe car elle introduit de la flexibilité et évite les +doubles perluettes '&&' dans les substitutions.

+
    +
  • Cette solution supprime le couple clé/valeur recherché : + +
    # Remove mykey=???
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1?%1%3"
    + +
    • + +
  • Cette solution remplace la partie de l'URL qui suit la valeur + recherchée par un '?' : + +
    # Copy from query string to PATH_INFO
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$"
+RewriteRule "(.*)" "$1/products/%2/?" [PT]
    + +
    • + +
  • Cette solution utilise la valeur recherchée dans une deuxième + condition :: + +
    # Capture the value of mykey in the query string
+RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$""
+RewriteCond "%2" !=not-so-secret-value 
+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 
+# /path?products=kitchen-sink.
+RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT]
    + +
    • +
+ +
+ +
+
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/rewritemap.html b/docs/manual/rewrite/rewritemap.html new file mode 100644 index 0000000..c5925e3 --- /dev/null +++ b/docs/manual/rewrite/rewritemap.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: rewritemap.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: rewritemap.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/rewritemap.html.en b/docs/manual/rewrite/rewritemap.html.en new file mode 100644 index 0000000..1f7c8dd --- /dev/null +++ b/docs/manual/rewrite/rewritemap.html.en @@ -0,0 +1,481 @@ + + + + + +Using RewriteMap - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Using RewriteMap

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It describes +the use of the RewriteMap directive, +and provides examples of each of the various RewriteMap types.

+ +
Note that many of these examples won't work unchanged in your +particular server configuration, so it's important that you understand +them, rather than merely cutting and pasting the examples into your +configuration.
+ +
+ +
top
+
+

Introduction

+ + +

+ The RewriteMap directive + defines an external function which can be called in the context of + RewriteRule or + RewriteCond directives to + perform rewriting that is too complicated, or too specialized to be + performed just by regular expressions. The source of this lookup can + be any of the types listed in the sections below, and enumerated in + the RewriteMap reference + documentation.

+ +

The syntax of the RewriteMap + directive is as follows:

+ +
RewriteMap MapName MapType:MapSource
+
+ + +

The MapName is an + arbitrary name that you assign to the map, and which you will use in + directives later on. Arguments are passed to the map via the + following syntax:

+ +

+ + ${ MapName : LookupKey + }
${ MapName : + LookupKey | DefaultValue } + +

+ +

When such a construct occurs, the map MapName is + consulted and the key LookupKey is looked-up. If the + key is found, the map-function construct is substituted by + SubstValue. If the key is not found then it is + substituted by DefaultValue or by the empty string + if no DefaultValue was specified.

+ +

For example, you can define a + RewriteMap as:

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

You would then be able to use this map in a + RewriteRule as follows:

+ 
RewriteRule "^/ex/(.*)" "${examplemap:$1}"
+ + +

A default value can be specified in the event that nothing is found +in the map:

+ +
RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}"
+ + +

Per-directory and .htaccess context

+

+The RewriteMap directive may not be +used in <Directory> sections or +.htaccess files. You must +declare the map in server or virtualhost context. You may use the map, +once created, in your RewriteRule and +RewriteCond directives in those +scopes. You just can't declare it in those scopes.

+
+ +

The sections that follow describe the various MapTypes that +may be used, and give examples of each.

+
top
+
+

int: Internal Function

+ + +

When a MapType of int is used, the MapSource is one + of the available internal RewriteMap + functions. Module authors can provide + additional internal functions by registering them with the + ap_register_rewrite_mapfunc API. + The functions that are provided by default are: +

+ +
    +
  • toupper:
    + Converts the key to all upper case.
    • +
  • tolower:
    + Converts the key to all lower case.
    • +
  • escape:
    + Translates special characters in the key to + hex-encodings.
    • +
  • unescape:
    + Translates hex-encodings in the key back to + special characters.
    • +
+ +

+ To use one of these functions, create a RewriteMap referencing + the int function, and then use that in your RewriteRule: +

+ +

Redirect a URI to an all-lowercase version of itself

+ 
RewriteMap lc int:tolower
+RewriteRule "(.*)" "${lc:$1}" [R]
+ + +
+

Please note that the example offered here is for + illustration purposes only, and is not a recommendation. If you want + to make URLs case-insensitive, consider using + mod_speling instead. +

+
+ +
top
+
+

txt: Plain text maps

+ + +

When a MapType of txt is used, the MapSource is a filesystem path to a + plain-text mapping file, containing one space-separated key/value pair + per line. Optionally, a line may contain a comment, starting with + a '#' character.

+ +

A valid text rewrite map file will have the following syntax:

+ +

+ # Comment line
+ MatchingKey SubstValue
+ MatchingKey SubstValue # comment
+

+ +

When the RewriteMap is invoked + the argument is looked for in the + first argument of a line, and, if found, the substitution value is + returned.

+ +

For example, we can use a mapfile to translate product names to + product IDs for easier-to-remember URLs, using the following + recipe:

+

Product to ID configuration

+ 
RewriteMap product2id "txt:/etc/apache2/productmap.txt"
+RewriteRule "^/product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
+ + +

We assume here that the prods.php script knows what + to do when it received an argument of id=NOTFOUND when + a product is not found in the lookup map.

+ +

The file /etc/apache2/productmap.txt then contains + the following:

+ +

Product to ID map

+##
+## productmap.txt - Product to ID map file
+##
+
+television 993
+stereo 198
+fishingrod 043
+basketball 418
+telephone 328 +

+ +

Thus, when http://example.com/product/television is + requested, the RewriteRule is + applied, and the request + is internally mapped to /prods.php?id=993.

+ +

Note: .htaccess files

+ The example given is crafted to be used in server or virtualhost + scope. If you're planning to use this in a .htaccess + file, you'll need to remove the leading slash from the rewrite + pattern in order for it to match anything: + 
RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
+ +
+ +

Cached lookups

+

+ The looked-up keys are cached by httpd until the mtime + (modified time) of the mapfile changes, or the httpd server is + restarted. This ensures better performance on maps that are called + by many requests. +

+
+ +
top
+
+

rnd: Randomized Plain Text

+ + +

When a MapType of rnd is used, the MapSource is a + filesystem path to a plain-text mapping file, each line of which + contains a key, and one or more values separated by |. + One of these values will be chosen at random if the key is + matched.

+ +

For example, you can use the following map + file and directives to provide a random load balancing between + several back-end servers, via a reverse-proxy. Images are sent + to one of the servers in the 'static' pool, while everything + else is sent to one of the 'dynamic' pool.

+ +

Rewrite map file

+##
+## map.txt -- rewriting map
+##
+
+static www1|www2|www3|www4
+dynamic www5|www6 +

+

Configuration directives

+ 
RewriteMap servers "rnd:/path/to/file/map.txt"
+
+RewriteRule "^/(.*\.(png|gif|jpg))" "http://${servers:static}/$1"  [NC,P,L]
+RewriteRule "^/(.*)"                "http://${servers:dynamic}/$1" [P,L]
+ + +

So, when an image is requested and the first of these rules is + matched, RewriteMap looks up the string + static in the map file, which returns one of the + specified hostnames at random, which is then used in the + RewriteRule target.

+ +

If you wanted to have one of the servers more likely to be chosen + (for example, if one of the server has more memory than the others, + and so can handle more requests) simply list it more times in the + map file.

+ +

+static www1|www1|www2|www3|www4 +

+ +
top
+
+

dbm: DBM Hash File

+ + +

When a MapType of dbm is used, the MapSource is a + filesystem path to a DBM database file containing key/value pairs to + be used in the mapping. This works exactly the same way as the + txt map, but is much faster, because a DBM is indexed, + whereas a text file is not. This allows more rapid access to the + desired key.

+ +

You may optionally specify a particular dbm type:

+ + 
RewriteMap examplemap "dbm=sdbm:/etc/apache/mapfile.dbm"
+ + +

The type can be sdbm, gdbm, ndbm + or db. + However, it is recommended that you just use the httxt2dbm utility that is + provided with Apache HTTP Server, as it will use the correct DBM library, + matching the one that was used when httpd itself was built.

+ +

To create a dbm file, first create a text map file as described + in the txt section. Then run + httxt2dbm:

+ +

+$ httxt2dbm -i mapfile.txt -o mapfile.map +

+ +

You can then reference the resulting file in your +RewriteMap directive:

+ +
RewriteMap mapname "dbm:/etc/apache/mapfile.map"
+ + +
+

Note that with some dbm types, more than one file is generated, with +a common base name. For example, you may have two files named +mapfile.map.dir and mapfile.map.pag. This is +normal, and you need only use the base name mapfile.map in +your RewriteMap directive.

+
+ +

Cached lookups

+

+The looked-up keys are cached by httpd until the mtime +(modified time) of the mapfile changes, or the httpd server is +restarted. This ensures better performance on maps that are called +by many requests. +

+
+ +
top
+
+

prg: External Rewriting Program

+ +

When a MapType of prg is used, the MapSource is a + filesystem path to an executable program which will providing the + mapping behavior. This can be a compiled binary file, or a program + in an interpreted language such as Perl or Python.

+ +

This program is started once, when the Apache HTTP Server is + started, and then communicates with the rewriting engine via + STDIN and STDOUT. That is, for each map + function lookup, it expects one argument via STDIN, and + should return one new-line terminated response string on + STDOUT. If there is no corresponding lookup value, the + map program should return the four-character string + "NULL" to indicate this.

+ +

External rewriting programs are not started if they're defined in + a context that does not have RewriteEngine set to + on.

+ +

By default, external rewriting programs are run as the + user:group who started httpd. This can be changed on UNIX systems + by passing user name and group name as third argument to + RewriteMap in the + username:groupname format.

+ +

This feature utilizes the rewrite-map mutex, + which is required for reliable communication with the program. + The mutex mechanism and lock file can be configured with the + Mutex directive.

+ +

A simple example is shown here which will replace all dashes with + underscores in a request URI.

+ +

Rewrite configuration

+ 
RewriteMap d2u "prg:/www/bin/dash2under.pl" apache:apache
+RewriteRule "-" "${d2u:%{REQUEST_URI}}"
+ + +

dash2under.pl

+ 
#!/usr/bin/perl
+$| = 1; # Turn off I/O buffering
+while (<STDIN>) {
+    s/-/_/g; # Replace dashes with underscores
+    print $_;
+}
+ + +

Caution!

+
    +
  • Keep your rewrite map program as simple as possible. If the program +hangs, it will cause httpd to wait indefinitely for a response from the +map, which will, in turn, cause httpd to stop responding to +requests.
    • +
  • Be sure to turn off buffering in your program. In Perl this is done +by the second line in the example script: $| = 1; This will +of course vary in other languages. Buffered I/O will cause httpd to wait +for the output, and so it will hang.
    • +
  • Remember that there is only one copy of the program, started at +server startup. All requests will need to go through this one bottleneck. +This can cause significant slowdowns if many requests must go through +this process, or if the script itself is very slow.
    • +
+
+ +
top
+
+

dbd or fastdbd: SQL Query

+ + +

When a MapType of dbd or fastdbd is + used, the MapSource is a SQL SELECT statement that takes a single + argument and returns a single value.

+ +

mod_dbd will need to be configured to point at + the right database for this statement to be executed.

+ +

There are two forms of this MapType. + Using a MapType of dbd causes the query to be + executed with each map request, while using fastdbd + caches the database lookups internally. So, while + fastdbd is more efficient, and therefore faster, it + won't pick up on changes to the database until the server is + restarted.

+ +

If a query returns more than one row, a random row from + the result set is used.

+ +

Example

RewriteMap myquery "fastdbd:SELECT destination FROM rewrite WHERE source = %s"
+
+ +

Note

+

The query name is passed to the database driver as a label for + an SQL prepared statement, and will therefore need to follow any rules + (such as case-sensitivity) required for your database.

+ +
top
+
+

Summary

+ + +

The RewriteMap directive can + occur more than once. For each mapping-function use one + RewriteMap directive to declare + its rewriting mapfile.

+ +

While you cannot declare a map in + per-directory context (.htaccess files or + <Directory> blocks) it is + possible to use this map in per-directory context.

+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/rewritemap.html.fr.utf8 b/docs/manual/rewrite/rewritemap.html.fr.utf8 new file mode 100644 index 0000000..2fbda44 --- /dev/null +++ b/docs/manual/rewrite/rewritemap.html.fr.utf8 @@ -0,0 +1,511 @@ + + + + + +Utilisation de RewriteMap - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Utilisation de RewriteMap

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la documentation de référence du + module mod_rewrite. Il décrit l'utilisation de la + directive RewriteMap, et + 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.
+ +
+ +
top
+
+

Introduction

+ + +

+ La directive RewriteMap + définit une fonction externe qui peut être appelée depuis une + directive RewriteRule ou + RewriteCond pour + accomplir une réécriture trop compliquée, ou trop spécialisée pour + être effectuée à partir d'expressions rationnelles. Vous trouverez + ci-dessous les différents types disponibles pour la source de + données, ceux-ci étant par ailleurs énumérés dans la documentation de + référence de RewriteMap.

+ +

La syntaxe de la directive RewriteMap est la suivante + :

+ +
RewriteMap MapName MapType:MapSource
+ + +

L'argument MapName + est un nom arbitraire que vous associez à la table de + correspondances, et que vous + pourrez utilisez par la suite dans les directives de réécriture. Les + recherches dans la table de correspondance s'effectuent en + respectant cette syntaxe :

+ +

+ + ${ nom-map : + clé-recherche + }
${ nom-map : + clé-recherche | DefaultValue } + +

+ +

Lorsque cette syntaxe est employée, la table de correspondances + nom-map est consultée et la clé clé-recherche + recherchée. Si la clé est trouvée, la fonction de recherche dans la + table de correspondance est remplacée par SubstValue, ou + par DefaultValue dans le cas contraire, ou par la chaîne + vide si aucune DefaultValue n'a été spécifiée.

+ +

Par exemple, vous pouvez définir une directive + RewriteMap comme suit :

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

Vous pourrez par la suite utiliser cette table de correspondances + dans une directive RewriteRule comme suit :

+
RewriteRule "^/ex/(.*)" "${examplemap:$1}"
+ + +

Il est possible de spécifier une valeur par défaut qui sera utilisée +si la recherche dans la table de correspondances est infructueuse :

+ +
RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}"
+ + +

Contexte de répertoire et fichiers.htaccess

+

+Vous ne pouvez utiliser la directive RewriteMap ni dans +les sections <Directory>, ni dans les fichiers +.htaccess. Vous devez déclarer la table de correspondances +au niveau du serveur principal ou dans un contexte de serveur virtuel. +En revanche, si vous ne pouvez pas déclarer la table dans une section +<Directory> ou dans un fichier .htaccess, vous +pourrez y faire référence dans ces contextes, une fois cette table +créée. +

+
+ +

Les sections suivantes décrivent les différents types de tables de +correspondances type-map disponibles, et fournissent des +exemples pour chacun d'entre eux.

+
top
+
+

int: Fonction interne

+ + +

Lorsque le type-map int est spécifié, la source est + une des fonctions RewriteMap internes disponibles. Les développeurs + de modules peuvent fournir des fonctions internes supplémentaires en + les enregistrant via l'API ap_register_rewrite_mapfunc. + Les fonctions fournies par défaut sont : +

+ +
    +
  • toupper:
    + Met tous les caractères de la clé en majuscules.
    • +
  • tolower:
    + Met tous les caractères de la clé en minuscules.
    • +
  • escape:
    + Protège les caractères spéciaux de la clé en les + transformant en leur code hexadécimal.
    • +
  • unescape:
    + Retraduit les codes hexadécimaux de la clé en caractères + spéciaux.
    • +
+ +

+ Pour utiliser une de ces fonctions, créez une + RewriteMap faisant référence à cette fonction int, et + utilisez-la dans votre règle RewriteRule : +

+ +

Redirige un URI vers son équivalent en minuscules

+ 
RewriteMap lc int:tolower
+RewriteRule "(.*)" "${lc:$1}" [R]
+ + +
+

Notez que cet exemple n'est fourni qu'à titre d'illustration, + et ne constitue en aucun cas une recommandation. Si vous voulez + rendre des URLs insensibles à la casse, vous devez plutôt vous + tourner vers mod_speling. +

+
+ +
top
+
+

txt: tables de correspondances au format texte

+ + +

Lorsqu'un type-map txt est utilisé, la source-map + est un chemin du système de fichiers vers un fichier de + correspondances au format texte, contenant sur chaque ligne une + paire clé/valeur séparées par un espace. Il est possible d'insérer + des commentaires sous la forme de chaînes commençant par le caractère + '#'.

+ +

Voici un exemple d'entrées valides dans un fichier de + correspondances :

+ +

+ # Ligne de commentaires
+ clé valeur-substitution
+ clé valeur-substitution # commentaire
+

+ +

Lorsque la table de correspondance fait l'objet d'une recherche, + la valeur spécifiée est recherchée dans le premier champ, et si elle + est trouvée, la valeur de substitution est renvoyée.

+ +

Par exemple, nous pourrions utiliser un fichier de + correspondances pour traduire des noms de produits en identifiants + produits pour obtenir des URLs plus simples à mémoriser, en + utilisant la recette suivante :

+ +

Product to ID configuration

+ 
RewriteMap product2id "txt:/etc/apache2/productmap.txt"
+RewriteRule "^/product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
+ + +

Nous supposons ici que le script prods.php sait quoi + faire lorsqu'il reçoit un argument id=NOTFOUND, dans + le cas où le produit ne se trouve pas dans la table de + correspondances.

+ +

Le fichier /etc/apache2/map-produit.txt contient ce + qui suit :

+ +

Fichier de correspondances Produit - Identifiant

+##
+## map-produit.txt - Fichier de correspondances Produit - Identifiant
+##
+
+TELEVISION 993
+STEREO 198
+CANNE-A-PECHE 043
+BALLON-BASKET 418
+TELEPHONE 328 +

+ +

Ainsi, lorsqu'une requête pour + http://example.com/produit/TELEVISION arrive, la directive + RewriteRule s'applique, et la + requête est transformée en interne en /prods.php?id=993.

+ +

Note: fichiers .htaccess

+ L'exemple donné est conçu pour être utilisé dans un contexte de + serveur principal ou de serveur virtuel. Si vous voulez l'utiliser + dans un fichier .htaccess, vous devrez supprimer le + slash de début dans le modèle de réécriture afin que ce dernier + puisse correspondre à toute URL : + 
RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT]
+ +
+ +

Recherches mises en cache

+

+ Les clés de recherche sont mises en cache par httpd jusqu'à ce que + le mtime (date de modification) du fichier de + correspondances soit modifié, ou que le serveur httpd soit + redémarré, ce qui améliore les performances pour les tables de + correspondances consultées par de nombreuses requêtes. +

+
+ +
top
+
+

rnd: Fichier texte à valeurs de substitution multiples + choisies de manière aléatoire

+ + +

Lorsque le type-map spécifié est rnd, la source est + un chemin du système de fichiers vers un fichier de correspondances + au format texte dont chaque ligne contient une clé, et une ou + plusieurs valeurs séparées par le caractère |. Si une + clé convient, une des valeurs correspondantes sera choisie de + manière aléatoire.

+ +

Par exemple, vous pouvez utiliser le fichier de correspondances + et les directives suivants pour implémenter une répartition de + charge aléatoire entre plusieurs serveurs d'arrière-plan, par + l'intermédiaire d'un mandataire inverse. Les images sont envoyées + vers un des serveurs de l'ensemble 'statique', tandis que tout le + reste est envoyé vers un des serveurs de l'ensemble 'dynamique'.

+ +

Fichier de correspondances

+##
+## map.txt -- table de réécriture
+##
+
+statique www1|www2|www3|www4
+dynamique www5|www6 +

+

Directives de configuration

+ 
RewriteMap servers "rnd:/path/to/file/map.txt"
+
+RewriteRule "^/(.*\.(png|gif|jpg))" "http://${servers:static}/$1" [NC,P,L]
+RewriteRule "^/(.*)"                "http://${servers:dynamic}/$1" [P,L]
+ + + +

Ainsi, lorsqu'une image est demandée et que la première règle + convient, RewriteMap recherche la chaîne + statique dans le fichier de correspondances qui + renvoie un des noms de serveurs spécifiés de manière aléatoire, + ce dernier étant utilisé dans la cible de la règle + RewriteRule.

+ +

Si vous voulez qu'un des serveurs soit plus souvent sollicité que + les autres (par exemple s'il possède plus de mémoire, et peut donc + traiter d'avantage de requêtes), spécifiez-le plusieurs fois dans la + liste des serveurs.

+ +

+statique www1|www1|www2|www3|www4 +

+ +
top
+
+

dbm: Fichier condensé DBM

+ + +

Lorsque le type-map dbm est utilisé, la source est + un chemin du système de fichiers vers un fichier de données DBM + contenant des paires clé/valeur permettant d'effectuer la + correspondance. Le fonctionnement est identique à celui du type-map + txt, mais beaucoup plus rapide car un fichier DBM est + indexé, alors qu'un fichier texte ne l'est pas. L'accès à la clé + recherchée est donc plus rapide.

+ +

Vous pouvez éventuellement spécifier un type dbm particulier :

+ + 
RewriteMap examplemap "dbm=sdbm:/etc/apache/mapfile.dbm"
+ + +

Ce type peut être choisi parmi sdbm, gdbm, + ndbm ou db. Il est + cependant recommandé d'utiliser l'utilitaire httxt2dbm fourni avec le + serveur HTTP Apache, car il utilise la bibliothèque DBM appropriée, + à savoir celle qui a été utilisée lors de la compilation de httpd.

+ +

Pour créer un fichier dbm, créez tout d'abord un fichier de + correspondances au format texte comme décrit dans la section txt. Traitez ensuite ce fichier avec + httxt2dbm :

+ +

+$ httxt2dbm -i fichier-map.txt -o fichier-map.map +

+ +

Vous pouvez alors faire référence au fichier obtenu dans votre +directive RewriteMap :

+
RewriteMap mapname "dbm:/etc/apache/mapfile.map"
+ + +
+

Notez qu'avec certains types dbm, plusieurs fichiers possédant le +même nom de base sont créés. Par exemple, vous pouvez obtenir deux +fichiers nommés fichier-map.map.dir et +fichier-map.map.pag. Ceci est tout à fait normal, et vous +ne devez utiliser que le nom de base fichier-map.map dans votre +directive RewriteMap.

+
+ +

Mise en cache des recherches

+

+ Les clés de recherche sont mises en cache par httpd jusqu'à ce que + le mtime (date de modification) du fichier de + correspondances soit modifié, ou que le serveur httpd soit + redémarré, ce qui améliore les performances pour les tables de + correspondances consultées par de nombreuses requêtes. +

+
+ +
top
+
+

prg: Programme de réécriture externe

+ +

Lorque le type-map prg est spécifié, la source est + un chemin du système de fichiers vers un programme exécutable + destiné à effectuer la mise en correspondance. Il peut s'agir d'un + fichier binaire compilé, ou d'un programme en langage interprété + comme Perl ou Python.

+ +

Ce programme est lancé une fois au démarrage du serveur HTTP + Apache, puis communique avec le moteur de réécriture via + STDIN et STDOUT. En d'autres termes, pour + chaque recherche de correspondance, il reçoit un argument via + STDIN, et doit renvoyer en guise de réponse une chaîne + terminée par un caractère nouvelle-ligne sur STDOUT. Si + la recherche de correspondance est infructueuse, le programme doit + l'indiquer en retournant la chaîne de quatre caractères + "NULL".

+ +

Les programmes de réécriture externes ne sont pas lancés s'il + n'ont pas été définis dans un contexte où la directive RewriteEngine est définie à + on.

+ +

Par défaut, les programmes de réécriture externes sont lancés par + l'utilisateur/groupe qui a démarré httpd. Pour changer ce comportement, il + est possible sur les systèmes de style Unix de spécifier un autre couple + utilisateur/groupe via le troisième argument de la directive RewriteMap, et ceci au format + utilisateur:groupe.

+ +

Cette fonctionnalité utilise le mutex rewrite-map + nécessaire à la fiabilité des communications avec le programme. Le + mécanisme de mutex et le fichier verrou peuvent être définis via la + directive Mutex.

+ +

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

+ +

Configuration de la réécriture

+ 
RewriteMap d2u "prg:/www/bin/dash2under.pl" apache:apache
+RewriteRule "-" "${d2u:%{REQUEST_URI}}"
+ + +

dash2under.pl

+ 
    #!/usr/bin/perl
+    $| = 1; # Turn off I/O buffering
+    while (<STDIN>) {
+        s/-/_/g; # Remplace tous les tirets par des caractères de soulignement
+        print $_;
+    }
+ + +

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. En Perl, ceci est effectué à la seconde ligne du script de +l'exemple - $| = 1; - La syntaxe sera bien entendu +différente dans +d'autres langages. Si les entrées/sorties sont mises en tampon, httpd va +attendre une sortie, et va par conséquent se bloquer.
    • +
  • 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 +significatifs si de nombreuses requêtes doivent être traitées, ou si le +script lui-même est très lent.
    • +
+
+ +
top
+
+

dbd ou fastdbd: requête SQL

+ + +

Lorsque le type-map dbd ou fastdbd est + spécifié, la source est une requête SQL SELECT qui reçoit un + argument et renvoie une seule valeur.

+ +

Pour que cette requête puisse être exécutée, + mod_dbd doit être configuré pour attaquer la base + de données concernée.

+ +

Ce type-map existe sous deux formes. Avec le type-map + dbd, la requête est exécutée à chaque demande, tandis + qu'avec le type-map fastdbd, les recherches dans la + base de données sont mises en cache en interne. fastdbd + est donc plus efficace et donc plus rapide ; par contre, il ne + tiendra pas compte des modifications apportées à la base de données + jusqu'à ce que le serveur soit redémarré.

+ +

Si une requête renvoie plusieurs enregistrements, un de ceux-ci + sera sélectionné aléatoirement.

+ +

Exemple

RewriteMap ma-requete "fastdbd:SELECT destination FROM rewrite WHERE source = %s"
+
+ +

Note

+

Le nom de la requête est transmis au pilote de base de données en tant + que label pour une requête SQL préparée, et doit donc respecter toutes les + règles imposées par votre base de données (comme la sensibilité à la casse).

+ +
top
+
+

Résumé

+ + +

La directive RewriteMap peut apparaître + plusieurs fois. Utilisez une directive + RewriteMap pour chaque fonction de mise en + correspondance pour déclarer son fichier de correspondances.

+ +

Bien que l'on ne puisse pas déclarer de fonction + de mise en correspondance dans un contexte de répertoire (fichier + .htaccess ou section <Directory>), il est + possible d'utiliser cette fonction dans un tel contexte.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/tech.html b/docs/manual/rewrite/tech.html new file mode 100644 index 0000000..f7b80ba --- /dev/null +++ b/docs/manual/rewrite/tech.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: tech.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: tech.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/tech.html.en b/docs/manual/rewrite/tech.html.en new file mode 100644 index 0000000..5207ec7 --- /dev/null +++ b/docs/manual/rewrite/tech.html.en @@ -0,0 +1,205 @@ + + + + + +Apache mod_rewrite Technical Details - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Apache mod_rewrite Technical Details

+
+

Available Languages:  en  | + fr 

+
+ +

This document discusses some of the technical details of mod_rewrite +and URL matching.

+
+ +
top
+
+

API Phases

+ +

The Apache HTTP Server handles requests in several phases. At + each of these phases, one or more modules may be called upon to + handle that portion of the request lifecycle. Phases include things + like URL-to-filename translation, authentication, authorization, + content, and logging. (This is not an exhaustive list.)

+ +

mod_rewrite acts in two of these phases (or "hooks", as they are + often called) to influence how URLs may be rewritten.

+ +

First, it uses the URL-to-filename translation hook, which occurs + after the HTTP request has been read, but before any authorization + starts. Secondly, it uses the Fixup hook, which is after the + authorization phases, and after per-directory configuration files + (.htaccess files) have been read, but before the + content handler is called.

+ +

So, after a request comes in and a corresponding server or + virtual host has been determined, the rewriting engine starts + processing any mod_rewrite directives appearing in the + per-server configuration. (i.e., in the main server configuration file + and <Virtualhost> + sections.) This happens in the URL-to-filename phase.

+ +

A few steps later, once the final data directories have been found, + the per-directory configuration directives (.htaccess + files and <Directory> blocks) are applied. This + happens in the Fixup phase.

+ +

In each of these cases, mod_rewrite rewrites the + REQUEST_URI either to a new URL, or to a filename.

+ +

In per-directory context (i.e., within .htaccess files + and Directory blocks), these rules are being applied + after a URL has already been translated to a filename. Because of + this, the URL-path that mod_rewrite initially compares RewriteRule directives against + is the full filesystem path to the translated filename with the current + directories path (including a trailing slash) removed from the front.

+ +

To illustrate: If rules are in /var/www/foo/.htaccess and a request + for /foo/bar/baz is being processed, an expression like ^bar/baz$ would + match.

+ +

If a substitution is made in per-directory context, a new internal + subrequest is issued with the new URL, which restarts processing of the + request phases. If the substitution is a relative path, the RewriteBase directive + determines the URL-path prefix prepended to the substitution. + In per-directory context, care must be taken to + create rules which will eventually (in some future "round" of per-directory + rewrite processing) not perform a substitution to avoid looping. + (See RewriteLooping + for further discussion of this problem.)

+ +

Because of this further manipulation of the URL in per-directory + context, you'll need to take care to craft your rewrite rules + differently in that context. In particular, remember that the + leading directory path will be stripped off of the URL that your + rewrite rules will see. Consider the examples below for further + clarification.

+ + + + + + + + + + + + + + + + + + + + + + + +
Location of ruleRule
VirtualHost sectionRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
.htaccess file in document rootRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
.htaccess file in images directoryRewriteRule "^(.+)\.jpg" "$1.gif"
+ +

For even more insight into how mod_rewrite manipulates URLs in + different contexts, you should consult the log entries made during + rewriting.

+ +
top
+
+

Ruleset Processing

+ +

Now when mod_rewrite is triggered in these two API phases, it + reads the configured rulesets from its configuration + structure (which itself was either created on startup for + per-server context or during the directory walk of the Apache + kernel for per-directory context). Then the URL rewriting + engine is started with the contained ruleset (one or more + rules together with their conditions). The operation of the + URL rewriting engine itself is exactly the same for both + configuration contexts. Only the final result processing is + different.

+ +

The order of rules in the ruleset is important because the + rewriting engine processes them in a special (and not very + obvious) order. The rule is this: The rewriting engine loops + through the ruleset rule by rule (RewriteRule directives) and + when a particular rule matches it optionally loops through + existing corresponding conditions (RewriteCond + directives). For historical reasons the conditions are given + first, and so the control flow is a little bit long-winded. See + Figure 1 for more details.

+

+ Flow of RewriteRule and RewriteCond matching
+ Figure 1:The control flow through the rewriting ruleset +

+

First the URL is matched against the + Pattern of each rule. If it fails, mod_rewrite + immediately stops processing this rule, and continues with the + next rule. If the Pattern matches, mod_rewrite looks + for corresponding rule conditions (RewriteCond directives, + appearing immediately above the RewriteRule in the configuration). + If none are present, it substitutes the URL with a new value, which is + constructed from the string Substitution, and goes on + with its rule-looping. But if conditions exist, it starts an + inner loop for processing them in the order that they are + listed. For conditions, the logic is different: we don't match + a pattern against the current URL. Instead we first create a + string TestString by expanding variables, + back-references, map lookups, etc. and then we try + to match CondPattern against it. If the pattern + doesn't match, the complete set of conditions and the + corresponding rule fails. If the pattern matches, then the + next condition is processed until no more conditions are + available. If all conditions match, processing is continued + with the substitution of the URL with + Substitution.

+ +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/tech.html.fr.utf8 b/docs/manual/rewrite/tech.html.fr.utf8 new file mode 100644 index 0000000..f246179 --- /dev/null +++ b/docs/manual/rewrite/tech.html.fr.utf8 @@ -0,0 +1,223 @@ + + + + + +Détails techniques sur le module Apache mod_rewrite - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Détails techniques sur le module Apache mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ +

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

+
+ +
top
+
+

Phases de l'API

+ +

Le traitement des requêtes par le serveur HTTP Apache se + déroule en plusieurs phases. Au cours de chaque phase, un ou + plusieurs modules peuvent être appelés pour traiter la partie + concernée du cycle de vie de la requête. Les différentes phases + peuvent consister en traduction d'URL en nom de fichier, + authentification, autorisation, gestion de contenu ou journalisation (la + liste n'est pas exhaustive).

+ +

mod_rewrite agit dans deux de ces phases (ou accroches - hooks - + comme on les nomme souvent) pour la réécriture des URLs.

+ +

Tout d'abord, il utilise le hook traduction URL vers nom de + fichier qui intervient après la lecture de la requête HTTP, mais + avant le processus d'autorisation. Ensuite, il utilise le hook + Fixup, qui intervient après les phases d'autorisation, après la + lecture des fichiers de configuration de niveau répertoire (fichiers + .htaccess), mais avant l'appel du gestionnaire de + contenu.

+ +

Ainsi, lorsqu'une requête arrive et une fois le serveur + correspondant ou le serveur virtuel déterminé, le moteur de + réécriture commence à traiter toute directive apparaissant dans la + configuration de niveau serveur (autrement dit dans le + fichier de configuration principal du serveur et les sections + <Virtualhost>). + Tout ce processus s'exécute au cours de la phase de traduction URL + vers nom de fichier.

+ +

Quelques étapes plus loin, une fois les répertoires de données + finaux trouvés, les directives de configuration de niveau répertoire + (fichiers .htaccess et sections <Directory>) sont appliquées. Ce processus + 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 + nom de fichier.

+ +

Dans un contexte de niveau répertoire (autrement dit dans les + fichiers .htaccess et les sections + Directory), les règles de réécriture s'appliquent après + la traduction de l'URL en nom de fichier. C'est pourquoi le chemin + URL auquel mod_rewrite compare initialement les directives + RewriteRule est le + chemin complet vers le nom de fichier traduit amputé de la partie + répertoires (y compris le dernier slash).

+ +

Un exemple : si les règles se trouvent dans + /var/www/foo/.htaccess et si une requête pour /foo/bar/baz est + traité, une expression comme ^bar/baz$ correspondra.

+ +

Si une substitution intervient dans un contexte de répertoire, + une nouvelle sous-requête interne est générée avec la nouvelle URL, + ce qui relance le traitement des phases de la requête. Si la + substitution est un chemin relatif, la directive RewriteBase détermine le chemin URL + devant préfixer cette substitution. Dans un contexte de répertoire, + il faut s'assurer de créer des règles qui + n'effectueront pas de substitution au + cours d'une passe ultérieure du processus de réécriture au niveau + répertoire afin d'éviter les bouclages . Voir Bouclage dans le + processus de réécriture pour une discussion plus détaillée à + propos de ce problème.

+ +

En conséquence de cette manipulation de l'URL , vous devrez + pensez à confectionner différemment vos règles de réécriture dans un + contexte de niveau répertoire. En particulier, rappelez-vous que le + chemin de répertoire sera absent de l'URL que vos règles de + réécriture verront. Voici quelques exemples qui permettront de + clarifier les choses :

+ + + + + + + + + + + + + + + + + + + + + + + +
Position de la règleRègle
Section VirtualHostRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
Fichier .htaccess à la racine des documentsRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
Fichier .htaccess dans le répertoire imagesRewriteRule "^(.+)\.jpg" "$1.gif"
+ +

Pour une étude plus approfondie de la manière dont mod_rewrite + manipule les URLs dans les différents contextes, vous pouvez + consulter les entrées du + journal générées au cours du processus de réécriture.

+ +
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.

+

+ Flux des comparaisons des directives RewriteRule et RewriteCond
+ Figure 1:Déroulement du contrôle à travers le jeu de + règles de réécriture +

+

L'URL est tout d'abord comparée 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 + Modèle, mod_rewrite recherche la présence de conditions + correspondantes (les directives Rewritecond apparaissant dans la + configuration juste + avant les règles de réécriture). S'il n'y en a pas, mod_rewrite remplace + l'URL par une chaîne élaborée à partir de la chaîne de + Substitution, puis passe à la règle suivante. Si des + conditions sont présentes, mod_rewrite lance un bouclage + secondaire afin de les traiter selon l'ordre dans lequel elles + sont définies. La logique de traitement des conditions est + différente : on ne compare pas l'URL à un modèle. Une chaîne de + test TestString est tout d'abord élaborée en développant + des variables, des références arrières, des recherches dans des + tables de correspondances, etc..., puis cette chaîne de test est + comparée au modèle de condition CondPattern. Si le modèle + ne correspond pas, les autres conditions du jeu ne sont pas + examinées et la règle correspondante ne s'applique pas. Si le + modèle correspond, la condition suivante est examinée et ainsi de + suite jusqu'à la dernière condition. Si toutes les conditions sont + satisfaites, le traitement de la règle en cours se poursuit avec + le remplacement de l'URL par la chaîne de Substitution.

+ +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/vhosts.html b/docs/manual/rewrite/vhosts.html new file mode 100644 index 0000000..e7f261c --- /dev/null +++ b/docs/manual/rewrite/vhosts.html @@ -0,0 +1,9 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: vhosts.html.en +Content-Language: en +Content-type: text/html; charset=UTF-8 + +URI: vhosts.html.fr.utf8 +Content-Language: fr +Content-type: text/html; charset=UTF-8 diff --git a/docs/manual/rewrite/vhosts.html.en b/docs/manual/rewrite/vhosts.html.en new file mode 100644 index 0000000..a2cbb99 --- /dev/null +++ b/docs/manual/rewrite/vhosts.html.en @@ -0,0 +1,228 @@ + + + + + +Dynamic mass virtual hosts with mod_rewrite - Apache HTTP Server Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.4

+
+
<-
+

Dynamic mass virtual hosts with mod_rewrite

+
+

Available Languages:  en  | + fr 

+
+ + +

This document supplements the mod_rewrite +reference documentation. It describes +how you can use mod_rewrite to create dynamically +configured virtual hosts.

+ +
mod_rewrite is not the best way to configure +virtual hosts. You should first consider the alternatives before resorting to +mod_rewrite. See also the "how to avoid +mod_rewrite document.
+ +
+ +
top
+
+

Virtual Hosts For Arbitrary Hostnames

+ + + +
+
Description:
+ +
+

We want to automatically create a virtual host for every hostname + which resolves in our domain, without having to create + new VirtualHost sections.

+ +

In this recipe, we assume that we'll be using the hostname + www.SITE.example.com for each + user, and serve their content out of + /home/SITE/www.

+
+ +
Solution:
+ +
+ +
RewriteEngine on
+
+RewriteMap    lowercase int:tolower
+
+RewriteCond   "${lowercase:%{HTTP_HOST}}"   "^www\.([^.]+)\.example\.com$"
+RewriteRule   "^(.*)" "/home/%1/www$1"
+
+ +
Discussion
+
+ +
You will need to take care of the DNS + resolution - Apache does + not handle name resolution. You'll need either to create CNAME + records for each hostname, or a DNS wildcard record. Creating DNS + records is beyond the scope of this document.
+ +

The internal tolower RewriteMap directive is used to +ensure that the hostnames being used are all lowercase, so that there is +no ambiguity in the directory structure which must be created.

+ +

Parentheses used in a RewriteCond are captured into the +backreferences %1, %2, etc, while parentheses +used in RewriteRule are +captured into the backreferences $1, $2, +etc.

+ +

+As with many techniques discussed in this document, mod_rewrite really +isn't the best way to accomplish this task. You should, instead, +consider using mod_vhost_alias instead, as it will much +more gracefully handle anything beyond serving static files, such as any +dynamic content, and Alias resolution. +

+
+
+ +
top
+
+

Dynamic + Virtual Hosts Using mod_rewrite

+ +

This extract from httpd.conf does the same + thing as the first example. The first + half is very similar to the corresponding part above, except for + some changes, required for backward compatibility and to make the + mod_rewrite part work properly; the second half + configures mod_rewrite to do the actual work.

+ +

Because mod_rewrite runs before other URI translation + modules (e.g., mod_alias), mod_rewrite must + be told to explicitly ignore any URLs that would have been handled + by those modules. And, because these rules would otherwise bypass + any ScriptAlias directives, we must have + mod_rewrite explicitly enact those mappings.

+ +
# get the server name from the Host: header
+UseCanonicalName Off
+
+# splittable logs
+LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+<Directory "/www/hosts">
+    # ExecCGI is needed here because we can't force
+    # CGI execution in the way that ScriptAlias does
+    Options FollowSymLinks ExecCGI
+</Directory>
+
+RewriteEngine On
+
+# a ServerName derived from a Host: header may be any case at all
+RewriteMap  lowercase  int:tolower
+
+## deal with normal documents first:
+# allow Alias "/icons/" to work - repeat for other aliases
+RewriteCond  "%{REQUEST_URI}"  "!^/icons/"
+# allow CGIs to work
+RewriteCond  "%{REQUEST_URI}"  "!^/cgi-bin/"
+# do the magic
+RewriteRule  "^/(.*)$"  "/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1"
+
+## and now deal with CGIs - we have to force a handler
+RewriteCond  "%{REQUEST_URI}"  "^/cgi-bin/"
+RewriteRule  "^/(.*)$"  "/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1"  [H=cgi-script]
+ + +
top
+
+

Using a Separate Virtual Host Configuration File

+ +

This arrangement uses more advanced mod_rewrite + features to work out the translation from virtual host to document + root, from a separate configuration file. This provides more + flexibility, but requires more complicated configuration.

+ +

The vhost.map file should look something like + this:

+ +

+customer-1.example.com /www/customers/1
+customer-2.example.com /www/customers/2
+# ...
+customer-N.example.com /www/customers/N
+

+ +

The httpd.conf should contain the following:

+ +
RewriteEngine on
+
+RewriteMap   lowercase  int:tolower
+
+# define the map file
+RewriteMap   vhost      "txt:/www/conf/vhost.map"
+
+# deal with aliases as above
+RewriteCond  "%{REQUEST_URI}"               "!^/icons/"
+RewriteCond  "%{REQUEST_URI}"               "!^/cgi-bin/"
+RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
+# this does the file-based remap
+RewriteCond  "${vhost:%1}"                  "^(/.*)$"
+RewriteRule  "^/(.*)$"                      "%1/docs/$1"
+
+RewriteCond  "%{REQUEST_URI}"               "^/cgi-bin/"
+RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
+RewriteCond  "${vhost:%1}"                  "^(/.*)$"
+RewriteRule  "^/cgi-bin/(.*)$"                      "%1/cgi-bin/$1" [H=cgi-script]
+ + +
+
+

Available Languages:  en  | + fr 

+
top

Comments

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file diff --git a/docs/manual/rewrite/vhosts.html.fr.utf8 b/docs/manual/rewrite/vhosts.html.fr.utf8 new file mode 100644 index 0000000..ee685c1 --- /dev/null +++ b/docs/manual/rewrite/vhosts.html.fr.utf8 @@ -0,0 +1,239 @@ + + + + + +Hébergement virtuel de masse avec mod_rewrite - Serveur HTTP Apache Version 2.4 + + + + + + +
+

Modules | Directives | FAQ | Glossaire | Plan du site

+

Serveur HTTP Apache Version 2.4

+
+
<-
+

Hébergement virtuel de masse avec mod_rewrite

+
+

Langues Disponibles:  en  | + fr 

+
+ + +

Ce document est un complément à la documentation de référence du module +mod_rewrite. Il décrit comment créer des serveurs +virtuels dynamiquement configurés en utilisant +mod_rewrite.

+ +
L'utilisation de mod_rewrite n'est pas la meilleure +méthode pour configurer des serveurs virtuels. Vous devez dans un +premier temps tenter de résoudre votre problème via ces d'autres méthodes avant d'avoir +recours à mod_rewrite. Voir aussi le document Comment éviter l'utilisation de +mod_rewrite.
+ + +
+ +
top
+
+

Serveurs virtuels pour des noms d'hôtes arbitraires

+ + + +
+
Description :
+ +
+

Nous voulons créer automatiquement un serveur virtuel pour tout + nom d'hôte qui peut être résolu dans notre domaine, sans avoir à + créer de nouvelle section VirtualHost.

+ +

Dans cet exemple, nous supposons que nous utilisons le nom d'hôte + www.SITE.example.com pour chaque + utilisateur, et que nous servons leur contenu depuis + /home/SITE/www.

+
+ +
Solution :
+ +
+ +
RewriteEngine on
+
+RewriteMap    lowercase int:tolower
+
+RewriteCond   "${lowercase:%{HTTP_HOST}}" "^www\.([^.]+)\.example\.com$"
+RewriteRule   "^(.*)" "/home/%1/www$1"
+
+ +
Discussion
+
+ +
Vous devez vérifier le bon fonctionnement de la + résolution DNS - Apache ne gère pas la résolution de nom. Vous + devrez créer soit des enregistrements CNAME pour chaque nom d'hôte, + soit un enregistrement DNS avec caractères génériques. La création + des enregistrements DNS est en dehors du sujet de ce document.
+ +

La directive RewriteMap interne tolower permet de +s'assurer que les noms d'hôtes utilisés seront tous en minuscules, de +façon à éviter toute ambiguité dans la structure des répertoires qui +doit être créée.

+ +

Les contenus des parenthèses utilisées dans une directive RewriteCond sont enregistrés dans les +références arrières %1, %2, etc..., alors que +les contenus des parenthèses utilisées dans une directive RewriteRule le sont dans les +références arrières $1, $2, etc...

+ +

+Comme c'est le cas pour de nombreuses techniques discutées dans ce +document, mod_rewrite n'est vraiment pas la meilleure méthode pour +accomplir cette tâche. Vous devez plutôt vous tourner vers +mod_vhost_alias, car ce dernier sera bien plus à même +de gérer tout ce qui est au delà du domaine des fichiers statiques, +comme les contenus dynamiques et la résolution des alias. +

+
+
+ +
top
+
+

Configuration dynamique de serveurs +virtuels via mod_rewrite

+ +

Cet extrait du fichier httpd.conf permet d'obtenir + le même résultat que le premier exemple. + La première moitié est très similaire à la partie correspondante + ci-dessus, excepté quelques modifications requises à des fins de + compatibilité ascendante et pour faire en sorte que la partie + mod_rewrite fonctionne correctement ; la seconde moitié + configure mod_rewrite pour effectuer le travail + proprement dit.

+ +

Comme mod_rewrite s'exécute avant tout autre module + de traduction d'URI (comme mod_alias), il faut lui + ordonner explicitement d'ignorer toute URL susceptible d'être + traitée par ces autres modules. Et comme ces règles auraient sinon + court-circuité toute directive ScriptAlias, nous devons + faire en sorte que mod_rewrite déclare explicitement + ces correspondances.

+ +
# extrait le nom de serveur de l'en-tête Host:
+UseCanonicalName Off
+
+# journaux dissociables
+LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon
+CustomLog "logs/access_log" vcommon
+
+<Directory "/www/hosts">
+    # ExecCGI est nécessaire ici car on ne peut pas forcer l'exécution
+    # des CGI à la manière de ScriptAlias
+    Options FollowSymLinks ExecCGI
+</Directory>
+
+RewriteEngine On
+
+# un nom de serveur extrait d'un en-tête Host: peut être dans n'importe
+# quelle casse
+RewriteMap  lowercase  int:tolower
+
+## on s'occupe tout d'abord des documents normaux :

+# permet à Alias "/icons/" de fonctionner - répéter pour les autres
+RewriteCond  "%{REQUEST_URI}"  "!^/icons/"
+# permet aux CGIs de fonctionner
+RewriteCond  "%{REQUEST_URI}"  "!^/cgi-bin/"
+# le coeur du traitement
+RewriteRule  "^/(.*)$"  "/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1"
+
+## on s'occupe maintenant des CGIs - on doit forcer l'utilisation d'un
+# gestionnaire
+RewriteCond  "%{REQUEST_URI}"  "^/cgi-bin/"
+RewriteRule  "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1"  [H=cgi-script]
+ + +
top
+
+

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

+ +

Cette construction utilise des fonctionnalités plus avancées de + mod_rewrite pour effectuer la traduction depuis le + serveur virtuel vers la racine des documents, à partir d'un fichier + de configuration séparé. Elle est plus souple mais nécessite une + configuration plus compliquée.

+ +

Le fichier vhost.map devrait ressembler à ceci :

+ +

+www.client-1.example.com /www/clients/1
+www.client-2.example.com /www/clients/2
+# ...
+www.client-N.example.com /www/clients/N
+

+ +

On doit ajouter à httpd.conf :

+ +
RewriteEngine on
+
+RewriteMap   lowercase  int:tolower
+
+# définit le fichier de correspondances
+RewriteMap   vhost      "txt:/www/conf/vhost.map"
+
+# on s'occupe des alias comme ci-dessus
+RewriteCond  "%{REQUEST_URI}"               "!^/icons/"
+RewriteCond  "%{REQUEST_URI}"               "!^/cgi-bin/"
+RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
+# on effectue ici la remise en correspondance à base de fichier
+RewriteCond  "${vhost:%1}"                  "^(/.*)$"
+RewriteRule  "^/(.*)$"                      "%1/docs/$1"
+
+RewriteCond  "%{REQUEST_URI}"               "^/cgi-bin/"
+RewriteCond  "${lowercase:%{SERVER_NAME}}"  "^(.+)$"
+RewriteCond  "${vhost:%1}"                  "^(/.*)$"
+RewriteRule  "^/cgi-bin/(.*)$"              "%1/cgi-bin/$1" [H=cgi-script]
+ + +
+
+

Langues Disponibles:  en  | + fr 

+
top

Commentaires

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Libera.chat, or sent to our mailing lists.
+
+ \ No newline at end of file -- cgit v1.2.3