From: Rich Bowen Date: Tue, 28 Apr 2026 17:43:35 +0000 (+0000) Subject: Translations for all languages, all files in the rewrite/ docs tree. X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=716ddee484c8e5081ec398b214084d3ca5faa6a2;p=thirdparty%2Fapache%2Fhttpd.git Translations for all languages, all files in the rewrite/ docs tree. This translation was facilitated by AI tools. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1933442 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/rewrite/access.xml.de b/docs/manual/rewrite/access.xml.de new file mode 100644 index 0000000000..691589f3d9 --- /dev/null +++ b/docs/manual/rewrite/access.xml.de @@ -0,0 +1,308 @@ + + + + + + + + + Rewrite + +Zugriffskontrolle mit mod_rewrite + + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es beschreibt, +wie Sie mod_rewrite zur Zugriffskontrolle auf +verschiedene Ressourcen verwenden können, sowie weitere verwandte Techniken. +Dies beinhaltet viele Beispiele für gängige Verwendungen von mod_rewrite, +einschließlich detaillierter Beschreibungen, wie jedes einzelne funktioniert.

+ +Beachten Sie, dass viele dieser Beispiele nicht unverändert in Ihrer +speziellen Serverkonfiguration funktionieren werden. Es ist daher wichtig, dass Sie +sie verstehen, anstatt die Beispiele einfach auszuschneiden und in Ihre +Konfiguration einzufügen. + +
+Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung + +Virtuelle Hosts +Proxying +Verwendung von RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
+ + Verhindern von Bild-"Hotlinking" + +
+
Beschreibung:
+ +
+

Die folgende Technik verhindert die Praxis, dass andere Websites + Ihre Bilder direkt in ihre Seiten einbinden. Diese Praxis wird + oft als "Hotlinking" bezeichnet und führt dazu, + dass Ihre Bandbreite verwendet wird, um Inhalte für die Website + einer anderen Person bereitzustellen.

+
+ +
Lösung:
+ +
+

Diese Technik beruht auf dem Wert der + HTTP_REFERER-Variable, die optional ist. Daher + ist es möglich, dass einige Personen diese Einschränkung + umgehen. Die meisten Benutzer werden jedoch die fehlgeschlagene + Anfrage bemerken, was im Laufe der Zeit dazu führen sollte, + dass das Bild von der anderen Website entfernt wird.

+

Es gibt mehrere Möglichkeiten, mit dieser Situation + umzugehen.

+ +

Im ersten Beispiel verweigern wir die Anfrage einfach, wenn sie nicht + von einer Seite unserer Website stammt. Für dieses Beispiel nehmen wir + an, dass unsere Website www.example.com ist.

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

Im zweiten Beispiel zeigen wir statt einer fehlgeschlagenen Anfrage + ein alternatives Bild an.

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

Im dritten Beispiel leiten wir die Anfrage auf ein Bild auf einer + anderen Website um.

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

Von diesen Techniken sind die letzten beiden am effektivsten, + um Personen davon abzuhalten, Ihre Bilder per Hotlink einzubinden, + da sie einfach nicht das Bild sehen werden, das sie erwartet haben.

+ +
+ +
Diskussion:
+ +
+

Wenn Sie lediglich den Zugriff auf die Ressource verweigern möchten, + anstatt die Anfrage woanders umzuleiten, kann dies ohne die + Verwendung von mod_rewrite erreicht werden:

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

+ In diesem Rezept besprechen wir, wie man hartnäckige Anfragen von + einem bestimmten Robot oder User-Agent blockiert.

+ +

Der Standard für den Ausschluss von Robots definiert eine Datei, + /robots.txt, die die Bereiche Ihrer Website festlegt, + von denen Sie Robots ausschließen möchten. Einige Robots halten sich + jedoch nicht an diese Dateien. +

+ +

Beachten Sie, dass es Methoden gibt, dies ohne die Verwendung + von mod_rewrite zu erreichen. Beachten Sie auch, dass jede Technik, die auf + dem USER_AGENT-String des Clients basiert, sehr leicht + umgangen werden kann, da dieser String geändert werden kann.

+
+ +
Lösung:
+ +
+

Wir verwenden einen Regelsatz, der das zu schützende Verzeichnis + und den Client-USER_AGENT angibt, der den bösartigen + oder hartnäckigen Robot identifiziert.

+ +

In diesem Beispiel blockieren wir einen Robot namens + NameOfBadRobot vom Standort + /secret/files. Sie können auch einen IP-Adressbereich + angeben, wenn Sie den User-Agent nur von einer bestimmten Quelle + blockieren möchten.

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

+ Anstatt mod_rewrite hierfür zu verwenden, können Sie dasselbe + Ziel mit alternativen Mitteln erreichen, wie hier gezeigt: +

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

+ Wie oben erwähnt, ist diese Technik trivial zu umgehen, indem man + einfach den USER_AGENT-Anfrage-Header ändert. Wenn Sie + einen anhaltenden Angriff erleben, sollten Sie erwägen, diesen + auf einer höheren Ebene zu blockieren, beispielsweise an Ihrer Firewall. +

+ +
+ +
+ +
+ +
+ + Ablehnung von Hosts in einer Sperrliste + +
+
Beschreibung:
+ +
+

Wir möchten eine Liste von Hosts pflegen, ähnlich wie + hosts.deny, und diesen Hosts den Zugriff auf + unseren Server verweigern.

+
+ +
Lösung:
+ +
+ +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
+##
+## ACHTUNG! Dies ist eine Map, keine Liste, auch wenn wir sie als solche behandeln.
+## mod_rewrite parst sie nach Schlüssel/Wert-Paaren, daher muss mindestens
+## ein Dummy-Wert "-" für jeden Eintrag vorhanden sein.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+
+ +
Diskussion:
+
+

+ Die zweite RewriteCond setzt voraus, dass HostNameLookups aktiviert ist, + damit Client-IP-Adressen aufgelöst werden. Wenn dies nicht der Fall ist, + sollten Sie die zweite RewriteCond weglassen und das [OR]-Flag + von der ersten RewriteCond entfernen. +

+
+
+ +
+ +
+ + Referer-basierter Umleiter + +
+
Beschreibung:
+ +
+

Anfragen basierend auf dem Referer umleiten, von dem die Anfrage + kam, mit unterschiedlichen Zielen pro Referer.

+
+ +
Lösung:
+ +
+

Der folgende Regelsatz verwendet eine Map-Datei, um jeden Referer + mit einem Umleitungsziel zu verknüpfen.

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

Die Map-Datei listet Umleitungsziele für jeden Referer auf, oder, + wenn wir nur zurück dorthin umleiten möchten, woher sie kamen, wird ein + "-" in die Map eingetragen:

+ + +## +## 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/ + + +
+
+ +
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/access.xml.es b/docs/manual/rewrite/access.xml.es new file mode 100644 index 0000000000..48fc05adff --- /dev/null +++ b/docs/manual/rewrite/access.xml.es @@ -0,0 +1,308 @@ + + + + + + + + + Rewrite + +Uso de mod_rewrite para control de acceso + + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +cómo puede usar mod_rewrite para controlar el acceso a +varios recursos, y otras técnicas relacionadas. +Esto incluye muchos ejemplos de usos comunes de mod_rewrite, +incluyendo descripciones detalladas de cómo funciona cada uno.

+ +Tenga en cuenta que muchos de estos ejemplos no funcionarán sin cambios en su +configuración particular del servidor, por lo que es importante que los +entienda, en lugar de simplemente copiar y pegar los ejemplos en su +configuración. + +
+Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo + +Hosts virtuales +Proxy +Uso de RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
+ + Prohibir el "Hotlinking" de imágenes + +
+
Descripción:
+ +
+

La siguiente técnica prohíbe la práctica de que otros sitios + incluyan sus imágenes en línea en sus páginas. Esta práctica se + conoce a menudo como "hotlinking", y resulta en que + su ancho de banda se use para servir contenido del sitio de + otra persona.

+
+ +
Solución:
+ +
+

Esta técnica se basa en el valor de la + variable HTTP_REFERER, que es opcional. Como + tal, es posible que algunas personas eviten esta + limitación. Sin embargo, la mayoría de los usuarios experimentarán la + solicitud fallida, lo que debería, con el tiempo, resultar en que la + imagen sea eliminada del otro sitio.

+

Hay varias formas en las que puede manejar esta + situación.

+ +

En este primer ejemplo, simplemente denegamos la solicitud, si no se + originó desde una página en nuestro sitio. Para el propósito de este ejemplo, + asumimos que nuestro sitio es www.example.com.

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

En este segundo ejemplo, en lugar de denegar la solicitud, mostramos + una imagen alternativa en su lugar.

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

En el tercer ejemplo, redirigimos la solicitud a una imagen en algún + otro sitio.

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

De estas técnicas, las dos últimas tienden a ser las más efectivas + para lograr que la gente deje de hacer hotlinking de sus imágenes, porque + simplemente no verán la imagen que esperaban ver.

+ +
+ +
Discusión:
+ +
+

Si todo lo que desea hacer es denegar el acceso al recurso, en lugar + de redirigir esa solicitud a otro lugar, esto se puede + lograr sin el uso de mod_rewrite:

+ + +SetEnvIf Referer example\.com localreferer +<FilesMatch "\.(jpg|png|gif)$"> + Require env localreferer +</FilesMatch> + +
+
+ +
+ +
+ + Bloqueo de Robots + +
+
Descripción:
+ +
+

+ En esta receta, discutimos cómo bloquear solicitudes persistentes de + un robot o agente de usuario en particular.

+ +

El estándar para exclusión de robots define un archivo, + /robots.txt que especifica aquellas partes de su + sitio web donde desea excluir robots. Sin embargo, algunos robots + no respetan estos archivos. +

+ +

Tenga en cuenta que hay métodos para lograr esto que no + usan mod_rewrite. Tenga en cuenta también que cualquier técnica que dependa + de la cadena USER_AGENT del cliente puede ser evitada + muy fácilmente, ya que esa cadena puede cambiarse.

+
+ +
Solución:
+ +
+

Usamos un conjunto de reglas que especifica el directorio a ser + protegido, y el USER_AGENT del cliente que + identifica al robot malicioso o persistente.

+ +

En este ejemplo, estamos bloqueando un robot llamado + NameOfBadRobot de una ubicación + /secret/files. También puede especificar un rango de + direcciones IP, si está intentando bloquear ese agente de usuario solo desde + la fuente particular.

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

+ En lugar de usar mod_rewrite para esto, puede lograr el + mismo resultado usando medios alternativos, como se ilustra aquí: +

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

+ Como se indicó anteriormente, esta técnica es trivial de evadir, simplemente + modificando la cabecera de solicitud USER_AGENT. Si + está experimentando un ataque sostenido, debería considerar bloquearlo + a un nivel superior, como en su firewall. +

+ +
+ +
+ +
+ +
+ + Denegación de Hosts en una Lista de Rechazo + +
+
Descripción:
+ +
+

Deseamos mantener una lista de hosts, similar a + hosts.deny, y hacer que esos hosts sean bloqueados + del acceso a nuestro servidor.

+
+ +
Solución:
+ +
+ +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
+##
+## ¡ATENCIÓN! Esto es un mapa, no una lista, incluso cuando lo tratamos como tal.
+## mod_rewrite lo analiza buscando pares clave/valor, así que al menos un
+## valor ficticio "-" debe estar presente para cada entrada.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+
+ +
Discusión:
+
+

+ La segunda RewriteCond asume que tiene HostNameLookups activado, + de modo que las direcciones IP de los clientes sean resueltas. Si ese no es el + caso, debería eliminar la segunda RewriteCond, y eliminar la + bandera [OR] de la primera RewriteCond. +

+
+
+ +
+ +
+ + Deflector basado en Referer + +
+
Descripción:
+ +
+

Redirigir solicitudes basadas en el Referer del cual provino la solicitud, + con diferentes destinos por Referer.

+
+ +
Solución:
+ +
+

El siguiente conjunto de reglas usa un archivo de mapa para asociar cada Referer + con un destino de redirección.

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

El archivo de mapa lista los destinos de redirección para cada referer, o, si + simplemente deseamos redirigir de vuelta a donde vinieron, se coloca un "-" + en el mapa:

+ + +## +## 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/ + + +
+
+ +
+ +
diff --git a/docs/manual/rewrite/access.xml.ja b/docs/manual/rewrite/access.xml.ja new file mode 100644 index 0000000000..5f5626f1e9 --- /dev/null +++ b/docs/manual/rewrite/access.xml.ja @@ -0,0 +1,301 @@ + + + + + + + + + Rewrite + +mod_rewrite を使ったアクセス制御 + + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +mod_rewrite を使用してさまざまなリソースへのアクセスを制御する方法と、 +その他の関連テクニックについて説明します。 +mod_rewrite の一般的な使用例を多数含んでおり、 +それぞれの動作についての詳細な説明も含まれています。

+ +これらの例の多くは、特定のサーバ設定ではそのまま +動作しないことに注意してください。そのため、単にコピー&ペーストするのではなく、 +内容を理解することが重要です。 + +
+モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング + +バーチャルホスト +プロキシ +RewriteMap の使用 +高度なテクニック +mod_rewrite を使わない場合 + +
+ + 画像の "直リンク" の禁止 + +
+
説明:
+ +
+

以下のテクニックは、他のサイトがあなたの画像をそのページに + インラインで含める行為を禁止します。この行為は + "直リンク" と呼ばれることが多く、あなたの帯域幅が + 他のサイトのコンテンツ提供のために使用される結果となります。

+
+ +
解決方法:
+ +
+

このテクニックは HTTP_REFERER 変数の値に + 依存していますが、この値はオプションです。そのため、一部の + ユーザはこの制限を回避できます。ただし、ほとんどのユーザは + リクエスト失敗を経験し、時間の経過とともにその画像が + 他のサイトから削除される結果となるはずです。

+

この状況に対処する方法はいくつかあります。

+ +

最初の例では、リクエストが当サイトのページから開始されたものでない + 場合、単純にリクエストを拒否します。この例では、当サイトが + www.example.com であると仮定しています。

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

2 番目の例では、リクエストを失敗させる代わりに、 + 代替画像を表示します。

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

3 番目の例では、リクエストを他のサイトの画像にリダイレクト + します。

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

これらのテクニックのうち、後の 2 つが画像の直リンクをやめさせる + のに最も効果的です。期待していた画像が表示されなくなるためです。

+ +
+ +
議論:
+ +
+

リクエストを他の場所にリダイレクトするのではなく、単にリソースへの + アクセスを拒否したいだけの場合、mod_rewrite を使わずに + 実現できます:

+ + +SetEnvIf Referer example\.com localreferer +<FilesMatch "\.(jpg|png|gif)$"> + Require env localreferer +</FilesMatch> + +
+
+ +
+ +
+ + ロボットのブロック + +
+
説明:
+ +
+

+ このレシピでは、特定のロボットやユーザエージェントからの + しつこいリクエストをブロックする方法について説明します。

+ +

ロボット排除の標準では、ウェブサイトのどの部分でロボットを + 除外したいかを指定する /robots.txt というファイルが + 定義されています。しかし、一部のロボットはこれらのファイルを + 尊重しません。

+ +

mod_rewrite を使用しない方法もあることに注意してください。 + また、クライアントの USER_AGENT 文字列に依存する + テクニックは、その文字列を変更できるため、非常に簡単に回避できる + ことにも注意してください。

+
+ +
解決方法:
+ +
+

保護するディレクトリと、悪意のあるまたはしつこいロボットを + 識別するクライアント USER_AGENT を指定する + ルールセットを使用します。

+ +

この例では、NameOfBadRobot というロボットを + /secret/files という場所からブロックしています。 + 特定のソースからのみそのユーザエージェントをブロックしたい場合は、 + IP アドレス範囲も指定できます。

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

+ mod_rewrite を使わずに、次に示すような代替手段で + 同じ目的を達成できます: +

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

+ 上記で述べたように、このテクニックは USER_AGENT + リクエストヘッダを変更するだけで簡単に回避できます。持続的な + 攻撃を受けている場合は、ファイアウォールなどのより上位のレベルで + ブロックすることを検討してください。 +

+ +
+ +
+ +
+ +
+ + 拒否リストのホストの拒否 + +
+
説明:
+ +
+

hosts.deny のようなホストのリストを管理し、 + それらのホストがサーバにアクセスするのをブロックしたいと + 考えています。

+
+ +
解決方法:
+ +
+ +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
+##
+## 注意! これはリストではなくマップです。リストとして扱う場合でも、
+## mod_rewrite はキー/値のペアとして解析するため、各エントリに
+## 少なくともダミーの値 "-" が必要です。
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+
+ +
議論:
+
+

+ 2 番目の RewriteCond は、HostNameLookups がオンになっていて、 + クライアント IP アドレスが解決されることを前提としています。 + そうでない場合は、2 番目の RewriteCond を削除し、最初の + RewriteCond から [OR] フラグを削除してください。 +

+
+
+ +
+ +
+ + リファラに基づくデフレクタ + +
+
説明:
+ +
+

リクエストの送信元のリファラに基づいてリクエストをリダイレクトし、 + リファラごとに異なるターゲットを設定します。

+
+ +
解決方法:
+ +
+

以下のルールセットは、マップファイルを使用して各リファラを + リダイレクト先に関連付けます。

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

マップファイルには各リファラのリダイレクト先が記述されています。 + 単にリファラ元にリダイレクトしたい場合は、マップに + "-" を配置します:

+ + +## +## 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/ + + +
+
+ +
+ +
diff --git a/docs/manual/rewrite/access.xml.ko b/docs/manual/rewrite/access.xml.ko new file mode 100644 index 0000000000..f7e1da5a06 --- /dev/null +++ b/docs/manual/rewrite/access.xml.ko @@ -0,0 +1,306 @@ + + + + + + + + + Rewrite + +mod_rewrite를 사용한 접근 제어 + + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +mod_rewrite를 사용하여 다양한 자원에 대한 +접근을 제어하는 방법과 기타 관련 기술을 설명합니다. +여기에는 mod_rewrite의 일반적인 사용 예제가 +많이 포함되어 있으며, 각각이 어떻게 작동하는지에 대한 +자세한 설명이 있습니다.

+ +이 예제들 중 많은 것이 특정 서버 설정에서 +그대로 작동하지 않을 수 있으므로, 단순히 예제를 복사하여 +설정에 붙여넣기보다는 이해하는 것이 중요합니다. + +
+모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 + +가상 호스트 +프록시 +RewriteMap 사용하기 +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
+ + 이미지 "핫링킹" 금지 + +
+
설명:
+ +
+

다음 기술은 다른 사이트가 여러분의 이미지를 + 자신의 페이지에 인라인으로 포함하는 것을 금지합니다. + 이 행위는 흔히 "핫링킹"이라고 하며, + 여러분의 대역폭이 다른 사이트의 콘텐츠를 제공하는 데 + 사용되는 결과를 초래합니다.

+
+ +
해결책:
+ +
+

이 기술은 HTTP_REFERER 변수의 값에 + 의존하며, 이는 선택적입니다. 따라서 일부 사용자가 + 이 제한을 우회할 수 있습니다. 그러나 대부분의 + 사용자는 실패한 요청을 경험하게 되며, 시간이 지나면 + 해당 이미지가 다른 사이트에서 제거되는 결과를 + 가져올 것입니다.

+

이 상황을 처리하는 몇 가지 방법이 있습니다.

+ +

첫 번째 예제에서는 우리 사이트의 페이지에서 시작되지 않은 + 요청을 단순히 거부합니다. 이 예제에서는 우리 사이트가 + www.example.com이라고 가정합니다.

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

두 번째 예제에서는 요청을 실패시키는 대신 + 대체 이미지를 표시합니다.

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

세 번째 예제에서는 요청을 다른 사이트의 이미지로 + 리다이렉트합니다.

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

이 기술들 중 마지막 두 가지가 이미지 핫링킹을 + 중단시키는 데 가장 효과적입니다. 사용자들이 기대한 + 이미지를 볼 수 없기 때문입니다.

+ +
+ +
토론:
+ +
+

요청을 다른 곳으로 리다이렉트하는 것이 아니라 + 단순히 자원에 대한 접근을 거부하려는 경우, + mod_rewrite를 사용하지 않고도 + 이를 수행할 수 있습니다:

+ + +SetEnvIf Referer example\.com localreferer +<FilesMatch "\.(jpg|png|gif)$"> + Require env localreferer +</FilesMatch> + +
+
+ +
+ +
+ + 로봇 차단 + +
+
설명:
+ +
+

이 레시피에서는 특정 로봇 또는 사용자 에이전트의 + 지속적인 요청을 차단하는 방법을 논의합니다.

+ +

로봇 배제 표준은 /robots.txt라는 + 파일을 정의하며, 이 파일은 로봇을 배제하고자 하는 + 웹사이트의 부분을 지정합니다. 그러나 일부 로봇은 + 이 파일을 준수하지 않습니다.

+ +

mod_rewrite를 사용하지 않고도 + 이를 수행할 수 있는 방법이 있다는 점에 유의하십시오. + 또한 클라이언트의 USER_AGENT 문자열에 + 의존하는 기술은 해당 문자열을 쉽게 변경할 수 있으므로 + 매우 쉽게 우회할 수 있다는 점에 유의하십시오.

+
+ +
해결책:
+ +
+

보호할 디렉토리와 악의적이거나 지속적인 로봇을 + 식별하는 클라이언트 USER_AGENT를 + 지정하는 규칙 세트를 사용합니다.

+ +

이 예제에서는 NameOfBadRobot이라는 + 로봇을 /secret/files 위치에서 + 차단합니다. 특정 소스에서만 해당 사용자 에이전트를 + 차단하려는 경우 IP 주소 범위를 지정할 수도 있습니다.

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

+ mod_rewrite를 사용하는 대신, 여기에 설명된 대로 + 다른 방법을 사용하여 동일한 결과를 달성할 수 있습니다: +

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

+ 위에서 언급한 바와 같이, 이 기술은 USER_AGENT + 요청 헤더를 수정하는 것만으로도 쉽게 우회할 수 있습니다. + 지속적인 공격을 받고 있다면, 방화벽과 같은 상위 수준에서 + 차단하는 것을 고려해야 합니다. +

+ +
+ +
+ +
+ +
+ + 거부 목록의 호스트 차단 + +
+
설명:
+ +
+

hosts.deny와 같은 호스트 목록을 관리하여 + 해당 호스트가 서버에 접근하지 못하도록 차단하고자 합니다.

+
+ +
해결책:
+ +
+ +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
+##
+## 주의! 이것은 목록이 아니라 맵입니다.
+## mod_rewrite가 키/값 쌍을 파싱하므로 각 항목에
+## 최소한 더미 값 "-"이 있어야 합니다.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+
+ +
토론:
+
+

+ 두 번째 RewriteCond는 HostNameLookups가 켜져 있어 + 클라이언트 IP 주소가 해석된다고 가정합니다. 그렇지 + 않은 경우, 두 번째 RewriteCond를 삭제하고 첫 번째 + RewriteCond에서 [OR] 플래그를 제거해야 + 합니다. +

+
+
+ +
+ +
+ + 리퍼러 기반 디플렉터 + +
+
설명:
+ +
+

요청이 온 리퍼러에 따라 요청을 리다이렉트하며, + 리퍼러별로 다른 대상을 지정합니다.

+
+ +
해결책:
+ +
+

다음 규칙 세트는 맵 파일을 사용하여 각 리퍼러를 + 리다이렉션 대상과 연결합니다.

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

맵 파일은 각 리퍼러에 대한 리다이렉션 대상을 + 나열하거나, 단순히 원래 위치로 리다이렉트하려는 + 경우 맵에 "-"을 넣습니다:

+ + +## +## 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/ + + +
+
+ +
+ +
diff --git a/docs/manual/rewrite/access.xml.meta b/docs/manual/rewrite/access.xml.meta index cda0183580..362dc08a8f 100644 --- a/docs/manual/rewrite/access.xml.meta +++ b/docs/manual/rewrite/access.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/access.xml.tr b/docs/manual/rewrite/access.xml.tr new file mode 100644 index 0000000000..6a2edcc8ad --- /dev/null +++ b/docs/manual/rewrite/access.xml.tr @@ -0,0 +1,308 @@ + + + + + + + + + Rewrite + +Erişim Denetimi için mod_rewrite Kullanımı + + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +Çeşitli kaynaklara erişimi denetlemek için mod_rewrite +modülünü nasıl kullanabileceğinizi ve diğer ilgili teknikleri açıklar. +mod_rewrite modülünün yaygın kullanımlarına ilişkin, +her birinin nasıl çalıştığının ayrıntılı açıklamalarını içeren birçok +örnek sunulmaktadır.

+ +Bu örneklerin birçoğunun sizin sunucu yapılandırmanızda +değişiklik yapılmadan çalışmayacağını unutmayın; bu nedenle örnekleri +yapılandırmanıza kopyalayıp yapıştırmak yerine anlamanız +önemlidir. + +
+Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme + +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
+ + Resim "Hotlinking"inin Engellenmesi + +
+
Açıklama:
+ +
+

Aşağıdaki teknik, diğer sitelerin resimlerinizi kendi + sayfalarına satır içi olarak dahil etme uygulamasını engeller. + Bu uygulama genellikle "hotlinking" olarak anılır ve + bant genişliğinizin başkasının sitesi için içerik sunmak + amacıyla kullanılmasına neden olur.

+
+ +
Çözüm:
+ +
+

Bu teknik, isteğe bağlı olan HTTP_REFERER + değişkeninin değerine dayanır. Bu nedenle, bazı kişilerin bu + sınırlamayı atlaması mümkündür. Ancak çoğu kullanıcı başarısız + isteği deneyimleyecektir ve bu, zamanla resmin o diğer siteden + kaldırılmasına yol açacaktır.

+

Bu durumu ele almanın birkaç yolu vardır.

+ +

Bu ilk örnekte, istek sitemizden bir sayfadan başlatılmadıysa + isteği reddederiz. Bu örnek için sitemizin + www.example.com olduğunu varsayıyoruz.

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

Bu ikinci örnekte, isteği reddetmek yerine alternatif bir resim + gösteriyoruz.

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

Üçüncü örnekte, isteği başka bir sitedeki bir resme + yönlendiriyoruz.

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

Bu tekniklerden son ikisi, insanların resimlerinizi + hotlinking yapmayı bırakmasını sağlamada en etkili olanlardır; + çünkü görmeyi bekledikleri resmi göremeyeceklerdir.

+ +
+ +
Tartışma:
+ +
+

Tek yapmak istediğiniz kaynağa erişimi reddetmekse, isteği + başka bir yere yönlendirmek yerine bu, + mod_rewrite kullanılmadan da + gerçekleştirilebilir:

+ + +SetEnvIf Referer example\.com localreferer +<FilesMatch "\.(jpg|png|gif)$"> + Require env localreferer +</FilesMatch> + +
+
+ +
+ +
+ + Robotların Engellenmesi + +
+
Açıklama:
+ +
+

+ Bu tarifle, belirli bir robot veya kullanıcı aracısından gelen + sürekli isteklerin nasıl engelleneceğini tartışıyoruz.

+ +

Robot dışlama standardı, web sitenizin robotları dışlamak + istediğiniz bölümlerini belirten /robots.txt + adında bir dosya tanımlar. Ancak bazı robotlar bu dosyalara + uymaz.

+ +

Bunu gerçekleştirmenin mod_rewrite + kullanmayan yöntemleri olduğunu unutmayın. Ayrıca istemcinin + USER_AGENT dizgesine dayanan herhangi bir tekniğin + kolayca atlanabileceğini de unutmayın; çünkü bu dizge + değiştirilebilir.

+
+ +
Çözüm:
+ +
+

Korunacak dizini ve zararlı ya da ısrarcı robotu tanımlayan + istemci USER_AGENT dizgesini belirten bir kural + kümesi kullanıyoruz.

+ +

Bu örnekte, NameOfBadRobot adlı bir robotu + /secret/files konumundan engelliyoruz. Kullanıcı + aracısını yalnızca belirli bir kaynaktan engellemek istiyorsanız + bir IP adresi aralığı da belirtebilirsiniz.

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

+ Bunun için mod_rewrite kullanmak yerine, aynı + sonucu burada gösterildiği gibi alternatif yollarla elde + edebilirsiniz: +

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

+ Yukarıda belirtildiği gibi, bu teknik USER_AGENT + istek başlığını değiştirerek kolayca atlanabilir. Sürekli bir + saldırıyla karşılaşıyorsanız, bunu güvenlik duvarınız gibi daha + üst bir düzeyde engellemeyi düşünmelisiniz. +

+ +
+ +
+ +
+ +
+ + Reddetme Listesindeki Konakların Engellenmesi + +
+
Açıklama:
+ +
+

hosts.deny gibi bir konak listesi tutmak ve bu + konakların sunucumuza erişimini engellemek istiyoruz.

+
+ +
Çözüm:
+ +
+ +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
+##
+## DİKKAT! Bu bir liste değil, bir eşlem dosyasıdır.
+## mod_rewrite bunu anahtar/değer çiftleri olarak çözümler,
+## bu yüzden her girdi için en azından bir yapay "-" değeri
+## mevcut olmalıdır.
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+
+ +
Tartışma:
+
+

+ İkinci RewriteCond, istemci IP adreslerinin çözümlenmesi için + HostNameLookups özelliğinin açık olduğunu varsayar. Durum böyle + değilse, ikinci RewriteCond'u kaldırmalı ve birinci RewriteCond'dan + [OR] bayrağını çıkarmalısınız. +

+
+
+ +
+ +
+ + Referer Tabanlı Yönlendirici + +
+
Açıklama:
+ +
+

İstekleri, isteğin geldiği Referer'a göre, her Referer için + farklı hedeflerle yeniden yönlendirir.

+
+ +
Çözüm:
+ +
+

Aşağıdaki kural kümesi, her Referer'ı bir yönlendirme hedefiyle + ilişkilendirmek için bir eşlem dosyası kullanır.

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

Eşlem dosyası, her referer için yeniden yönlendirme hedeflerini + listeler veya yalnızca geldikleri yere geri yönlendirmek + istiyorsak eşleme bir "-" konur:

+ + +## +## 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/ + + +
+
+ +
+ +
diff --git a/docs/manual/rewrite/access.xml.zh-cn b/docs/manual/rewrite/access.xml.zh-cn new file mode 100644 index 0000000000..fb585c22b5 --- /dev/null +++ b/docs/manual/rewrite/access.xml.zh-cn @@ -0,0 +1,283 @@ + + + + + + + + + Rewrite + +使用 mod_rewrite 控制访问 + + + +

本文档是 mod_rewrite +参考文档的补充。它描述了如何使用 +mod_rewrite 来控制对各种资源的访问,以及其他相关技术。 +其中包括许多 mod_rewrite 的常见用法示例, +以及每个示例工作原理的详细描述。

+ +请注意,这些示例中的许多不会在你的特定服务器配置中直接生效, +因此理解它们非常重要,而不仅仅是将示例复制粘贴到你的配置中。 + +
+模块文档 +mod_rewrite 简介 +重定向和重映射 + +虚拟主机 +代理 +使用 RewriteMap +高级技术 +何时不使用 mod_rewrite + +
+ + 禁止图片"盗链" + +
+
描述:
+ +
+

以下技术禁止其他站点将你的图片内联到他们的页面中。 + 这种做法通常被称为"盗链",会导致你的带宽被用来为他人的站点提供内容。

+
+ +
解决方案:
+ +
+

此技术依赖于 HTTP_REFERER 变量的值, + 该变量是可选的。因此,某些人可能会绕过此限制。 + 但是,大多数用户将会遇到请求失败的情况, + 随着时间推移,这应该会导致图片从其他站点上被移除。

+

有几种方法可以处理这种情况。

+ +

在第一个示例中,如果请求不是从我们站点上的页面发起的, + 我们只是简单地拒绝请求。在本示例中, + 我们假设我们的站点是 www.example.com。

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

在第二个示例中,我们不是让请求失败,而是显示一个替代图片。

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

在第三个示例中,我们将请求重定向到另一个站点上的图片。

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

在这些技术中,后两种往往最能有效地阻止盗链行为, + 因为他们根本看不到预期的图片。

+ +
+ +
讨论:
+ +
+

如果你只想拒绝对资源的访问,而不是将请求重定向到其他地方, + 可以不使用 mod_rewrite 来实现:

+ + +SetEnvIf Referer example\.com localreferer +<FilesMatch "\.(jpg|png|gif)$"> + Require env localreferer +</FilesMatch> + +
+
+ +
+ +
+ + 阻止机器人 + +
+
描述:
+ +
+

在本配置方案中,我们讨论如何阻止来自特定机器人或用户代理的持续请求。

+ +

机器人排除标准定义了一个文件 /robots.txt, + 用于指定你网站中希望排除机器人访问的部分。但是,某些机器人不遵守这些文件。

+ +

请注意,有些方法可以在不使用 mod_rewrite 的情况下实现此目的。 + 还要注意,任何依赖客户端 USER_AGENT + 字符串的技术都可以很容易地被绕过,因为该字符串可以被更改。

+
+ +
解决方案:
+ +
+

我们使用一组规则来指定要保护的目录, + 以及标识恶意或持续机器人的客户端 USER_AGENT。

+ +

在本示例中,我们从位置 /secret/files + 阻止一个名为 NameOfBadRobot 的机器人。 + 如果你只想从特定来源阻止该用户代理, + 也可以指定 IP 地址范围。

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

+ 你可以使用替代方法来实现相同的目的,而不必使用 + mod_rewrite,如下所示: +

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

+ 如上所述,这种技术很容易被绕过,只需修改 + USER_AGENT 请求头即可。如果你遭受持续攻击, + 应考虑在更高层级(如防火墙)进行阻止。 +

+ +
+ +
+ +
+ +
+ + 拒绝列表中的主机 + +
+
描述:
+ +
+

我们希望维护一个主机列表,类似于 hosts.deny, + 并阻止这些主机访问我们的服务器。

+
+ +
解决方案:
+ +
+ +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
+##
+## 注意!这是一个映射文件,不是列表,即使我们将其作为列表使用。
+## mod_rewrite 将其解析为键/值对,因此每个条目
+## 至少必须存在一个虚拟值 "-"。
+##
+
+193.102.180.41 -
+bsdti1.sdm.de -
+192.76.162.40 -
+
+
+ +
讨论:
+
+

+ 第二个 RewriteCond 假设你已启用 HostNameLookups, + 以便客户端 IP 地址会被解析。如果未启用, + 你应该删除第二个 RewriteCond,并从第一个 RewriteCond 中删除 + [OR] 标志。 +

+
+
+ +
+ +
+ + 基于 Referer 的转向器 + +
+
描述:
+ +
+

根据请求来源的 Referer 重定向请求, + 对每个 Referer 使用不同的目标。

+
+ +
解决方案:
+ +
+

以下规则集使用映射文件将每个 Referer 与重定向目标关联。

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

映射文件列出了每个 referer 的重定向目标, + 或者如果我们只想重定向回他们的来源地,则在映射中放置 "-":

+ + +## +## 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/ + + +
+
+ +
+ +
diff --git a/docs/manual/rewrite/advanced.xml.de b/docs/manual/rewrite/advanced.xml.de new file mode 100644 index 0000000000..aee08b66f9 --- /dev/null +++ b/docs/manual/rewrite/advanced.xml.de @@ -0,0 +1,366 @@ + + + + + + + + + Rewrite + +Fortgeschrittene Techniken mit mod_rewrite + + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es bietet +einige fortgeschrittene Techniken zur Verwendung von mod_rewrite.

+ + + +Beachten Sie, dass viele dieser Beispiele nicht unverändert in Ihrer +speziellen Serverkonfiguration funktionieren werden. Es ist daher wichtig, dass Sie +sie verstehen, anstatt die Beispiele einfach auszuschneiden und in Ihre +Konfiguration einzufügen. + +
+Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung +Zugriffskontrolle +Virtuelle Hosts +Proxying +Verwendung von RewriteMap + +Wann man mod_rewrite nicht verwenden sollte + +
+ + URL-basiertes Sharding über mehrere Backends + +
+
Beschreibung:
+ +
+

Eine gängige Technik zur Verteilung der Serverlast oder des + Speicherplatzes wird als "Sharding" bezeichnet. + Bei Verwendung dieser Methode verwendet ein Frontend-Server die + URL, um Benutzer oder Objekte konsistent auf separate + Backend-Server zu "verteilen".

+
+ +
Lösung:
+ +
+

Eine Zuordnung von Benutzern zu Zielservern wird in externen + Map-Dateien gepflegt. Diese sehen wie folgt aus:

+ + +user1 physical_host_of_user1
+user2 physical_host_of_user2
+# ... und so weiter +
+ +

Wir legen dies in eine map.users-to-hosts-Datei. Das + Ziel ist es, folgende Zuordnung vorzunehmen:

+ + +/u/user1/anypath + + +

zu

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

Somit muss nicht jeder URL-Pfad auf jedem physischen Backend-Host + gültig sein. Der folgende Regelsatz erledigt dies für uns mit Hilfe der + Map-Dateien, wobei server0 ein Standardserver ist, der verwendet wird, + wenn ein Benutzer keinen Eintrag in der Map hat:

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

Siehe die RewriteMap-Dokumentation + und das RewriteMap-HowTo + für weitere Informationen zur Syntax dieser Direktive.

+ +
+ +
+ + Dynamische Inhaltsregenerierung + +
+
Beschreibung:
+ +
+

Wir möchten Inhalte dynamisch generieren, sie aber statisch + speichern, sobald sie einmal generiert wurden. Diese Regel prüft, + ob die statische Datei vorhanden ist, und generiert sie, falls + nicht. Die statischen Dateien können bei Bedarf regelmäßig + entfernt werden (z.B. per Cron) und werden bei Bedarf neu + generiert.

+
+ +
Lösung:
+ +
+ Dies wird durch den folgenden Regelsatz erreicht: + + +# This example is valid in per-directory context only +RewriteCond "%{REQUEST_URI}" !-U +RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L] + + +

Der -U-Operator prüft, ob der Teststring + (in diesem Fall REQUEST_URI) eine gültige URL ist. Er + macht dies über eine Unteranfrage. Falls diese Unteranfrage fehlschlägt - + das heißt, die angeforderte Ressource existiert nicht - ruft diese + Regel das CGI-Programm /regenerate_page.cgi auf, das + die angeforderte Ressource generiert und im Dokumentenverzeichnis + speichert, sodass beim nächsten Aufruf eine statische Kopie + ausgeliefert werden kann.

+ +

Auf diese Weise können Dokumente, die selten aktualisiert werden, in + statischer Form ausgeliefert werden. Wenn Dokumente aktualisiert werden + müssen, können sie aus dem Dokumentenverzeichnis gelöscht werden, und sie + werden dann beim nächsten Aufruf erneut generiert.

+
+
+ +
+ +
+ + Lastverteilung + +
+
Beschreibung:
+ +
+

Wir möchten die Last zufällig auf mehrere Server verteilen, + indem wir mod_rewrite verwenden.

+
+ +
Lösung:
+ +
+

Wir verwenden RewriteMap und eine Serverliste, + um dies zu erreichen.

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

serverlist.txt enthält eine Liste der Server:

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

Wenn Sie möchten, dass ein bestimmter Server mehr Last als die +anderen erhält, fügen Sie ihn mehrmals zur Liste hinzu.

+ +
+ +
Diskussion
+
+

Apache wird mit einem Lastverteilungsmodul ausgeliefert - +mod_proxy_balancer - das wesentlich flexibler und +funktionsreicher ist als alles, was Sie mit mod_rewrite +zusammenstellen können.

+
+
+ +
+ +
+ + Strukturierte Benutzerverzeichnisse + +
+
Beschreibung:
+ +
+

Einige Websites mit Tausenden von Benutzern verwenden ein + strukturiertes Heimatverzeichnis-Layout, d.h. jedes + Heimatverzeichnis befindet sich in einem Unterverzeichnis, das + (beispielsweise) mit dem ersten Zeichen des Benutzernamens beginnt. + So ist /~larry/anypath gleich + /home/l/larry/public_html/anypath, + während /~waldo/anypath gleich + /home/w/waldo/public_html/anypath ist.

+
+ +
Lösung:
+ +
+

Wir verwenden den folgenden Regelsatz, um die Tilde-URLs + in das obige Layout umzusetzen.

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

Standardmäßig funktioniert die Umleitung zu einem HTML-Anker nicht, + da mod_rewrite das #-Zeichen maskiert und + es in %23 umwandelt. Dies wiederum unterbricht die + Umleitung.

+
+ +
Lösung:
+ +
+

Verwenden Sie das [NE]-Flag in der + RewriteRule. NE steht für No Escape (Nicht maskieren). +

+
+ +
Diskussion:
+
Diese Technik funktioniert natürlich auch mit anderen + Sonderzeichen, die mod_rewrite standardmäßig URL-kodiert.
+
+ +
+ +
+ + Zeitabhängiges Umschreiben + +
+
Beschreibung:
+ +
+

Wir möchten mod_rewrite verwenden, um je nach Tageszeit + unterschiedliche Inhalte auszuliefern.

+
+ +
Lösung:
+ +
+

Es gibt viele Variablen namens TIME_xxx + für Rewrite-Bedingungen. In Verbindung mit den speziellen + lexikographischen Vergleichsmustern <STRING, + >STRING und =STRING können wir + zeitabhängige Umleitungen durchführen:

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

Dies liefert den Inhalt von foo.day.html + unter der URL foo.html von + 07:01-18:59 und zur restlichen Zeit den + Inhalt von foo.night.html.

+ + mod_cache, Zwischenproxys + und Browser können jeweils Antworten zwischenspeichern und dazu + führen, dass eine der beiden Seiten außerhalb des konfigurierten + Zeitfensters angezeigt wird. + mod_expires kann verwendet werden, um diesen + Effekt zu kontrollieren. Es ist natürlich viel besser, die + Inhalte einfach dynamisch auszuliefern und basierend auf der + Tageszeit anzupassen. + +
+
+ +
+ +
+ + Umgebungsvariablen basierend auf URL-Teilen setzen + +
+
Beschreibung:
+ +
+

Manchmal möchten wir eine Art Status beibehalten, wenn wir + ein Umschreiben durchführen. Beispielsweise möchten Sie sich + merken, dass dieses Umschreiben stattgefunden hat, damit Sie + später prüfen können, ob eine Anfrage über dieses Umschreiben + kam. Eine Möglichkeit dafür ist das Setzen einer + Umgebungsvariable.

+
+ +
Lösung:
+ +
+

Verwenden Sie das [E]-Flag, um eine Umgebungsvariable zu setzen.

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

Später in Ihrem Regelsatz können Sie diese Umgebungsvariable + mit einer RewriteCond prüfen:

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

Beachten Sie, dass Umgebungsvariablen eine externe Umleitung nicht + überleben. Sie könnten stattdessen das [CO]-Flag verwenden, um ein + Cookie zu setzen. Für Verzeichniskontext- und htaccess-Umschreibungen, + bei denen die endgültige Ersetzung als interne Umleitung verarbeitet + wird, werden Umgebungsvariablen aus der vorherigen Runde des + Umschreibens mit dem Präfix "REDIRECT_" versehen.

+ +
+
+ +
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/advanced.xml.es b/docs/manual/rewrite/advanced.xml.es new file mode 100644 index 0000000000..06d537a17b --- /dev/null +++ b/docs/manual/rewrite/advanced.xml.es @@ -0,0 +1,358 @@ + + + + + + + + + Rewrite + +Técnicas avanzadas con mod_rewrite + + + +

Este documento complementa la mod_rewrite +documentación de referencia. Proporciona +algunas técnicas avanzadas usando mod_rewrite.

+ + + +Tenga en cuenta que muchos de estos ejemplos no funcionarán sin cambios en su +configuración particular del servidor, por lo que es importante que los +entienda, en lugar de simplemente copiar y pegar los ejemplos en su +configuración. + +
+Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo +Control de acceso +Hosts virtuales +Proxy +Uso de RewriteMap + +Cuándo no usar mod_rewrite + +
+ + Fragmentación basada en URL entre múltiples backends + +
+
Descripción:
+ +
+

Una técnica común para distribuir la carga del + servidor o el espacio de almacenamiento se llama "fragmentación" (sharding). + Al usar este método, un servidor front-end usará la + URL para "fragmentar" consistentemente usuarios u objetos a servidores + backend separados.

+
+ +
Solución:
+ +
+

Se mantiene un mapeo, de usuarios a servidores destino, en + archivos de mapa externos. Tienen este aspecto:

+ + +user1 physical_host_of_user1
+user2 physical_host_of_user2
+# ... y así sucesivamente +
+ +

Colocamos esto en un archivo map.users-to-hosts. El + objetivo es mapear;

+ + +/u/user1/anypath + + +

a

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

por lo que no es necesario que cada ruta URL sea válida en cada host físico + backend. El siguiente conjunto de reglas hace esto por nosotros con la ayuda de los + archivos de mapa, asumiendo que server0 es un servidor predeterminado que se usará si + un usuario no tiene entrada en el mapa:

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

Consulte la documentación de la directiva RewriteMap + y el Cómo usar RewriteMap + para más discusión de la sintaxis de esta directiva.

+ +
+ +
+ + Regeneración de Contenido sobre la marcha + +
+
Descripción:
+ +
+

Deseamos generar contenido dinámicamente, pero almacenarlo + estáticamente una vez que se ha generado. Esta regla verificará la + existencia del archivo estático, y si no está allí, lo generará. + Los archivos estáticos pueden eliminarse periódicamente, si se desea (digamos, + mediante cron) y se regenerarán bajo demanda.

+
+ +
Solución:
+ +
+ Esto se hace mediante el siguiente conjunto de reglas: + + +# This example is valid in per-directory context only +RewriteCond "%{REQUEST_URI}" !-U +RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L] + + +

El operador -U determina si la cadena de prueba + (en este caso, REQUEST_URI) es una URL válida. Lo hace + mediante una sub-solicitud. En el caso de que esta sub-solicitud falle - + es decir, el recurso solicitado no existe - esta regla invoca + el programa CGI /regenerate_page.cgi, que genera + el recurso solicitado y lo guarda en el directorio de documentos, de modo + que la próxima vez que se solicite, se pueda servir una copia estática.

+ +

De esta manera, documentos que se actualizan con poca frecuencia pueden servirse en + forma estática. Si los documentos necesitan actualizarse, pueden eliminarse + del directorio de documentos, y se regenerarán la + próxima vez que se soliciten.

+
+
+ +
+ +
+ + Balanceo de Carga + +
+
Descripción:
+ +
+

Deseamos distribuir aleatoriamente la carga entre varios servidores + usando mod_rewrite.

+
+ +
Solución:
+ +
+

Usaremos RewriteMap y una lista de servidores + para lograr esto.

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

serverlist.txt contendrá una lista de los servidores:

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

Si desea que un servidor particular reciba más carga que los +otros, agreguelo más veces a la lista.

+ +
+ +
Discusión
+
+

Apache viene con un módulo de balanceo de carga - +mod_proxy_balancer - que es mucho más flexible y +con más funcionalidades que cualquier cosa que pueda construir usando mod_rewrite.

+
+
+ +
+ +
+ + Directorios de Usuario Estructurados + +
+
Descripción:
+ +
+

Algunos sitios con miles de usuarios usan una + disposición de directorio personal estructurada, es decir, cada directorio personal está en un + subdirectorio que comienza (por ejemplo) con el primer + carácter del nombre de usuario. Así, /~larry/anypath + es /home/l/larry/public_html/anypath + mientras que /~waldo/anypath es + /home/w/waldo/public_html/anypath.

+
+ +
Solución:
+ +
+

Usamos el siguiente conjunto de reglas para expandir las URLs de tilde + a la disposición anterior.

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

Por defecto, redirigir a un ancla HTML no funciona, + porque mod_rewrite escapa el carácter #, + convirtiéndolo en %23. Esto, a su vez, rompe la + redirección.

+
+ +
Solución:
+ +
+

Use la bandera [NE] en la + RewriteRule. NE significa No Escapar. +

+
+ +
Discusión:
+
Esta técnica por supuesto también funcionará con otros + caracteres especiales que mod_rewrite, por defecto, codifica en URL.
+
+ +
+ +
+ + Reescritura Dependiente del Tiempo + +
+
Descripción:
+ +
+

Deseamos usar mod_rewrite para servir contenido diferente basado en + la hora del día.

+
+ +
Solución:
+ +
+

Hay muchas variables llamadas TIME_xxx + para condiciones de reescritura. En conjunto con los patrones + especiales de comparación lexicográfica <STRING, + >STRING y =STRING podemos + hacer redirecciones dependientes del tiempo:

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

Esto proporciona el contenido de foo.day.html + bajo la URL foo.html de + 07:01-18:59 y en el tiempo restante el + contenido de foo.night.html.

+ + mod_cache, proxies intermedios + y navegadores pueden cada uno almacenar en caché las respuestas y causar que cualquiera de las páginas se + muestre fuera de la ventana de tiempo configurada. + Se puede usar mod_expires para controlar este + efecto. Por supuesto, es mucho mejor simplemente servir el + contenido dinámicamente y personalizarlo basándose en la hora del día. + +
+
+ +
+ +
+ + Establecer Variables de Entorno Basadas en Partes de la URL + +
+
Descripción:
+ +
+

A veces, queremos mantener algún tipo de estado cuando + realizamos una reescritura. Por ejemplo, desea tomar nota de que + ha realizado esa reescritura, para poder verificar más tarde si una + solicitud llegó a través de esa reescritura. Una forma de hacer esto es estableciendo una + variable de entorno.

+
+ +
Solución:
+ +
+

Use la bandera [E] para establecer una variable de entorno.

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

Más adelante en su conjunto de reglas puede verificar esta variable + de entorno usando una RewriteCond:

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

Tenga en cuenta que las variables de entorno no sobreviven a una + redirección externa. Podría considerar usar la bandera [CO] para establecer una + cookie. Para reescrituras en contexto per-directorio y htaccess, donde la sustitución + final se procesa como una redirección interna, las variables + de entorno de la ronda anterior de reescritura se prefijan con + "REDIRECT_".

+ +
+
+ +
+ +
diff --git a/docs/manual/rewrite/advanced.xml.ja b/docs/manual/rewrite/advanced.xml.ja new file mode 100644 index 0000000000..6694731875 --- /dev/null +++ b/docs/manual/rewrite/advanced.xml.ja @@ -0,0 +1,361 @@ + + + + + + + + + Rewrite + +mod_rewrite の高度なテクニック + + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +mod_rewrite を使用したいくつかの高度なテクニックを提供します。

+ + + +これらの例の多くは、特定のサーバ設定ではそのまま +動作しないことに注意してください。そのため、単にコピー&ペーストするのではなく、 +内容を理解することが重要です。 + +
+モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング +アクセス制御 +バーチャルホスト +プロキシ +RewriteMap の使用 + +mod_rewrite を使わない場合 + +
+ + URL ベースの複数バックエンドへのシャーディング + +
+
説明:
+ +
+

サーバ負荷やストレージスペースの負担を分散するための + 一般的なテクニックは「シャーディング」と呼ばれます。 + この方法を使用すると、フロントエンドサーバは URL を使用して + ユーザやオブジェクトを別々のバックエンドサーバに一貫して + 「シャード」します。

+
+ +
解決方法:
+ +
+

ユーザからターゲットサーバへのマッピングが外部マップファイルに + 保持されています。次のような形式です:

+ + +user1 physical_host_of_user1
+user2 physical_host_of_user2
+# ... 以下同様 +
+ +

これを map.users-to-hosts ファイルに入れます。目的は + 以下をマッピングすることです:

+ + +/u/user1/anypath + + +

を以下にマッピング:

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

このようにすると、すべての URL パスがすべてのバックエンド物理 + ホストで有効である必要はありません。以下のルールセットは、 + マップファイルの助けを借りてこれを実現します。server0 は、 + ユーザがマップにエントリを持たない場合に使用されるデフォルト + サーバとして想定しています:

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

このディレクティブの構文の詳細については、 + RewriteMap + ドキュメントと RewriteMap ハウツー + を参照してください。

+ +
+ +
+ + オンザフライのコンテンツ再生成 + +
+
説明:
+ +
+

コンテンツを動的に生成したいが、一度生成したら静的に + 保存したいとします。このルールは静的ファイルの存在を確認し、 + 存在しない場合は生成します。静的ファイルは必要に応じて + (例えば cron で) 定期的に削除でき、要求に応じて再生成 + されます。

+
+ +
解決方法:
+ +
+ これは以下のルールセットで実現されます: + + +# This example is valid in per-directory context only +RewriteCond "%{REQUEST_URI}" !-U +RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L] + + +

-U 演算子は、テスト文字列 (この場合は + REQUEST_URI) が有効な URL かどうかを判定します。 + これはサブリクエストを通じて行われます。このサブリクエストが + 失敗した場合、つまりリクエストされたリソースが存在しない場合、 + このルールは CGI プログラム /regenerate_page.cgi + を呼び出し、リクエストされたリソースを生成してドキュメント + ディレクトリに保存します。これにより、次回リクエストされたときに + 静的コピーを提供できます。

+ +

このようにして、更新頻度の低いドキュメントを静的形式で + 提供できます。ドキュメントを更新する必要がある場合は、 + ドキュメントディレクトリから削除すれば、次回リクエストされたときに + 再生成されます。

+
+
+ +
+ +
+ + ロードバランシング + +
+
説明:
+ +
+

mod_rewrite を使用して、複数のサーバに + ランダムに負荷を分散したいとします。

+
+ +
解決方法:
+ +
+

これを実現するために RewriteMap とサーバの + リストを使用します。

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

serverlist.txt にはサーバのリストが含まれます:

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

特定のサーバにより多くの負荷を割り当てたい場合は、 +リストにそのサーバを複数回追加してください。

+ +
+ +
議論
+
+

Apache にはロードバランシングモジュール - +mod_proxy_balancer - が付属しており、 +mod_rewrite で構築できるものよりもはるかに柔軟で +機能豊富です。

+
+
+ +
+ +
+ + 構造化ユーザディレクトリ + +
+
説明:
+ +
+

数千人のユーザを持つサイトの中には、構造化されたホームディレクトリ + レイアウトを使用するものがあります。つまり、各ホームディレクトリは + ユーザ名の最初の文字で始まるサブディレクトリにあります。例えば、 + /~larry/anypath は + /home/l/larry/public_html/anypath + であり、/~waldo/anypath は + /home/w/waldo/public_html/anypath + です。

+
+ +
解決方法:
+ +
+

上記のレイアウトにチルダ URL を展開するために、以下のルールセットを + 使用します。

+ + +RewriteEngine on +RewriteRule "^/~(([a-z])[a-z0-9]+)(.*)" "/home/$2/$1/public_html$3" + +
+
+ +
+ +
+ + アンカーのリダイレクト + +
+
説明:
+ +
+

デフォルトでは、HTML アンカーへのリダイレクトは機能しません。 + mod_rewrite が # 文字をエスケープして + %23 に変換するためです。これによりリダイレクトが + 壊れます。

+
+ +
解決方法:
+ +
+

RewriteRule で [NE] フラグを + 使用します。NE は No Escape (エスケープしない) の略です。 +

+
+ +
議論:
+
このテクニックは、mod_rewrite がデフォルトで + URL エンコードする他の特殊文字にも適用できます。
+
+ +
+ +
+ + 時間に依存する書き換え + +
+
説明:
+ +
+

mod_rewrite を使用して、時間帯に基づいて + 異なるコンテンツを提供したいとします。

+
+ +
解決方法:
+ +
+

書き換え条件に使用できる TIME_xxx という名前の + 変数が多数あります。特殊な辞書順比較パターン + <STRING、>STRING、 + =STRING と組み合わせることで、時間に依存する + リダイレクトを行えます:

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

これにより、URL foo.html で + 07:01-18:59 の間は foo.day.html の + コンテンツを、残りの時間帯は foo.night.html の + コンテンツを提供します。

+ + mod_cache、中間プロキシ、 + およびブラウザはそれぞれレスポンスをキャッシュし、設定された + 時間枠外にいずれかのページが表示される可能性があります。 + mod_expires を使用してこの影響を制御できます。 + もちろん、コンテンツを動的に提供し、時間帯に基づいて + カスタマイズする方がはるかに良いでしょう。 + +
+
+ +
+ +
+ + URL の部分に基づく環境変数の設定 + +
+
説明:
+ +
+

書き換えを実行する際に何らかの状態を維持したい場合が + あります。例えば、書き換えを行ったことをメモし、後でリクエストが + その書き換えを経由したかどうかを確認したいとします。これを行う + 1 つの方法は、環境変数を設定することです。

+
+ +
解決方法:
+ +
+

[E] フラグを使用して環境変数を設定します。

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

後のルールセットで RewriteCond を使用してこの環境変数を + 確認できます:

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

環境変数は外部リダイレクトでは保持されないことに注意 + してください。[CO] フラグを使用して cookie を設定することを + 検討するとよいでしょう。ディレクトリ単位および htaccess の + 書き換えでは、最終的な置換が内部リダイレクトとして処理されるため、 + 前回の書き換えラウンドの環境変数には "REDIRECT_" がプレフィックスとして + 付きます。

+ +
+
+ +
+ +
diff --git a/docs/manual/rewrite/advanced.xml.ko b/docs/manual/rewrite/advanced.xml.ko new file mode 100644 index 0000000000..c27e46140f --- /dev/null +++ b/docs/manual/rewrite/advanced.xml.ko @@ -0,0 +1,352 @@ + + + + + + + + + Rewrite + +mod_rewrite 고급 기술 + + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +mod_rewrite를 사용한 몇 가지 고급 기술을 +제공합니다.

+ +이 예제들 중 많은 것이 특정 서버 설정에서 +그대로 작동하지 않을 수 있으므로, 단순히 예제를 복사하여 +설정에 붙여넣기보다는 이해하는 것이 중요합니다. + +
+모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 +접근 제어 +가상 호스트 +프록시 +RewriteMap 사용하기 + +mod_rewrite를 사용하지 말아야 할 경우 + +
+ + 여러 백엔드에 대한 URL 기반 샤딩 + +
+
설명:
+ +
+

서버 부하나 저장 공간을 분산하는 일반적인 기술을 + "샤딩"이라고 합니다. 이 방법을 사용할 때 프론트엔드 + 서버는 URL을 사용하여 사용자 또는 객체를 별도의 + 백엔드 서버에 일관되게 "샤딩"합니다.

+
+ +
해결책:
+ +
+

사용자에서 대상 서버로의 매핑이 외부 맵 파일에 + 유지됩니다. 다음과 같은 형태입니다:

+ + +user1 physical_host_of_user1
+user2 physical_host_of_user2
+# ... 등등 +
+ +

이것을 map.users-to-hosts 파일에 넣습니다. + 목적은 다음을 매핑하는 것입니다;

+ + +/u/user1/anypath + + +

위의 것을 다음으로:

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

따라서 모든 URL 경로가 모든 백엔드 물리적 호스트에서 + 유효할 필요가 없습니다. 다음 규칙 세트는 맵 파일의 + 도움으로 이를 수행하며, 사용자가 맵에 항목이 없는 + 경우 server0이 기본 서버로 사용됩니다:

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

이 지시어의 구문에 대한 자세한 내용은 + RewriteMap + 문서와 RewriteMap 사용법을 + 참조하십시오.

+ +
+ +
+ + 실시간 콘텐츠 재생성 + +
+
설명:
+ +
+

콘텐츠를 동적으로 생성하되, 한 번 생성되면 + 정적으로 저장하고자 합니다. 이 규칙은 정적 파일의 + 존재를 확인하고, 없으면 생성합니다. 정적 파일은 + 원하는 경우 (예를 들어 cron을 통해) 주기적으로 + 제거할 수 있으며, 필요에 따라 재생성됩니다.

+
+ +
해결책:
+ +
+ 이는 다음 규칙 세트로 수행됩니다: + + +# This example is valid in per-directory context only +RewriteCond "%{REQUEST_URI}" !-U +RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L] + + +

-U 연산자는 테스트 문자열(이 경우 + REQUEST_URI)이 유효한 URL인지 + 판단합니다. 이는 서브요청을 통해 수행됩니다. + 이 서브요청이 실패하면 - 즉, 요청된 자원이 존재하지 + 않으면 - 이 규칙은 CGI 프로그램 + /regenerate_page.cgi를 호출하여 + 요청된 자원을 생성하고 문서 디렉토리에 저장하므로, + 다음에 요청될 때 정적 복사본을 제공할 수 있습니다.

+ +

이 방식으로 자주 업데이트되지 않는 문서를 정적 + 형태로 제공할 수 있습니다. 문서를 새로고침해야 하는 + 경우 문서 디렉토리에서 삭제할 수 있으며, 다음에 + 요청될 때 재생성됩니다.

+
+
+ +
+ +
+ + 부하 분산 + +
+
설명:
+ +
+

mod_rewrite를 사용하여 여러 서버에 + 무작위로 부하를 분산하고자 합니다.

+
+ +
해결책:
+ +
+

RewriteMap과 + 서버 목록을 사용하여 이를 수행합니다.

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

serverlist.txt에는 서버 목록이 포함됩니다:

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

특정 서버가 다른 서버보다 더 많은 부하를 받도록 하려면 +목록에 해당 서버를 더 많이 추가하십시오.

+ +
+ +
토론
+
+

Apache에는 부하 분산 모듈인 +mod_proxy_balancer가 포함되어 있으며, +이것은 mod_rewrite를 사용하여 조합할 수 있는 +어떤 것보다 훨씬 더 유연하고 기능이 풍부합니다.

+
+
+ +
+ +
+ + 구조화된 사용자 디렉토리 + +
+
설명:
+ +
+

수천 명의 사용자가 있는 일부 사이트는 구조화된 + 홈 디렉토리 레이아웃을 사용합니다. 즉, 각 + 홈 디렉토리는 사용자 이름의 첫 번째 문자로 시작하는 + 하위 디렉토리에 있습니다. 예를 들어 + /~larry/anypath는 + /home/l/larry/public_html/anypath이고 + /~waldo/anypath는 + /home/w/waldo/public_html/anypath입니다.

+
+ +
해결책:
+ +
+

위의 레이아웃으로 물결표 URL을 확장하기 위해 + 다음 규칙 세트를 사용합니다.

+ + +RewriteEngine on +RewriteRule "^/~(([a-z])[a-z0-9]+)(.*)" "/home/$2/$1/public_html$3" + +
+
+ +
+ +
+ + 앵커 리다이렉트 + +
+
설명:
+ +
+

기본적으로 HTML 앵커로의 리다이렉트는 작동하지 + 않습니다. mod_rewrite가 # + 문자를 이스케이프하여 %23으로 변환하기 + 때문입니다. 이로 인해 리다이렉션이 중단됩니다.

+
+ +
해결책:
+ +
+

RewriteRule에 [NE] + 플래그를 사용합니다. NE는 No Escape를 의미합니다.

+
+ +
토론:
+
이 기술은 mod_rewrite가 기본적으로 + URL 인코딩하는 다른 특수 문자에도 물론 적용됩니다.
+
+ +
+ +
+ + 시간 기반 재작성 + +
+
설명:
+ +
+

mod_rewrite를 사용하여 시간대에 따라 + 다른 콘텐츠를 제공하고자 합니다.

+
+ +
해결책:
+ +
+

재작성 조건에 사용할 수 있는 TIME_xxx라는 + 많은 변수가 있습니다. 특수 사전식 비교 패턴 + <STRING, >STRING, + =STRING과 함께 시간 기반 리다이렉트를 + 수행할 수 있습니다:

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

이것은 07:01-18:59 사이에는 URL + foo.html 하에 foo.day.html의 + 콘텐츠를 제공하고, 나머지 시간에는 + foo.night.html의 콘텐츠를 제공합니다.

+ + mod_cache, 중간 프록시 + 및 브라우저는 각각 응답을 캐시할 수 있으며, 구성된 + 시간 창 밖에서 어느 쪽 페이지든 표시될 수 있습니다. + mod_expires를 사용하여 이 효과를 + 제어할 수 있습니다. 물론 콘텐츠를 동적으로 제공하고 + 시간대에 따라 사용자 정의하는 것이 훨씬 좋습니다. + +
+
+ +
+ +
+ + URL 부분에 따른 환경 변수 설정 + +
+
설명:
+ +
+

때때로 재작성을 수행할 때 어떤 종류의 상태를 + 유지하고 싶을 수 있습니다. 예를 들어, 해당 재작성을 + 수행했다는 것을 기록하여 나중에 요청이 해당 재작성을 + 통해 왔는지 확인하고 싶을 수 있습니다. 이를 수행하는 + 한 가지 방법은 환경 변수를 설정하는 것입니다.

+
+ +
해결책:
+ +
+

[E] 플래그를 사용하여 환경 변수를 설정합니다.

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

나중에 규칙 세트에서 RewriteCond를 사용하여 + 이 환경 변수를 확인할 수 있습니다:

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

환경 변수는 외부 리다이렉트에서 유지되지 않는다는 + 점에 유의하십시오. 쿠키를 설정하려면 [CO] 플래그를 + 사용하는 것을 고려할 수 있습니다. 디렉토리별 및 + htaccess 재작성에서 최종 치환이 내부 리다이렉트로 + 처리되는 경우, 이전 라운드의 재작성에서 온 환경 변수는 + "REDIRECT_" 접두사가 붙습니다.

+ +
+
+ +
+ +
diff --git a/docs/manual/rewrite/advanced.xml.meta b/docs/manual/rewrite/advanced.xml.meta index 98192e7018..d4121a859a 100644 --- a/docs/manual/rewrite/advanced.xml.meta +++ b/docs/manual/rewrite/advanced.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/advanced.xml.tr b/docs/manual/rewrite/advanced.xml.tr new file mode 100644 index 0000000000..a8361f82ed --- /dev/null +++ b/docs/manual/rewrite/advanced.xml.tr @@ -0,0 +1,362 @@ + + + + + + + + + Rewrite + +mod_rewrite ile İleri Teknikler + + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +mod_rewrite kullanarak birkaç ileri teknik sunar.

+ + + +Bu örneklerin birçoğunun sizin sunucu yapılandırmanızda +değişiklik yapılmadan çalışmayacağını unutmayın; bu nedenle örnekleri +yapılandırmanıza kopyalayıp yapıştırmak yerine anlamanız +önemlidir. + +
+Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme +Erişim denetimi +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı + +mod_rewrite kullanılmaması gereken durumlar + +
+ + Birden Fazla Arka Uç Arasında URL Tabanlı Parçalama + +
+
Açıklama:
+ +
+

Sunucu yükünü veya depolama alanını dağıtmak için yaygın bir + teknik "parçalama" (sharding) olarak adlandırılır. Bu yöntem + kullanıldığında, bir ön uç sunucu kullanıcıları veya nesneleri + tutarlı bir şekilde ayrı arka uç sunuculara "parçalamak" için + URL'yi kullanır.

+
+ +
Çözüm:
+ +
+

Kullanıcılardan hedef sunuculara bir eşleme, harici eşlem + dosyalarında tutulur. Şöyle görünürler:

+ + +user1 physical_host_of_user1
+user2 physical_host_of_user2
+# ... ve böyle devam eder +
+ +

Bunu bir map.users-to-hosts dosyasına koyarız. Amaç + şunu eşlemektir;

+ + +/u/user1/anypath + + +

buna

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

böylece her URL yolunun her arka uç fiziksel konakta geçerli + olması gerekmez. Aşağıdaki kural kümesi, eşlem dosyalarının + yardımıyla bunu bizim için yapar; bir kullanıcının eşlemde + girdisi yoksa server0'ın öntanımlı sunucu olarak + kullanılacağını varsayar:

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

Bu yönergenin sözdizimi hakkında daha fazla tartışma için + RewriteMap belgelerine ve + RewriteMap Nasıl Yapılır belgesine + bakın.

+ +
+ +
+ + Anında İçerik Yeniden Oluşturma + +
+
Açıklama:
+ +
+

İçeriği devingen olarak oluşturmak, ancak oluşturulduktan + sonra statik olarak saklamak istiyoruz. Bu kural, statik dosyanın + varlığını kontrol eder ve yoksa oluşturur. Statik dosyalar + istenirse periyodik olarak (örneğin cron ile) kaldırılabilir ve + istek üzerine yeniden oluşturulur.

+
+ +
Çözüm:
+ +
+ Bu, aşağıdaki kural kümesiyle yapılır: + + +# This example is valid in per-directory context only +RewriteCond "%{REQUEST_URI}" !-U +RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L] + + +

-U işleci, sınama dizgesinin (bu durumda + REQUEST_URI) geçerli bir URL olup olmadığını belirler. + Bunu bir alt istek aracılığıyla yapar. Bu alt istek başarısız + olursa - yani istenen kaynak mevcut değilse - bu kural, istenen + kaynağı oluşturan ve belge dizinine kaydeden + /regenerate_page.cgi CGI programını çalıştırır; böylece + bir sonraki istekte statik bir kopya sunulabilir.

+ +

Bu şekilde, seyrek güncellenen belgeler statik biçimde + sunulabilir. Belgelerin yenilenmesi gerekiyorsa belge dizininden + silinebilir ve bir sonraki istekte yeniden oluşturulur.

+
+
+ +
+ +
+ + Yük Dengeleme + +
+
Açıklama:
+ +
+

mod_rewrite kullanarak yükü birkaç sunucu + arasında rastgele dağıtmak istiyoruz.

+
+ +
Çözüm:
+ +
+

Bunu gerçekleştirmek için RewriteMap ve bir sunucu listesi + kullanacağız.

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

serverlist.txt sunucuların bir listesini içerecektir:

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

Belirli bir sunucunun diğerlerinden daha fazla yük almasını +istiyorsanız, onu listeye daha fazla kez ekleyin.

+ +
+ +
Tartışma
+
+

Apache, mod_rewrite ile bir araya getireceğiniz +herhangi bir şeyden çok daha esnek ve özellik açısından zengin bir yük +dengeleme modülü olan mod_proxy_balancer ile +birlikte gelir.

+
+
+ +
+ +
+ + Yapılandırılmış Kullanıcı Dizinleri + +
+
Açıklama:
+ +
+

Binlerce kullanıcısı olan bazı siteler yapılandırılmış bir + ev dizini düzeni kullanır; yani her ev dizini, kullanıcı + adının (örneğin) ilk karakteriyle başlayan bir alt dizindedir. + Böylece, /~larry/anypath şu olur: + /home/l/larry/public_html/anypath; + /~waldo/anypath ise şu olur: + /home/w/waldo/public_html/anypath.

+
+ +
Çözüm:
+ +
+

Tilde URL'leri yukarıdaki düzene göre genişletmek için + aşağıdaki kural kümesini kullanırız.

+ + +RewriteEngine on +RewriteRule "^/~(([a-z])[a-z0-9]+)(.*)" "/home/$2/$1/public_html$3" + +
+
+ +
+ +
+ + Çapaların Yeniden Yönlendirilmesi + +
+
Açıklama:
+ +
+

Öntanımlı olarak, bir HTML çapasına yönlendirme çalışmaz; + çünkü mod_rewrite # karakterini + kodlayarak %23'e dönüştürür. Bu da yönlendirmeyi + bozar.

+
+ +
Çözüm:
+ +
+

RewriteRule üzerinde [NE] bayrağını + kullanın. NE, Kodlama Yapma (No Escape) anlamına gelir. +

+
+ +
Tartışma:
+
Bu teknik, mod_rewrite modülünün öntanımlı + olarak URL-kodladığı diğer özel karakterlerle de çalışacaktır.
+
+ +
+ +
+ + Zamana Bağlı Yeniden Yazma + +
+
Açıklama:
+ +
+

Günün saatine göre farklı içerik sunmak için + mod_rewrite kullanmak istiyoruz.

+
+ +
Çözüm:
+ +
+

Yeniden yazma koşulları için TIME_xxx adlı birçok + değişken vardır. Özel sözlüksel karşılaştırma kalıpları olan + <DİZGE, >DİZGE ve + =DİZGE ile birlikte zamana bağlı yönlendirmeler + yapabiliriz:

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

Bu, foo.html URL'si altında + 07:01-18:59 saatleri arasında + foo.day.html içeriğini, geri kalan zamanda ise + foo.night.html içeriğini sunar.

+ + mod_cache, ara vekiller + ve tarayıcıların her biri yanıtları önbelleğe alabilir ve + yapılandırılan zaman penceresinin dışında herhangi bir sayfanın + gösterilmesine neden olabilir. Bu etkiyi kontrol etmek için + mod_expires kullanılabilir. Elbette, içeriği + devingen olarak sunmak ve günün saatine göre özelleştirmek çok + daha iyidir. + +
+
+ +
+ +
+ + URL Parçalarına Göre Ortam Değişkenleri Atama + +
+
Açıklama:
+ +
+

Bazen bir yeniden yazma gerçekleştirdiğimizde bir tür durum + bilgisi tutmak isteriz. Örneğin, bu yeniden yazmayı yaptığınıza + dair bir not almak isteyebilirsiniz; böylece daha sonra bir + isteğin bu yeniden yazma yoluyla gelip gelmediğini kontrol + edebilirsiniz. Bunu yapmanın bir yolu bir ortam değişkeni + ayarlamaktır.

+
+ +
Çözüm:
+ +
+

Bir ortam değişkeni ayarlamak için [E] bayrağını kullanın.

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

Daha sonra kural kümenizde bu ortam değişkenini bir RewriteCond + kullanarak kontrol edebilirsiniz:

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

Ortam değişkenlerinin harici bir yönlendirmeden sonra kalıcı + olmadığını unutmayın. [CO] bayrağını kullanarak bir çerez + ayarlamayı düşünebilirsiniz. Dizin başına ve htaccess yeniden + yazmaları için, son değiştirme dahili bir yönlendirme olarak + işlendiğinde, önceki yeniden yazma turundan gelen ortam + değişkenlerinin başına "REDIRECT_" eklenir.

+ +
+
+ +
+ +
diff --git a/docs/manual/rewrite/advanced.xml.zh-cn b/docs/manual/rewrite/advanced.xml.zh-cn new file mode 100644 index 0000000000..40eafe1939 --- /dev/null +++ b/docs/manual/rewrite/advanced.xml.zh-cn @@ -0,0 +1,336 @@ + + + + + + + + + Rewrite + +mod_rewrite 高级技术 + + + +

本文档是 mod_rewrite +参考文档的补充。 +它提供了一些使用 mod_rewrite 的高级技术。

+ + + +请注意,这些示例中的许多不会在你的特定服务器配置中直接生效, +因此理解它们非常重要,而不仅仅是将示例复制粘贴到你的配置中。 + +
+模块文档 +mod_rewrite 简介 +重定向和重映射 +访问控制 +虚拟主机 +代理 +使用 RewriteMap + +何时不使用 mod_rewrite + +
+ + 基于 URL 的跨多后端分片 + +
+
描述:
+ +
+

一种分配服务器负载或存储空间的常见技术称为"分片"。 + 使用此方法时,前端服务器将使用 URL 将用户或对象一致地"分片"到 + 不同的后端服务器。

+
+ +
解决方案:
+ +
+

在外部映射文件中维护从用户到目标服务器的映射。 + 它们看起来像:

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

我们将其放入 map.users-to-hosts 文件。 + 目标是映射:

+ + +/u/user1/anypath + + +

到

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

这样每个 URL 路径不需要在每个后端物理主机上都有效。 + 以下规则集借助映射文件为我们完成此操作, + 假设 server0 是在用户在映射中没有条目时使用的默认服务器:

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

请参阅 RewriteMap + 文档和 RewriteMap 指南 + 以了解此指令语法的更多讨论。

+ +
+ +
+ + 即时内容再生成 + +
+
描述:
+ +
+

我们希望动态生成内容,但一旦生成就将其静态存储。 + 此规则将检查静态文件是否存在,如果不存在,则生成它。 + 静态文件可以定期删除(例如通过 cron), + 并在需要时按需重新生成。

+
+ +
解决方案:
+ +
+ 这通过以下规则集完成: + + +# This example is valid in per-directory context only +RewriteCond "%{REQUEST_URI}" !-U +RewriteRule "^(.+)\.html$" "/regenerate_page.cgi" [PT,L] + + +

-U 操作符确定测试字符串(在本例中为 + REQUEST_URI)是否是有效的 URL。它通过子请求来完成。 + 如果此子请求失败——即请求的资源不存在——此规则将调用 CGI 程序 + /regenerate_page.cgi,该程序生成请求的资源并将其保存到 + 文档目录中,这样下次请求时就可以提供静态副本了。

+ +

通过这种方式,不经常更新的文档可以以静态形式提供。 + 如果需要刷新文档,可以从文档目录中删除它们, + 下次请求时将重新生成。

+
+
+ +
+ +
+ + 负载均衡 + +
+
描述:
+ +
+

我们希望使用 mod_rewrite + 在多台服务器之间随机分配负载。

+
+ +
解决方案:
+ +
+

我们将使用 RewriteMap 和服务器列表来实现。

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

serverlist.txt 将包含服务器列表:

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

如果你希望某台特定服务器承担更多负载,可以在列表中多次添加它。

+ +
+ +
讨论
+
+

Apache 自带一个负载均衡模块 - +mod_proxy_balancer - 它比你使用 +mod_rewrite 拼凑出来的任何方案都更加灵活和功能丰富。

+
+
+ +
+ +
+ + 结构化用户目录 + +
+
描述:
+ +
+

一些拥有数千用户的站点使用结构化的主目录布局, + 即每个主目录位于一个子目录中, + 该子目录以用户名的第一个字符开头。因此, + /~larry/anypath 是 + /home/l/larry/public_html/anypath, + 而 /~waldo/anypath 是 + /home/w/waldo/public_html/anypath。

+
+ +
解决方案:
+ +
+

我们使用以下规则集将波浪号 URL 展开为上述布局。

+ + +RewriteEngine on +RewriteRule "^/~(([a-z])[a-z0-9]+)(.*)" "/home/$2/$1/public_html$3" + +
+
+ +
+ +
+ + 重定向锚点 + +
+
描述:
+ +
+

默认情况下,重定向到 HTML 锚点不起作用,因为 + mod_rewrite 会转义 # 字符, + 将其变为 %23。这反过来会破坏重定向。

+
+ +
解决方案:
+ +
+

在 RewriteRule 上使用 [NE] 标志。 + NE 代表不转义(No Escape)。 +

+
+ +
讨论:
+
此技术当然也适用于 mod_rewrite + 默认会进行 URL 编码的其他特殊字符。
+
+ +
+ +
+ + 基于时间的重写 + +
+
描述:
+ +
+

我们希望使用 mod_rewrite + 根据一天中的时间提供不同的内容。

+
+ +
解决方案:
+ +
+

有许多名为 TIME_xxx + 的变量可用于重写条件。结合特殊的词法比较模式 + <STRING、>STRING 和 + =STRING,我们可以进行基于时间的重定向:

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

这将在 07:01-18:59 时间段内,以 URL + foo.html 提供 foo.day.html 的内容, + 在其余时间提供 foo.night.html 的内容。

+ + mod_cache、中间代理和浏览器 + 可能各自缓存响应,导致在配置的时间窗口之外显示某个页面。 + 可以使用 mod_expires 来控制此效果。 + 当然,动态提供内容并根据时间自定义它是更好的方式。 + +
+
+ +
+ +
+ + 根据 URL 部分设置环境变量 + +
+
描述:
+ +
+

有时,我们希望在执行重写时保持某种状态。例如, + 你想记录你已完成该重写,以便稍后检查请求是否通过该重写。 + 一种方法是设置环境变量。

+
+ +
解决方案:
+ +
+

使用 [E] 标志设置环境变量。

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

稍后在你的规则集中,你可以使用 RewriteCond 检查此环境变量:

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

请注意,环境变量在外部重定向后不会保留。你可以考虑使用 [CO] + 标志来设置 cookie。对于目录级和 htaccess 重写, + 当最终替换作为内部重定向处理时,上一轮重写的环境变量会以 + "REDIRECT_" 为前缀。

+ +
+
+ +
+ +
diff --git a/docs/manual/rewrite/avoid.xml.de b/docs/manual/rewrite/avoid.xml.de new file mode 100644 index 0000000000..a67e1c4eba --- /dev/null +++ b/docs/manual/rewrite/avoid.xml.de @@ -0,0 +1,251 @@ + + + + + + + + + Rewrite + +Wann man mod_rewrite nicht verwenden sollte + + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es beschreibt +vielleicht eines der wichtigsten Konzepte bezüglich mod_rewrite - +nämlich, wann man es vermeiden sollte.

+ +

mod_rewrite sollte als letzter Ausweg betrachtet werden, wenn andere +Alternativen nicht ausreichen. Die Verwendung, wenn einfachere +Alternativen existieren, führt zu Konfigurationen, die verwirrend, fragil und +schwer zu warten sind. Das Verständnis der verfügbaren Alternativen ist +ein sehr wichtiger Schritt zur Beherrschung von mod_rewrite.

+ +

Beachten Sie, dass viele dieser Beispiele nicht unverändert in Ihrer +speziellen Serverkonfiguration funktionieren werden. Es ist daher wichtig, +dass Sie sie verstehen, anstatt die Beispiele einfach auszuschneiden und +in Ihre Konfiguration einzufügen.

+ +

Die häufigste Situation, in der mod_rewrite das +richtige Werkzeug ist, ist wenn die allerbeste Lösung Zugriff auf die +Serverkonfigurationsdateien erfordert und Sie diesen Zugriff nicht haben. +Einige Konfigurationsdirektiven sind nur in der Serverkonfigurationsdatei +verfügbar. Wenn Sie sich in einer Hosting-Situation befinden, in der Sie +nur mit .htaccess-Dateien arbeiten können, müssen Sie möglicherweise auf +mod_rewrite zurückgreifen.

+ +
+Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung +Zugriffskontrolle +Virtuelle Hosts +Proxying +Verwendung von RewriteMap +Fortgeschrittene Techniken + + +
+Einfache Umleitung + +

mod_alias stellt die Direktiven Redirect und RedirectMatch bereit, die eine Möglichkeit +bieten, eine URL zu einer anderen umzuleiten. Diese Art der einfachen +Umleitung einer URL oder einer Klasse von URLs an einen anderen Ort sollte +mit diesen Direktiven und nicht mit RewriteRule erfolgen. RedirectMatch +ermöglicht es Ihnen, einen regulären Ausdruck in Ihre Umleitungskriterien +einzubinden, was viele der Vorteile der Verwendung von +RewriteRule bietet.

+ +

Eine häufige Verwendung von RewriteRule ist die Umleitung +einer ganzen Klasse von URLs. Beispielsweise müssen alle URLs im Verzeichnis +/one nach http://one.example.com/ umgeleitet werden, +oder alle http-Anfragen müssen nach https +umgeleitet werden.

+ +

Diese Situationen werden besser mit der Redirect-Direktive +behandelt. Denken Sie daran, dass Redirect Pfadinformationen +beibehält. Das heißt, eine Umleitung für die URL /one +wird auch alle darunter liegenden URLs umleiten, wie +/one/two.html und /one/three/four.html.

+ +

Um URLs unter /one nach +http://one.example.com umzuleiten, tun Sie Folgendes:

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

Um einen Hostnamen zu einem anderen umzuleiten, beispielsweise +example.com zu www.example.com, siehe das +Rezept für kanonische Hostnamen.

+ +

Um http-URLs nach https umzuleiten, tun Sie +Folgendes:

+ + +<VirtualHost *:80> + ServerName www.example.com + Redirect "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> + ServerName www.example.com + # ... SSL-Konfiguration hier +</VirtualHost> + + +

Die Verwendung von RewriteRule für diese Aufgabe kann +angemessen sein, wenn andere RewriteRule-Direktiven im +selben Geltungsbereich vorhanden sind. Dies liegt daran, dass bei +Redirect- und RewriteRule-Direktiven im selben +Geltungsbereich die RewriteRule-Direktiven immer zuerst +ausgeführt werden, unabhängig von der Reihenfolge in der +Konfigurationsdatei.

+ +

Im Fall der http-zu-https-Umleitung wäre die Verwendung +von RewriteRule angemessen, wenn Sie keinen Zugriff auf die +Hauptserverkonfigurationsdatei haben und diese Aufgabe stattdessen in einer +.htaccess-Datei erledigen müssen.

+ +
+ +
URL-Aliasing +

Die Alias-Direktive bietet +eine Zuordnung von einem URI zu einem Verzeichnis - normalerweise einem +Verzeichnis außerhalb Ihres DocumentRoot. +Obwohl es möglich ist, diese Zuordnung mit mod_rewrite +durchzuführen, ist Alias aus Gründen +der Einfachheit und Leistung die bevorzugte Methode.

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

+Die Verwendung von mod_rewrite für diese Zuordnung kann +angemessen sein, wenn Sie keinen Zugriff auf die Serverkonfigurationsdateien +haben. Alias kann nur im Server- oder VirtualHost-Kontext verwendet werden +und nicht in einer .htaccess-Datei. +

+ +

Symbolische Links wären eine weitere Möglichkeit, dasselbe zu erreichen, +wenn Sie Options FollowSymLinks auf Ihrem Server aktiviert +haben.

+
+ +
Virtuelles Hosting +

Obwohl es möglich ist, virtuelle Hosts +mit mod_rewrite zu verwalten, ist dies selten der richtige Weg. Das +Erstellen einzelner VirtualHost-Blöcke +ist fast immer der richtige Ansatz. Falls Sie eine enorme Anzahl virtueller +Hosts haben, erwägen Sie die Verwendung von +mod_vhost_alias, um diese Hosts automatisch zu erstellen.

+ +

Module wie mod_macro sind ebenfalls nützlich, um eine +große Anzahl virtueller Hosts dynamisch zu erstellen.

+ +

Die Verwendung von mod_rewrite für die Erstellung +virtueller Hosts kann angemessen sein, wenn Sie einen Hosting-Dienst +verwenden, der Ihnen keinen Zugriff auf die Serverkonfigurationsdateien +gewährt und Sie daher auf die Konfiguration mittels +.htaccess-Dateien beschränkt sind.

+ +

Siehe das Dokument Virtuelle Hosts mit mod_rewrite +für weitere Details, wie Sie dies erreichen können, wenn es Ihnen immer +noch als der richtige Ansatz erscheint.

+ +
+ +
Einfaches Proxying + +

RewriteRule bietet das [P]-Flag, um umgeschriebene URIs über +mod_proxy weiterzuleiten.

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

In vielen Fällen jedoch, wenn kein tatsächlicher Musterabgleich +erforderlich ist, wie im obigen Beispiel, ist die ProxyPass-Direktive die bessere Wahl. +Das Beispiel hier könnte wie folgt dargestellt werden:

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

Beachten Sie, dass Sie unabhängig davon, ob Sie RewriteRule oder ProxyPass verwenden, die +ProxyPassReverse-Direktive +benötigen, um Umleitungen vom Backend-Server korrekt weiterzuleiten:

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

Sie müssen möglicherweise stattdessen RewriteRule verwenden, +wenn andere RewriteRules im selben Geltungsbereich aktiv sind, +da eine RewriteRule in der Regel vor einem +ProxyPass wirksam wird und somit das gewünschte Ergebnis +vorwegnehmen kann.

+ +
+ +
Test von Umgebungsvariablen + +

mod_rewrite wird häufig verwendet, um eine bestimmte +Aktion basierend auf dem Vorhandensein oder Fehlen einer bestimmten +Umgebungsvariable oder eines Anfrage-Headers durchzuführen. Dies kann +effizienter mit der If-Direktive +erreicht werden.

+ +

Betrachten Sie beispielsweise das häufige Szenario, in dem +RewriteRule verwendet wird, um einen kanonischen +Hostnamen zu erzwingen, wie www.example.com anstelle von +example.com. Dies kann mit der If-Direktive wie hier gezeigt +erreicht werden:

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

Diese Technik kann verwendet werden, um Aktionen basierend auf jedem +beliebigen Anfrage-Header, Antwort-Header oder Umgebungsvariable +durchzuführen und mod_rewrite in vielen gängigen +Szenarien zu ersetzen.

+ +

Siehe insbesondere die Dokumentation zur +Ausdrucksauswertung für einen Überblick darüber, welche Arten von +Ausdrücken Sie in If-Abschnitten +und in bestimmten anderen Direktiven verwenden können.

+ +
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/avoid.xml.es b/docs/manual/rewrite/avoid.xml.es new file mode 100644 index 0000000000..7608538de4 --- /dev/null +++ b/docs/manual/rewrite/avoid.xml.es @@ -0,0 +1,245 @@ + + + + + + + + + Rewrite + +Cuándo no usar mod_rewrite + + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +quizás uno de los conceptos más importantes sobre mod_rewrite - concretamente, +cuándo evitar usarlo.

+ +

mod_rewrite debería considerarse como último recurso, cuando otras +alternativas resultan insuficientes. Usarlo cuando hay alternativas más simples +lleva a configuraciones que son confusas, frágiles y +difíciles de mantener. Entender qué otras alternativas están disponibles es +un paso muy importante hacia el dominio de mod_rewrite.

+ +

Tenga en cuenta que muchos de estos ejemplos no funcionarán sin cambios en su +configuración particular del servidor, por lo que es importante que los +entienda, en lugar de simplemente copiar y pegar los ejemplos en su +configuración.

+ +

La situación más común en la que mod_rewrite es +la herramienta correcta es cuando la mejor solución requiere acceso a los +archivos de configuración del servidor, y usted no tiene ese acceso. Algunas +directivas de configuración solo están disponibles en el archivo de configuración +del servidor. Así que si está en una situación de alojamiento donde solo tiene archivos .htaccess +con los que trabajar, puede necesitar recurrir a +mod_rewrite.

+ +
+Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo +Control de acceso +Hosts virtuales +Proxy +Uso de RewriteMap +Técnicas avanzadas + + +
+Redirección Simple + +

mod_alias proporciona las directivas Redirect y RedirectMatch, que proporcionan un +medio para redirigir una URL a otra. Este tipo de redirección simple de +una URL, o una clase de URLs, a otro lugar, debería realizarse +usando estas directivas en lugar de RewriteRule. RedirectMatch +le permite incluir una expresión regular en sus criterios de redirección, +proporcionando muchos de los beneficios de usar RewriteRule.

+ +

Un uso común de RewriteRule es redirigir toda una +clase de URLs. Por ejemplo, todas las URLs en el directorio /one +deben ser redirigidas a http://one.example.com/, o quizás +todas las solicitudes http deben ser redirigidas a +https.

+ +

Estas situaciones se manejan mejor con la directiva Redirect. +Recuerde que Redirect preserva la información de +ruta. Es decir, una redirección para una URL /one también +redirigirá todas las URLs bajo ella, como /one/two.html +y /one/three/four.html.

+ +

Para redirigir URLs bajo /one a +http://one.example.com, haga lo siguiente:

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

Para redirigir un nombre de host a otro, por ejemplo +example.com a www.example.com, vea la +receta de Nombres de Host Canónicos.

+ +

Para redirigir URLs http a https, haga lo +siguiente:

+ + +<VirtualHost *:80> + ServerName www.example.com + Redirect "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> + ServerName www.example.com + # ... la configuración SSL va aquí +</VirtualHost> + + +

El uso de RewriteRule para realizar esta tarea puede ser +apropiado si hay otras directivas RewriteRule en +el mismo ámbito. Esto se debe a que, cuando hay directivas Redirect +y RewriteRule en el mismo ámbito, las +directivas RewriteRule se ejecutarán primero, independientemente del +orden de aparición en el archivo de configuración.

+ +

En el caso de la redirección de http-a-https, el uso de +RewriteRule sería apropiado si no tiene acceso +al archivo de configuración principal del servidor, y está obligado a realizar esta +tarea en un archivo .htaccess en su lugar.

+ +
+ +
Alias de URL +

La directiva Alias +proporciona mapeo de un URI a un directorio - generalmente un directorio fuera +de su DocumentRoot. Aunque es +posible realizar este mapeo con mod_rewrite, +Alias es el método preferido, por +razones de simplicidad y rendimiento.

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

+El uso de mod_rewrite para realizar este mapeo puede ser +apropiado cuando no tiene acceso a los archivos de configuración +del servidor. Alias solo puede usarse en contexto de servidor o virtualhost, y no +en un archivo .htaccess. +

+ +

Los enlaces simbólicos serían otra forma de lograr lo mismo, si +tiene Options FollowSymLinks habilitado en su +servidor.

+
+ +
Alojamiento Virtual +

Aunque es posible manejar hosts virtuales +con mod_rewrite, rara vez es la forma correcta. Crear bloques +VirtualHost individuales es +casi siempre la forma correcta de proceder. En el +caso de que tenga un número enorme de hosts virtuales, considere usar +mod_vhost_alias para crear estos hosts automáticamente.

+ +

Módulos como mod_macro también son +útiles para crear un gran número de hosts virtuales dinámicamente.

+ +

Usar mod_rewrite para la creación de hosts virtuales puede ser +apropiado si está usando un servicio de alojamiento que no le proporciona +acceso a los archivos de configuración del servidor, y por lo tanto está +restringido a la configuración usando archivos .htaccess.

+ +

Vea el documento de hosts virtuales con mod_rewrite +para más detalles sobre cómo podría lograr esto si aún +parece ser el enfoque correcto.

+ +
+ +
Proxy Simple + +

RewriteRule proporciona la bandera [P] para pasar URIs reescritas a través de +mod_proxy.

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

Sin embargo, en muchos casos, cuando no hay necesidad real de coincidencia +de patrones, como en el ejemplo mostrado arriba, la directiva ProxyPass es una mejor opción. +El ejemplo aquí podría expresarse como:

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

Tenga en cuenta que ya sea que use RewriteRule o ProxyPass, todavía necesitará usar la +directiva ProxyPassReverse para +capturar redirecciones emitidas por el servidor backend:

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

Puede necesitar usar RewriteRule en su lugar cuando hay +otras RewriteRules en efecto en el mismo ámbito, ya que una +RewriteRule generalmente tendrá efecto antes que un +ProxyPass, y por lo tanto puede anticiparse a lo que está intentando +lograr.

+ +
+ +
Prueba de Variables de Entorno + +

mod_rewrite se usa frecuentemente para tomar una acción particular +basada en la presencia o ausencia de una variable de entorno particular +o cabecera de solicitud. Esto puede hacerse de manera más eficiente usando la +directiva If.

+ +

Considere, por ejemplo, el escenario común donde +RewriteRule se usa para imponer un nombre de +host canónico, como www.example.com en lugar de +example.com. Esto puede hacerse usando la directiva If, como se muestra aquí:

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

Esta técnica puede usarse para tomar acciones basadas en cualquier cabecera de +solicitud, cabecera de respuesta o variable de entorno, reemplazando +mod_rewrite en muchos escenarios comunes.

+ +

Vea especialmente la documentación de evaluación +de expresiones para una visión general de qué tipos de expresiones puede +usar en secciones If, +y en ciertas otras directivas.

+ +
+ +
diff --git a/docs/manual/rewrite/avoid.xml.fr b/docs/manual/rewrite/avoid.xml.fr index 0024b2189b..13cd4a7f25 100644 --- a/docs/manual/rewrite/avoid.xml.fr +++ b/docs/manual/rewrite/avoid.xml.fr @@ -1,7 +1,7 @@ - + @@ -100,7 +100,7 @@ rediriger toutes les URLs de niveaux inférieurs comme http://un.example.com/, utilisez cette définition :

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

Pour rediriger un nom d'hôte vers un autre nom d'hôte, par exemple @@ -112,13 +112,13 @@ utilisez cette définition :

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

<If "req('Host') != 'www.example.com'"> - Redirect "/" "http://www.example.com" + Redirect "/" "http://www.example.com/" </If> @@ -265,4 +265,3 @@ ainsi que dans certaines directives.

- diff --git a/docs/manual/rewrite/avoid.xml.ja b/docs/manual/rewrite/avoid.xml.ja new file mode 100644 index 0000000000..2226b0d959 --- /dev/null +++ b/docs/manual/rewrite/avoid.xml.ja @@ -0,0 +1,237 @@ + + + + + + + + + Rewrite + +mod_rewrite を使わない場合 + + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +mod_rewrite について最も重要な概念の一つ、 +すなわち、いつ使用を避けるべきかについて説明します。

+ +

mod_rewrite は、他の代替手段が不十分な場合の最後の手段と +考えるべきです。よりシンプルな代替手段がある場合に使用すると、 +設定が混乱しやすく、壊れやすく、メンテナンスしにくくなります。 +他にどのような代替手段が利用できるかを理解することは、 +mod_rewrite を習得するための非常に重要なステップです。

+ +

これらの例の多くは、特定のサーバ設定ではそのまま動作しないことに +注意してください。そのため、単にコピー&ペーストするのではなく、 +内容を理解することが重要です。

+ +

mod_rewrite が適切なツールである最も一般的な状況は、 +最善の解決策がサーバ設定ファイルへのアクセスを必要とし、そのアクセスが +ない場合です。一部の設定ディレクティブはサーバ設定ファイルでのみ +使用可能です。そのため、.htaccess ファイルのみを使用できるホスティング +環境にいる場合は、mod_rewrite に頼る必要があるかもしれません。

+ +
+モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング +アクセス制御 +バーチャルホスト +プロキシ +RewriteMap の使用 +高度なテクニック + + +
+シンプルなリダイレクト + +

mod_alias は、ある URL から別の URL へのリダイレクト手段を +提供する Redirect および RedirectMatch ディレクティブを提供します。 +この種の、ある URL または URL のクラスを別の場所へのシンプルなリダイレクトは、 +RewriteRule ではなく、これらの +ディレクティブを使用して行うべきです。RedirectMatch では +リダイレクト基準に正規表現を含めることができ、RewriteRule を +使用する利点の多くを享受できます。

+ +

RewriteRule の一般的な使用法は、URL のクラス全体を +リダイレクトすることです。例えば、/one ディレクトリのすべての +URL を http://one.example.com/ にリダイレクトする必要がある場合や、 +すべての http リクエストを https に +リダイレクトする必要がある場合などです。

+ +

これらの状況は Redirect ディレクティブで処理する方が +適切です。Redirect はパス情報を保持することを忘れないでください。 +つまり、URL /one のリダイレクトは、/one/two.html +や /one/three/four.html など、その配下のすべての URL も +リダイレクトします。

+ +

/one 配下の URL を +http://one.example.com にリダイレクトするには、 +以下のようにします:

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

あるホスト名から別のホスト名にリダイレクトするには、例えば +example.com を www.example.com にリダイレクトするには、 +正規ホスト名 +のレシピを参照してください。

+ +

http URL を https にリダイレクトするには、 +以下のようにします:

+ + +<VirtualHost *:80> + ServerName www.example.com + Redirect "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> + ServerName www.example.com + # ... SSL 設定をここに記述 +</VirtualHost> + + +

同じスコープに他の RewriteRule ディレクティブがある場合は、 +このタスクに RewriteRule を使用するのが適切な場合があります。 +これは、同じスコープに Redirect と RewriteRule +ディレクティブがある場合、設定ファイルでの出現順序に関係なく、 +RewriteRule ディレクティブが先に実行されるためです。

+ +

http から https へのリダイレクトの場合、メインサーバ設定ファイルに +アクセスできず、.htaccess ファイルでこのタスクを実行する必要がある +場合は、RewriteRule の使用が適切です。

+ +
+ +
URL エイリアス +

Alias ディレクティブは、 +URI からディレクトリ (通常は DocumentRoot +の外部のディレクトリ) へのマッピングを提供します。このマッピングを +mod_rewrite で行うことは可能ですが、シンプルさとパフォーマンスの +理由から Alias が推奨される +方法です。

+ +Alias の使用 + +Alias "/cats" "/var/www/virtualhosts/felines/htdocs" + + + +

+サーバ設定ファイルにアクセスできない場合に、このマッピングを行うために +mod_rewrite を使用するのが適切な場合があります。Alias は +サーバまたはバーチャルホストのコンテキストでのみ使用でき、 +.htaccess ファイルでは使用できません。 +

+ +

サーバで Options FollowSymLinks が有効になっている場合は、 +シンボリックリンクも同じことを実現する方法の一つです。

+
+ +
バーチャルホスティング +

mod_rewrite でバーチャルホストを +処理することは可能ですが、適切な方法であることはめったにありません。 +個別の VirtualHost +ブロックを作成するのがほぼ常に正しい方法です。非常に多数のバーチャルホストが +ある場合は、mod_vhost_alias を使用してこれらのホストを +自動的に作成することを検討してください。

+ +

mod_macro などのモジュールも、 +多数のバーチャルホストを動的に作成するのに便利です。

+ +

ホスティングサービスがサーバ設定ファイルへのアクセスを提供せず、 +.htaccess ファイルを使用した設定に制限されている場合は、 +バーチャルホスト作成に mod_rewrite を使用するのが +適切な場合があります。

+ +

それでも適切なアプローチと思われる場合に、これをどのように実現 +するかの詳細については、mod_rewrite による +バーチャルホストドキュメントを参照してください。

+ +
+ +
シンプルなプロキシ + +

RewriteRule は、書き換えた URI を +mod_proxy 経由で渡すための [P] +フラグを提供します。

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

ただし、上の例のように実際のパターンマッチングが不要な場合は、 +ProxyPass ディレクティブの方が +適切な選択です。上の例は以下のように記述できます:

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

RewriteRule と ProxyPass のどちらを使用する場合でも、 +バックエンドサーバから発行されるリダイレクトをキャッチするために +ProxyPassReverse ディレクティブを +使用する必要があることに注意してください:

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

同じスコープで他の RewriteRule が有効な場合は、 +RewriteRule は通常 ProxyPass よりも先に適用されるため、 +実現しようとしていることを横取りする可能性があり、代わりに +RewriteRule を使用する必要がある場合があります。

+ +
+ +
環境変数のテスト + +

mod_rewrite は、特定の環境変数やリクエストヘッダの +有無に基づいて特定のアクションを実行するために頻繁に使用されます。 +これは If +ディレクティブを使用してより効率的に行えます。

+ +

例えば、正規ホスト名を強制するために RewriteRule +を使用する一般的なシナリオ、つまり example.com の代わりに +www.example.com を使用させるシナリオを考えてみましょう。 +これは、次に示すように If +ディレクティブを使用して行えます:

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

このテクニックは、任意のリクエストヘッダ、レスポンスヘッダ、または +環境変数に基づいてアクションを実行するために使用でき、多くの一般的な +シナリオで mod_rewrite を置き換えることができます。

+ +

特に If セクションや +その他の特定のディレクティブで使用できる式の種類の概要については、 +式の評価ドキュメントを参照してください。

+ +
+ +
diff --git a/docs/manual/rewrite/avoid.xml.ko b/docs/manual/rewrite/avoid.xml.ko new file mode 100644 index 0000000000..cfdb395d17 --- /dev/null +++ b/docs/manual/rewrite/avoid.xml.ko @@ -0,0 +1,252 @@ + + + + + + + + + Rewrite + +mod_rewrite를 사용하지 말아야 할 경우 + + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +mod_rewrite에 대한 가장 중요한 개념 중 하나, +즉 사용을 피해야 할 때를 설명합니다.

+ +

mod_rewrite는 다른 대안이 부족할 때 최후의 +수단으로 고려해야 합니다. 더 간단한 대안이 있을 때 이를 +사용하면 혼란스럽고 취약하며 유지 관리하기 어려운 설정이 +됩니다. 어떤 다른 대안이 가능한지 이해하는 것은 +mod_rewrite 숙달을 위한 매우 중요한 +단계입니다.

+ +

이 예제들 중 많은 것이 특정 서버 설정에서 그대로 +작동하지 않을 수 있으므로, 단순히 예제를 복사하여 설정에 +붙여넣기보다는 이해하는 것이 중요합니다.

+ +

mod_rewrite가 올바른 도구인 가장 일반적인 +상황은 최선의 해결책이 서버 설정 파일에 대한 접근을 +필요로 하지만 그 접근 권한이 없는 경우입니다. 일부 설정 +지시어는 서버 설정 파일에서만 사용할 수 있습니다. 따라서 +.htaccess 파일만 사용할 수 있는 호스팅 환경에 있다면 +mod_rewrite에 의존해야 할 수 있습니다.

+ +
+모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 +접근 제어 +가상 호스트 +프록시 +RewriteMap 사용하기 +고급 기술 + + +
+단순 리다이렉션 + +

mod_alias는 Redirect와 RedirectMatch 지시어를 제공하며, +하나의 URL을 다른 URL로 리다이렉트하는 수단을 제공합니다. +하나의 URL 또는 URL 클래스를 다른 곳으로 이러한 종류의 +단순 리다이렉션은 RewriteRule 대신 이 지시어를 +사용하여 수행해야 합니다. RedirectMatch를 사용하면 +리다이렉션 기준에 정규 표현식을 포함할 수 있어 +RewriteRule 사용의 많은 이점을 제공합니다.

+ +

RewriteRule의 일반적인 용도는 전체 URL 클래스를 +리다이렉트하는 것입니다. 예를 들어, /one 디렉토리의 +모든 URL을 http://one.example.com/으로 +리다이렉트하거나, 모든 http 요청을 +https로 리다이렉트해야 할 수 있습니다.

+ +

이러한 상황은 Redirect 지시어로 더 잘 처리됩니다. +Redirect는 경로 정보를 보존한다는 것을 +기억하십시오. 즉, URL /one에 대한 리다이렉트는 +/one/two.html 및 +/one/three/four.html과 같은 그 아래의 모든 +URL도 리다이렉트합니다.

+ +

/one 아래의 URL을 +http://one.example.com으로 리다이렉트하려면 +다음과 같이 하십시오:

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

하나의 호스트명을 다른 것으로 리다이렉트하려면, 예를 들어 +example.com을 www.example.com으로, +정규 호스트명 +레시피를 참조하십시오.

+ +

http URL을 https로 +리다이렉트하려면 다음과 같이 하십시오:

+ + +<VirtualHost *:80> + ServerName www.example.com + Redirect "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> + ServerName www.example.com + # ... SSL 설정은 여기에 +</VirtualHost> + + +

같은 범위에 다른 RewriteRule 지시어가 있는 +경우 이 작업을 수행하기 위해 RewriteRule을 +사용하는 것이 적절할 수 있습니다. 이는 같은 범위에 +Redirect와 RewriteRule 지시어가 +있을 때 설정 파일의 순서에 관계없이 RewriteRule +지시어가 먼저 실행되기 때문입니다.

+ +

http에서 https로의 리다이렉션의 경우, 주 서버 +설정 파일에 접근할 수 없고 .htaccess 파일에서 +이 작업을 수행해야 하는 경우 RewriteRule 사용이 +적절합니다.

+ +
+ +
URL 별칭 지정 +

Alias 지시어는 +URI에서 디렉토리로의 매핑을 제공하며, 보통 +DocumentRoot 외부의 +디렉토리입니다. mod_rewrite로 이 매핑을 +수행할 수 있지만, 단순성과 성능의 이유로 +Alias가 선호되는 +방법입니다.

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

+서버 설정 파일에 접근할 수 없는 경우 이 매핑을 수행하기 위해 +mod_rewrite를 사용하는 것이 적절할 수 있습니다. +Alias는 서버 또는 가상호스트 컨텍스트에서만 사용할 수 있으며 +.htaccess 파일에서는 사용할 수 없습니다. +

+ +

서버에서 Options FollowSymLinks가 활성화되어 +있다면 심볼릭 링크도 같은 것을 달성하는 또 다른 방법이 +될 수 있습니다.

+
+ +
가상 호스팅 +

mod_rewrite로 가상 호스트를 +처리할 수 있지만, 올바른 방법은 거의 아닙니다. 개별 +VirtualHost +블록을 만드는 것이 거의 항상 올바른 방법입니다. 가상 호스트가 +매우 많은 경우 이러한 호스트를 자동으로 생성하기 위해 +mod_vhost_alias 사용을 고려하십시오.

+ +

mod_macro와 같은 모듈도 대량의 가상 +호스트를 동적으로 생성하는 데 유용합니다.

+ +

서버 설정 파일에 대한 접근 권한을 제공하지 않는 호스팅 +서비스를 사용하고 있어 .htaccess 파일을 사용한 +설정으로 제한되는 경우 가상호스트 생성에 +mod_rewrite를 사용하는 것이 적절할 수 +있습니다.

+ +

이것이 여전히 올바른 접근 방법으로 보인다면 이를 어떻게 +수행할 수 있는지에 대한 자세한 내용은 +mod_rewrite로 가상 호스트 문서를 +참조하십시오.

+ +
+ +
단순 프록시 + +

RewriteRule은 +재작성된 URI를 mod_proxy를 통해 전달하기 위한 +[P] 플래그를 제공합니다.

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

그러나 위의 예제처럼 실제 패턴 매칭이 필요하지 않은 +많은 경우 ProxyPass +지시어가 더 나은 선택입니다. 여기의 예제는 다음과 같이 +표현할 수 있습니다:

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

RewriteRule이든 +ProxyPass이든, +백엔드 서버에서 발행한 리다이렉트를 올바르게 전달하기 위해 +ProxyPassReverse +지시어를 사용해야 한다는 점에 유의하십시오:

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

같은 범위에 다른 RewriteRule이 적용되고 있어 +RewriteRule이 ProxyPass보다 먼저 +적용되어 수행하려는 작업을 선점할 수 있는 경우 +RewriteRule을 대신 사용해야 할 수 있습니다.

+ +
+ +
환경 변수 테스트 + +

mod_rewrite는 특정 환경 변수 또는 요청 +헤더의 존재 여부에 따라 특정 동작을 수행하는 데 자주 +사용됩니다. 이것은 If 지시어를 사용하여 더 효율적으로 +수행할 수 있습니다.

+ +

예를 들어, RewriteRule이 +example.com 대신 www.example.com과 +같은 정규 호스트명을 강제하는 데 사용되는 일반적인 시나리오를 +고려하십시오. 이것은 여기에 표시된 대로 If 지시어를 사용하여 +수행할 수 있습니다:

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

이 기술은 요청 헤더, 응답 헤더 또는 환경 변수에 기반한 +동작을 수행하는 데 사용할 수 있으며, 많은 일반적인 +시나리오에서 mod_rewrite를 대체합니다.

+ +

If 섹션과 +특정 다른 지시어에서 사용할 수 있는 표현식 유형에 대한 +개요는 특히 표현식 평가 +문서를 참조하십시오.

+ +
+ +
diff --git a/docs/manual/rewrite/avoid.xml.meta b/docs/manual/rewrite/avoid.xml.meta index 405691d6af..aa4a8b2c99 100644 --- a/docs/manual/rewrite/avoid.xml.meta +++ b/docs/manual/rewrite/avoid.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/avoid.xml.tr b/docs/manual/rewrite/avoid.xml.tr new file mode 100644 index 0000000000..1c39663c80 --- /dev/null +++ b/docs/manual/rewrite/avoid.xml.tr @@ -0,0 +1,248 @@ + + + + + + + + + Rewrite + +mod_rewrite Ne Zaman Kullanılmamalı + + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +mod_rewrite hakkındaki belki de en önemli kavramlardan +birini açıklar: ne zaman kullanılmaması gerektiğini.

+ +

mod_rewrite, diğer alternatiflerin yetersiz kaldığı +durumlarda son çare olarak düşünülmelidir. Daha basit alternatifler +varken kullanılması, kafa karıştırıcı, kırılgan ve bakımı zor +yapılandırmalara yol açar. Hangi alternatiflerin mevcut olduğunu +anlamak, mod_rewrite konusunda uzmanlaşmanın çok +önemli bir adımıdır.

+ +

Bu örneklerin birçoğunun sizin sunucu yapılandırmanızda değişiklik +yapılmadan çalışmayacağını unutmayın; bu nedenle örnekleri +yapılandırmanıza kopyalayıp yapıştırmak yerine anlamanız +önemlidir.

+ +

mod_rewrite modülünün doğru araç olduğu en yaygın +durum, en iyi çözümün sunucu yapılandırma dosyalarına erişim +gerektirdiği ancak bu erişime sahip olmadığınız durumdur. Bazı +yapılandırma yönergeleri yalnızca sunucu yapılandırma dosyasında +kullanılabilir. Bu nedenle, yalnızca .htaccess dosyalarıyla +çalışabileceğiniz bir barındırma ortamındaysanız, +mod_rewrite kullanmanız gerekebilir.

+ +
+Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme +Erişim denetimi +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı +İleri teknikler + + +
+Basit Yönlendirme + +

mod_alias, bir URL'yi başka birine yönlendirme +aracı sağlayan Redirect ve +RedirectMatch yönergelerini +sunar. Bir URL'nin veya bir URL sınıfının başka bir yere bu tür basit +yönlendirmesi, RewriteRule +yerine bu yönergeler kullanılarak gerçekleştirilmelidir. +RedirectMatch, yönlendirme kriterlerinize düzenli ifade +eklemenize olanak tanır ve RewriteRule kullanmanın +avantajlarının birçoğunu sağlar.

+ +

RewriteRule için yaygın bir kullanım, URL'lerin tüm bir +sınıfını yönlendirmektir. Örneğin, /one dizinindeki tüm +URL'ler http://one.example.com/ adresine yönlendirilmeli +veya belki tüm http istekleri https'ye +yönlendirilmelidir.

+ +

Bu durumlar Redirect yönergesiyle daha iyi ele alınır. +Redirect yönergesinin yol bilgisini koruduğunu +unutmayın. Yani, /one URL'si için bir yönlendirme, +/one/two.html ve /one/three/four.html +gibi altındaki tüm URL'leri de yönlendirecektir.

+ +

/one altındaki URL'leri +http://one.example.com adresine yönlendirmek için +şunları yapın:

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

Bir konak adını başka birine yönlendirmek için, örneğin +example.com'u www.example.com'a yönlendirmek +için Kurallı Konak Adları +tarifine bakın.

+ +

http URL'lerini https'ye yönlendirmek +için şunları yapın:

+ + +<VirtualHost *:80> + ServerName www.example.com + Redirect "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> + ServerName www.example.com + # ... SSL yapılandırması burada yer alır +</VirtualHost> + + +

RewriteRule kullanarak bu görevi gerçekleştirmek, aynı +kapsamda başka RewriteRule yönergeleri varsa uygun +olabilir. Çünkü aynı kapsamda Redirect ve +RewriteRule yönergeleri olduğunda, +RewriteRule yönergeleri yapılandırma dosyasındaki sıraya +bakılmaksızın önce çalışacaktır.

+ +

http-to-https yönlendirmesi durumunda, ana sunucu +yapılandırma dosyasına erişiminiz yoksa ve bu görevi bunun yerine bir +.htaccess dosyasında gerçekleştirmek zorundaysanız, +RewriteRule kullanımı uygun olacaktır.

+ +
+ +
URL Takma Adlandırma +

Alias yönergesi, bir +URI'den bir dizine - genellikle DocumentRoot dışındaki bir dizine - eşleme +sağlar. Bu eşlemeyi mod_rewrite ile gerçekleştirmek +mümkün olsa da, basitlik ve performans nedeniyle Alias tercih edilen yöntemdir.

+ +Alias Kullanımı + +Alias "/cats" "/var/www/virtualhosts/felines/htdocs" + + + +

+Bu eşlemeyi gerçekleştirmek için mod_rewrite +kullanımı, sunucu yapılandırma dosyalarına erişiminiz olmadığında +uygun olabilir. Alias yalnızca sunucu veya sanal konak bağlamında +kullanılabilir, .htaccess dosyasında kullanılamaz. +

+ +

Sunucunuzda Options FollowSymLinks etkinse, sembolik +bağlantılar aynı şeyi gerçekleştirmenin başka bir yolu olabilir.

+
+ +
Sanal Konak Oluşturma +

mod_rewrite ile sanal konakları yönetmek +mümkün olsa da, nadiren doğru yoldur. Ayrı ayrı VirtualHost blokları +oluşturmak neredeyse her zaman doğru yaklaşımdır. Çok sayıda sanal +konağınız olması durumunda, bu konakları otomatik olarak oluşturmak +için mod_vhost_alias kullanmayı düşünün.

+ +

mod_macro gibi modüller de çok sayıda sanal konağı +devingen olarak oluşturmak için yararlıdır.

+ +

Sanal konak oluşturma için mod_rewrite kullanımı, +sunucu yapılandırma dosyalarına erişim sağlamayan bir barındırma +hizmeti kullanıyorsanız ve yapılandırmayı .htaccess +dosyaları kullanarak yapmak zorundaysanız uygun olabilir.

+ +

Yine de doğru yaklaşım gibi görünüyorsa, bunu nasıl +gerçekleştirebileceğiniz hakkında daha fazla ayrıntı için mod_rewrite ile sanal konaklar belgesine +bakın.

+ +
+ +
Basit Vekil Kullanımı + +

RewriteRule, yeniden +yazılmış URI'leri mod_proxy üzerinden geçirmek için +[P] bayrağını sağlar.

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

Ancak birçok durumda, yukarıdaki örnekte gösterildiği gibi gerçek +bir kalıp eşleştirmesine gerek olmadığında, ProxyPass yönergesi daha iyi bir +seçimdir. Buradaki örnek şöyle ifade edilebilir:

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

İster RewriteRule +ister ProxyPass kullanın, +arka uç sunucu tarafından verilen yönlendirmeleri yakalamak için yine de +ProxyPassReverse yönergesini +kullanmanız gerekeceğini unutmayın:

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

Aynı kapsamda diğer RewriteRule'lar etkinse, +RewriteRule kullanmanız gerekebilir; çünkü +RewriteRule genellikle ProxyPass'tan önce +etki eder ve yapmaya çalıştığınız şeyi geçersiz kılabilir.

+ +
+ +
Ortam Değişkeni Sınaması + +

mod_rewrite, belirli bir ortam değişkeninin veya +istek başlığının varlığına veya yokluğuna bağlı olarak belirli bir +eylem yapmak için sıklıkla kullanılır. Bu, If yönergesi kullanılarak daha verimli bir +şekilde yapılabilir.

+ +

Örneğin, RewriteRule kullanılarak +www.example.com gibi kurallı bir konak adının +zorlanmasının yaygın senaryosunu ele alalım. Bu, burada gösterildiği +gibi If +yönergesi kullanılarak yapılabilir:

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

Bu teknik, herhangi bir istek başlığına, yanıt başlığına veya ortam +değişkenine dayalı eylemler yapmak için kullanılabilir ve birçok yaygın +senaryoda mod_rewrite yerine geçer.

+ +

Özellikle If +bölümlerinde ve belirli diğer yönergelerde kullanabileceğiniz ifade +türlerine genel bir bakış için ifade +değerlendirme belgelerine bakın.

+ +
+ +
diff --git a/docs/manual/rewrite/avoid.xml.zh-cn b/docs/manual/rewrite/avoid.xml.zh-cn new file mode 100644 index 0000000000..ea42f70d8c --- /dev/null +++ b/docs/manual/rewrite/avoid.xml.zh-cn @@ -0,0 +1,228 @@ + + + + + + + + + Rewrite + +何时不使用 mod_rewrite + + + +

本文档是 mod_rewrite +参考文档的补充。它描述了关于 +mod_rewrite 最重要的概念之一—— +即何时应避免使用它。

+ +

mod_rewrite 应被视为最后的手段, +当其他替代方案不能满足需求时才使用。在有更简单替代方案的情况下使用它, +会导致配置混乱、脆弱且难以维护。 +了解有哪些替代方案可用是掌握 mod_rewrite 的重要一步。

+ +

请注意,这些示例中的许多不会在你的特定服务器配置中直接生效, +因此理解它们非常重要,而不仅仅是将示例复制粘贴到你的配置中。

+ +

最常见的适合使用 mod_rewrite 的情况是, +最佳解决方案需要访问服务器配置文件,而你没有该访问权限。 +某些配置指令只能在服务器配置文件中使用。因此, +如果你处于只能使用 .htaccess 文件的托管环境中, +你可能需要借助 mod_rewrite。

+ +
+模块文档 +mod_rewrite 简介 +重定向和重映射 +访问控制 +虚拟主机 +代理 +使用 RewriteMap +高级技术 + + +
+简单重定向 + +

mod_alias 提供了 Redirect 和 RedirectMatch 指令, +它们提供了将一个 URL 重定向到另一个 URL 的方法。 +这种简单的将一个 URL 或一类 URL 重定向到其他地方的操作, +应使用这些指令而不是 +RewriteRule 来完成。 +RedirectMatch 允许你在重定向条件中包含正则表达式, +提供了使用 RewriteRule 的许多好处。

+ +

RewriteRule 的一个常见用途是重定向整类 URL。 +例如,/one 目录中的所有 URL 必须重定向到 +http://one.example.com/,或者所有 http +请求必须重定向到 https。

+ +

这些情况更适合使用 Redirect 指令处理。 +请记住,Redirect 会保留路径信息。也就是说, +对 URL /one 的重定向也会重定向其下的所有 URL, +例如 /one/two.html 和 /one/three/four.html。

+ +

要将 /one 下的 URL 重定向到 +http://one.example.com,请执行以下操作:

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

要将一个主机名重定向到另一个,例如将 +example.com 重定向到 www.example.com, +请参阅规范主机名方案。

+ +

要将 http URL 重定向到 https, +请执行以下操作:

+ + +<VirtualHost *:80> + ServerName www.example.com + Redirect "/" "https://www.example.com/" +</VirtualHost> + +<VirtualHost *:443> + ServerName www.example.com + # ... SSL 配置放在这里 +</VirtualHost> + + +

当同一作用域中存在其他 RewriteRule 指令时, +使用 RewriteRule 来完成此任务可能是合适的。 +这是因为,当 Redirect 和 RewriteRule +指令在同一作用域中时,无论它们在配置文件中的出现顺序如何, +RewriteRule 指令都会先执行。

+ +

对于 http 到 https 的重定向, +当你无权访问主服务器配置文件, +而被迫在 .htaccess 文件中执行此任务时, +使用 RewriteRule 是合适的。

+ +
+ +
URL 别名 +

Alias +指令提供了从 URI 到目录的映射——通常是 +DocumentRoot 之外的目录。 +虽然可以使用 mod_rewrite 执行此映射, +但出于简便性和性能原因,Alias +是首选方法。

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

+当你无权访问服务器配置文件时,使用 mod_rewrite +执行此映射可能是合适的。Alias 只能在服务器或虚拟主机上下文中使用, +不能在 .htaccess 文件中使用。 +

+ +

如果你的服务器启用了 Options FollowSymLinks, +符号链接将是实现同样目标的另一种方式。

+
+ +
虚拟主机 +

虽然可以使用 mod_rewrite 处理虚拟主机, +但这很少是正确的方式。创建单独的 +VirtualHost +块几乎总是正确的做法。如果你有大量的虚拟主机, +可以考虑使用 mod_vhost_alias 来自动创建这些主机。

+ +

mod_macro 等模块对于动态创建大量虚拟主机也很有用。

+ +

当你使用的托管服务不提供服务器配置文件的访问权限, +你只能使用 .htaccess 文件进行配置时, +使用 mod_rewrite 创建虚拟主机可能是合适的。

+ +

请参阅使用 mod_rewrite 的虚拟主机文档, +了解如何实现此目的(如果这仍然看起来是正确的方法)。

+ +
+ +
简单代理 + +

RewriteRule 提供了 [P] 标志,用于将重写后的 URI 通过 +mod_proxy 传递。

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

但是,在许多情况下,当不需要实际的模式匹配时(如上面的示例所示), +ProxyPass 指令是更好的选择。 +上面的示例可以表示为:

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

请注意,无论你使用 +RewriteRule 还是 +ProxyPass, +你仍然需要使用 +ProxyPassReverse +指令来捕获后端服务器发出的重定向:

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

当同一作用域中有其他 RewriteRule 生效时, +你可能需要使用 RewriteRule 代替, +因为 RewriteRule 通常会在 ProxyPass +之前生效,可能会抢先处理你要完成的操作。

+ +
+ +
环境变量测试 + +

mod_rewrite 经常用于根据特定环境变量或请求头 +是否存在来执行特定操作。使用 +If +指令可以更高效地完成此操作。

+ +

例如,考虑使用 RewriteRule +来强制使用规范主机名(如 www.example.com 而不是 +example.com)的常见场景。可以使用 +If +指令来完成,如下所示:

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

此技术可用于根据任何请求头、响应头或环境变量执行操作, +在许多常见场景中替代 mod_rewrite。

+ +

特别请参阅表达式求值文档, +了解在 If +配置段和某些其他指令中可以使用哪些类型的表达式。

+ +
+ +
diff --git a/docs/manual/rewrite/flags.xml.de b/docs/manual/rewrite/flags.xml.de new file mode 100644 index 0000000000..0b94f4598f --- /dev/null +++ b/docs/manual/rewrite/flags.xml.de @@ -0,0 +1,915 @@ + + + + + + + + +Rewrite + + RewriteRule-Flags + + +

Dieses Dokument behandelt die Flags, die für die Direktive +RewriteRule verfügbar sind, +und bietet detaillierte Erklärungen und Beispiele.

+
+ +Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung +Zugriffskontrolle +Virtuelle Hosts +Proxying +Verwendung von RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
Einführung +

Das Verhalten einer RewriteRule +kann durch ein oder mehrere Flags modifiziert werden. Flags werden in +eckigen Klammern am Ende der Regel angegeben, und mehrere Flags werden +durch Kommas getrennt.

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

Jedes Flag hat (mit wenigen Ausnahmen) eine Kurzform, wie +CO, sowie eine Langform, wie cookie. +Obwohl es am häufigsten ist, die Kurzform zu verwenden, wird empfohlen, +sich mit der Langform vertraut zu machen, damit Sie sich merken können, +was jedes Flag bewirken soll. Einige Flags akzeptieren ein oder mehrere +Argumente. Flags unterscheiden nicht zwischen Groß- und Kleinschreibung.

+ +

Flags, die mit der Anfrage verknüpfte Metadaten ändern (T=, H=, E=), +haben im Verzeichniskontext und htaccess-Kontext keine Wirkung, wenn eine +Ersetzung (außer '-') während derselben Runde der Umschreibungsverarbeitung +durchgeführt wird.

+ +

Hier werden alle verfügbaren Flags vorgestellt, zusammen mit einem +Beispiel, wie Sie diese verwenden könnten.

+
+ +
B (Rückreferenzen maskieren) +

Das [B]-Flag weist RewriteRule an, nicht-alphanumerische +Zeichen vor der Anwendung der Transformation zu maskieren.

+ +

mod_rewrite muss URLs demaskieren, bevor sie zugeordnet werden, +sodass Rückreferenzen zum Zeitpunkt ihrer Anwendung demaskiert sind. +Mit dem B-Flag werden nicht-alphanumerische Zeichen in Rückreferenzen +maskiert. Betrachten Sie beispielsweise die folgende Regel:

+ +

Für eine ähnliche Maskierung von Server-Variablen siehe die + "escape"-Zuordnungsfunktion

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

Bei einem Suchbegriff von 'x & y/z' kodiert ein Browser diesen als +'x%20%26%20y%2Fz', sodass die Anfrage 'search/x%20%26%20y%2Fz' lautet. Ohne das B-Flag +wird diese Rewrite-Regel auf 'search.php?term=x & y/z' abgebildet, was +keine gültige URL ist und daher als +search.php?term=x%20&y%2Fz= kodiert würde, was nicht beabsichtigt war.

+ +

Mit gesetztem B-Flag bei derselben Regel werden die Parameter erneut +kodiert, bevor sie an die Ausgabe-URL übergeben werden, was zu einer korrekten +Zuordnung zu /search.php?term=x%20%26%20y%2Fz führt.

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

Beachten Sie, dass Sie möglicherweise auch AllowEncodedSlashes auf On setzen müssen, +damit dieses spezielle Beispiel funktioniert, da httpd keine kodierten +Schrägstriche in URLs zulässt und bei deren Auftreten einen 404-Fehler +zurückgibt.

+ +

Diese Maskierung ist besonders notwendig in einer Proxy-Situation, +wenn das Backend bei einer nicht-maskierten URL Probleme haben könnte.

+ +

Eine Alternative zu diesem Flag ist die Verwendung einer RewriteCond, die gegen %{THE_REQUEST} prüft, welche Strings +in kodierter Form erfasst.

+ +

Ab Version 2.4.26 können Sie die Maskierung auf bestimmte Zeichen +in Rückreferenzen beschränken, indem Sie diese auflisten: [B=#?;]. +Hinweis: Das Leerzeichen kann in der Liste der zu maskierenden Zeichen +verwendet werden, aber Sie müssen das gesamte dritte Argument der +RewriteRule in Anführungszeichen +setzen und das Leerzeichen darf nicht das letzte Zeichen in der Liste sein.

+ + +# Leerzeichen und Fragezeichen maskieren. Die Anführungszeichen um das letzte Argument +# sind erforderlich, wenn ein Leerzeichen enthalten ist. +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]" + + +

Um die auf diese Weise maskierten Zeichen einzuschränken, siehe #flag_bne + und #flag_bctls

+
+ +
BNP|backrefnoplus (Leerzeichen nicht zu + maskieren) +

Das [BNP]-Flag weist RewriteRule an, das Leerzeichen +in einer Rückreferenz zu %20 statt zu '+' zu maskieren. Nützlich, wenn die +Rückreferenz im Pfadteil statt im Query-String verwendet wird.

+ + +# Leerzeichen im Pfad zu %20 maskieren statt zu +, wie es bei Formularübermittlungen +# über den Query-String verwendet wird +RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]" + + +

Dieses Flag ist ab Version 2.4.26 verfügbar.

+
+ +
BCTLS +

Das [BCTLS]-Flag ähnelt dem [B]-Flag, maskiert aber nur +Steuerzeichen und das Leerzeichen. Dies ist dieselbe Menge von +Zeichen, die abgelehnt werden, wenn sie unkodiert in den Query-String +kopiert werden.

+ + +# Steuerzeichen und Leerzeichen maskieren +RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]" + + +

Dieses Flag ist ab Version 2.5.1 verfügbar.

+ +
+ +
BNE +

Die Liste der Zeichen in [BNE=...] wird als Ausnahmen von den +Zeichen der [B]- oder [BCTLS]-Flags behandelt. Die aufgelisteten Zeichen +werden nicht maskiert.

+ + +# Standardzeichen maskieren, aber / beibehalten +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]" + + +

Dieses Flag ist ab Version 2.5.1 verfügbar.

+
+ +
C|chain +

Das [C]- oder [chain]-Flag zeigt an, dass die RewriteRule mit der nächsten Regel +verkettet ist. Wenn die Regel übereinstimmt, wird sie wie gewohnt +verarbeitet und die Kontrolle geht an die nächste Regel über. Wenn sie +jedoch nicht übereinstimmt, werden die nächste Regel und alle weiteren +verketteten Regeln übersprungen.

+ +
+ +
CO|cookie +

Das [CO]- oder [cookie]-Flag ermöglicht es Ihnen, ein Cookie zu setzen, +wenn eine bestimmte RewriteRule +übereinstimmt. Das Argument besteht aus drei erforderlichen und fünf +optionalen Feldern.

+ +

Die vollständige Syntax für das Flag einschließlich aller Attribute +lautet wie folgt:

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

Wenn ein literales ':'-Zeichen in einem der Cookie-Felder benötigt wird, +steht eine alternative Syntax zur Verfügung. Um die alternative Syntax zu +verwenden, sollte der Cookie-"Name" mit einem ';'-Zeichen eingeleitet werden, +und die Feldtrenner sollten als ';' angegeben werden.

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

Sie müssen einen Namen, einen Wert und eine Domain angeben, damit das +Cookie gesetzt wird.

+ +
+
Domain
+
Die Domain, für die das Cookie gültig sein soll. Dies kann ein +Hostname sein, wie www.example.com, oder eine Domain, +wie .example.com. Sie muss aus mindestens zwei durch einen +Punkt getrennten Teilen bestehen. Das heißt, sie kann nicht einfach nur +.com oder .net sein. Cookies dieser Art werden +durch das Cookie-Sicherheitsmodell verboten.
+
+ +

Sie können optional auch die folgenden Werte setzen:

+ +
+
Lebensdauer
+
Die Zeit, für die das Cookie bestehen bleibt, in Minuten.
+
Ein Wert von 0 bedeutet, dass das Cookie nur für die aktuelle +Browser-Sitzung bestehen bleibt. Dies ist der Standardwert, wenn keiner +angegeben wird.
+
Ein negativer Wert bewirkt, dass das Cookie im Browser gelöscht wird.
+ +
Pfad
+
Der Pfad auf der aktuellen Website, für den das Cookie gültig ist, +wie /customers/ oder /files/download/.
+
Standardmäßig ist dies auf / gesetzt - also die gesamte +Website.
+ +
Secure
+
Wenn auf secure, true oder 1 +gesetzt, wird das Cookie nur über sichere (https-)Verbindungen +übertragen.
+ +
httponly
+
Wenn auf HttpOnly, true oder +1 gesetzt, wird das Cookie mit dem HttpOnly-Flag +versehen, was bedeutet, dass das Cookie für JavaScript-Code in Browsern, +die diese Funktion unterstützen, nicht zugänglich ist.
+ +
samesite
+
Wenn auf etwas anderes als false oder 0 gesetzt, +wird das SameSite-Attribut auf den angegebenen Wert gesetzt. +Typische Werte sind None, Lax und +Strict. Verfügbar ab Version 2.5.1.
+
+ +

Betrachten Sie dieses Beispiel:

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

In diesem Beispiel schreibt die Regel die Anfrage nicht um. +Das "-"-Umschreibungsziel weist mod_rewrite an, die Anfrage +unverändert weiterzuleiten. Stattdessen setzt sie ein Cookie +namens 'frontdoor' auf den Wert 'yes'. Das Cookie ist für jeden Host +in der .example.com-Domain gültig. Es läuft in 1440 +Minuten (24 Stunden) ab und wird für alle URIs zurückgegeben.

+ +
+ +
DPI|discardpath +

Das DPI-Flag bewirkt, dass der PATH_INFO-Teil des umgeschriebenen URI +verworfen wird.

+

Dieses Flag ist ab Version 2.2.12 verfügbar.

+

Im Verzeichniskontext wird der URI, gegen den jede +RewriteRule prüft, aus der Verkettung der aktuellen +Werte von URI und PATH_INFO gebildet.

+ +

Der aktuelle URI kann der ursprünglich vom Client angeforderte URI sein, +das Ergebnis einer vorherigen Runde der mod_rewrite-Verarbeitung +oder das Ergebnis einer früheren Regel in der aktuellen Runde der +mod_rewrite-Verarbeitung.

+ +

Im Gegensatz dazu spiegelt der PATH_INFO, der vor jeder Regel an den +URI angehängt wird, nur den Wert von PATH_INFO vor dieser Runde der +mod_rewrite-Verarbeitung wider. Wenn daher große Teile +des URI in einer Ersetzung in mehreren RewriteRule-Direktiven +abgeglichen und kopiert werden, ohne zu berücksichtigen, welche Teile des +URI vom aktuellen PATH_INFO stammen, kann der endgültige URI mehrere +Kopien von PATH_INFO enthalten.

+ +

Verwenden Sie dieses Flag bei jeder Ersetzung, bei der der PATH_INFO, +der aus der vorherigen Zuordnung dieser Anfrage zum Dateisystem resultierte, +nicht von Interesse ist. Dieses Flag vergisst dauerhaft den PATH_INFO, +der vor dieser Runde der mod_rewrite-Verarbeitung festgelegt wurde. +PATH_INFO wird erst neu berechnet, wenn die aktuelle Runde der +mod_rewrite-Verarbeitung abgeschlossen ist. Nachfolgende Regeln +während dieser Runde der Verarbeitung sehen nur das direkte Ergebnis der +Ersetzungen, ohne angehängten PATH_INFO.

+
+ +
E|env +

Mit dem [E]- oder [env]-Flag können Sie den Wert einer Umgebungsvariable +setzen. Beachten Sie, dass einige Umgebungsvariablen nach der Ausführung +der Regel gesetzt werden können, wodurch das von Ihnen Gesetzte überschrieben +wird. Siehe das Dokument zu Umgebungsvariablen +für weitere Details zur Funktionsweise von Umgebungsvariablen.

+ +

Die vollständige Syntax für dieses Flag lautet:

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

VAL kann Rückreferenzen ($N oder +%N) enthalten, die expandiert werden.

+ +

In der Kurzform

+ + +[E=VAR] + + +

können Sie die Umgebungsvariable namens VAR auf einen +leeren Wert setzen.

+ +

Die Form

+ + +[E=!VAR] + + +

ermöglicht es, eine zuvor gesetzte Umgebungsvariable namens +VAR zu löschen.

+ +

Umgebungsvariablen können dann in verschiedenen Kontexten verwendet +werden, einschließlich CGI-Programmen, anderen RewriteRule-Direktiven +oder CustomLog-Direktiven.

+ +

Das folgende Beispiel setzt eine Umgebungsvariable namens 'image' auf +den Wert '1', wenn der angeforderte URI eine Bilddatei ist. Dann wird +diese Umgebungsvariable verwendet, um diese Anfragen aus dem +Zugriffsprotokoll auszuschließen.

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

Beachten Sie, dass derselbe Effekt mit SetEnvIf erzielt werden kann. Diese +Technik wird als Beispiel angeboten, nicht als Empfehlung.

+
+ +
END +

Die Verwendung des [END]-Flags beendet nicht nur die aktuelle Runde der +Umschreibungsverarbeitung (wie [L]), sondern verhindert auch jede +nachfolgende Umschreibungsverarbeitung im Verzeichniskontext (htaccess).

+ +

Dies gilt nicht für neue Anfragen, die aus externen Umleitungen +resultieren.

+
+ +
F|forbidden +

Die Verwendung des [F]-Flags bewirkt, dass der Server einen +403-Forbidden-Statuscode an den Client zurückgibt. Obwohl dasselbe +Verhalten mit der Deny-Direktive +erreicht werden kann, ermöglicht dies mehr Flexibilität bei der Zuweisung +eines Forbidden-Status.

+ +

Die folgende Regel verbietet das Herunterladen von .exe-Dateien +von Ihrem Server.

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

Dieses Beispiel verwendet die "-"-Syntax für das Umschreibungsziel, +was bedeutet, dass der angeforderte URI nicht geändert wird. Es gibt +keinen Grund, zu einem anderen URI umzuschreiben, wenn Sie die Anfrage +verweigern möchten.

+ +

Bei der Verwendung von [F] wird ein [L] impliziert - das heißt, die +Antwort wird sofort zurückgegeben und keine weiteren Regeln werden +ausgewertet.

+ +
+ +
G|gone +

Das [G]-Flag zwingt den Server, einen 410-Gone-Status mit der +Antwort zurückzugeben. Dies zeigt an, dass eine Ressource früher +verfügbar war, aber nicht mehr verfügbar ist.

+ +

Wie beim [F]-Flag verwenden Sie typischerweise die "-"-Syntax für das +Umschreibungsziel, wenn Sie das [G]-Flag verwenden:

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

Bei der Verwendung von [G] wird ein [L] impliziert - das heißt, die +Antwort wird sofort zurückgegeben und keine weiteren Regeln werden +ausgewertet.

+ +
+ +
H|handler +

Erzwingt, dass die resultierende Anfrage mit dem angegebenen +Handler behandelt wird. Beispielsweise könnte man dies verwenden, um +alle Dateien ohne Dateiendung vom PHP-Handler parsen zu lassen:

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

+Der obige reguläre Ausdruck - !\. - stimmt mit jeder Anfrage +überein, die kein literales .-Zeichen enthält. +

+ +

Dies kann auch verwendet werden, um den Handler basierend auf +bestimmten Bedingungen zu erzwingen. Beispielsweise ermöglicht der +folgende Ausschnitt, der im Server-Kontext verwendet wird, dass +.php-Dateien von mod_php angezeigt +werden, wenn sie mit der .phps-Erweiterung angefordert werden:

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

Der obige reguläre Ausdruck - ^(/source/.+\.php)s$ - stimmt +mit jeder Anfrage überein, die mit /source/ beginnt, gefolgt von +einem oder mehreren Zeichen, gefolgt von .phps. Die Rückreferenz +$1 verweist auf die erfasste Übereinstimmung innerhalb der Klammern des +regulären Ausdrucks.

+
+ +
L|last +

Das [L]-Flag bewirkt, dass mod_rewrite die Verarbeitung +des Regelsatzes stoppt. In den meisten Kontexten bedeutet dies, dass bei +Übereinstimmung der Regel keine weiteren Regeln verarbeitet werden. Dies +entspricht dem last-Befehl in Perl oder dem break-Befehl +in C. Verwenden Sie dieses Flag, um anzuzeigen, dass die aktuelle Regel +sofort angewendet werden soll, ohne weitere Regeln zu berücksichtigen.

+ +

Wenn Sie RewriteRule in +.htaccess-Dateien oder in +Directory-Abschnitten +verwenden, ist es wichtig, ein gewisses Verständnis dafür zu haben, wie die +Regeln verarbeitet werden. Die vereinfachte Form davon ist, dass nach der +Verarbeitung der Regeln die umgeschriebene Anfrage an die URL-Parsing-Engine +zurückgegeben wird. Es ist möglich, dass bei der Verarbeitung der +umgeschriebenen Anfrage die .htaccess-Datei oder der +Directory-Abschnitt +erneut angetroffen wird und der Regelsatz von Anfang an erneut durchlaufen +wird. Am häufigsten geschieht dies, wenn eine der Regeln eine Umleitung +auslöst - entweder intern oder extern - wodurch der Anfrageprozess von +vorne beginnt.

+ +

Es ist daher wichtig, wenn Sie RewriteRule-Direktiven in einem dieser +Kontexte verwenden, dass Sie explizite Maßnahmen ergreifen, um +Regelschleifen zu vermeiden, und sich nicht ausschließlich auf das [L]-Flag +verlassen, um die Ausführung einer Reihe von Regeln zu beenden, wie +unten gezeigt.

+ +

Ein alternatives Flag, [END], kann verwendet werden, um nicht nur die +aktuelle Runde der Umschreibungsverarbeitung zu beenden, sondern auch +jede nachfolgende Umschreibungsverarbeitung im Verzeichniskontext (htaccess) +zu verhindern. Dies gilt nicht für neue Anfragen, die aus externen +Umleitungen resultieren.

+ +

Das hier gegebene Beispiel schreibt jede Anfrage auf +index.php um und gibt die ursprüngliche Anfrage als +Query-String-Argument an index.php weiter. Die RewriteCond stellt jedoch sicher, dass die +RewriteRule übersprungen wird, +wenn die Anfrage bereits für index.php bestimmt ist.

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

+Das [N]-Flag bewirkt, dass der Regelsatz von oben neu gestartet wird, +wobei das bisherige Ergebnis des Regelsatzes als Ausgangspunkt verwendet wird. +Verwenden Sie es mit äußerster Vorsicht, da es zu Schleifen führen kann. +

+

+Das [Next]-Flag könnte beispielsweise verwendet werden, wenn Sie einen +bestimmten String oder Buchstaben wiederholt in einer Anfrage ersetzen +möchten. Das hier gezeigte Beispiel ersetzt A überall in einer Anfrage +durch B und fährt damit fort, bis keine weiteren A mehr zu ersetzen sind. +

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

Sie können sich dies als while-Schleife vorstellen: Solange +dieses Muster noch übereinstimmt (d.h. solange der URI noch ein +A enthält), führe diese Ersetzung durch (d.h. ersetze das +A durch ein B).

+ +

Ab Version 2.5.0 gibt dieses Modul nach 10.000 Iterationen einen Fehler +zurück, um vor unbeabsichtigten Schleifen zu schützen. Eine alternative +maximale Anzahl von Iterationen kann durch Hinzufügen zum N-Flag angegeben +werden.

+ +# Bereit, 1 Zeichen pro Schleifendurchlauf zu ersetzen +RewriteRule "(.+)[><;]$" "$1" [N=32000] +# ... oder nach 10 Schleifen aufgeben +RewriteRule "(.+)[><;]$" "$1" [N=10] + + +
+ +
NC|nocase +

Die Verwendung des [NC]-Flags bewirkt, dass die RewriteRule ohne Berücksichtigung der +Groß-/Kleinschreibung abgeglichen wird. Das heißt, es spielt keine Rolle, +ob Buchstaben im abgeglichenen URI als Groß- oder Kleinbuchstaben +erscheinen.

+ +

Im folgenden Beispiel wird jede Anfrage nach einer Bilddatei an Ihren +dedizierten Bildserver weitergeleitet. Der Abgleich erfolgt ohne +Berücksichtigung der Groß-/Kleinschreibung, sodass beispielsweise sowohl +.jpg- als auch .JPG-Dateien akzeptiert werden.

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

Standardmäßig werden bei einer RewriteRule, +die zu einer externen Umleitung führt, alle Zeichen in der Ausgabe, die +nicht in der folgenden sicheren Menge enthalten sind, in ihre +Hexcode-Äquivalente (prozentcodiert) umgewandelt:

+ +
    +
  • Alphanumerische Zeichen: A-Z, a-z, + 0-9
  • +
  • Sonderzeichen: $-_.+!*'(),:;@&=/~
  • +
+ +

Beispielsweise würde # in %23 umgewandelt +und ? in %3F. Das %-Zeichen +wird ebenfalls maskiert (zu %25), was bedeutet, dass jede +bereits vorhandene Prozentkodierung in der Ersetzung doppelt kodiert wird.

+ +

Die Verwendung des [NE]-Flags verhindert diese Maskierung und ermöglicht, +dass Zeichen wie # und ? unverändert an die +Umleitungs-URL weitergegeben werden.

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

+Das obige Beispiel leitet /anchor/xyz auf +/bigpage.html#xyz um. Ohne [NE] würde das #-Zeichen in +sein Hexcode-Äquivalent %23 umgewandelt, was dann zu einem +404-Nicht-Gefunden-Fehler führen würde. +

+ +
+ +
NS|nosubreq +

Die Verwendung des [NS]-Flags verhindert, dass die Regel auf +Unteranfragen angewendet wird. Beispielsweise ist eine Seite, die mittels +SSI (Server Side Include) eingebunden wird, eine Unteranfrage, und Sie +möchten möglicherweise Umschreibungen bei diesen Unteranfragen vermeiden. +Auch wenn mod_dir versucht, Informationen über mögliche +Standarddateien des Verzeichnisses herauszufinden (wie +index.html-Dateien), handelt es sich um eine interne +Unteranfrage, und Sie möchten häufig Umschreibungen bei solchen +Unteranfragen vermeiden. Bei Unteranfragen ist es nicht immer nützlich +und kann sogar Fehler verursachen, wenn der vollständige Regelsatz +angewendet wird. Verwenden Sie dieses Flag, um problematische Regeln +auszuschließen.

+ +

Um zu entscheiden, ob Sie diese Regel verwenden sollten oder nicht: Wenn +Sie URLs mit CGI-Skripten voranstellen, um deren Verarbeitung durch das +CGI-Skript zu erzwingen, werden Sie wahrscheinlich bei Unteranfragen auf +Probleme (oder erheblichen Overhead) stoßen. In diesen Fällen verwenden +Sie dieses Flag.

+ +

+Bilder, JavaScript-Dateien oder CSS-Dateien, die als Teil einer HTML-Seite +geladen werden, sind keine Unteranfragen - der Browser fordert sie als +separate HTTP-Anfragen an. +

+
+ +
P|proxy +

Die Verwendung des [P]-Flags bewirkt, dass die Anfrage von +mod_proxy behandelt und über eine Proxy-Anfrage verarbeitet +wird. Wenn Sie beispielsweise möchten, dass alle Bildanfragen von einem +Backend-Bildserver behandelt werden, könnten Sie Folgendes tun:

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

Die Verwendung des [P]-Flags impliziert [L] - das heißt, die Anfrage +wird sofort durch den Proxy geleitet und nachfolgende Regeln werden nicht +berücksichtigt.

+ +

+Sie müssen sicherstellen, dass der Ersetzungsstring ein gültiger URI ist +(typischerweise beginnend mit http://hostname), +der von mod_proxy verarbeitet werden kann. Andernfalls +erhalten Sie einen Fehler vom Proxy-Modul. Verwenden Sie dieses Flag, +um eine leistungsfähigere Implementierung der ProxyPass-Direktive zu erreichen und +entfernte Inhalte in den Namensraum des lokalen Servers einzubinden.

+ + +Sicherheitswarnung +

Seien Sie vorsichtig beim Aufbau der Ziel-URL der Regel und bedenken Sie +die Sicherheitsauswirkungen, wenn Sie dem Client Einfluss auf die Menge +der URLs gewähren, für die Ihr Server als Proxy fungiert. Stellen Sie +sicher, dass Schema und Hostname-Teil der URL entweder fest sind oder dem +Client keinen unangemessenen Einfluss gewähren.

+
+ + +Leistungswarnung +

Die Verwendung dieses Flags löst die Nutzung von mod_proxy aus, +ohne Verwaltung persistenter Verbindungen, da in diesem Fall der +Standard-Worker verwendet wird, der kein Connection-Pooling/-Reuse +durchführt.

+

Um persistente Verbindungen zu nutzen, müssen Sie einen +Proxy-Block mindestens für den +Schema- und Host-Teil der Ziel-URL einrichten, der eine +ProxySet-Direktive enthält, +in der Sie z.B. ein Timeout setzen.

+

Wenn Sie es mit ProxyPass oder +ProxyPassMatch einrichten, +werden persistente Verbindungen automatisch verwendet.

+
+ +

Hinweis: mod_proxy muss aktiviert sein, um dieses +Flag verwenden zu können.

+ +
+ +
PT|passthrough + +

+Das Ziel (oder der Ersetzungsstring) in einer RewriteRule wird +standardmäßig als Dateipfad behandelt. Die Verwendung des [PT]-Flags +bewirkt, dass es stattdessen als URI behandelt wird. Das heißt, die +Verwendung des [PT]-Flags bewirkt, dass das Ergebnis der RewriteRule durch die +URL-Zuordnung zurückgeleitet wird, sodass standortbasierte Zuordnungen +wie Alias, Redirect oder ScriptAlias beispielsweise wirksam +werden können. +

+ +

+Wenn Sie beispielsweise einen Alias +für /icons haben und eine RewriteRule dorthin zeigt, sollten +Sie das [PT]-Flag verwenden, um sicherzustellen, dass der +Alias ausgewertet wird. +

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

+Das Weglassen des [PT]-Flags in diesem Fall führt dazu, dass der Alias +ignoriert wird und ein 'Datei nicht gefunden'-Fehler zurückgegeben wird. +

+ +

Das PT-Flag impliziert das L-Flag: +Die Umschreibung wird gestoppt, um die Anfrage an die +nächste Verarbeitungsphase weiterzuleiten.

+ +

Beachten Sie, dass das PT-Flag in Verzeichniskontexten +wie Directory-Abschnitten +oder in .htaccess-Dateien impliziert ist. Die einzige +Möglichkeit, dies zu umgehen, ist die Umschreibung zu -.

+ +
+ +
QSA|qsappend +

+Wenn der Ersetzungs-URI einen Query-String enthält, ist das Standardverhalten +von RewriteRule, den vorhandenen +Query-String zu verwerfen und durch den neu generierten zu ersetzen. +Die Verwendung des [QSA]-Flags bewirkt, dass die Query-Strings kombiniert +werden. +

+ +

Betrachten Sie die folgende Regel:

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

Mit dem [QSA]-Flag wird eine Anfrage für /pages/123?one=two +auf /page.php?page=123&one=two abgebildet. Ohne das +[QSA]-Flag wird dieselbe Anfrage auf /page.php?page=123 +abgebildet - das heißt, der vorhandene Query-String wird verworfen. +

+
+ +
QSD|qsdiscard +

+Wenn der angeforderte URI einen Query-String enthält und der Ziel-URI +nicht, ist das Standardverhalten von RewriteRule, diesen Query-String in den +Ziel-URI zu kopieren. Die Verwendung des [QSD]-Flags bewirkt, dass der +Query-String verworfen wird. +

+ +

Dieses Flag ist ab Version 2.4.0 verfügbar.

+ +

+Die gemeinsame Verwendung von [QSD] und [QSA] führt dazu, dass [QSD] +Vorrang hat. +

+ +

+Wenn der Ziel-URI einen Query-String hat, wird das Standardverhalten +beobachtet - das heißt, der ursprüngliche Query-String wird verworfen und +durch den Query-String im RewriteRule-Ziel-URI ersetzt. +

+ +
+ +
QSL|qslast +

+Standardmäßig trennt das erste (linkeste) Fragezeichen in der Ersetzung +den Pfad vom Query-String. Die Verwendung des [QSL]-Flags weist +RewriteRule an, stattdessen +die beiden Komponenten beim letzten (rechtesten) Fragezeichen zu trennen. +

+ +

+Dies ist nützlich bei der Zuordnung zu Dateien, die literale Fragezeichen +in ihrem Dateinamen haben. Wenn kein Query-String in der Ersetzung +verwendet wird, kann ein Fragezeichen in Kombination mit diesem Flag +angehängt werden. +

+ +

Dieses Flag ist ab Version 2.4.19 verfügbar.

+ +
+ +
R|redirect +

+Die Verwendung des [R]-Flags bewirkt, dass eine HTTP-Umleitung an den +Browser gesendet wird. Wenn eine vollqualifizierte URL angegeben wird +(das heißt, einschließlich http://servername/), wird eine +Umleitung an diesen Ort durchgeführt. Andernfalls werden das aktuelle +Protokoll, der Servername und die Portnummer verwendet, um die URL zu +generieren, die mit der Umleitung gesendet wird. +

+ +

+Jeder gültige HTTP-Antwort-Statuscode kann angegeben werden, +mit der Syntax [R=305], wobei standardmäßig ein 302-Statuscode verwendet +wird, wenn keiner angegeben ist. Der angegebene Statuscode muss nicht +unbedingt ein Umleitungs-(3xx-)Statuscode sein. Wenn jedoch ein Statuscode +außerhalb des Umleitungsbereichs (300-399) liegt, wird der +Ersetzungsstring vollständig verworfen und die Umschreibung gestoppt, +als ob L verwendet worden wäre.

+ +

Zusätzlich zu Antwort-Statuscodes können Sie auch den Umleitungsstatus +mit ihren symbolischen Namen angeben: temp (Standard), +permanent oder seeother.

+ +

+Sie werden fast immer [R] in Verbindung mit [L] verwenden wollen (also +[R,L]), da das [R]-Flag allein http://thishost[:thisport] dem +URI voranstellt, dies aber dann an die nächste Regel im Regelsatz +weitergibt, was häufig zu 'Ungültiger URI in Anfrage'-Warnungen führen kann. +

+ +

Hinweis: httpd unterstützt nur Statuscodes, die in der HTTP-Spezifikation +enthalten sind. Die Verwendung eines nicht erkannten Statuscodes führt zu +einem 500-Fehler und einer Fehlermeldung im Fehlerprotokoll.

+ +
+ +
S|skip +

Das [S]-Flag wird verwendet, um Regeln zu überspringen, die Sie nicht +ausführen möchten. Die Syntax des Skip-Flags ist [S=N], wobei +N die Anzahl der zu überspringenden Regeln angibt (vorausgesetzt, +die RewriteRule und alle +vorhergehenden RewriteCond-Direktiven +stimmen überein). Dies kann als goto-Anweisung in Ihrem +Umschreibungsregelsatz betrachtet werden. Im folgenden Beispiel möchten +wir die RewriteRule nur +ausführen, wenn der angeforderte URI keiner tatsächlichen Datei entspricht.

+ + +# Ist die Anfrage für eine nicht existierende Datei? +RewriteCond "%{REQUEST_FILENAME}" !-f +RewriteCond "%{REQUEST_FILENAME}" !-d +# Falls ja, überspringe diese zwei RewriteRules +RewriteRule ".?" "-" [S=2] + +RewriteRule "(.*\.gif)" "images.php?$1" +RewriteRule "(.*\.html)" "docs.php?$1" + + +

Diese Technik ist nützlich, weil eine RewriteCond nur auf die unmittelbar +darauf folgende RewriteRule +angewendet wird. Wenn Sie also eine RewriteCond auf mehrere +RewriteRules anwenden möchten, besteht eine Möglichkeit darin, +diese Bedingungen zu negieren und eine RewriteRule mit einem +[Skip]-Flag hinzuzufügen. Sie können damit Pseudo-if-then-else-Konstrukte +erstellen: Die letzte Regel der then-Klausel wird zu +skip=N, wobei N die Anzahl der Regeln in der +else-Klausel ist:

+ +# Existiert die Datei? +RewriteCond "%{REQUEST_FILENAME}" !-f +RewriteCond "%{REQUEST_FILENAME}" !-d +# Erstelle ein if-then-else-Konstrukt, indem 3 Zeilen übersprungen werden, wenn wir zur "else"-Klausel wollten. +RewriteRule ".?" "-" [S=3] + +# WENN die Datei existiert, dann: + RewriteRule "(.*\.gif)" "images.php?$1" + RewriteRule "(.*\.html)" "docs.php?$1" + # Überspringe die "else"-Klausel. + RewriteRule ".?" "-" [S=1] +# SONST... + RewriteRule "(.*)" "404.php?file=$1" +# ENDE + + +

Es ist wahrscheinlich einfacher, diese Art der Konfiguration mit den +Direktiven If, ElseIf und Else zu erreichen.

+ +
+ +
T|type +

Setzt den MIME-Typ, mit dem die resultierende Antwort gesendet wird. +Dies hat denselben Effekt wie die AddType-Direktive.

+ +

Sie könnten beispielsweise die folgende Technik verwenden, um +Perl-Quellcode als Klartext bereitzustellen, wenn er auf eine bestimmte +Weise angefordert wird:

+ + +# .pl-Dateien als Klartext bereitstellen +RewriteRule "\.pl$" "-" [T=text/plain] + + +

Oder wenn Sie eine Kamera haben, die JPEG-Bilder ohne Dateiendungen +produziert, könnten Sie erzwingen, dass diese Bilder mit dem korrekten +MIME-Typ bereitgestellt werden, basierend auf ihren Dateinamen:

+ + +# Dateien mit 'IMG' im Namen sind jpg-Bilder. +RewriteRule "IMG" "-" [T=image/jpg] + + +

Bitte beachten Sie, dass dies ein triviales Beispiel ist und besser mit +FilesMatch gelöst werden +könnte. Berücksichtigen Sie immer die alternativen Lösungen für ein Problem, +bevor Sie auf Umschreibung zurückgreifen, die stets eine weniger +effiziente Lösung darstellt als die Alternativen.

+ +

+Bei Verwendung im Verzeichniskontext verwenden Sie nur - (Bindestrich) +als Ersetzung für die gesamte Runde der mod_rewrite-Verarbeitung, +da sonst der mit diesem Flag gesetzte MIME-Typ durch eine interne +Neuverarbeitung verloren geht (einschließlich nachfolgender Runden der +mod_rewrite-Verarbeitung). Das L-Flag kann in +diesem Kontext nützlich sein, um die aktuelle Runde der +mod_rewrite-Verarbeitung zu beenden.

+
+ +
UnsafeAllow3F +

Das Setzen dieses Flags ist erforderlich, um eine Umschreibung + fortzusetzen, wenn die zu schreibende HTTP-Anfrage ein kodiertes + Fragezeichen '%3f' enthält und das umgeschriebene Ergebnis ein '?' in + der Ersetzung hat. Dies schützt vor einer bösartigen URL, die eine + Erfassung und Neuersetzung des kodierten Fragezeichens ausnutzt.

+
+
UnsafePrefixStat +

Das Setzen dieses Flags ist erforderlich bei Server-Kontext-Ersetzungen, + die mit einer Variable oder Rückreferenz beginnen und zu einem + Dateisystempfad aufgelöst werden. Diesen Ersetzungen wird nicht das + Document Root vorangestellt. Dies schützt vor einer bösartigen URL, + die die expandierte Ersetzung auf einen unerwarteten + Dateisystemstandort abbilden lässt.

+ +

2.5.1

+
+
UNC +

Das Setzen dieses Flags verhindert das Zusammenführen mehrerer + führender Schrägstriche, wie sie in Windows-UNC-Pfaden verwendet werden. + Das Flag ist nicht erforderlich, wenn die Regelersetzung mit mehreren + literalen Schrägstrichen beginnt.

+ +

2.5.1

+
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/flags.xml.es b/docs/manual/rewrite/flags.xml.es new file mode 100644 index 0000000000..08618aa173 --- /dev/null +++ b/docs/manual/rewrite/flags.xml.es @@ -0,0 +1,895 @@ + + + + + + + + +Rewrite + + Banderas de RewriteRule + + +

Este documento describe las banderas que están disponibles para la +directiva RewriteRule, +proporcionando explicaciones detalladas y ejemplos.

+
+ +Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo +Control de acceso +Hosts virtuales +Proxy +Uso de RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
Introducción +

Una RewriteRule puede tener +su comportamiento modificado por una o más banderas. Las banderas se incluyen entre +corchetes al final de la regla, y múltiples banderas se separan +con comas.

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

Cada bandera (con algunas excepciones) tiene una forma corta, como +CO, así como una forma más larga, como cookie. +Aunque es más común usar +la forma corta, se recomienda que se familiarice con la +forma larga, para que recuerde qué se supone que hace cada bandera. +Algunas banderas toman uno o más argumentos. Las banderas no distinguen entre mayúsculas y minúsculas.

+ +

Las banderas que alteran metadatos asociados con la solicitud (T=, H=, E=) +no tienen efecto en contexto per-directorio y htaccess, cuando una sustitución +(distinta de '-') se realiza durante la misma ronda de procesamiento de reescritura. +

+ +

Aquí se presentan cada una de las banderas disponibles, junto con un ejemplo +de cómo podría usarlas.

+
+ +
B (escapar referencias inversas) +

La bandera [B] indica a RewriteRule que escape los caracteres no alfanuméricos +antes de aplicar la transformación.

+ +

mod_rewrite tiene que desescapar URLs antes de mapearlas, +por lo que las referencias inversas se desescapan en el momento en que se aplican. +Usando la bandera B, los caracteres no alfanuméricos en las referencias inversas +se escaparán. Por ejemplo, considere la regla:

+ +

Para un escape similar de variables del servidor, vea + la función de mapeo "escape"

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

Dado un término de búsqueda de 'x & y/z', un navegador lo codificará como +'x%20%26%20y%2Fz', haciendo la solicitud 'search/x%20%26%20y%2Fz'. Sin la bandera B, +esta regla de reescritura mapeará a 'search.php?term=x & y/z', que +no es una URL válida, y por lo tanto sería codificada como +search.php?term=x%20&y%2Fz=, que no era lo que se pretendía.

+ +

Con la bandera B establecida en esta misma regla, los parámetros se re-codifican +antes de pasarse a la URL de salida, resultando en un mapeo correcto a +/search.php?term=x%20%26%20y%2Fz.

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

Tenga en cuenta que también puede necesitar establecer AllowEncodedSlashes a On para que este +ejemplo particular funcione, ya que httpd no permite barras codificadas en URLs, y +devuelve un 404 si ve una.

+ +

Este escape es particularmente necesario en una situación de proxy, +cuando el backend puede fallar si se le presenta una URL sin escapar.

+ +

Una alternativa a esta bandera es usar una RewriteCond para capturar contra %{THE_REQUEST} que capturará +cadenas en la forma codificada.

+ +

En 2.4.26 y posterior, puede limitar el escape a caracteres específicos +en las referencias inversas listándolos: [B=#?;]. Nota: El carácter +de espacio puede usarse en la lista de caracteres a escapar, pero debe entrecomillar +el tercer argumento completo de RewriteRule +y el espacio no debe ser el último carácter en la lista.

+ + +# Escapar espacios y signos de interrogación. Las comillas alrededor del argumento final +# son necesarias cuando se incluye un espacio. +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]" + + +

Para limitar los caracteres escapados de esta manera, vea #flag_bne + y #flag_bctls

+
+ +
BNP|backrefnoplus (no escapar espacio a +) +

La bandera [BNP] indica a RewriteRule que escape el carácter de espacio +en una referencia inversa a %20 en lugar de '+'. Útil cuando la referencia inversa +se usará en el componente de ruta en lugar de la cadena de consulta.

+ + +# Escapar espacios a %20 en la ruta en lugar de + como se usa en el envío de formularios a través de +# la cadena de consulta +RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]" + + + +

Esta bandera está disponible en la versión 2.4.26 y posterior.

+
+ +
BCTLS +

La bandera [BCTLS] es similar a la bandera [B], pero solo escapa +caracteres de control y el carácter de espacio. Este es el mismo conjunto de +caracteres rechazados cuando se copian en la cadena de consulta sin codificar. +

+ + +# Escapar caracteres de control y espacios +RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]" + + +

Esta bandera está disponible en la versión 2.5.1 y posterior.

+ +
+ +
BNE +

La lista de caracteres en [BNE=...] se trata como exclusiones de los +caracteres de las banderas [B] o [BCTLS]. Los caracteres listados no serán +escapados. +

+ + +# Escapar los caracteres predeterminados, pero dejar / +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]" + + +

Esta bandera está disponible en la versión 2.5.1 y posterior.

+
+ +
C|chain +

La bandera [C] o [chain] indica que la RewriteRule está encadenada a la siguiente +regla. Es decir, si la regla coincide, entonces se procesa como de costumbre y +el control pasa a la siguiente regla. Sin embargo, si no coincide, entonces +la siguiente regla, y cualquier otra regla que esté encadenada, se +omiten.

+ +
+ +
CO|cookie +

La bandera [CO], o [cookie], le permite establecer una cookie cuando una +RewriteRule particular +coincide. El argumento consiste en tres campos obligatorios y cinco +campos opcionales.

+ +

La sintaxis completa para la bandera, incluyendo todos los atributos, es la +siguiente:

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

Si se necesita un carácter literal ':' en cualquiera de los campos de la cookie, está disponible una +sintaxis alternativa. Para optar por la sintaxis alternativa, el +"Name" de la cookie debe ir precedido por un carácter ';', y los separadores de campo deben +especificarse como ';'.

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

Debe declarar un nombre, un valor y un dominio para que la cookie se establezca.

+ +
+
Dominio
+
El dominio para el cual desea que la cookie sea válida. Este puede ser un +nombre de host, como www.example.com, o puede ser un dominio, +como .example.com. Debe tener al menos dos partes +separadas por un punto. Es decir, no puede ser simplemente .com o +.net. Las cookies de ese tipo están prohibidas por el modelo de +seguridad de cookies.
+
+ +

Opcionalmente también puede establecer los siguientes valores:

+ +
+
Tiempo de vida
+
El tiempo durante el cual la cookie persistirá, en minutos.
+
Un valor de 0 indica que la cookie persistirá solo durante la +sesión actual del navegador. Este es el valor predeterminado si no se +especifica ninguno.
+
Un valor negativo causa que la cookie sea eliminada en el navegador.
+ +
Ruta
+
La ruta, en el sitio web actual, para la cual la cookie es válida, +como /customers/ o /files/download/.
+
Por defecto, esto se establece a / - es decir, todo el +sitio web.
+ +
Secure
+
Si se establece a secure, true, o 1, +la cookie solo se permitirá ser transmitida a través de conexiones seguras (https).
+ +
httponly
+
Si se establece a HttpOnly, true, o +1, la cookie tendrá la bandera HttpOnly establecida, +lo que significa que la cookie es inaccesible para código JavaScript en +navegadores que soportan esta característica.
+ +
samesite
+
Si se establece a algo distinto de false o 0, el atributo SameSite +se establece al valor especificado. Valores típicos son None, +Lax, y Strict. Disponible en 2.5.1 y posterior.
+
+ + +

Considere este ejemplo:

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

En el ejemplo dado, la regla no reescribe la solicitud. +El destino de reescritura "-" le dice a mod_rewrite que pase la solicitud +sin cambios. En su lugar, establece una cookie +llamada 'frontdoor' con un valor de 'yes'. La cookie es válida para cualquier host +en el dominio .example.com. Se establece para expirar en 1440 +minutos (24 horas) y se devuelve para todas las URIs.

+ +
+ +
DPI|discardpath +

La bandera DPI causa que la porción PATH_INFO de la URI reescrita sea +descartada.

+

Esta bandera está disponible en la versión 2.2.12 y posterior.

+

En contexto per-directorio, la URI contra la que cada RewriteRule +compara es la concatenación de los valores actuales de la URI +y PATH_INFO.

+ +

La URI actual puede ser la URI inicial solicitada por el cliente, el +resultado de una ronda anterior de procesamiento de mod_rewrite, o el resultado de +una regla previa en la ronda actual de procesamiento de mod_rewrite.

+ +

En contraste, el PATH_INFO que se añade a la URI antes de cada +regla refleja solo el valor de PATH_INFO antes de esta ronda de +procesamiento de mod_rewrite. Como consecuencia, si porciones grandes +de la URI se hacen coincidir y copian en una sustitución en múltiples +directivas RewriteRule, sin considerar +qué partes de la URI provienen del PATH_INFO actual, la URI +final puede tener múltiples copias de PATH_INFO añadidas.

+ +

Use esta bandera en cualquier sustitución donde el PATH_INFO que resultó +del mapeo anterior de esta solicitud al sistema de archivos no es de +interés. Esta bandera olvida permanentemente el PATH_INFO establecido +antes de que comenzara esta ronda de procesamiento de mod_rewrite. PATH_INFO no +se recalculará hasta que se complete la ronda actual de procesamiento de mod_rewrite. +Las reglas subsiguientes durante esta ronda de procesamiento verán +solo el resultado directo de las sustituciones, sin ningún PATH_INFO +añadido.

+
+ +
E|env +

Con la bandera [E], o [env], puede establecer el valor de una variable +de entorno. Tenga en cuenta que algunas variables de entorno pueden establecerse después de que la regla +se ejecute, deshaciendo así lo que ha establecido. Vea el +documento de Variables de Entorno para más detalles sobre cómo funcionan las variables +de entorno.

+ +

La sintaxis completa para esta bandera es:

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

VAL puede contener referencias inversas ($N o +%N) que se expanden.

+ +

Usando la forma corta

+ + +[E=VAR] + + +

puede establecer la variable de entorno llamada VAR a un +valor vacío.

+ +

La forma

+ + +[E=!VAR] + + +

permite eliminar una variable de entorno previamente establecida +llamada VAR.

+ +

Las variables de entorno pueden usarse en una variedad de +contextos, incluyendo programas CGI, otras directivas RewriteRule, o +directivas CustomLog.

+ +

El siguiente ejemplo establece una variable de entorno llamada 'image' con un +valor de '1' si la URI solicitada es un archivo de imagen. Entonces, esa +variable de entorno se usa para excluir esas solicitudes del registro de +acceso.

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

Tenga en cuenta que este mismo efecto se puede obtener usando SetEnvIf. Esta técnica se ofrece como +un ejemplo, no como una recomendación.

+
+ +
END +

Usar la bandera [END] termina no solo la ronda actual de procesamiento de +reescritura (como [L]) sino también previene que cualquier procesamiento de +reescritura posterior ocurra en contexto per-directorio (htaccess).

+ +

Esto no se aplica a nuevas solicitudes resultantes de +redirecciones externas.

+
+ +
F|forbidden +

Usar la bandera [F] causa que el servidor devuelva un código de estado 403 Forbidden +al cliente. Aunque el mismo comportamiento puede lograrse usando +la directiva Deny, esto +permite más flexibilidad en la asignación de un estado Forbidden.

+ +

La siguiente regla prohibirá que archivos .exe sean +descargados de su servidor.

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

Este ejemplo usa la sintaxis "-" para el destino de reescritura, que significa +que la URI solicitada no se modifica. No hay razón para reescribir a +otra URI, si va a prohibir la solicitud.

+ +

Cuando se usa [F], se implica un [L] - es decir, la respuesta se devuelve +inmediatamente, y no se evalúan más reglas.

+ +
+ +
G|gone +

La bandera [G] fuerza al servidor a devolver un estado 410 Gone con la +respuesta. Esto indica que un recurso solía estar disponible, pero ya no +lo está.

+ +

Como con la bandera [F], normalmente usará la sintaxis "-" para el +destino de reescritura cuando use la bandera [G]:

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

Cuando se usa [G], se implica un [L] - es decir, la respuesta se devuelve +inmediatamente, y no se evalúan más reglas.

+ +
+ +
H|handler +

Fuerza que la solicitud resultante sea manejada con el manejador +especificado. Por ejemplo, uno podría usar esto para forzar que todos los archivos sin +extensión de archivo sean procesados por el manejador de php:

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

+La expresión regular anterior - !\. - coincidirá con cualquier solicitud +que no contenga el carácter literal .. +

+ +

Esto también puede usarse para forzar el manejador basado en algunas condiciones. +Por ejemplo, el siguiente fragmento usado en contexto per-servidor permite que +archivos .php sean mostrados por mod_php +si se solicitan con la extensión .phps:

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

La expresión regular anterior - ^(/source/.+\.php)s$ - coincidirá +con cualquier solicitud que comience con /source/ seguido de 1 o +más caracteres seguidos de .phps literalmente. La referencia inversa +$1 se refiere a la coincidencia capturada dentro de los paréntesis de la expresión +regular.

+
+ +
L|last +

La bandera [L] causa que mod_rewrite deje de procesar +el conjunto de reglas. En la mayoría de los contextos, esto significa que si la regla coincide, no +se procesarán más reglas. Esto corresponde al +comando last en Perl, o al comando break en +C. Use esta bandera para indicar que la regla actual debe aplicarse +inmediatamente sin considerar más reglas.

+ +

Si está usando RewriteRule en archivos +.htaccess o en +secciones Directory, +es importante entender cómo se procesan las reglas. La forma simplificada de esto es que una vez que las reglas han sido +procesadas, la solicitud reescrita se devuelve al motor de análisis +de URL para que haga lo que pueda con ella. Es posible que mientras se maneja la solicitud reescrita, el archivo .htaccess o +la sección Directory +pueda encontrarse de nuevo, y así el conjunto de reglas pueda ejecutarse de nuevo desde el +inicio. Lo más común es que esto suceda si una de las reglas causa una +redirección - ya sea interna o externa - causando que el proceso de solicitud +comience de nuevo.

+ +

Es por lo tanto importante, si está usando directivas RewriteRule en uno de estos +contextos, que tome pasos explícitos para evitar bucles en las reglas, y no +contar únicamente con la bandera [L] para terminar la ejecución de una serie de +reglas, como se muestra a continuación.

+ +

Una bandera alternativa, [END], puede usarse para terminar no solo la +ronda actual de procesamiento de reescritura sino prevenir cualquier +procesamiento de reescritura posterior en contexto per-directorio +(htaccess). Esto no se aplica a nuevas solicitudes resultantes de +redirecciones externas.

+ +

El ejemplo dado aquí reescribirá cualquier solicitud a +index.php, dando la solicitud original como un argumento de cadena +de consulta a index.php, sin embargo, la RewriteCond asegura que si la solicitud +ya es para index.php, la RewriteRule se omitirá.

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

+La bandera [N] causa que el conjunto de reglas comience de nuevo desde el principio, usando +el resultado del conjunto de reglas hasta el momento como punto de partida. Use +con extrema precaución, ya que puede resultar en un bucle. +

+

+La bandera [Next] podría usarse, por ejemplo, si deseara reemplazar una +cierta cadena o letra repetidamente en una solicitud. El ejemplo mostrado aquí +reemplazará A con B en todas partes de una solicitud, y continuará haciéndolo +hasta que no haya más As por reemplazar. +

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

Puede pensar en esto como un bucle while: Mientras este +patrón siga coincidiendo (es decir, mientras la URI aún contenga una +A), realice esta sustitución (es decir, reemplace la +A con una B).

+ +

En 2.5.0 y posterior, este módulo devuelve un error después de 10,000 iteraciones para +proteger contra bucles no intencionados. Se puede especificar un número máximo alternativo de +iteraciones añadiéndolo a la bandera N.

+ +# Estar dispuesto a reemplazar 1 carácter en cada pasada del bucle +RewriteRule "(.+)[><;]$" "$1" [N=32000] +# ... o, rendirse después de 10 bucles +RewriteRule "(.+)[><;]$" "$1" [N=10] + + +
+ +
NC|nocase +

El uso de la bandera [NC] causa que la RewriteRule se evalúe de manera +insensible a mayúsculas/minúsculas. Es decir, no importa si las letras aparecen +en mayúsculas o minúsculas en la URI coincidente.

+ +

En el ejemplo siguiente, cualquier solicitud de un archivo de imagen será proxied +a su servidor de imágenes dedicado. La coincidencia es insensible a mayúsculas/minúsculas, de modo que +archivos .jpg y .JPG son ambos aceptables, por +ejemplo.

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

Por defecto, cuando una RewriteRule +resulta en una redirección externa, cualquier carácter en la salida que no esté +en el siguiente conjunto seguro será convertido a sus equivalentes en hexadecimal +(codificación porcentual):

+ +
    +
  • Caracteres alfanuméricos: A-Z, a-z, + 0-9
  • +
  • Caracteres especiales: $-_.+!*'(),:;@&=/~
  • +
+ +

Por ejemplo, # se convertiría a %23, +y ? a %3F. El carácter % +también se escapa (a %25), lo que significa que cualquier +codificación porcentual ya presente en la sustitución será +doblemente codificada.

+ +

Usar la bandera [NE] previene este escape, permitiendo que caracteres +como # y ? pasen a la +URL de redirección sin modificar.

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

+El ejemplo anterior redirigirá /anchor/xyz a +/bigpage.html#xyz. Omitir la [NE] resultará en que el # +sea convertido a su equivalente hexadecimal, %23, lo que +entonces resultará en una condición de error 404 No Encontrado. +

+ +
+ +
NS|nosubreq +

El uso de la bandera [NS] previene que la regla se use en +sub-solicitudes. Por ejemplo, una página incluida usando un SSI (Server +Side Include) es una sub-solicitud, y usted puede querer evitar que las reescrituras +ocurran en esas sub-solicitudes. También, cuando mod_dir +intenta encontrar información sobre posibles archivos predeterminados de directorio +(como archivos index.html), esto es una +sub-solicitud interna, y a menudo querrá evitar reescrituras en tales sub-solicitudes. +En sub-solicitudes, no siempre es útil, e incluso puede causar errores, si +el conjunto completo de reglas se aplica. Use esta bandera para excluir +reglas problemáticas.

+ +

Para decidir si usar o no esta regla: si prefija URLs con +scripts CGI, para forzar que sean procesadas por el script CGI, es +probable que tenga problemas (o una sobrecarga significativa) +en sub-solicitudes. En estos casos, use esta bandera.

+ +

+Imágenes, archivos javascript, o archivos css, cargados como parte de una página HTML, +no son sub-solicitudes - el navegador los solicita como solicitudes HTTP +separadas. +

+
+ +
P|proxy +

El uso de la bandera [P] causa que la solicitud sea manejada por +mod_proxy, y procesada a través de una solicitud proxy. Por +ejemplo, si quisiera que todas las solicitudes de imágenes fueran manejadas por un servidor +de imágenes backend, podría hacer algo como lo siguiente:

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

El uso de la bandera [P] implica [L] - es decir, la solicitud se envía inmediatamente +a través del proxy, y cualquier regla siguiente no será +considerada.

+ +

+Debe asegurarse de que la cadena de sustitución sea una URI válida +(típicamente comenzando con http://hostname) que pueda ser +manejada por mod_proxy. Si no, obtendrá un +error del módulo proxy. Use esta bandera para lograr una +implementación más potente de la directiva ProxyPass, +para mapear contenido remoto al espacio de nombres del servidor local.

+ + +Advertencia de Seguridad +

Tenga cuidado al construir la URL destino de la regla, considerando +el impacto de seguridad de permitir que el cliente influya en el conjunto de +URLs a las que su servidor actuará como proxy. Asegúrese de que la parte del esquema +y nombre de host de la URL sea fija, o no permita al +cliente una influencia indebida.

+
+ + +Advertencia de Rendimiento +

Usar esta bandera provoca el uso de mod_proxy, sin +manejo de conexiones persistentes ya que se usa el worker predeterminado en este caso, +el cual no maneja agrupación/reutilización de conexiones.

+

Para usar conexiones persistentes necesita configurar un +bloque Proxy al menos para la parte del esquema +y host de la URL destino conteniendo una +directiva ProxySet donde por ejemplo establezca +un timeout.

+

Si lo configura con ProxyPass o +ProxyPassMatch se usarán conexiones +persistentes automáticamente.

+
+ +

Nota: mod_proxy debe estar habilitado para +usar esta bandera.

+ +
+ +
PT|passthrough + +

+El destino (o cadena de sustitución) en una RewriteRule se asume que es una +ruta de archivo, por defecto. El uso de la bandera [PT] causa que sea tratada +como una URI en su lugar. Es decir, el +uso de la bandera [PT] causa que el resultado de la RewriteRule se pase de vuelta a través del +mapeo de URL, de modo que mapeos basados en ubicación, como Alias, Redirect, o ScriptAlias, por ejemplo, puedan tener la +oportunidad de tomar efecto. +

+ +

+Si, por ejemplo, tiene un +Alias +para /icons, y tiene una RewriteRule apuntando allí, debería +usar la bandera [PT] para asegurar que el +Alias sea evaluado. +

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

+La omisión de la bandera [PT] en este caso causará que el Alias sea +ignorado, resultando en un error 'Archivo no encontrado'. +

+ +

La bandera PT implica la bandera L: +la reescritura se detendrá para pasar la solicitud a +la siguiente fase de procesamiento.

+ +

Tenga en cuenta que la bandera PT está implícita en contextos per-directorio +como secciones +Directory +o en archivos .htaccess. La única forma de evitar eso +es reescribir a -.

+ +
+ +
QSA|qsappend +

+Cuando la URI de reemplazo contiene una cadena de consulta, el comportamiento predeterminado +de RewriteRule es descartar +la cadena de consulta existente, y reemplazarla con la recién generada. +Usar la bandera [QSA] causa que las cadenas de consulta se combinen. +

+ +

Considere la siguiente regla:

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

Con la bandera [QSA], una solicitud para /pages/123?one=two será +mapeada a /page.php?page=123&one=two. Sin la bandera [QSA], +esa misma solicitud será mapeada a +/page.php?page=123 - es decir, la cadena de consulta existente +será descartada. +

+
+ +
QSD|qsdiscard +

+Cuando la URI solicitada contiene una cadena de consulta, y la URI destino no +la contiene, el comportamiento predeterminado de RewriteRule es copiar esa cadena de consulta +a la URI destino. Usar la bandera [QSD] causa que la cadena de consulta +sea descartada. +

+ +

Esta bandera está disponible en la versión 2.4.0 y posterior.

+ +

+Usar [QSD] y [QSA] juntos resultará en que [QSD] tenga precedencia. +

+ +

+Si la URI destino tiene una cadena de consulta, se observará el comportamiento predeterminado +- es decir, la cadena de consulta original será descartada y +reemplazada con la cadena de consulta en la URI destino de la RewriteRule. +

+ +
+ +
QSL|qslast +

+Por defecto, el primer signo de interrogación (el más a la izquierda) en la sustitución +delimita la ruta de la cadena de consulta. Usar la bandera [QSL] indica a +RewriteRule que en su lugar divida +los dos componentes usando el último signo de interrogación (el más a la derecha).

+ +

+Esto es útil cuando se mapea a archivos que tienen signos de interrogación literales en +sus nombres de archivo. Si no se usa cadena de consulta en la sustitución, +se puede añadir un signo de interrogación en combinación con esta bandera.

+ +

Esta bandera está disponible en la versión 2.4.19 y posterior.

+ +
+ + +
R|redirect +

+El uso de la bandera [R] causa que se emita una redirección HTTP al navegador. +Si se especifica una URL completamente cualificada (es decir, incluyendo +http://servername/) entonces se emitirá una redirección a esa +ubicación. De lo contrario, se usará el protocolo actual, nombre del servidor, y número de puerto +para generar la URL enviada con la redirección. +

+ +

+Se puede especificar cualquier código de estado de respuesta HTTP válido, +usando la sintaxis [R=305], con un código de estado 302 siendo usado por +defecto si no se especifica ninguno. El código de estado especificado no necesita +necesariamente ser un código de estado de redirección (3xx). Sin embargo, +si un código de estado está fuera del rango de redirección (300-399) entonces la +cadena de sustitución se descarta por completo, y la reescritura se detiene como si +se usara L.

+ +

Además de los códigos de estado de respuesta, también puede especificar estados de +redirección usando sus nombres simbólicos: temp (predeterminado), +permanent, o seeother.

+ +

+Casi siempre querrá usar [R] junto con [L] (es decir, +usar [R,L]) porque por sí sola, la bandera [R] antepone +http://thishost[:thisport] a la URI, pero luego pasa esto +a la siguiente regla en el conjunto de reglas, lo que a menudo puede resultar en advertencias de 'URI +inválida en solicitud'. +

+ +

Nota: httpd solo soporta códigos de estado que están incluidos en la especificación +HTTP. Usar un código de estado no reconocido resultará en un error 500 y +un mensaje en el log de errores.

+ +
+ +
S|skip +

La bandera [S] se usa para omitir reglas que no desea ejecutar. La +sintaxis de la bandera skip es [S=N], donde N indica +el número de reglas a omitir (siempre que la +RewriteRule y cualquier directiva +RewriteCond precedente coincidan). Esto puede pensarse como una +sentencia goto en su conjunto de reglas de reescritura. En el siguiente +ejemplo, solo queremos ejecutar la +RewriteRule si la URI solicitada no corresponde a un +archivo real.

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

Esta técnica es útil porque una RewriteCond solo se aplica a la +RewriteRule inmediatamente +siguiente. Así, si desea hacer que una RewriteCond se aplique +a varias RewriteRules, una técnica posible es negar +esas condiciones y añadir una RewriteRule con una bandera [Skip]. Puede +usar esto para hacer construcciones pseudo if-then-else: La última regla de +la cláusula then se convierte en skip=N, donde N es el +número de reglas en la cláusula else:

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

Probablemente sea más fácil lograr este tipo de configuración usando +las directivas If, ElseIf, y Else en su lugar.

+ +
+ +
T|type +

Establece el tipo MIME con el que se enviará la respuesta +resultante. Esto tiene el mismo efecto que la directiva AddType.

+ +

Por ejemplo, podría usar la siguiente técnica para servir código fuente Perl +como texto plano, si se solicita de una manera particular:

+ + +# Servir archivos .pl como texto plano +RewriteRule "\.pl$" "-" [T=text/plain] + + +

O, quizás, si tiene una cámara que produce imágenes jpeg sin +extensiones de archivo, podría forzar que esas imágenes sean servidas con el +tipo MIME correcto por virtud de sus nombres de archivo:

+ + +# Los archivos con 'IMG' en el nombre son imágenes jpg. +RewriteRule "IMG" "-" [T=image/jpg] + + +

Por favor tenga en cuenta que este es un ejemplo trivial, y podría hacerse mejor +usando FilesMatch +en su lugar. Siempre considere las soluciones +alternativas a un problema antes de recurrir a rewrite, que invariablemente +será una solución menos eficiente que las alternativas.

+ +

+Si se usa en contexto per-directorio, use solo - (guión) +como la sustitución para toda la ronda de procesamiento de mod_rewrite, +de lo contrario el tipo MIME establecido con esta bandera se pierde debido a un +re-procesamiento interno (incluyendo rondas posteriores de procesamiento de mod_rewrite). +La bandera L puede ser útil en este contexto para terminar la +ronda actual de procesamiento de mod_rewrite.

+
+ +
UnsafeAllow3F +

Establecer esta bandera es necesario para permitir que una reescritura continúe si la + solicitud HTTP que se está reescribiendo tiene un signo de interrogación codificado, '%3f', y el + resultado reescrito tiene un '?' en la sustitución. Esto protege contra una URL + maliciosa que aproveche una captura y re-sustitución del signo de interrogación + codificado.

+
+
UnsafePrefixStat +

Establecer esta bandera es necesario en sustituciones de ámbito de servidor + que comienzan con una variable o referencia inversa y se resuelven a una ruta del sistema de archivos. + Estas sustituciones no se prefijan con la raíz del documento. + Esto protege contra una URL maliciosa que cause que la sustitución expandida se + mapee a una ubicación inesperada del sistema de archivos.

+ +

2.5.1

+
+
UNC +

Establecer esta bandera previene la fusión de múltiples barras iniciales, + como se usa en las rutas UNC de Windows. La bandera no es necesaria cuando la + sustitución de las reglas comienza con múltiples barras literales.

+ +

2.5.1

+
+ +
diff --git a/docs/manual/rewrite/flags.xml.ja b/docs/manual/rewrite/flags.xml.ja new file mode 100644 index 0000000000..e2ef7e2244 --- /dev/null +++ b/docs/manual/rewrite/flags.xml.ja @@ -0,0 +1,853 @@ + + + + + + + + +Rewrite + + RewriteRule フラグ + + +

このドキュメントでは、RewriteRule +ディレクティブで使用可能なフラグについて、詳細な説明と例を提供します。

+
+ +モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング +アクセス制御 +バーチャルホスト +プロキシ +RewriteMap の使用 +高度なテクニック +mod_rewrite を使わない場合 + +
はじめに +

RewriteRule は、 +1 つ以上のフラグによって動作を変更できます。フラグはルールの末尾の +角括弧内に含まれ、複数のフラグはカンマで区切られます。

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

各フラグ (いくつかの例外を除き) には CO のような短い形式と、 +cookie のような長い形式があります。短い形式を使用するのが +最も一般的ですが、各フラグの機能を覚えるために長い形式に慣れることを +お勧めします。一部のフラグは 1 つ以上の引数を取ります。フラグは +大文字小文字を区別しません。

+ +

メタデータを変更するフラグ (T=、H=、E=) は、ディレクトリ単位および +htaccess コンテキストで、同じ書き換え処理ラウンド中に ('-' 以外の) +置換が行われる場合、効果がありません。

+ +

ここでは、各フラグと使用例を紹介します。

+
+ +
B (バックリファレンスのエスケープ) +

[B] フラグは、変換を適用する前に非英数字文字をエスケープするよう +RewriteRule に指示します。

+ +

mod_rewrite はマッピング前に URL をアンエスケープする +必要があるため、バックリファレンスは適用時にアンエスケープされています。 +B フラグを使用すると、バックリファレンス内の非英数字文字がエスケープ +されます。例えば、以下のルールを考えてみてください:

+ +

サーバ変数の同様のエスケープについては、"escape" + マッピング関数を参照してください

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

検索語が 'x & y/z' の場合、ブラウザはこれを +'x%20%26%20y%2Fz' としてエンコードし、リクエストは 'search/x%20%26%20y%2Fz' +になります。B フラグがない場合、この書き換えルールは 'search.php?term=x & y/z' +にマッピングされますが、これは有効な URL ではないため、 +search.php?term=x%20&y%2Fz= としてエンコードされ、 +意図した結果になりません。

+ +

同じルールに B フラグを設定すると、パラメータは出力 URL に渡される前に +再エンコードされ、正しいマッピング +/search.php?term=x%20%26%20y%2Fz になります。

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

この特定の例を動作させるには、AllowEncodedSlashes を On に +設定する必要がある場合があることに注意してください。httpd は URL 内の +エンコードされたスラッシュを許可せず、見つけた場合は 404 を返します。

+ +

このエスケープは特にプロキシの状況で必要です。バックエンドが +アンエスケープされた URL を受け取ると壊れる可能性があるためです。

+ +

このフラグの代替として、RewriteCond を使用して %{THE_REQUEST} に対してキャプチャする +方法があります。これはエンコードされた形式の文字列をキャプチャします。

+ +

2.4.26 以降では、エスケープする文字を特定の文字に限定できます: +[B=#?;]。注: スペース文字はエスケープする文字リストに +含めることができますが、RewriteRule +の 3 番目の引数全体を引用符で囲む必要があり、スペースはリストの +最後の文字にしてはいけません。

+ + +# スペースと疑問符をエスケープ。最後の引数の引用符は +# スペースが含まれる場合に必要です。 +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]" + + +

この方法でエスケープされる文字を制限するには、#flag_bne + および #flag_bctls を参照してください

+
+ +
BNP|backrefnoplus (スペースを + にエスケープしない) +

[BNP] フラグは、バックリファレンス内のスペース文字を '+' ではなく +%20 にエスケープするよう RewriteRule に指示します。 +バックリファレンスがクエリ文字列ではなくパスコンポーネントで使用される +場合に便利です。

+ + +# クエリ文字列経由のフォーム送信で使用される + ではなく、 +# パス内のスペースを %20 にエスケープ +RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]" + + +

このフラグはバージョン 2.4.26 以降で使用可能です。

+
+ +
BCTLS +

[BCTLS] フラグは [B] フラグに似ていますが、制御文字とスペース文字のみを +エスケープします。これは、エンコードされずにクエリ文字列にコピーされた +場合に拒否される文字セットと同じです。

+ + +# 制御文字とスペースをエスケープ +RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]" + + +

このフラグはバージョン 2.5.1 以降で使用可能です。

+ +
+ +
BNE +

[BNE=...] 内の文字リストは、[B] または [BCTLS] フラグの文字に対する +除外として扱われます。リストされた文字はエスケープされません。

+ + +# デフォルトの文字をエスケープするが、/ は除外 +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]" + + +

このフラグはバージョン 2.5.1 以降で使用可能です。

+
+ +
C|chain +

[C] または [chain] フラグは、RewriteRule が次のルールに +チェーンされることを示します。つまり、ルールがマッチすると通常通り +処理され、制御は次のルールに移ります。しかし、マッチしない場合は、 +次のルールおよびチェーンされたその他のルールがスキップされます。

+ +
+ +
CO|cookie +

[CO] または [cookie] フラグは、特定の +RewriteRule がマッチした場合に +cookie を設定できるようにします。引数は 3 つの必須フィールドと +5 つのオプションフィールドで構成されます。

+ +

フラグの完全な構文 (すべての属性を含む) は以下の通りです:

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

cookie フィールドのいずれかにリテラルの ':' 文字が必要な場合、 +代替構文が利用可能です。代替構文にオプトインするには、cookie の +"Name" の前に ';' 文字を付け、フィールドセパレータを ';' として +指定してください。

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

cookie が設定されるためには、名前、値、およびドメインを宣言する +必要があります。

+ +
+
Domain
+
cookie が有効なドメインです。www.example.com のような +ホスト名か、.example.com のようなドメインです。 +ドットで区切られた少なくとも 2 つのパートが必要です。つまり、 +単に .com や .net にはできません。 +そのような cookie は cookie セキュリティモデルで禁止されています。
+
+ +

オプションで以下の値も設定できます:

+ +
+
Lifetime
+
cookie が保持される時間 (分単位)。
+
値が 0 の場合、cookie は現在のブラウザセッションの間のみ保持されます。 +指定されない場合のデフォルト値です。
+
負の値を指定すると、ブラウザで cookie が削除されます。
+ +
Path
+
cookie が有効な現在のウェブサイトのパスです。 +/customers/ や /files/download/ などです。
+
デフォルトでは / (ウェブサイト全体) に設定されます。
+ +
Secure
+
secure、true、または 1 に +設定すると、cookie はセキュアな (https) 接続経由でのみ送信が許可されます。
+ +
httponly
+
HttpOnly、true、または 1 に +設定すると、cookie に HttpOnly フラグが設定され、 +この機能をサポートするブラウザでは JavaScript コードから cookie に +アクセスできなくなります。
+ +
samesite
+
false または 0 以外の値に設定すると、 +SameSite 属性が指定された値に設定されます。典型的な値は +None、Lax、Strict です。 +2.5.1 以降で使用可能です。
+
+ + +

以下の例を考えてみましょう:

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

この例では、ルールはリクエストを書き換えません。 +書き換えターゲットの "-" は mod_rewrite にリクエストを +変更せずに通過させることを意味します。代わりに、'frontdoor' という名前で +値 'yes' の cookie を設定します。cookie は .example.com +ドメイン内のすべてのホストに対して有効です。有効期限は 1440 分 +(24 時間) で、すべての URI に対して返されます。

+ +
+ +
DPI|discardpath +

DPI フラグは、書き換えた URI の PATH_INFO 部分を破棄します。

+

このフラグはバージョン 2.2.12 以降で使用可能です。

+

ディレクトリ単位のコンテキストでは、各 +RewriteRule が比較する URI は、URI と PATH_INFO の +現在の値を連結したものです。

+ +

現在の URI は、クライアントが要求した初期 URI、 +mod_rewrite の前のラウンドの処理結果、または現在のラウンドの +mod_rewrite 処理の前のルールの結果である可能性があります。

+ +

一方、各ルールの前に URI に追加される PATH_INFO は、この +mod_rewrite 処理ラウンド前の PATH_INFO の値のみを +反映します。その結果、URI の大部分が複数の +RewriteRule ディレクティブで置換にマッチおよび +コピーされ、URI のどの部分が現在の PATH_INFO から来たかを考慮しない場合、 +最終的な URI に PATH_INFO の複数のコピーが追加される可能性があります。

+ +

前のマッピングの結果としてのこのリクエストの PATH_INFO が不要な +置換にはこのフラグを使用してください。このフラグは、この +mod_rewrite 処理ラウンドの開始前に確立された PATH_INFO を +永続的に破棄します。PATH_INFO は、現在の mod_rewrite +処理ラウンドが完了するまで再計算されません。このラウンド中の +後続のルールは、PATH_INFO が追加されていない置換の直接の結果のみを +参照します。

+
+ +
E|env +

[E] または [env] フラグを使用すると、環境変数の値を設定できます。 +一部の環境変数はルールの実行後に設定される可能性があり、設定した値が +上書きされることがあることに注意してください。環境変数の動作の詳細は +環境変数ドキュメントを参照してください。

+ +

このフラグの完全な構文は以下の通りです:

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

VAL には展開されるバックリファレンス ($N や +%N) を含めることができます。

+ +

短い形式

+ + +[E=VAR] + + +

を使用すると、VAR という名前の環境変数を空の値に +設定できます。

+ +

以下の形式

+ + +[E=!VAR] + + +

で、以前に設定された VAR という名前の環境変数を +削除できます。

+ +

環境変数は CGI プログラム、他の RewriteRule ディレクティブ、 +CustomLog ディレクティブなど、さまざまなコンテキストで使用できます。

+ +

以下の例は、リクエストされた URI が画像ファイルの場合、'image' という +環境変数を値 '1' に設定します。その後、その環境変数を使用して、 +それらのリクエストをアクセスログから除外します。

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

この効果は SetEnvIf を +使用しても得られることに注意してください。このテクニックは推奨としてではなく、 +例として提供されています。

+
+ +
END +

[END] フラグを使用すると、([L] のように) 現在の書き換え処理ラウンドを +終了するだけでなく、ディレクトリ単位 (htaccess) コンテキストでの +以降の書き換え処理も防止します。

+ +

これは外部リダイレクトによる新しいリクエストには適用されません。

+
+ +
F|forbidden +

[F] フラグを使用すると、サーバはクライアントに 403 Forbidden +ステータスコードを返します。同じ動作は +Deny ディレクティブでも +実現できますが、このフラグの方が Forbidden ステータスの割り当てに +柔軟性があります。

+ +

以下のルールは、サーバから .exe ファイルのダウンロードを +禁止します。

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

この例は書き換えターゲットに "-" 構文を使用しており、リクエスト URI は +変更されません。リクエストを禁止するのであれば、別の URI に書き換える +理由はありません。

+ +

[F] を使用すると [L] が暗黙的に含まれます - つまり、レスポンスが +直ちに返され、後続のルールは評価されません。

+ +
+ +
G|gone +

[G] フラグは、サーバにレスポンスとして 410 Gone ステータスを +返すよう強制します。これは、リソースがかつて利用可能であったが、 +もはや利用できないことを示します。

+ +

[F] フラグと同様に、[G] フラグを使用する場合は通常書き換えターゲットに +"-" 構文を使用します:

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

[G] を使用すると [L] が暗黙的に含まれます - つまり、レスポンスが +直ちに返され、後続のルールは評価されません。

+ +
+ +
H|handler +

結果のリクエストを指定されたハンドラで処理するよう強制します。 +例えば、ファイル拡張子のないすべてのファイルを php ハンドラで +解析させるために使用できます:

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

+上記の正規表現 - !\. - は、リテラルの . +文字を含まないすべてのリクエストにマッチします。 +

+ +

これは条件に基づいてハンドラを強制するためにも使用できます。 +例えば、以下のスニペットをサーバ単位のコンテキストで使用すると、 +.php ファイルが .phps 拡張子でリクエスト +された場合に mod_php によって表示されます:

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

上記の正規表現 - ^(/source/.+\.php)s$ - は +/source/ で始まり、1 文字以上の任意の文字が続き、 +リテラルの .phps で終わるリクエストにマッチします。 +バックリファレンス $1 は正規表現の括弧内のキャプチャされたマッチを +参照します。

+
+ +
L|last +

[L] フラグは mod_rewrite にルールセットの処理を +停止させます。ほとんどのコンテキストで、ルールがマッチした場合、 +以降のルールは処理されなくなります。これは Perl の last +コマンドや C の break コマンドに相当します。 +このフラグは、後続のルールを考慮せずに現在のルールを直ちに適用 +すべきことを示すために使用します。

+ +

.htaccess ファイルまたは +Directory +セクションで RewriteRule +を使用している場合、ルールがどのように処理されるかについてある程度の +理解が重要です。簡略化すると、ルールが処理された後、書き換えられた +リクエストは URL 解析エンジンに渡されます。書き換えられたリクエストが +処理される際に、.htaccess ファイルまたは +Directory セクションが +再び検出され、ルールセットが最初から再実行される可能性があります。 +これは最も一般的に、ルールの 1 つが (内部または外部の) リダイレクトを +引き起こし、リクエスト処理が最初からやり直される場合に発生します。

+ +

したがって、これらのコンテキストで RewriteRule ディレクティブを使用する場合、 +ルールのループを避けるための明示的な対策を取り、一連のルールの実行 +終了を [L] フラグだけに頼らないことが重要です。以下に示す通りです。

+ +

代替フラグ [END] は、現在の書き換え処理ラウンドを終了するだけでなく、 +ディレクトリ単位 (htaccess) コンテキストでの以降の書き換え処理も +防止するために使用できます。これは外部リダイレクトによる新しい +リクエストには適用されません。

+ +

ここに示す例は、すべてのリクエストを index.php に +書き換え、元のリクエストを index.php へのクエリ文字列 +引数として渡しますが、RewriteCond +により、リクエストが既に index.php に対するものである場合は +RewriteRule がスキップされます。

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

+[N] フラグは、それまでのルールセットの結果を出発点として、ルールセットを +最初からやり直します。ループを引き起こす可能性があるため、 +極めて慎重に使用してください。 +

+

+[Next] フラグは、例えばリクエスト内の特定の文字列や文字を繰り返し +置換したい場合に使用できます。ここに示す例は、リクエスト内のすべての +A を B に置換し、置換すべき A がなくなるまで続けます。 +

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

これは while ループと考えることができます: このパターンが +まだマッチする間 (つまり、URI にまだ A が含まれている間)、 +この置換を実行します (つまり、A を B に +置換します)。

+ +

2.5.0 以降では、意図しないループを防ぐため、10,000 回の反復後に +エラーを返します。N フラグに追加することで、代替の最大反復回数を +指定できます。

+ +# ループの各パスで 1 文字を置換 +RewriteRule "(.+)[><;]$" "$1" [N=32000] +# ... または、10 ループ後に諦める +RewriteRule "(.+)[><;]$" "$1" [N=10] + + +
+ +
NC|nocase +

[NC] フラグを使用すると、RewriteRule は大文字小文字を +区別せずにマッチします。つまり、マッチする URI で文字が大文字か +小文字かを気にしません。

+ +

以下の例では、画像ファイルのリクエストは専用の画像サーバに +プロキシされます。マッチは大文字小文字を区別しないため、例えば +.jpg と .JPG ファイルの両方が受け入れられます。

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

デフォルトでは、RewriteRule +が外部リダイレクトをもたらす場合、出力内の以下の安全なセット以外の文字は +16 進コード (パーセントエンコード) に変換されます:

+ +
    +
  • 英数字: A-Z、a-z、 + 0-9
  • +
  • 特殊文字: $-_.+!*'(),:;@&=/~
  • +
+ +

例えば、# は %23 に、? は +%3F に変換されます。% 文字もエスケープされ +(%25 に)、これにより置換に既に存在するパーセントエンコーディングが +二重エンコードされることを意味します。

+ +

[NE] フラグを使用すると、このエスケープが防止され、# や +? などの文字がそのままリダイレクト URL に渡されます。

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

+上記の例は /anchor/xyz を /bigpage.html#xyz に +リダイレクトします。[NE] を省略すると、# が 16 進コード相当の +%23 に変換され、404 Not Found エラーが発生します。 +

+ +
+ +
NS|nosubreq +

[NS] フラグを使用すると、サブリクエストでのルールの使用が +防止されます。例えば、SSI (Server Side Include) を使用して +インクルードされたページはサブリクエストであり、それらのサブリクエストで +書き換えが行われないようにしたい場合があります。また、 +mod_dir がディレクトリのデフォルトファイル +(index.html ファイルなど) の情報を調べようとする場合も +内部サブリクエストであり、そのようなサブリクエストでの書き換えを +避けたい場合が多くあります。サブリクエストでは、ルールの完全なセットが +適用されると有用でない場合やエラーを引き起こす場合があります。 +問題のあるルールを除外するためにこのフラグを使用してください。

+ +

このルールを使用するかどうかを決定するには: CGI スクリプトで +URL をプレフィックスし、CGI スクリプトで処理させるようにしている場合、 +サブリクエストで問題 (または大きなオーバーヘッド) が発生する +可能性があります。そのような場合はこのフラグを使用してください。

+ +

+HTML ページの一部として読み込まれる画像、JavaScript ファイル、 +CSS ファイルはサブリクエストではありません - ブラウザがそれらを +別の HTTP リクエストとしてリクエストします。 +

+
+ +
P|proxy +

[P] フラグを使用すると、リクエストは mod_proxy によって +処理され、プロキシリクエストとして扱われます。例えば、すべての画像 +リクエストをバックエンド画像サーバで処理したい場合、以下のようにします:

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

[P] フラグの使用は [L] を暗黙的に含みます - つまり、リクエストは +直ちにプロキシに送られ、後続のルールは考慮されません。

+ +

+置換文字列が mod_proxy で処理できる有効な URI +(通常 http://hostname で始まる) であることを +確認する必要があります。そうでない場合、プロキシモジュールからエラーが +発生します。このフラグは、ProxyPass +ディレクティブのより強力な実装を実現し、リモートコンテンツをローカル +サーバのネームスペースにマッピングするために使用します。

+ + +セキュリティ警告 +

ルールのターゲット URL を構築する際には、サーバがプロキシとして +動作する URL のセットに対するクライアントの影響のセキュリティ上の +影響を考慮してください。URL のスキームとホスト名の部分が固定されているか、 +クライアントに過度の影響を与えないことを確認してください。

+
+ + +パフォーマンス警告 +

このフラグを使用すると、デフォルトワーカーが使用されるため、 +永続的な接続が処理されない mod_proxy の使用がトリガー +されます。接続プーリング/再利用が処理されません。

+

永続的な接続を使用するには、少なくともターゲット URL のスキームと +ホスト部分に対する Proxy +ブロックを設定し、例えばタイムアウトを設定する +ProxySet ディレクティブを +含めてください。

+

ProxyPass または +ProxyPassMatch で設定すると、 +永続的な接続が自動的に使用されます。

+
+ +

注: このフラグを使用するには mod_proxy が +有効になっている必要があります。

+ +
+ +
PT|passthrough + +

+RewriteRule のターゲット (置換文字列) はデフォルトではファイルパスと +想定されます。[PT] フラグを使用すると、代わりに URI として扱われます。 +つまり、[PT] フラグを使用すると、RewriteRule の結果が URL マッピングに +戻され、Alias、Redirect、ScriptAlias などの場所ベースのマッピングが +効果を発揮する機会が与えられます。 +

+ +

+例えば、/icons に対する Alias があり、 +そこを指す RewriteRule がある +場合、Alias が評価されるように +[PT] フラグを使用する必要があります。 +

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

+この場合に [PT] フラグを省略すると、Alias が無視され、 +'File not found' エラーが返されます。 +

+ +

PT フラグは L フラグを暗黙的に含みます: +リクエストを処理の次のフェーズに渡すために書き換えが停止されます。

+ +

PT フラグは、 +Directory セクションや +.htaccess ファイルなどのディレクトリ単位のコンテキストでは +暗黙的に含まれることに注意してください。これを回避する唯一の方法は、 +- に書き換えることです。

+ +
+ +
QSA|qsappend +

+置換 URI にクエリ文字列が含まれる場合、 +RewriteRule のデフォルト動作は +既存のクエリ文字列を破棄し、新しく生成されたもので置き換えることです。 +[QSA] フラグを使用すると、クエリ文字列が結合されます。 +

+ +

以下のルールを考えてみましょう:

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

[QSA] フラグがある場合、/pages/123?one=two へのリクエストは +/page.php?page=123&one=two にマッピングされます。 +[QSA] フラグがない場合、同じリクエストは /page.php?page=123 +にマッピングされます - つまり、既存のクエリ文字列は破棄されます。 +

+
+ +
QSD|qsdiscard +

+リクエストされた URI にクエリ文字列が含まれ、ターゲット URI に含まれない +場合、RewriteRule のデフォルト +動作はそのクエリ文字列をターゲット URI にコピーすることです。 +[QSD] フラグを使用すると、クエリ文字列が破棄されます。 +

+ +

このフラグはバージョン 2.4.0 以降で使用可能です。

+ +

+[QSD] と [QSA] を一緒に使用すると、[QSD] が優先されます。 +

+ +

+ターゲット URI にクエリ文字列がある場合は、デフォルトの動作が +観察されます - つまり、元のクエリ文字列は破棄され、 +RewriteRule ターゲット URI のクエリ文字列に +置き換えられます。 +

+ +
+ +
QSL|qslast +

+デフォルトでは、置換内の最初の (左端の) 疑問符がパスとクエリ文字列を +区切ります。[QSL] フラグを使用すると、代わりに最後の (右端の) 疑問符で +2 つのコンポーネントを分割するよう +RewriteRule に指示します。

+ +

+これは、ファイル名にリテラルの疑問符が含まれるファイルへのマッピング時に +便利です。置換でクエリ文字列が使用されない場合、このフラグと組み合わせて +疑問符を追加できます。

+ +

このフラグはバージョン 2.4.19 以降で使用可能です。

+ +
+ + +
R|redirect +

+[R] フラグを使用すると、ブラウザに HTTP リダイレクトが発行されます。 +完全修飾 URL (つまり http://servername/ を含む) が指定された +場合、その場所へのリダイレクトが発行されます。それ以外の場合は、 +現在のプロトコル、サーバ名、ポート番号がリダイレクトで送信される +URL の生成に使用されます。 +

+ +

+[R=305] のような構文を使用して、任意の有効な HTTP レスポンスステータス +コードを指定できます。指定されない場合、デフォルトの 302 ステータスコードが +使用されます。指定されたステータスコードは必ずしもリダイレクト (3xx) +ステータスコードである必要はありません。ただし、リダイレクト範囲 (300-399) +外のステータスコードの場合、置換文字列は完全に破棄され、L +が使用されたかのように書き換えが停止されます。

+ +

レスポンスステータスコードに加えて、シンボリック名を使用して +リダイレクトステータスを指定することもできます: temp +(デフォルト)、permanent、または seeother。

+ +

+[R] フラグはほぼ常に [L] と組み合わせて使用します (つまり [R,L])。 +[R] フラグ単独では、URI に http://thishost[:thisport] を +前置しますが、これをルールセットの次のルールに渡すため、しばしば +'Invalid URI in request' 警告が発生します。 +

+ +

注: httpd は HTTP 仕様に含まれるステータスコードのみをサポートします。 +認識されないステータスコードを使用すると、500 エラーとエラーログ +メッセージが発生します。

+ +
+ +
S|skip +

[S] フラグは、実行したくないルールをスキップするために使用されます。 +スキップフラグの構文は [S=N] で、N はスキップする +ルールの数を表します (RewriteRule +と先行する RewriteCond +ディレクティブがマッチする場合)。これは書き換えルールセット内の +goto 文と考えることができます。以下の例では、リクエストされた +URI が実際のファイルに対応しない場合にのみ +RewriteRule を実行したいとします。

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

このテクニックが有用なのは、RewriteCond は直後の +RewriteRule にのみ適用されるため +です。複数の RewriteRule に RewriteCond を +適用したい場合の一つの方法は、条件を否定して [Skip] フラグ付きの +RewriteRule を追加することです。これを使用して疑似的な +if-then-else 構造を作成できます: then 節の最後のルールが +skip=N となり、N は else 節のルール数です:

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

この種の設定は、代わりに If、 +ElseIf、Else ディレクティブを使用する方が +おそらく簡単でしょう。

+ +
+ +
T|type +

結果のレスポンスが送信される MIME タイプを設定します。 +これは AddType ディレクティブと +同じ効果を持ちます。

+ +

例えば、特定の方法でリクエストされた場合に Perl ソースコードを +プレーンテキストとして提供するために、以下のテクニックを使用できます:

+ + +# .pl ファイルをプレーンテキストとして提供 +RewriteRule "\.pl$" "-" [T=text/plain] + + +

あるいは、ファイル拡張子のない jpeg 画像を生成するカメラがある場合、 +ファイル名によって正しい MIME タイプで画像を提供するよう強制できます:

+ + +# 名前に 'IMG' を含むファイルは jpg 画像 +RewriteRule "IMG" "-" [T=image/jpg] + + +

これは簡単な例であり、代わりに +FilesMatch を使用する +方が良いことに注意してください。問題に対する代替の解決策を常に検討して +から書き換えに頼ってください。書き換えは常に代替手段よりも +効率が悪くなります。

+ +

+ディレクトリ単位のコンテキストで使用する場合は、 +mod_rewrite 処理の全ラウンドの置換として +- (ダッシュ) のみを使用してください。そうしないと、 +内部的な再処理 (mod_rewrite 処理の後続ラウンドを含む) +により、このフラグで設定された MIME タイプが失われます。 +現在の mod_rewrite 処理ラウンドを終了するために +L フラグが有用です。

+
+ +
UnsafeAllow3F +

このフラグを設定すると、書き換え対象の HTTP リクエストに + エンコードされた疑問符 '%3f' が含まれ、書き換え結果の置換に + '?' がある場合でも書き換えを続行できます。これは、悪意のある + URL がエンコードされた疑問符のキャプチャと再置換を利用するのを + 防止します。

+
+
UnsafePrefixStat +

このフラグを設定すると、サーバスコープの置換が変数や + バックリファレンスで始まり、ファイルシステムパスに解決される場合に + 必要です。これらの置換にはドキュメントルートがプレフィックスとして + 付加されません。これは、悪意のある URL が展開された置換を + 予期しないファイルシステムの場所にマッピングさせるのを防止します。

+ +

2.5.1

+
+
UNC +

このフラグを設定すると、Windows UNC パスで使用される複数の + 先頭スラッシュのマージが防止されます。ルールの置換がリテラルの + 複数スラッシュで始まる場合、このフラグは不要です。

+ +

2.5.1

+
+ +
diff --git a/docs/manual/rewrite/flags.xml.ko b/docs/manual/rewrite/flags.xml.ko new file mode 100644 index 0000000000..bb322d5174 --- /dev/null +++ b/docs/manual/rewrite/flags.xml.ko @@ -0,0 +1,930 @@ + + + + + + + + +Rewrite + + RewriteRule 플래그 + + +

이 문서는 RewriteRule +지시어에 사용할 수 있는 플래그를 논의하며, 자세한 설명과 +예제를 제공합니다.

+
+ +모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 +접근 제어 +가상 호스트 +프록시 +RewriteMap 사용하기 +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
소개 +

RewriteRule의 +동작은 하나 이상의 플래그로 수정할 수 있습니다. 플래그는 +규칙 끝에 대괄호 안에 포함되며, 여러 플래그는 쉼표로 +구분됩니다.

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

각 플래그는 (몇 가지 예외를 제외하고) CO와 +같은 짧은 형태와 cookie와 같은 긴 형태를 +가집니다. 짧은 형태를 사용하는 것이 가장 일반적이지만, +각 플래그가 무엇을 하는지 기억하기 위해 긴 형태에 +익숙해지는 것이 좋습니다. 일부 플래그는 하나 이상의 +인수를 취합니다. 플래그는 대소문자를 구분하지 않습니다.

+ +

요청과 관련된 메타데이터를 변경하는 플래그(T=, H=, E=)는 +디렉토리별 및 htaccess 컨텍스트에서 동일한 재작성 처리 +라운드 중에 ('-' 이외의) 치환이 수행될 때 효과가 없습니다. +

+ +

여기에서는 사용 가능한 각 플래그와 함께 사용 방법의 +예제가 제시됩니다.

+
+ +
B (역참조 이스케이프) +

[B] 플래그는 RewriteRule에 +변환을 적용하기 전에 영숫자가 아닌 문자를 이스케이프하도록 +지시합니다.

+ +

mod_rewrite는 URL을 매핑하기 전에 +이스케이프를 해제해야 하므로, 역참조는 적용될 때 +이스케이프가 해제됩니다. B 플래그를 사용하면 역참조의 +영숫자가 아닌 문자가 이스케이프됩니다. +예를 들어, 다음 규칙을 고려하십시오:

+ +

서버 변수의 유사한 이스케이프에 대해서는 + "escape" 매핑 함수를 참조하십시오

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

검색어가 'x & y/z'인 경우 브라우저는 이를 +'x%20%26%20y%2Fz'로 인코딩하여 'search/x%20%26%20y%2Fz' +요청을 만듭니다. B 플래그 없이 이 재작성 규칙은 +'search.php?term=x & y/z'로 매핑되며, 이는 유효한 +URL이 아니므로 search.php?term=x%20&y%2Fz=로 +인코딩되어 의도한 것과 다릅니다.

+ +

동일한 규칙에 B 플래그를 설정하면 매개변수가 출력 URL에 +전달되기 전에 다시 인코딩되어 +/search.php?term=x%20%26%20y%2Fz로 올바르게 +매핑됩니다.

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

이 특정 예제가 작동하려면 +AllowEncodedSlashes를 +On으로 설정해야 할 수도 있습니다. httpd는 +URL에서 인코딩된 슬래시를 허용하지 않고 하나를 보면 +404를 반환하기 때문입니다.

+ +

이 이스케이프는 특히 프록시 상황에서 필요합니다. +백엔드가 이스케이프되지 않은 URL을 제시받으면 중단될 수 +있기 때문입니다.

+ +

이 플래그의 대안은 RewriteCond를 사용하여 %{THE_REQUEST}에 대해 +캡처하는 것이며, 이는 인코딩된 형태의 문자열을 +캡처합니다.

+ +

2.4.26 이상에서는 역참조에서 이스케이프할 특정 문자를 +나열하여 제한할 수 있습니다: [B=#?;]. +참고: 이스케이프할 문자 목록에 공백 문자를 사용할 수 +있지만 RewriteRule의 +전체 세 번째 인수를 인용해야 하며 공백이 목록의 마지막 +문자가 되어서는 안 됩니다.

+ + +# 공백과 물음표를 이스케이프합니다. 공백이 포함된 경우 +# 최종 인수 주위의 따옴표가 필요합니다. +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]" + + +

이 방식으로 이스케이프되는 문자를 제한하려면 +#flag_bne와 +#flag_bctls를 참조하십시오

+
+ +
BNP|backrefnoplus (공백을 +로 이스케이프하지 않음) +

[BNP] 플래그는 RewriteRule에 +역참조에서 공백 문자를 '+' 대신 %20으로 이스케이프하도록 +지시합니다. 역참조가 쿼리 문자열이 아닌 경로 구성 요소에서 +사용될 때 유용합니다.

+ + +# 쿼리 문자열을 통한 양식 제출에 사용되는 + 대신 +# 경로에서 공백을 %20으로 이스케이프 +RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]" + + + +

이 플래그는 버전 2.4.26 이상에서 사용할 수 있습니다.

+
+ +
BCTLS +

[BCTLS] 플래그는 [B] 플래그와 유사하지만 제어 문자와 +공백 문자만 이스케이프합니다. 이것은 인코딩되지 않은 채 +쿼리 문자열로 복사될 때 거부되는 동일한 문자 세트입니다. +

+ + +# 제어 문자와 공백을 이스케이프 +RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]" + + +

이 플래그는 버전 2.5.1 이상에서 사용할 수 있습니다.

+ +
+ +
BNE +

[BNE=...]의 문자 목록은 [B] 또는 [BCTLS] 플래그의 +문자에 대한 제외로 처리됩니다. 나열된 문자는 이스케이프되지 +않습니다. +

+ + +# 기본 문자를 이스케이프하되 /는 남김 +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]" + + +

이 플래그는 버전 2.5.1 이상에서 사용할 수 있습니다.

+
+ +
C|chain +

[C] 또는 [chain] 플래그는 RewriteRule이 다음 규칙에 +체인되어 있음을 나타냅니다. 즉, 규칙이 일치하면 평소와 +같이 처리되고 제어가 다음 규칙으로 이동합니다. 그러나 +일치하지 않으면 다음 규칙과 함께 체인된 다른 모든 규칙이 +건너뛰어집니다.

+ +
+ +
CO|cookie +

[CO] 또는 [cookie] 플래그를 사용하면 특정 +RewriteRule이 +일치할 때 쿠키를 설정할 수 있습니다. 인수는 세 개의 +필수 필드와 다섯 개의 선택적 필드로 구성됩니다.

+ +

플래그의 전체 구문은 모든 속성을 포함하여 +다음과 같습니다:

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

쿠키 필드에 리터럴 ':' 문자가 필요한 경우 대체 구문을 +사용할 수 있습니다. 대체 구문을 선택하려면 쿠키 "Name" 앞에 +';' 문자를 붙이고 필드 구분자를 ';'로 지정해야 합니다.

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

쿠키를 설정하려면 이름, 값 및 도메인을 선언해야 +합니다.

+ +
+
Domain
+
쿠키가 유효한 도메인입니다. www.example.com과 +같은 호스트명이거나 .example.com과 같은 +도메인일 수 있습니다. 점으로 구분된 최소 두 부분이어야 +합니다. 즉, 단순히 .com이나 +.net일 수 없습니다. 이러한 종류의 쿠키는 +쿠키 보안 모델에 의해 금지됩니다.
+
+ +

선택적으로 다음 값도 설정할 수 있습니다:

+ +
+
Lifetime
+
쿠키가 지속되는 시간(분)입니다.
+
값이 0이면 쿠키가 현재 브라우저 세션 동안만 지속됩니다. +지정하지 않으면 이것이 기본값입니다.
+
음수 값은 브라우저에서 쿠키를 삭제합니다.
+ +
Path
+
현재 웹사이트에서 쿠키가 유효한 경로입니다. +예: /customers/ 또는 +/files/download/.
+
기본적으로 /로 설정됩니다 - 즉, +전체 웹사이트입니다.
+ +
Secure
+
secure, true 또는 +1로 설정하면 쿠키는 보안(https) 연결을 +통해서만 전달됩니다.
+ +
httponly
+
HttpOnly, true 또는 +1로 설정하면 쿠키에 +HttpOnly 플래그가 설정되며, 이는 이 기능을 +지원하는 브라우저에서 쿠키가 JavaScript 코드로 접근할 수 +없음을 의미합니다.
+ +
samesite
+
false 또는 0 이외의 값으로 +설정하면 SameSite 속성이 지정된 값으로 +설정됩니다. 일반적인 값은 None, +Lax 및 Strict입니다. +2.5.1 이상에서 사용할 수 있습니다.
+
+ + +

다음 예제를 고려하십시오:

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

주어진 예제에서 규칙은 요청을 재작성하지 않습니다. +"-" 재작성 대상은 mod_rewrite에게 요청을 +변경 없이 통과시키도록 지시합니다. 대신 'frontdoor'라는 +쿠키를 'yes' 값으로 설정합니다. 쿠키는 +.example.com 도메인의 모든 호스트에 유효합니다. +1440분(24시간) 후에 만료되도록 설정되며 모든 URI에 대해 +반환됩니다.

+ +
+ +
DPI|discardpath +

DPI 플래그는 재작성된 URI의 PATH_INFO 부분을 +버립니다.

+

이 플래그는 버전 2.2.12 이상에서 사용할 수 있습니다.

+

디렉토리별 컨텍스트에서 각 +RewriteRule이 비교하는 URI는 URI와 +PATH_INFO의 현재 값의 연결입니다.

+ +

현재 URI는 클라이언트가 요청한 초기 URI이거나, +이전 mod_rewrite 처리 라운드의 결과이거나, +현재 mod_rewrite 처리 라운드에서 이전 +규칙의 결과일 수 있습니다.

+ +

반면, 각 규칙 전에 URI에 추가되는 PATH_INFO는 +이 mod_rewrite 처리 라운드 전의 PATH_INFO +값만 반영합니다. 결과적으로 URI의 큰 부분이 여러 +RewriteRule 지시어에서 치환으로 +일치되고 복사될 때, URI의 어느 부분이 현재 PATH_INFO에서 +왔는지 고려하지 않으면 최종 URI에 PATH_INFO의 여러 복사본이 +추가될 수 있습니다.

+ +

이전 요청의 파일 시스템 매핑에서 생성된 PATH_INFO가 +관심 없는 치환에 이 플래그를 사용하십시오. 이 플래그는 +이 mod_rewrite 처리 라운드 전에 설정된 +PATH_INFO를 영구적으로 잊습니다. PATH_INFO는 현재 +mod_rewrite 처리 라운드가 완료될 때까지 +다시 계산되지 않습니다. 이 처리 라운드 중 후속 규칙은 +PATH_INFO가 추가되지 않은 치환의 직접적인 결과만 봅니다.

+
+ +
E|env +

[E] 또는 [env] 플래그를 사용하면 환경 변수의 값을 +설정할 수 있습니다. 일부 환경 변수는 규칙이 실행된 후에 +설정될 수 있으므로, 설정한 것을 해제할 수 있다는 점에 +유의하십시오. 환경 변수의 작동 방식에 대한 자세한 내용은 +환경 변수 문서를 참조하십시오.

+ +

이 플래그의 전체 구문은 다음과 같습니다:

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

VAL에는 확장되는 역참조($N +또는 %N)가 포함될 수 있습니다.

+ +

짧은 형태를 사용하여

+ + +[E=VAR] + + +

VAR이라는 환경 변수를 빈 값으로 설정할 수 +있습니다.

+ +

다음 형태

+ + +[E=!VAR] + + +

를 사용하면 이전에 설정된 VAR이라는 +환경 변수를 해제할 수 있습니다.

+ +

환경 변수는 CGI 프로그램, 다른 RewriteRule 지시어 또는 +CustomLog 지시어를 포함한 다양한 컨텍스트에서 사용할 수 +있습니다.

+ +

다음 예제는 요청된 URI가 이미지 파일인 경우 +'image'라는 환경 변수를 '1' 값으로 설정합니다. 그런 다음 +해당 환경 변수를 사용하여 접근 로그에서 해당 요청을 +제외합니다.

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

이 동일한 효과는 SetEnvIf를 사용하여 얻을 수 +있습니다. 이 기술은 권장 사항이 아닌 예제로 제공됩니다.

+
+ +
END +

[END] 플래그를 사용하면 ([L]과 같이) 현재 재작성 처리 +라운드를 종료할 뿐만 아니라 디렉토리별(htaccess) +컨텍스트에서 후속 재작성 처리가 발생하는 것도 +방지합니다.

+ +

이것은 외부 리다이렉트로 인한 새 요청에는 적용되지 +않습니다.

+
+ +
F|forbidden +

[F] 플래그를 사용하면 서버가 클라이언트에 403 Forbidden +상태 코드를 반환합니다. Deny 지시어를 +사용하여 동일한 동작을 수행할 수 있지만, 이것은 Forbidden +상태를 할당하는 데 더 많은 유연성을 제공합니다.

+ +

다음 규칙은 서버에서 .exe 파일의 +다운로드를 금지합니다.

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

이 예제는 재작성 대상에 "-" 구문을 사용하며, 요청된 +URI가 수정되지 않음을 의미합니다. 요청을 금지하려는 경우 +다른 URI로 재작성할 이유가 없습니다.

+ +

[F]를 사용할 때 [L]이 암시됩니다 - 즉, 응답이 즉시 +반환되고 추가 규칙은 평가되지 않습니다.

+ +
+ +
G|gone +

[G] 플래그는 서버가 응답과 함께 410 Gone 상태를 +반환하도록 강제합니다. 이것은 자원이 이전에 사용 +가능했지만 더 이상 사용할 수 없음을 나타냅니다.

+ +

[F] 플래그와 마찬가지로 [G] 플래그를 사용할 때는 +일반적으로 재작성 대상에 "-" 구문을 사용합니다:

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

[G]를 사용할 때 [L]이 암시됩니다 - 즉, 응답이 즉시 +반환되고 추가 규칙은 평가되지 않습니다.

+ +
+ +
H|handler +

결과 요청이 지정된 핸들러로 처리되도록 강제합니다. +예를 들어, 파일 확장자가 없는 모든 파일을 php 핸들러로 +파싱하도록 강제할 수 있습니다:

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

+위의 정규 표현식 - !\. - 은 리터럴 . +문자를 포함하지 않는 모든 요청과 일치합니다. +

+ +

이것은 일부 조건에 따라 핸들러를 강제하는 데에도 +사용할 수 있습니다. 예를 들어, 서버별 컨텍스트에서 사용되는 +다음 스니펫은 .phps 확장자로 요청된 경우 +.php 파일을 mod_php에 의해 +표시되도록 합니다:

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

위의 정규 표현식 - ^(/source/.+\.php)s$ - +은 /source/로 시작하고 1개 이상의 문자가 뒤따르고 +리터럴 .phps가 뒤따르는 모든 요청과 일치합니다. +역참조 $1은 정규 표현식의 괄호 안의 캡처된 일치를 +참조합니다.

+
+ +
L|last +

[L] 플래그는 mod_rewrite가 규칙 세트의 +처리를 중지하도록 합니다. 대부분의 컨텍스트에서 이것은 +규칙이 일치하면 더 이상 규칙이 처리되지 않음을 의미합니다. +이것은 Perl의 last 명령이나 C의 +break 명령에 해당합니다. 이 플래그를 사용하여 +현재 규칙이 추가 규칙을 고려하지 않고 즉시 적용되어야 +함을 나타냅니다.

+ +

.htaccess 파일이나 +Directory +섹션에서 RewriteRule을 +사용하는 경우 규칙이 처리되는 방식에 대한 이해가 중요합니다. +이것의 간단한 형태는 규칙이 처리되면 재작성된 요청이 +URL 파싱 엔진에 다시 전달되어 처리된다는 것입니다. +재작성된 요청이 처리될 때 .htaccess 파일이나 +Directory +섹션이 다시 만나질 수 있으며, 따라서 규칙 세트가 처음부터 +다시 실행될 수 있습니다. 가장 일반적으로 이것은 규칙 중 +하나가 내부 또는 외부 리다이렉트를 일으켜 요청 처리가 +다시 시작되는 경우에 발생합니다.

+ +

따라서 이러한 컨텍스트 중 하나에서 RewriteRule 지시어를 +사용하는 경우 규칙의 루핑을 피하기 위한 명시적 조치를 +취하고, 아래에 표시된 대로 일련의 규칙의 실행을 종료하기 +위해 [L] 플래그에만 의존하지 않는 것이 중요합니다.

+ +

대안 플래그인 [END]는 현재 재작성 처리 라운드를 +종료할 뿐만 아니라 디렉토리별(htaccess) 컨텍스트에서 +후속 재작성 처리가 발생하는 것도 방지합니다. 이것은 +외부 리다이렉트로 인한 새 요청에는 적용되지 않습니다.

+ +

여기 주어진 예제는 모든 요청을 index.php로 +재작성하며, 원래 요청을 index.php에 쿼리 문자열 +인수로 제공합니다. 그러나 +RewriteCond는 +요청이 이미 index.php에 대한 것인 경우 +RewriteRule이 +건너뛰어지도록 합니다.

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

+[N] 플래그는 규칙 세트를 지금까지의 규칙 세트 결과를 +시작점으로 사용하여 처음부터 다시 시작하도록 합니다. +루프를 초래할 수 있으므로 극도의 주의를 기울여 +사용하십시오. +

+

+[Next] 플래그는 예를 들어, 요청에서 특정 문자열이나 +문자를 반복적으로 대체하려는 경우에 사용할 수 있습니다. +여기 표시된 예제는 요청의 모든 곳에서 A를 B로 대체하며 +더 이상 대체할 A가 없을 때까지 계속합니다. +

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

이것을 while 루프로 생각할 수 있습니다: +이 패턴이 여전히 일치하는 동안(즉, URI에 여전히 +A가 포함되어 있는 동안) 이 치환을 +수행합니다(즉, A를 B로 +대체합니다).

+ +

2.5.0 이상에서 이 모듈은 의도하지 않은 루핑으로부터 +보호하기 위해 10,000번의 반복 후에 오류를 반환합니다. +N 플래그에 추가하여 대안적인 최대 반복 횟수를 지정할 수 +있습니다.

+ +# 루프의 각 패스에서 1개의 문자를 대체할 의향 +RewriteRule "(.+)[><;]$" "$1" [N=32000] +# ... 또는 10번 루프 후 포기 +RewriteRule "(.+)[><;]$" "$1" [N=10] + + +
+ +
NC|nocase +

[NC] 플래그를 사용하면 +RewriteRule이 +대소문자를 구분하지 않는 방식으로 일치됩니다. 즉, +일치하는 URI에서 문자가 대문자인지 소문자인지 상관하지 +않습니다.

+ +

아래 예제에서 이미지 파일에 대한 모든 요청은 전용 +이미지 서버로 프록시됩니다. 일치는 대소문자를 구분하지 +않으므로, 예를 들어 .jpg와 .JPG +파일 모두 허용됩니다.

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

기본적으로 RewriteRule이 +외부 리다이렉트로 이어질 때, 출력에서 다음 안전 세트에 포함되지 +않는 모든 문자는 16진수 코드(퍼센트 인코딩)로 변환됩니다:

+ +
    +
  • 영숫자 문자: A-Z, a-z, + 0-9
  • +
  • 특수 문자: $-_.+!*'(),:;@&=/~
  • +
+ +

예를 들어, #은 %23으로, +?는 %3F로 변환됩니다. +% 문자도 (%25로) 이스케이프되므로 +치환에 이미 존재하는 퍼센트 인코딩이 이중 인코딩됩니다.

+ +

[NE] 플래그를 사용하면 이 이스케이프를 방지하여 +#과 ?와 같은 문자가 수정되지 않고 +리다이렉트 URL로 전달됩니다.

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

+위의 예제는 /anchor/xyz를 +/bigpage.html#xyz로 리다이렉트합니다. +[NE]를 생략하면 #이 16진수 코드인 %23으로 +변환되어 404 Not Found 오류 조건이 발생합니다. +

+ +
+ +
NS|nosubreq +

[NS] 플래그를 사용하면 서브요청에서 규칙이 사용되는 것을 +방지합니다. 예를 들어, SSI(Server Side Include)를 사용하여 +포함된 페이지는 서브요청이며, 해당 서브요청에서 재작성이 +발생하는 것을 피하고 싶을 수 있습니다. 또한 +mod_dir이 가능한 디렉토리 기본 파일(예: +index.html 파일)에 대한 정보를 찾으려 할 때 +이것은 내부 서브요청이며, 종종 이러한 서브요청에서 +재작성을 피하고 싶을 것입니다. 서브요청에서는 전체 +규칙 세트가 적용되는 것이 항상 유용하지 않으며 오류를 +일으킬 수도 있습니다. 이 플래그를 사용하여 문제가 되는 +규칙을 제외하십시오.

+ +

이 규칙을 사용할지 여부를 결정하려면: CGI 스크립트로 +URL에 접두사를 붙여 CGI 스크립트에 의해 처리되도록 강제하는 +경우, 서브요청에서 문제(또는 상당한 오버헤드)가 발생할 +가능성이 있습니다. 이러한 경우 이 플래그를 +사용하십시오.

+ +

+HTML 페이지의 일부로 로드되는 이미지, 자바스크립트 파일 +또는 CSS 파일은 서브요청이 아닙니다 - 브라우저는 이를 +별도의 HTTP 요청으로 요청합니다. +

+
+ +
P|proxy +

[P] 플래그를 사용하면 요청이 +mod_proxy에 의해 처리되고 프록시 요청을 +통해 처리됩니다. 예를 들어, 모든 이미지 요청이 백엔드 +이미지 서버에 의해 처리되도록 하려면 다음과 같이 할 수 +있습니다:

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

[P] 플래그를 사용하면 [L]이 암시됩니다 - 즉, 요청이 +즉시 프록시를 통해 전달되고 이후의 규칙은 고려되지 +않습니다.

+ +

+치환 문자열이 mod_proxy가 처리할 수 있는 +유효한 URI(일반적으로 http://hostname으로 +시작)인지 확인해야 합니다. 그렇지 않으면 프록시 모듈에서 +오류가 발생합니다. 이 플래그를 사용하여 로컬 서버의 네임스페이스에 +원격 콘텐츠를 매핑하는 +ProxyPass 지시어의 +더 강력한 구현을 달성합니다.

+ + +보안 경고 +

규칙의 대상 URL을 구성할 때, 서버가 프록시로 작동할 +URL 세트에 대한 클라이언트의 영향으로 인한 보안 영향을 +고려하여 주의하십시오. URL의 스키마 및 호스트명 부분이 +고정되어 있거나 클라이언트에게 부당한 영향을 주지 +않도록 하십시오.

+
+ + +성능 경고 +

이 플래그를 사용하면 mod_proxy의 사용이 +트리거되며, 이 경우 기본 워커가 사용되어 연결 +풀링/재사용을 처리하지 않으므로 영구 연결을 처리하지 +않습니다.

+

영구 연결을 사용하려면 대상 URL의 스키마 및 호스트 +부분에 대한 Proxy +블록을 최소한 설정하고 예를 들어 타임아웃을 설정하는 +ProxySet 지시어를 +포함해야 합니다.

+

ProxyPass 또는 +ProxyPassMatch로 +설정하면 영구 연결이 자동으로 사용됩니다.

+
+ +

참고: 이 플래그를 사용하려면 +mod_proxy가 활성화되어 있어야 합니다.

+ +
+ +
PT|passthrough + +

+RewriteRule의 대상(또는 치환 문자열)은 기본적으로 파일 +경로로 간주됩니다. [PT] 플래그를 사용하면 대신 URI로 +처리됩니다. 즉, [PT] 플래그를 사용하면 +RewriteRule의 +결과가 URL 매핑을 통해 다시 전달되므로, +Alias, +Redirect 또는 +ScriptAlias와 같은 +위치 기반 매핑이 효과를 발휘할 기회를 가집니다. +

+ +

+예를 들어, /icons에 대한 +Alias가 있고 +거기를 가리키는 RewriteRule이 +있다면 Alias가 +평가되도록 [PT] 플래그를 사용해야 합니다. +

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

+이 경우 [PT] 플래그를 생략하면 Alias가 무시되어 +'File not found' 오류가 반환됩니다. +

+ +

PT 플래그는 L 플래그를 +암시합니다: 요청을 처리의 다음 단계로 전달하기 위해 +재작성이 중지됩니다.

+ +

PT 플래그는 +Directory +섹션이나 .htaccess 파일과 같은 디렉토리별 +컨텍스트에서 암시됩니다. 이를 우회하는 유일한 방법은 +-로 재작성하는 것입니다.

+ +
+ +
QSA|qsappend +

+대체 URI에 쿼리 문자열이 포함된 경우 +RewriteRule의 +기본 동작은 기존 쿼리 문자열을 버리고 새로 생성된 것으로 +대체하는 것입니다. [QSA] 플래그를 사용하면 쿼리 문자열이 +결합됩니다. +

+ +

다음 규칙을 고려하십시오:

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

[QSA] 플래그를 사용하면 /pages/123?one=two에 +대한 요청이 /page.php?page=123&one=two로 +매핑됩니다. [QSA] 플래그 없이 동일한 요청은 +/page.php?page=123으로 매핑됩니다 - 즉, +기존 쿼리 문자열이 버려집니다. +

+
+ +
QSD|qsdiscard +

+요청된 URI에 쿼리 문자열이 포함되어 있고 대상 URI에는 +없는 경우, RewriteRule의 +기본 동작은 해당 쿼리 문자열을 대상 URI에 복사하는 +것입니다. [QSD] 플래그를 사용하면 쿼리 문자열이 +버려집니다. +

+ +

이 플래그는 버전 2.4.0 이상에서 사용할 수 있습니다.

+ +

+[QSD]와 [QSA]를 함께 사용하면 [QSD]가 우선합니다. +

+ +

+대상 URI에 쿼리 문자열이 있는 경우 기본 동작이 +관찰됩니다 - 즉, 원래 쿼리 문자열이 버려지고 +RewriteRule 대상 URI의 쿼리 문자열로 +대체됩니다. +

+ +
+ +
QSL|qslast +

+기본적으로 치환에서 첫 번째(가장 왼쪽) 물음표가 경로와 +쿼리 문자열을 구분합니다. [QSL] 플래그를 사용하면 +RewriteRule이 +대신 마지막(가장 오른쪽) 물음표를 사용하여 두 구성 요소를 +분리합니다.

+ +

+이것은 파일명에 리터럴 물음표가 있는 파일에 매핑할 때 +유용합니다. 치환에 쿼리 문자열이 사용되지 않는 경우 +이 플래그와 함께 물음표를 추가할 수 있습니다.

+ +

이 플래그는 버전 2.4.19 이상에서 사용할 수 있습니다.

+ +
+ + +
R|redirect +

+[R] 플래그를 사용하면 브라우저에 HTTP 리다이렉트가 +발행됩니다. 완전한 URL(즉, +http://servername/ 포함)이 지정되면 +해당 위치로 리다이렉트가 발행됩니다. 그렇지 않으면 +현재 프로토콜, 서버명 및 포트 번호가 리다이렉트와 +함께 전송되는 URL을 생성하는 데 사용됩니다. +

+ +

+유효한 모든 HTTP 응답 상태 코드를 +[R=305] 구문으로 지정할 수 있으며, 지정하지 않으면 +302 상태 코드가 기본적으로 사용됩니다. 지정된 상태 코드가 +반드시 리다이렉트(3xx) 상태 코드일 필요는 없습니다. +그러나 상태 코드가 리다이렉트 범위(300-399) 밖에 있으면 +치환 문자열이 완전히 삭제되고 L이 사용된 +것처럼 재작성이 중지됩니다.

+ +

응답 상태 코드 외에도 기호 이름을 사용하여 리다이렉트 +상태를 지정할 수도 있습니다: temp(기본값), +permanent 또는 seeother.

+ +

+거의 항상 [R]을 [L]과 함께 사용하고 싶을 것입니다(즉, +[R,L]). [R] 플래그 단독으로는 URI 앞에 +http://thishost[:thisport]를 추가하지만 +이를 규칙 세트의 다음 규칙에 전달하여 종종 +'Invalid URI in request' 경고를 초래합니다. +

+ +

참고: httpd는 HTTP 사양에 포함된 상태 코드만 +지원합니다. 인식할 수 없는 상태 코드를 사용하면 +500 오류와 오류 로그 메시지가 발생합니다.

+ +
+ +
S|skip +

[S] 플래그는 실행하고 싶지 않은 규칙을 건너뛰는 데 +사용됩니다. 건너뛰기 플래그의 구문은 [S=N]이며, +N은 건너뛸 규칙의 수를 나타냅니다 +(RewriteRule과 +선행 RewriteCond +지시어가 일치하는 경우). 이것은 재작성 규칙 세트의 +goto 문으로 생각할 수 있습니다. 다음 예제에서는 +요청된 URI가 실제 파일에 해당하지 않는 경우에만 +RewriteRule을 +실행하고자 합니다.

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

이 기술은 RewriteCond가 +바로 다음에 오는 +RewriteRule에만 +적용되기 때문에 유용합니다. 따라서 +RewriteCond를 여러 +RewriteRule에 적용하려면 가능한 기술 중 +하나는 해당 조건을 부정하고 [Skip] 플래그를 가진 +RewriteRule을 추가하는 것입니다. +이를 사용하여 유사 if-then-else 구조를 만들 수 있습니다: +then 절의 마지막 규칙은 skip=N이 되며, +N은 else 절의 규칙 수입니다:

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

If, +ElseIf 및 +Else 지시어를 +대신 사용하면 이러한 종류의 설정을 더 쉽게 달성할 수 +있습니다.

+ +
+ +
T|type +

결과 응답이 전송될 MIME 유형을 설정합니다. 이것은 +AddType 지시어와 +동일한 효과를 가집니다.

+ +

예를 들어, 특정 방식으로 요청된 경우 Perl 소스 코드를 +일반 텍스트로 제공하기 위해 다음 기술을 사용할 수 +있습니다:

+ + +# .pl 파일을 일반 텍스트로 제공 +RewriteRule "\.pl$" "-" [T=text/plain] + + +

또는 파일 확장자 없이 jpeg 이미지를 생성하는 카메라가 +있는 경우 파일 이름을 기준으로 올바른 MIME 유형으로 +해당 이미지가 제공되도록 강제할 수 있습니다:

+ + +# 이름에 'IMG'가 포함된 파일은 jpg 이미지입니다. +RewriteRule "IMG" "-" [T=image/jpg] + + +

이것은 간단한 예제이며 대신 +FilesMatch를 +사용하여 더 잘 수행할 수 있다는 점에 유의하십시오. +재작성에 의존하기 전에 항상 문제에 대한 대안 솔루션을 +고려하십시오. 재작성은 대안보다 항상 덜 효율적인 +솔루션이 됩니다.

+ +

+디렉토리별 컨텍스트에서 사용하는 경우 전체 +mod_rewrite 처리 라운드에 대해 +치환으로 -(대시)만 사용하십시오. +그렇지 않으면 내부 재처리(후속 +mod_rewrite 처리 라운드 포함)로 인해 +이 플래그로 설정된 MIME 유형이 손실됩니다. +L 플래그는 이 컨텍스트에서 +mod_rewrite 처리의 현재 라운드를 +종료하는 데 유용할 수 있습니다.

+
+ +
UnsafeAllow3F +

작성 중인 HTTP 요청에 인코딩된 물음표 '%3f'가 있고 + 재작성 결과의 치환에 '?'가 있는 경우 재작성이 계속되도록 + 허용하려면 이 플래그를 설정해야 합니다. 이는 인코딩된 + 물음표의 캡처 및 재치환을 이용하는 악의적인 URL로부터 + 보호합니다.

+
+
UnsafePrefixStat +

서버 범위의 치환이 변수나 역참조로 시작하고 파일 시스템 + 경로로 해석되는 경우 이 플래그를 설정해야 합니다. + 이러한 치환은 문서 루트로 접두사가 붙지 않습니다. + 이는 확장된 치환이 예상치 못한 파일 시스템 위치에 + 매핑되는 악의적인 URL로부터 보호합니다.

+ +

2.5.1

+
+
UNC +

이 플래그를 설정하면 Windows UNC 경로에서 사용되는 + 여러 선행 슬래시의 병합을 방지합니다. 규칙의 치환이 + 여러 리터럴 슬래시로 시작하는 경우 이 플래그는 + 필요하지 않습니다.

+ +

2.5.1

+
+ +
diff --git a/docs/manual/rewrite/flags.xml.meta b/docs/manual/rewrite/flags.xml.meta index 912229af03..97d7b5dd80 100644 --- a/docs/manual/rewrite/flags.xml.meta +++ b/docs/manual/rewrite/flags.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/flags.xml.tr b/docs/manual/rewrite/flags.xml.tr new file mode 100644 index 0000000000..9e0fdb64d5 --- /dev/null +++ b/docs/manual/rewrite/flags.xml.tr @@ -0,0 +1,918 @@ + + + + + + + + +Rewrite + + RewriteRule Bayrakları + + +

Bu belge, RewriteRule +yönergesinde kullanılabilecek bayrakları ayrıntılı açıklamalar ve +örneklerle açıklar.

+
+ +Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme +Erişim denetimi +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
Giriş +

Bir RewriteRule +yönergesinin davranışı bir veya daha fazla bayrakla +değiştirilebilir. Bayraklar kuralın sonunda köşeli parantez içinde +belirtilir ve birden fazla bayrak virgülle ayrılır.

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

Her bayrağın (birkaç istisna dışında) CO gibi kısa bir +biçimi ve cookie gibi uzun bir biçimi vardır. Kısa biçim +en yaygın olarak kullanılsa da, her bayrağın ne yapması gerektiğini +hatırlamanız için uzun biçime aşina olmanız önerilir. Bazı bayraklar +bir veya daha fazla argüman alır. Bayraklar büyük/küçük harf +duyarsızdır.

+ +

İstekle ilişkili üstveriyi değiştiren bayraklar (T=, H=, E=), bir +değiştirme ('-' dışında) aynı yeniden yazma işleme turunda +gerçekleştirildiğinde dizin başına ve htaccess bağlamında etkili +olmaz.

+ +

Burada mevcut bayrakların her biri, nasıl kullanabileceğinize dair +bir örnekle birlikte sunulmaktadır.

+
+ +
B (geri başvuruları kodla) +

[B] bayrağı, RewriteRule +yönergesine dönüşümü uygulamadan önce alfasayısal olmayan karakterleri +kodlamasını söyler.

+ +

mod_rewrite URL'leri eşlemeden önce kodlarını +çözmek zorundadır, bu nedenle geri başvurular uygulandığında kodları +çözülmüş olur. B bayrağı kullanıldığında, geri başvurulardaki +alfasayısal olmayan karakterler kodlanır. Örneğin, şu kuralı ele +alalım:

+ +

Sunucu değişkenlerinin benzer şekilde kodlanması için + "escape" eşleme işlevine bakın

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

Arama terimi 'x & y/z' olduğunda, tarayıcı bunu +'x%20%26%20y%2Fz' olarak kodlar ve istek 'search/x%20%26%20y%2Fz' +olur. B bayrağı olmadan bu yeniden yazma kuralı 'search.php?term=x +& y/z' ile eşleşir ki bu geçerli bir URL değildir ve +search.php?term=x%20&y%2Fz= olarak kodlanır, bu da +amaçlanan değildir.

+ +

Aynı kuralda B bayrağı ayarlandığında, parametreler çıktı URL'sine +geçirilmeden önce yeniden kodlanır ve doğru bir eşleme olan +/search.php?term=x%20%26%20y%2Fz elde edilir.

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

Bu belirli örneğin çalışması için AllowEncodedSlashes yönergesini +On olarak ayarlamanız gerekebileceğini unutmayın; çünkü +httpd URL'lerde kodlanmış eğik çizgilere izin vermez ve bir tane +görürse 404 döndürür.

+ +

Bu kodlama özellikle vekil durumunda gereklidir; arka uç, kodları +çözülmüş bir URL ile karşılaşırsa bozulabilir.

+ +

Bu bayrağa bir alternatif, %{THE_REQUEST} değerine karşı yakalama +yapan bir RewriteCond +kullanmaktır; bu, dizgeleri kodlanmış biçimde yakalar.

+ +

2.4.26 ve sonrasında, geri başvurulardaki kodlamayı belirli +karakterlerle sınırlayabilirsiniz: [B=#?;]. Not: Boşluk +karakteri kodlanacak karakterler listesinde kullanılabilir, ancak +RewriteRule yönergesinin +üçüncü argümanının tamamını tırnak içine almanız ve boşluğun listenin +son karakteri olmaması gerekir.

+ + +# Boşlukları ve soru işaretlerini kodla. Son argüman etrafındaki +# tırnak işaretleri, boşluk dahil edildiğinde gereklidir. +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]" + + +

Bu şekilde kodlanan karakterleri sınırlamak için #flag_bne ve #flag_bctls bayraklarına bakın

+
+ +
BNP|backrefnoplus (boşluğu +'ya kodlama) +

[BNP] bayrağı, RewriteRule +yönergesine geri başvurulardaki boşluk karakterini '+' yerine %20 +olarak kodlamasını söyler. Geri başvuru sorgu dizgesi yerine yol +bileşeninde kullanılacaksa yararlıdır.

+ + +# Form gönderimi yoluyla sorgu dizgesinde kullanılan + yerine yolda +# boşlukları %20 olarak kodla +RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]" + + + +

Bu bayrak 2.4.26 ve sonraki sürümlerde mevcuttur.

+
+ +
BCTLS +

[BCTLS] bayrağı [B] bayrağına benzer, ancak yalnızca kontrol +karakterlerini ve boşluk karakterini kodlar. Bu, sorgu dizgesine +kodlanmadan kopyalandıklarında reddedilen karakter kümesiyle +aynıdır.

+ + +# Kontrol karakterlerini ve boşlukları kodla +RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]" + + +

Bu bayrak 2.5.1 ve sonraki sürümlerde mevcuttur.

+ +
+ +
BNE +

[BNE=...] içindeki karakter listesi, [B] veya [BCTLS] bayraklarının +karakterlerinden istisna olarak değerlendirilir. Listelenen karakterler +kodlanmayacaktır.

+ + +# Öntanımlı karakterleri kodla, ancak / karakterini bırak +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]" + + +

Bu bayrak 2.5.1 ve sonraki sürümlerde mevcuttur.

+
+ +
C|chain +

[C] veya [chain] bayrağı, RewriteRule yönergesinin bir sonraki +kurala zincirleneceğini belirtir. Yani, kural eşleşirse her zamanki +gibi işlenir ve denetim bir sonraki kurala geçer. Ancak eşleşmezse bir +sonraki kural ve birlikte zincirlenen diğer kurallar atlanır.

+ +
+ +
CO|cookie +

[CO] veya [cookie] bayrağı, belirli bir RewriteRule eşleştiğinde bir çerez +ayarlamanıza olanak tanır. Argüman üç zorunlu ve beş isteğe bağlı +alandan oluşur.

+ +

Bayrağın tüm öznitelikler dahil tam sözdizimi şöyledir:

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

Çerez alanlarından herhangi birinde birebir ':' karakterine ihtiyaç +duyulursa, alternatif bir sözdizimi mevcuttur. Alternatif sözdizimini +etkinleştirmek için çerez "Name" alanının önüne ';' karakteri +konulmalı ve alan ayırıcıları ';' olarak belirtilmelidir.

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

Çerezin ayarlanması için bir ad, bir değer ve bir alan adı +bildirmelisiniz.

+ +
+
Alan Adı (Domain)
+
Çerezin geçerli olmasını istediğiniz alan adı. Bu, +www.example.com gibi bir konak adı veya +.example.com gibi bir alan adı olabilir. En az iki +parçadan oluşmalı ve bir nokta ile ayrılmalıdır. Yani yalnızca +.com veya .net olamaz. Bu tür çerezler +çerez güvenlik modeli tarafından yasaklanmıştır.
+
+ +

İsteğe bağlı olarak aşağıdaki değerleri de ayarlayabilirsiniz:

+ +
+
Ömür (Lifetime)
+
Çerezin kalıcı olacağı süre, dakika cinsinden.
+
0 değeri, çerezin yalnızca geçerli tarayıcı oturumu süresince +kalıcı olacağını belirtir. Hiçbir değer belirtilmezse bu öntanımlı +değerdir.
+
Negatif bir değer, çerezin tarayıcıda silinmesine neden olur.
+ +
Yol (Path)
+
Geçerli web sitesinde çerezin geçerli olduğu yol; +/customers/ veya /files/download/ gibi.
+
Öntanımlı olarak / olarak ayarlanır - yani web +sitesinin tamamı.
+ +
Güvenli (Secure)
+
secure, true veya 1 olarak +ayarlanırsa, çerez yalnızca güvenli (https) bağlantılar üzerinden +aktarılabilir.
+ +
httponly
+
HttpOnly, true veya 1 +olarak ayarlanırsa, çerez HttpOnly bayrağıyla +ayarlanır; bu, çerezin bu özelliği destekleyen tarayıcılarda +JavaScript koduna erişilemez olduğu anlamına gelir.
+ +
samesite
+
false veya 0 dışında bir değere +ayarlanırsa, SameSite özniteliği belirtilen değere +ayarlanır. Tipik değerler None, Lax ve +Strict'tir. 2.5.1 ve sonrasında mevcuttur.
+
+ + +

Şu örneği ele alalım:

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

Verilen örnekte, kural isteği yeniden yazmaz. "-" yeniden yazma +hedefi, mod_rewrite modülüne isteği değiştirmeden +geçirmesini söyler. Bunun yerine, 'frontdoor' adlı bir çerezi 'yes' +değeriyle ayarlar. Çerez .example.com alan adındaki +herhangi bir konak için geçerlidir. 1440 dakika (24 saat) sonra sona +erecek şekilde ayarlanır ve tüm URI'ler için döndürülür.

+ +
+ +
DPI|discardpath +

DPI bayrağı, yeniden yazılmış URI'nin PATH_INFO bölümünün +atılmasına neden olur.

+

Bu bayrak 2.2.12 ve sonraki sürümlerde mevcuttur.

+

Dizin başına bağlamda, her RewriteRule +yönergesinin karşılaştırdığı URI, URI'nin ve PATH_INFO'nun geçerli +değerlerinin birleşimidir.

+ +

Geçerli URI, istemcinin istediği ilk URI, önceki bir +mod_rewrite işleme turunun sonucu veya geçerli +mod_rewrite işleme turundaki önceki bir kuralın +sonucu olabilir.

+ +

Buna karşılık, her kuraldan önce URI'ye eklenen PATH_INFO yalnızca +bu mod_rewrite işleme turundan önceki PATH_INFO +değerini yansıtır. Sonuç olarak, URI'nin büyük bölümleri birden fazla +RewriteRule yönergesinde bir değiştirmeye +eşlenip kopyalanırsa ve URI'nin hangi bölümlerinin geçerli +PATH_INFO'dan geldiğine dikkat edilmezse, son URI'ye PATH_INFO'nun +birden fazla kopyası eklenebilir.

+ +

Bu bayrağı, önceki dosya sistemi eşlemesinden kaynaklanan +PATH_INFO'nun ilgilendirmediği herhangi bir değiştirmede kullanın. Bu +bayrak, bu mod_rewrite işleme turu başlamadan önce +oluşturulan PATH_INFO'yu kalıcı olarak unutur. PATH_INFO, geçerli +mod_rewrite işleme turu tamamlanana kadar yeniden +hesaplanmaz. Bu tur boyunca sonraki kurallar, yalnızca değiştirmelerin +doğrudan sonucunu görür; eklenmiş bir PATH_INFO olmaz.

+
+ +
E|env +

[E] veya [env] bayrağıyla bir ortam değişkeninin değerini +ayarlayabilirsiniz. Bazı ortam değişkenlerinin kural çalıştıktan sonra +ayarlanabileceğini ve böylece ayarladığınız değeri geçersiz +kılabileceğini unutmayın. Ortam değişkenlerinin nasıl çalıştığı +hakkında daha fazla ayrıntı için Ortam +Değişkenleri belgesine bakın.

+ +

Bu bayrağın tam sözdizimi şöyledir:

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

VAL, genişletilen geri başvurular ($N +veya %N) içerebilir.

+ +

Kısa biçimi kullanarak

+ + +[E=VAR] + + +

VAR adlı ortam değişkenini boş bir değere +ayarlayabilirsiniz.

+ +

Şu biçim

+ + +[E=!VAR] + + +

daha önce ayarlanmış VAR adlı ortam değişkeninin +silinmesine olanak tanır.

+ +

Ortam değişkenleri daha sonra CGI programları, diğer RewriteRule +yönergeleri veya CustomLog yönergeleri dahil olmak üzere çeşitli +bağlamlarda kullanılabilir.

+ +

Aşağıdaki örnek, istenen URI bir resim dosyasıysa 'image' adlı bir +ortam değişkenini '1' değerine ayarlar. Daha sonra bu ortam değişkeni, +bu istekleri erişim günlüğünden dışlamak için kullanılır.

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

Aynı etkinin SetEnvIf +kullanılarak elde edilebileceğini unutmayın. Bu teknik bir öneri olarak +değil, bir örnek olarak sunulmuştur.

+
+ +
END +

[END] bayrağı kullanmak, yalnızca geçerli yeniden yazma işleme +turunu durdurmakla kalmaz ([L] gibi), aynı zamanda dizin başına +(htaccess) bağlamda sonraki yeniden yazma işlemlerinin de +gerçekleşmesini engeller.

+ +

Bu, harici yönlendirmelerden kaynaklanan yeni istekler için +geçerli değildir.

+
+ +
F|forbidden +

[F] bayrağı kullanmak, sunucunun istemciye 403 Yasak durum kodu +döndürmesine neden olur. Aynı davranış Deny yönergesiyle de +gerçekleştirilebilir ancak bu, Yasak durumu atamada daha fazla esneklik +sağlar.

+ +

Aşağıdaki kural, .exe dosyalarının sunucunuzdan +indirilmesini yasaklar.

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

Bu örnek, yeniden yazma hedefi için "-" sözdizimini kullanır; bu, +istenen URI'nin değiştirilmediği anlamına gelir. İsteği yasaklayacaksanız +başka bir URI'ye yeniden yazmanın bir nedeni yoktur.

+ +

[F] kullanıldığında, [L] zımnen uygulanır - yani yanıt hemen +döndürülür ve başka kural değerlendirilmez.

+ +
+ +
G|gone +

[G] bayrağı, sunucuyu yanıtla birlikte 410 Kalktı durum kodu +döndürmeye zorlar. Bu, bir kaynağın eskiden mevcut olduğunu ancak +artık mevcut olmadığını belirtir.

+ +

[F] bayrağında olduğu gibi, [G] bayrağını kullanırken genellikle +yeniden yazma hedefi için "-" sözdizimini kullanırsınız:

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

[G] kullanıldığında, [L] zımnen uygulanır - yani yanıt hemen +döndürülür ve başka kural değerlendirilmez.

+ +
+ +
H|handler +

Elde edilen isteğin belirtilen işleyici ile işlenmesini zorlar. +Örneğin, dosya uzantısı olmayan tüm dosyaların php işleyicisi +tarafından çözümlenmesini zorlamak için kullanılabilir:

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

+Yukarıdaki düzenli ifade - !\. - birebir . +karakterini içermeyen herhangi bir istekle eşleşir. +

+ +

Bu, bazı koşullara dayalı olarak işleyiciyi zorlamak için de +kullanılabilir. Örneğin, sunucu bağlamında kullanılan aşağıdaki +kod parçası, .phps uzantısıyla istendiğinde +.php dosyalarının mod_php tarafından +görüntülenmesini sağlar:

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

Yukarıdaki düzenli ifade - ^(/source/.+\.php)s$ - +/source/ ile başlayan, ardından 1 veya n karakter gelen +ve birebir .phps ile biten herhangi bir istekle eşleşir. +$1 geri başvurusu, düzenli ifadenin parantez içindeki yakalanan +eşleşmeye referans verir.

+
+ +
L|last +

[L] bayrağı, mod_rewrite modülünün kural kümesini +işlemeyi durdurmasına neden olur. Çoğu bağlamda, kural eşleşirse başka +kural işlenmeyeceği anlamına gelir. Bu, Perl'deki last +komutuna veya C'deki break komutuna karşılık gelir. Bu +bayrağı, geçerli kuralın diğer kurallar dikkate alınmadan hemen +uygulanması gerektiğini belirtmek için kullanın.

+ +

RewriteRule yönergesini +.htaccess dosyalarında veya Directory bölümlerinde kullanıyorsanız, +kuralların nasıl işlendiğini anlamanız önemlidir. Bunun basitleştirilmiş +biçimi, kurallar işlendikten sonra yeniden yazılmış isteğin URL +çözümleme motoruna geri verildiğidir. Yeniden yazılmış istek +işlenirken .htaccess dosyası veya Directory bölümüyle tekrar karşılaşılması +ve kural kümesinin baştan çalıştırılması mümkündür. En yaygın olarak +bu, kurallardan birinin dahili veya harici bir yönlendirmeye neden +olması durumunda olur ve istek sürecinin yeniden başlamasına yol +açar.

+ +

Bu nedenle, RewriteRule +yönergelerini bu bağlamlardan birinde kullanıyorsanız, kuralların +döngüye girmesinden kaçınmak için açık adımlar atmanız ve bir dizi +kuralın yürütülmesini sonlandırmak için yalnızca [L] bayrağına +güvenmemeniz önemlidir; aşağıda gösterildiği gibi.

+ +

Alternatif bir bayrak olan [END], yalnızca geçerli yeniden yazma +işleme turunu sonlandırmak için değil, aynı zamanda dizin başına +(htaccess) bağlamda sonraki yeniden yazma işlemlerinin de +gerçekleşmesini engellemek için kullanılabilir. Bu, harici +yönlendirmelerden kaynaklanan yeni istekler için geçerli değildir.

+ +

Burada verilen örnek, herhangi bir isteği index.php'ye +yeniden yazar ve orijinal isteği index.php'ye sorgu +dizgesi argümanı olarak verir; ancak RewriteCond, istek zaten +index.php için ise RewriteRule yönergesinin +atlanmasını sağlar.

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

+[N] bayrağı, kural kümesinin şimdiye kadarki sonucu başlangıç noktası +olarak kullanarak en baştan yeniden başlamasına neden olur. Döngüye +neden olabileceğinden son derece dikkatli kullanın. +

+

+[Next] bayrağı, örneğin bir istekteki belirli bir dizgeyi veya harfi +tekrar tekrar değiştirmek istediğinizde kullanılabilir. Burada +gösterilen örnek, bir istekteki her yerde A'yı B ile değiştirecek ve +değiştirilecek A kalmayana kadar bunu yapmaya devam edecektir. +

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

Bunu bir while döngüsü olarak düşünebilirsiniz: Bu +kalıp hâlâ eşleştiği sürece (yani URI hâlâ bir A +içerdiği sürece), bu değiştirmeyi yap (yani A'yı +B ile değiştir).

+ +

2.5.0 ve sonrasında, bu modül istenmeyen döngülere karşı koruma +sağlamak için 10.000 yinelemeden sonra hata döndürür. N bayrağına +eklenerek alternatif bir maksimum yineleme sayısı belirtilebilir.

+ +# Döngünün her geçişinde 1 karakter değiştirmeye razı ol +RewriteRule "(.+)[><;]$" "$1" [N=32000] +# ... veya 10 döngüden sonra vazgeç +RewriteRule "(.+)[><;]$" "$1" [N=10] + + +
+ +
NC|nocase +

[NC] bayrağının kullanımı, RewriteRule yönergesinin büyük/küçük +harf duyarsız biçimde eşleştirilmesine neden olur. Yani eşleşen +URI'de harflerin büyük veya küçük harf olarak görünüp görünmediği +önemli değildir.

+ +

Aşağıdaki örnekte, herhangi bir resim dosyası isteği özel resim +sunucunuza vekil olarak iletilir. Eşleşme büyük/küçük harf +duyarsızdır; bu nedenle örneğin hem .jpg hem de +.JPG dosyaları kabul edilir.

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

Öntanımlı olarak, bir RewriteRule harici yönlendirmeyle +sonuçlandığında, çıktıda aşağıdaki güvenli küme dışında kalan +karakterler onaltılık kod (yüzde kodlu) eşdeğerlerine +dönüştürülür:

+ +
    +
  • Alfasayısal karakterler: A-Z, a-z, + 0-9
  • +
  • Özel karakterler: $-_.+!*'(),:;@&=/~
  • +
+ +

Örneğin, # karakteri %23'e ve +? karakteri %3F'e dönüştürülür. +% karakteri de kodlanır (%25'e), bu da +değiştirmede zaten mevcut olan yüzde kodlamanın çift kodlanacağı +anlamına gelir.

+ +

[NE] bayrağı kullanmak bu kodlamayı engeller ve # ile +? gibi karakterlerin yönlendirme URL'sine +değiştirilmeden geçmesine olanak tanır.

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

+Yukarıdaki örnek /anchor/xyz adresini +/bigpage.html#xyz adresine yönlendirecektir. [NE] +kullanılmazsa # karakteri onaltılık kod eşdeğeri olan +%23'e dönüştürülür ve bu da 404 Bulunamadı hata durumuna +yol açar. +

+ +
+ +
NS|nosubreq +

[NS] bayrağının kullanımı, kuralın alt isteklerde kullanılmasını +engeller. Örneğin, SSI (Sunucu Tarafı Dahil Etme) kullanılarak dahil +edilen bir sayfa bir alt istektir ve bu alt isteklerde yeniden +yazmaların gerçekleşmesini engellemek isteyebilirsiniz. Ayrıca, +mod_dir olası dizin öntanımlı dosyaları (örneğin +index.html dosyaları) hakkında bilgi edinmeye +çalıştığında, bu bir dahili alt istektir ve genellikle bu tür alt +isteklerde yeniden yazmaları engellemek istersiniz. Alt isteklerde, +kuralların tamamının uygulanması her zaman yararlı olmaz ve hatalara +bile neden olabilir. Sorunlu kuralları dışlamak için bu bayrağı +kullanın.

+ +

Bu kuralı kullanıp kullanmamaya karar vermek için: URL'leri CGI +betikleriyle ön ekliyorsanız ve bunların CGI betiği tarafından +işlenmesini zorluyorsanız, alt isteklerde sorunlarla (veya önemli ek +yükle) karşılaşmanız olasıdır. Bu durumlarda bu bayrağı kullanın.

+ +

+Bir HTML sayfasının parçası olarak yüklenen resimler, javascript +dosyaları veya css dosyaları alt istek değildir - tarayıcı bunları +ayrı HTTP istekleri olarak ister. +

+
+ +
P|proxy +

[P] bayrağının kullanımı, isteğin mod_proxy +tarafından işlenmesine ve bir vekil isteği üzerinden ele alınmasına +neden olur. Örneğin, tüm resim isteklerinin bir arka uç resim +sunucusu tarafından işlenmesini istiyorsanız, şöyle bir şey +yapabilirsiniz:

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

[P] bayrağının kullanımı [L] anlamına gelir - yani istek hemen +vekil üzerinden iletilir ve sonraki kurallar dikkate alınmaz.

+ +

+Değiştirme dizgesinin mod_proxy tarafından +işlenebilecek geçerli bir URI olduğundan (genellikle +http://konakadı ile başlayan) emin olmalısınız. +Değilse, vekil modülünden bir hata alırsınız. Bu bayrağı, uzak +içeriği yerel sunucunun ad alanına eşlemek için ProxyPass yönergesinin daha güçlü +bir uygulamasını gerçekleştirmek için kullanın.

+ + +Güvenlik Uyarısı +

Kuralın hedef URL'sini oluştururken, istemcinin sunucunuzun vekil +olarak davranacağı URL kümesi üzerindeki etkisinin güvenlik +sonuçlarını dikkate alın. URL'nin şema ve konak adı bölümünün ya sabit +olduğundan ya da istemciye gereksiz etki izni vermediğinden emin +olun.

+
+ + +Performans uyarısı +

Bu bayrağı kullanmak, kalıcı bağlantıları yönetmeyen öntanımlı +işçi bu durumda kullanıldığından bağlantı havuzlama/yeniden kullanımı +olmaksızın mod_proxy kullanımını tetikler.

+

Kalıcı bağlantıları kullanmak için en azından hedef URL'nin şema +ve konak bölümü için örneğin bir zaman aşımı ayarladığınız +ProxySet yönergesi içeren +bir Proxy bloğu +kurmalısınız.

+

ProxyPass veya +ProxyPassMatch ile +kurarsanız kalıcı bağlantılar otomatik olarak kullanılacaktır.

+
+ +

Not: Bu bayrağı kullanmak için mod_proxy +etkinleştirilmiş olmalıdır.

+ +
+ +
PT|passthrough + +

+Bir RewriteRule'daki hedef (veya değiştirme dizgesi) öntanımlı olarak +bir dosya yolu olarak kabul edilir. [PT] bayrağının kullanılması, +bunun yerine bir URI olarak işlenmesine neden olur. Yani, [PT] +bayrağının kullanılması, RewriteRule sonucunun, Alias, Redirect veya ScriptAlias gibi konum tabanlı +eşlemelerin etki edebilmesi için URL eşlemesine geri iletilmesine +neden olur. +

+ +

+Örneğin, /icons için bir Alias tanımınız varsa ve oraya +işaret eden bir RewriteRule varsa, Alias yönergesinin +değerlendirilmesini sağlamak için [PT] bayrağını kullanmalısınız. +

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

+Bu durumda [PT] bayrağının atlanması, Alias'ın yok sayılmasına neden +olur ve 'Dosya bulunamadı' hatası döndürülür. +

+ +

PT bayrağı L bayrağını ima eder: +isteği bir sonraki işleme aşamasına geçirmek için yeniden yazma +durdurulur.

+ +

PT bayrağının Directory bölümleri veya +.htaccess dosyaları gibi dizin başına bağlamlarda +zımnen uygulandığını unutmayın. Bundan kaçınmanın tek yolu +-'ye yeniden yazmaktır.

+ +
+ +
QSA|qsappend +

+Değiştirme URI'si bir sorgu dizgesi içerdiğinde, RewriteRule yönergesinin öntanımlı +davranışı mevcut sorgu dizgesini atıp yeni oluşturulanla +değiştirmektir. [QSA] bayrağı kullanmak sorgu dizgelerinin +birleştirilmesine neden olur. +

+ +

Şu kuralı ele alalım:

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

[QSA] bayrağıyla, /pages/123?one=two isteği +/page.php?page=123&one=two ile eşlenir. [QSA] +bayrağı olmadan, aynı istek +/page.php?page=123 ile eşlenir - yani mevcut sorgu +dizgesi atılır. +

+
+ +
QSD|qsdiscard +

+İstenen URI bir sorgu dizgesi içerdiğinde ve hedef URI içermediğinde, +RewriteRule yönergesinin +öntanımlı davranışı o sorgu dizgesini hedef URI'ye kopyalamaktır. +[QSD] bayrağı kullanmak sorgu dizgesinin atılmasına neden olur. +

+ +

Bu bayrak 2.4.0 ve sonraki sürümlerde mevcuttur.

+ +

+[QSD] ve [QSA] birlikte kullanıldığında [QSD] öncelikli olur. +

+ +

+Hedef URI bir sorgu dizgesine sahipse, öntanımlı davranış +gözlemlenir - yani orijinal sorgu dizgesi atılır ve +RewriteRule hedef URI'sindeki sorgu dizgesiyle +değiştirilir. +

+ +
+ +
QSL|qslast +

+Öntanımlı olarak, değiştirmedeki ilk (en soldaki) soru işareti yolu +sorgu dizgesinden ayırır. [QSL] bayrağı kullanmak, RewriteRule yönergesine iki bileşeni +son (en sağdaki) soru işaretini kullanarak ayırmasını söyler.

+ +

+Bu, dosya adlarında birebir soru işaretleri bulunan dosyalara eşleme +yaparken yararlıdır. Değiştirmede sorgu dizgesi kullanılmıyorsa, bu +bayrakla birlikte sonuna bir soru işareti eklenebilir.

+ +

Bu bayrak 2.4.19 ve sonraki sürümlerde mevcuttur.

+ +
+ + +
R|redirect +

+[R] bayrağı kullanmak, tarayıcıya bir HTTP yönlendirmesi +verilmesine neden olur. Tam nitelikli bir URL belirtilmişse (yani +http://sunucuadı/ dahil), o konuma bir yönlendirme +verilir. Aksi takdirde, yönlendirmeyle gönderilen URL'yi oluşturmak +için geçerli protokol, sunucu adı ve bağlantı noktası numarası +kullanılır. +

+ +

+[R=305] sözdizimi kullanılarak geçerli herhangi bir HTTP yanıt durum +kodu belirtilebilir; hiçbiri belirtilmezse öntanımlı olarak 302 durum +kodu kullanılır. Belirtilen durum kodunun mutlaka bir yönlendirme +(3xx) durum kodu olması gerekmez. Ancak durum kodu yönlendirme +aralığının (300-399) dışındaysa değiştirme dizgesi tamamen atılır ve +L kullanılmış gibi yeniden yazma durdurulur.

+ +

Yanıt durum kodlarına ek olarak, yönlendirme durumunu sembolik +adlarıyla da belirtebilirsiniz: temp (öntanımlı), +permanent veya seeother.

+ +

+[R] bayrağını neredeyse her zaman [L] ile birlikte kullanmak +istersiniz (yani [R,L] kullanın); çünkü [R] bayrağı tek başına +URI'nin önüne http://bukonak[:buport] ekler ancak bunu +kural kümesindeki bir sonraki kurala geçirir ve bu da çoğu zaman +'İstekte Geçersiz URI' uyarılarına neden olabilir. +

+ +

Not: httpd yalnızca HTTP belirtiminde bulunan durum kodlarını +destekler. Tanınmayan bir durum kodu kullanmak 500 hatasına ve hata +günlüğü mesajına neden olacaktır.

+ +
+ +
S|skip +

[S] bayrağı, çalıştırmak istemediğiniz kuralları atlamak için +kullanılır. Atlama bayrağının sözdizimi [S=N]'dir; burada +N atlanacak kural sayısını belirtir (RewriteRule ve ondan önceki +RewriteCond yönergeleri +eşleştiği takdirde). Bu, yeniden yazma kural kümenizde bir +goto deyimi olarak düşünülebilir. Aşağıdaki örnekte, +RewriteRule yönergesini +yalnızca istenen URI gerçek bir dosyaya karşılık gelmiyorsa +çalıştırmak istiyoruz.

+ + +# İstek var olmayan bir dosya için mi? +RewriteCond "%{REQUEST_FILENAME}" !-f +RewriteCond "%{REQUEST_FILENAME}" !-d +# Öyleyse, bu iki RewriteRule'u atla +RewriteRule ".?" "-" [S=2] + +RewriteRule "(.*\.gif)" "images.php?$1" +RewriteRule "(.*\.html)" "docs.php?$1" + + +

Bu teknik yararlıdır; çünkü bir RewriteCond yalnızca hemen ardından +gelen RewriteRule için +geçerlidir. Bu nedenle, bir RewriteCond'un birkaç +RewriteRule için geçerli olmasını istiyorsanız, olası +bir teknik bu koşulları olumsuzlamak ve [Skip] bayrağıyla bir +RewriteRule eklemektir. Bunu, sözde if-then-else +yapıları oluşturmak için kullanabilirsiniz: then yan tümcesinin son +kuralı skip=N olur; burada N, else yan tümcesindeki +kural sayısıdır:

+ +# Dosya var mı? +RewriteCond "%{REQUEST_FILENAME}" !-f +RewriteCond "%{REQUEST_FILENAME}" !-d +# "else" kısmına gitmek istiyorsak 3 satır atlayarak bir if-then-else yapısı oluştur. +RewriteRule ".?" "-" [S=3] + +# EĞER dosya varsa: + RewriteRule "(.*\.gif)" "images.php?$1" + RewriteRule "(.*\.html)" "docs.php?$1" + # "else" kısmını atla. + RewriteRule ".?" "-" [S=1] +# DEĞİLSE... + RewriteRule "(.*)" "404.php?file=$1" +# SON + + +

Bu tür yapılandırmayı, bunun yerine If, ElseIf ve Else yönergelerini kullanarak +gerçekleştirmek muhtemelen daha kolaydır.

+ +
+ +
T|type +

Elde edilen yanıtın gönderileceği MIME türünü ayarlar. Bu, +AddType yönergesiyle aynı +etkiye sahiptir.

+ +

Örneğin, Perl kaynak kodunu belirli bir şekilde istendiğinde düz +metin olarak sunmak için aşağıdaki tekniği kullanabilirsiniz:

+ + +# .pl dosyalarını düz metin olarak sun +RewriteRule "\.pl$" "-" [T=text/plain] + + +

Veya dosya uzantısı olmayan jpeg resimleri üreten bir kameranız +varsa, bu resimlerin dosya adlarına bakarak doğru MIME türüyle +sunulmasını zorlayabilirsiniz:

+ + +# Adında 'IMG' bulunan dosyalar jpg resimlerdir. +RewriteRule "IMG" "-" [T=image/jpg] + + +

Bunun önemsiz bir örnek olduğunu ve bunun yerine FilesMatch kullanılarak +daha iyi yapılabileceğini lütfen unutmayın. Yeniden yazmaya +başvurmadan önce her zaman bir soruna alternatif çözümleri +düşünün; yeniden yazma her zaman alternatiflerden daha az verimli +bir çözüm olacaktır.

+ +

+Dizin başına bağlamda kullanılıyorsa, mod_rewrite +işlemesinin tüm turu boyunca değiştirme olarak yalnızca +- (tire) kullanın; aksi takdirde dahili yeniden +işleme (sonraki mod_rewrite işleme turları dahil) +nedeniyle bu bayrakla ayarlanan MIME türü kaybolur. +L bayrağı bu bağlamda mod_rewrite +işlemesinin geçerli turunu sonlandırmak için yararlı +olabilir.

+
+ +
UnsafeAllow3F +

Yazılmakta olan HTTP isteğinde kodlanmış bir soru işareti + '%3f' varsa ve yeniden yazılmış sonucun değiştirmesinde '?' varsa, + yeniden yazmanın devam etmesine izin vermek için bu bayrağın + ayarlanması gereklidir. Bu, kodlanmış soru işaretinin yakalanması + ve yeniden değiştirilmesinden yararlanan kötü niyetli bir URL'ye + karşı koruma sağlar.

+
+
UnsafePrefixStat +

Sunucu kapsamlı değiştirmeler bir değişken veya geri başvuru + ile başlayıp bir dosya sistemi yoluna çözümlendiğinde bu bayrağın + ayarlanması gereklidir. Bu değiştirmeler belge kökü ile + öneklenmez. Bu, genişletilmiş değiştirmenin beklenmeyen bir dosya + sistemi konumuna eşlenmesine neden olan kötü niyetli bir URL'ye + karşı koruma sağlar.

+ +

2.5.1

+
+
UNC +

Bu bayrağın ayarlanması, Windows UNC yollarında kullanıldığı + gibi birden fazla baştaki eğik çizginin birleştirilmesini engeller. + Kural değiştirmesi birden fazla birebir eğik çizgi ile + başladığında bayrak gerekli değildir.

+ +

2.5.1

+
+ +
diff --git a/docs/manual/rewrite/flags.xml.zh-cn b/docs/manual/rewrite/flags.xml.zh-cn new file mode 100644 index 0000000000..f8a0c81d3f --- /dev/null +++ b/docs/manual/rewrite/flags.xml.zh-cn @@ -0,0 +1,801 @@ + + + + + + + + +Rewrite + + RewriteRule 标志 + + +

本文档讨论了 RewriteRule +指令可用的标志,并提供了详细的说明和示例。

+
+ +模块文档 +mod_rewrite 简介 +重定向和重映射 +访问控制 +虚拟主机 +代理 +使用 RewriteMap +高级技术 +何时不使用 mod_rewrite + +
介绍 +

RewriteRule +的行为可以通过一个或多个标志来修改。标志包含在规则末尾的方括号中, +多个标志之间用逗号分隔。

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

每个标志(除少数例外)都有一个缩写形式,如 CO, +以及一个较长的形式,如 cookie。虽然最常用的是缩写形式, +但建议你熟悉长形式,以便记住每个标志的作用。 +某些标志接受一个或多个参数。标志不区分大小写。

+ +

修改与请求关联的元数据的标志(T=、H=、E=)在目录级和 htaccess +上下文中,当在同一轮重写处理中执行了替换(非 '-')时不会生效。 +

+ +

下面逐一介绍每个可用的标志,并给出使用示例。

+
+ +
B(转义反向引用) +

[B] 标志指示 RewriteRule +在应用转换之前转义非字母数字字符。

+ +

mod_rewrite 在映射 URL 之前必须对其进行反转义, +因此反向引用在应用时是未转义的。使用 B 标志,反向引用中的非字母数字字符将被转义。 +例如,考虑以下规则:

+ +

有关类似的服务器变量转义,请参阅 + "escape" 映射函数

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

给定搜索词 'x & y/z',浏览器会将其编码为 +'x%20%26%20y%2Fz',发出请求 'search/x%20%26%20y%2Fz'。不使用 B +标志时,此重写规则将映射为 'search.php?term=x & y/z', +这不是一个有效的 URL,因此会被编码为 +search.php?term=x%20&y%2Fz=,这不是预期的结果。

+ +

在同一规则上设置 B 标志后,参数会在传递到输出 URL 之前重新编码, +从而正确映射到 +/search.php?term=x%20%26%20y%2Fz。

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

请注意,你可能还需要将 AllowEncodedSlashes 设置为 On +才能使此特定示例正常工作,因为 httpd 不允许 URL 中包含编码的斜杠, +如果发现编码斜杠则返回 404。

+ +

在代理场景中,这种转义尤其必要, +因为后端如果收到未转义的 URL 可能会出错。

+ +

此标志的替代方案是使用 RewriteCond 对 %{THE_REQUEST} 进行捕获, +这将以编码形式捕获字符串。

+ +

在 2.4.26 及更高版本中,你可以通过列出字符来限制反向引用中要转义的特定字符: +[B=#?;]。注意:空格字符可以包含在要转义的字符列表中, +但你必须引用 RewriteRule +的整个第三个参数,并且空格不能是列表中的最后一个字符。

+ + +# 转义空格和问号。最后一个参数周围的引号 +# 在包含空格时是必需的。 +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B= ?]" + + +

要限制以这种方式转义的字符,请参阅 #flag_bne + 和 #flag_bctls

+
+ +
BNP|backrefnoplus(不将空格转义为 +) +

[BNP] 标志指示 RewriteRule 将反向引用中的空格字符 +转义为 %20 而不是 '+'。当反向引用将用于路径部分而不是查询字符串时很有用。

+ + +# 在路径中将空格转义为 %20,而不是表单提交中通过 +# 查询字符串使用的 + +RewriteRule "^search/(.*)$" "/search.php/$1" "[B,BNP]" + + + +

此标志在 2.4.26 及更高版本中可用。

+
+ +
BCTLS +

[BCTLS] 标志类似于 [B] 标志,但只转义控制字符和空格字符。 +这与未编码复制到查询字符串时被拒绝的字符集相同。 +

+ + +# 转义控制字符和空格 +RewriteRule "^search/(.*)$" "/search.php/$1" "[BCTLS]" + + +

此标志在 2.5.1 及更高版本中可用。

+ +
+ +
BNE +

[BNE=...] 中的字符列表被视为 [B] 或 [BCTLS] 标志的排除项。 +列出的字符将不会被转义。 +

+ + +# 转义默认字符,但保留 / +RewriteRule "^search/(.*)$" "/search.php?term=$1" "[B,BNE=/]" + + +

此标志在 2.5.1 及更高版本中可用。

+
+ +
C|chain +

[C] 或 [chain] 标志表示该 RewriteRule +与下一条规则链接在一起。也就是说,如果该规则匹配,则照常处理, +控制继续传递到下一条规则。但如果不匹配, +则跳过下一条规则以及所有链接在一起的其他规则。

+ +
+ +
CO|cookie +

[CO] 或 [cookie] 标志允许你在特定的 +RewriteRule +匹配时设置 cookie。参数由三个必需字段和五个可选字段组成。

+ +

该标志的完整语法(包括所有属性)如下:

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

如果任何 cookie 字段中需要使用字面量 ':' 字符, +可以使用替代语法。要选择替代语法,cookie 的 "Name" +前应加 ';' 字符,字段分隔符也应指定为 ';'。

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

你必须声明 cookie 的名称、值和域才能设置 cookie。

+ +
+
Domain
+
你希望 cookie 有效的域。这可以是主机名, +如 www.example.com,也可以是域名, +如 .example.com。它必须至少包含两个由点分隔的部分。 +也就是说,不能仅为 .com 或 .net。 +cookie 安全模型禁止这类 cookie。
+
+ +

你还可以选择设置以下值:

+ +
+
Lifetime
+
cookie 的持续时间,以分钟为单位。
+
值为 0 表示 cookie 仅在当前浏览器会话期间持续存在。 +如果未指定,这是默认值。
+
负值会导致浏览器中的 cookie 被取消设置。
+ +
Path
+
当前网站上 cookie 有效的路径, +如 /customers/ 或 /files/download/。
+
默认设置为 /——即整个网站。
+ +
Secure
+
如果设置为 secure、true 或 1, +则 cookie 只允许通过安全(https)连接传输。
+ +
httponly
+
如果设置为 HttpOnly、true 或 +1,cookie 将设置 HttpOnly 标记, +这意味着在支持此功能的浏览器上,JavaScript 代码无法访问该 cookie。
+ +
samesite
+
如果设置为 false 或 0 以外的任何值, +SameSite 属性将被设置为指定的值。 +典型值为 None、Lax 和 Strict。 +在 2.5.1 及更高版本中可用。
+
+ + +

请看以下示例:

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

在此示例中,规则不会重写请求。"-" 重写目标告诉 +mod_rewrite 不做修改地传递请求。 +相反,它设置了一个名为 'frontdoor'、值为 'yes' 的 cookie。 +该 cookie 对 .example.com 域中的所有主机有效。 +它被设置为在 1440 分钟(24 小时)后过期,并对所有 URI 返回。

+ +
+ +
DPI|discardpath +

DPI 标志使重写后 URI 的 PATH_INFO 部分被丢弃。

+

此标志在 2.2.12 及更高版本中可用。

+

在目录级上下文中,每个 RewriteRule +比较的 URI 是 URI 当前值和 PATH_INFO 的拼接。

+ +

当前 URI 可以是客户端最初请求的 URI、 +mod_rewrite 前一轮处理的结果, +或当前轮 mod_rewrite 处理中先前规则的结果。

+ +

相比之下,在每条规则之前附加到 URI 的 PATH_INFO +仅反映本轮 mod_rewrite 处理之前的 PATH_INFO 值。 +因此,如果 URI 的大部分内容在多个 RewriteRule +指令中被匹配并复制到替换中,而不考虑 URI 的哪些部分来自当前的 +PATH_INFO,则最终 URI 可能会附加多个 PATH_INFO 副本。

+ +

在任何替换中使用此标志,如果从此请求先前映射到文件系统所产生的 +PATH_INFO 不需要的话。此标志会永久忘记本轮 +mod_rewrite 处理开始之前建立的 PATH_INFO。 +在当前轮 mod_rewrite 处理完成之前,PATH_INFO +不会被重新计算。此轮处理中的后续规则将只看到替换的直接结果, +而不会附加任何 PATH_INFO。

+
+ +
E|env +

使用 [E] 或 [env] 标志,你可以设置环境变量的值。 +请注意,某些环境变量可能在规则运行后被设置, +从而取消你所设置的值。有关环境变量工作方式的更多详细信息, +请参阅环境变量文档。

+ +

此标志的完整语法为:

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

VAL 可以包含会被展开的反向引用($N 或 +%N)。

+ +

使用缩写形式

+ + +[E=VAR] + + +

你可以将名为 VAR 的环境变量设置为空值。

+ +

使用以下形式

+ + +[E=!VAR] + + +

可以取消设置先前设置的名为 VAR 的环境变量。

+ +

环境变量随后可以在多种上下文中使用, +包括 CGI 程序、其他 RewriteRule 指令或 CustomLog 指令。

+ +

以下示例在请求的 URI 是图像文件时将名为 'image' 的环境变量设置为 '1'。 +然后,该环境变量用于将这些请求从访问日志中排除。

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

请注意,使用 SetEnvIf +也可以达到相同的效果。此处提供此技术作为示例,而非建议。

+
+ +
END +

使用 [END] 标志不仅会终止当前轮的重写处理(如 [L]), +还会阻止在目录级(htaccess)上下文中发生任何后续的重写处理。

+ +

这不适用于由外部重定向产生的新请求。

+
+ +
F|forbidden +

使用 [F] 标志会导致服务器向客户端返回 403 Forbidden 状态码。 +虽然使用 Deny +指令也可以实现相同的行为,但这种方式在分配 Forbidden 状态时更加灵活。

+ +

以下规则将禁止从你的服务器下载 .exe 文件。

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

此示例使用 "-" 语法作为重写目标,这意味着请求的 URI 不会被修改。 +如果你打算禁止请求,就没有理由将其重写到另一个 URI。

+ +

使用 [F] 时,会隐含 [L]——也就是说,响应会立即返回, +不会再评估后续规则。

+ +
+ +
G|gone +

[G] 标志强制服务器在响应中返回 410 Gone 状态。 +这表示资源曾经可用,但现在已不再可用。

+ +

与 [F] 标志一样,使用 [G] 标志时通常使用 "-" 语法作为重写目标:

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

使用 [G] 时,会隐含 [L]——也就是说,响应会立即返回, +不会再评估后续规则。

+ +
+ +
H|handler +

强制使用指定的处理器来处理结果请求。例如, +可以使用此标志强制所有没有文件扩展名的文件由 php 处理器解析:

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

+上面的正则表达式——!\.——将匹配任何不包含字面量 +. 字符的请求。 +

+ +

这也可以用于根据某些条件强制使用处理器。例如, +以下代码片段在服务器级上下文中使用时, +允许以 .phps 扩展名请求的 .php +文件由 mod_php 显示其源代码:

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

上面的正则表达式——^(/source/.+\.php)s$——将匹配任何以 +/source/ 开头,后跟 1 个或多个字符, +再后跟 .phps 的请求。反向引用 +$1 引用正则表达式括号内捕获的匹配内容。

+
+ +
L|last +

[L] 标志使 mod_rewrite +停止处理规则集。在大多数上下文中,这意味着如果规则匹配, +将不再处理后续规则。这对应于 Perl 中的 last +命令或 C 中的 break 命令。使用此标志表示当前规则应立即应用, +而不考虑后续规则。

+ +

如果你在 .htaccess 文件或 +Directory +配置段中使用 RewriteRule, +理解规则的处理方式非常重要。简化来说,一旦规则处理完毕, +重写后的请求会被交回 URL 解析引擎进行后续处理。在处理重写后的请求时, +可能会再次遇到 .htaccess 文件或 +Directory 配置段, +从而规则集可能会从头开始重新运行。最常见的情况是某条规则导致了重定向—— +无论是内部还是外部重定向——使请求处理重新开始。

+ +

因此,如果你在这些上下文中使用 +RewriteRule +指令,采取明确措施避免规则循环非常重要, +不要仅依赖 [L] 标志来终止一系列规则的执行,如下所示。

+ +

替代标志 [END] 可用于终止当前轮的重写处理, +并阻止在目录级(htaccess)上下文中发生任何后续的重写处理。 +这不适用于由外部重定向产生的新请求。

+ +

此处给出的示例将把所有请求重写到 index.php, +将原始请求作为查询字符串参数传递给 index.php, +但 RewriteCond +确保如果请求已经是 index.php, +则 RewriteRule 将被跳过。

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

+[N] 标志使规则集从头开始重新运行,使用到目前为止的规则集结果作为起点。 +请极其谨慎地使用,因为它可能导致循环。 +

+

+例如,如果你想在请求中重复替换某个字符串或字母,可以使用 [Next] 标志。 +下面的示例将请求中所有的 A 替换为 B,并持续执行直到没有更多的 A 需要替换。 +

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

你可以将此看作 while 循环:当此模式仍然匹配时 +(即 URI 仍然包含 A),执行此替换 +(即将 A 替换为 B)。

+ +

在 2.5.0 及更高版本中,此模块在 10,000 次迭代后返回错误, +以防止意外循环。可以通过向 N 标志添加参数来指定替代的最大迭代次数。

+ +# 每次循环替换 1 个字符 +RewriteRule "(.+)[><;]$" "$1" [N=32000] +# ……或者,10 次循环后放弃 +RewriteRule "(.+)[><;]$" "$1" [N=10] + + +
+ +
NC|nocase +

使用 [NC] 标志使 RewriteRule +以不区分大小写的方式进行匹配。也就是说, +匹配的 URI 中字母是大写还是小写都无所谓。

+ +

在下面的示例中,任何图像文件请求将被代理到你的专用图像服务器。 +匹配不区分大小写,因此 .jpg 和 .JPG +文件都可以接受。

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

默认情况下,当 RewriteRule +导致外部重定向时,输出中不在以下安全集中的字符将被转换为其十六进制编码 +(百分比编码)等价物:

+ +
    +
  • 字母数字字符:A-Z、a-z、 + 0-9
  • +
  • 特殊字符:$-_.+!*'(),:;@&=/~
  • +
+ +

例如,# 将被转换为 %23, +? 转换为 %3F。% +字符也会被转义(为 %25),这意味着替换中已有的百分比编码 +将被双重编码。

+ +

使用 [NE] 标志可防止此转义,允许 +# 和 ? 等字符不经修改地传递到重定向 URL。

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

+上面的示例将 /anchor/xyz 重定向到 +/bigpage.html#xyz。省略 [NE] 将导致 # +被转换为其十六进制等价物 %23, +从而导致 404 Not Found 错误。 +

+ +
+ +
NS|nosubreq +

使用 [NS] 标志可防止规则被用于子请求。例如, +使用 SSI(服务器端包含)包含的页面是子请求, +你可能希望避免在这些子请求上发生重写。此外, +当 mod_dir +尝试查找可能的目录默认文件(如 index.html 文件)的信息时, +这是一个内部子请求,你通常希望避免在此类子请求上进行重写。 +在子请求上,应用完整的规则集并不总是有用的,甚至可能导致错误。 +使用此标志排除有问题的规则。

+ +

要决定是否使用此规则:如果你使用 CGI 脚本为 URL 添加前缀, +强制它们由 CGI 脚本处理,那么在子请求上你很可能会遇到问题 +(或显著的性能开销)。在这些情况下,请使用此标志。

+ +

+作为 HTML 页面一部分加载的图像、JavaScript 文件或 CSS 文件不是子请求—— +浏览器将它们作为单独的 HTTP 请求发出。 +

+
+ +
P|proxy +

使用 [P] 标志使请求由 mod_proxy +处理,并通过代理请求进行处理。例如, +如果你想让所有图像请求由后端图像服务器处理,可以这样做:

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

使用 [P] 标志隐含 [L]——也就是说,请求会立即通过代理推送, +后续规则将不被考虑。

+ +

+你必须确保替换字符串是有效的 URI +(通常以 http://hostname 开头), +可以由 mod_proxy 处理。如果不是,你将从代理模块收到错误。 +使用此标志可以实现比 ProxyPass +指令更强大的远程内容到本地服务器命名空间的映射。

+ + +安全警告 +

构造规则的目标 URL 时要小心,考虑允许客户端影响你的服务器将作为代理的 +URL 集的安全影响。确保 URL 的方案和主机名部分是固定的, +或者不允许客户端过度影响。

+
+ + +性能警告 +

使用此标志会触发 mod_proxy 的使用, +在这种情况下使用默认 worker,不处理持久连接, +因为默认 worker 不处理连接池/重用。

+

要使用持久连接,你需要至少为目标 URL 的方案和主机部分设置一个 +Proxy 块, +其中包含一个 ProxySet +指令,例如设置超时时间。

+

如果使用 ProxyPass 或 +ProxyPassMatch +进行设置,将自动使用持久连接。

+
+ +

注意:必须启用 mod_proxy 才能使用此标志。

+ +
+ +
PT|passthrough + +

+RewriteRule 中的目标(或替换字符串)默认被假定为文件路径。 +使用 [PT] 标志使其被视为 URI。也就是说, +使用 [PT] 标志会使 RewriteRule 的结果 +被传回到 URL 映射中,从而基于位置的映射,如 +Alias、 +Redirect 或 +ScriptAlias +等,有机会生效。 +

+ +

+例如,如果你有一个 Alias +指向 /icons,并且有一个 RewriteRule 指向那里, +你应该使用 [PT] 标志以确保 +Alias 被正确评估。 +

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

+在这种情况下省略 [PT] 标志会导致 Alias 被忽略, +从而返回"文件未找到"错误。 +

+ +

PT 标志隐含 L 标志: +重写将停止以便将请求传递给下一个处理阶段。

+ +

请注意,PT 标志在目录级上下文中是隐含的, +例如 Directory +配置段或 .htaccess 文件中。规避此行为的唯一方法是重写为 +-。

+ +
+ +
QSA|qsappend +

+当替换 URI 包含查询字符串时, +RewriteRule +的默认行为是丢弃现有的查询字符串,并用新生成的替换。 +使用 [QSA] 标志可以将查询字符串合并。 +

+ +

请看以下规则:

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

使用 [QSA] 标志,对 /pages/123?one=two 的请求将被映射到 +/page.php?page=123&one=two。不使用 [QSA] +标志时,同一请求将被映射到 +/page.php?page=123——也就是说,现有的查询字符串将被丢弃。 +

+
+ +
QSD|qsdiscard +

+当请求的 URI 包含查询字符串而目标 URI 不包含时, +RewriteRule +的默认行为是将该查询字符串复制到目标 URI。 +使用 [QSD] 标志可以丢弃查询字符串。 +

+ +

此标志在 2.4.0 及更高版本中可用。

+ +

+同时使用 [QSD] 和 [QSA] 将导致 [QSD] 优先。 +

+ +

+如果目标 URI 有查询字符串,将执行默认行为—— +也就是说,原始查询字符串将被丢弃并替换为 RewriteRule +目标 URI 中的查询字符串。 +

+ +
+ +
QSL|qslast +

+默认情况下,替换中第一个(最左边的)问号将路径与查询字符串分开。 +使用 [QSL] 标志指示 +RewriteRule +改为使用最后一个(最右边的)问号来分隔两个组件。

+ +

+当映射到文件名中包含字面量问号的文件时,这很有用。 +如果替换中未使用查询字符串,可以结合此标志在替换后附加一个问号。

+ +

此标志在 2.4.19 及更高版本中可用。

+ +
+ + +
R|redirect +

+使用 [R] 标志会导致向浏览器发出 HTTP 重定向。 +如果指定了完全限定的 URL(即包含 http://servername/), +则将重定向到该位置。否则,将使用当前协议、服务器名称和端口号 +来生成与重定向一起发送的 URL。 +

+ +

+可以使用 [R=305] 语法指定任何有效的 HTTP 响应状态码, +如果未指定则默认使用 302 状态码。指定的状态码不一定必须是重定向(3xx)状态码。 +但是,如果状态码超出重定向范围(300-399),替换字符串将被完全丢弃, +重写将像使用了 L 一样停止。

+ +

除了响应状态码外,你还可以使用它们的符号名称指定重定向状态: +temp(默认)、permanent 或 seeother。

+ +

+你几乎总是希望将 [R] 与 [L] 结合使用(即使用 [R,L]), +因为 [R] 标志本身只是在 URI 前面添加 +http://thishost[:thisport],然后将其传递给规则集中的下一条规则, +这通常会导致"请求中的 URI 无效"警告。 +

+ +

注意:httpd 仅支持 HTTP 规范中包含的状态码。 +使用无法识别的状态码将导致 500 错误和错误日志消息。

+ +
+ +
S|skip +

[S] 标志用于跳过你不想运行的规则。 +跳过标志的语法为 [S=N],其中 N +表示要跳过的规则数(前提是 +RewriteRule 及其前面的 +RewriteCond +指令匹配)。这可以看作是重写规则集中的 goto 语句。 +在以下示例中,我们只想在请求的 URI +不对应实际文件时才运行 RewriteRule。

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

此技术很有用,因为 RewriteCond 只应用于紧随其后的 +RewriteRule。 +因此,如果你想让一个 RewriteCond 应用于多个 +RewriteRule,一种可能的技术是否定这些条件并添加一个带有 +[Skip] 标志的 RewriteRule。你可以用此构造伪 +if-then-else 结构:then 子句的最后一条规则变为 +skip=N,其中 N 是 else 子句中的规则数:

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

使用 If、ElseIf 和 Else 指令可能更容易实现这种配置。

+ +
+ +
T|type +

设置响应将以何种 MIME 类型发送。这与 AddType 指令的效果相同。

+ +

例如,你可以使用以下技术在以特定方式请求时将 Perl 源代码作为纯文本提供:

+ + +# 将 .pl 文件作为纯文本提供 +RewriteRule "\.pl$" "-" [T=text/plain] + + +

或者,如果你有一台相机生成没有文件扩展名的 jpeg 图像, +你可以根据文件名强制使用正确的 MIME 类型来提供这些图像:

+ + +# 文件名中包含 'IMG' 的是 jpg 图像。 +RewriteRule "IMG" "-" [T=image/jpg] + + +

请注意,这是一个简单的示例,使用 +FilesMatch +可以更好地完成。在使用重写之前,始终考虑问题的替代解决方案, +因为重写总是比替代方案效率更低。

+ +

+如果在目录级上下文中使用,在整轮 mod_rewrite +处理过程中仅使用 -(破折号)作为替换, +否则使用此标志设置的 MIME 类型将由于内部重新处理 +(包括后续轮次的 mod_rewrite 处理)而丢失。 +L 标志在此上下文中可用于结束当前轮的 +mod_rewrite 处理。

+
+ +
UnsafeAllow3F +

如果被重写的 HTTP 请求包含编码的问号 '%3f', + 且重写结果的替换中包含 '?',则需要设置此标志才能允许重写继续。 + 这可以防止恶意 URL 利用捕获和重新替换编码的问号。

+
+
UnsafePrefixStat +

当服务器范围内的替换以变量或反向引用开头并解析为文件系统路径时, + 需要设置此标志。这些替换不会以文档根目录为前缀。 + 这可以防止恶意 URL 导致展开的替换映射到意外的文件系统位置。

+ +

2.5.1

+
+
UNC +

设置此标志可防止合并多个前导斜杠, + 如 Windows UNC 路径中使用的那样。当规则替换以多个字面量斜杠开头时, + 不需要此标志。

+ +

2.5.1

+
+ +
diff --git a/docs/manual/rewrite/htaccess.xml.de b/docs/manual/rewrite/htaccess.xml.de new file mode 100644 index 0000000000..dfec6d9e24 --- /dev/null +++ b/docs/manual/rewrite/htaccess.xml.de @@ -0,0 +1,46 @@ + + + + + + + + + Rewrite + +mod_rewrite und .htaccess-Dateien + + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es beschreibt, +wie sich die Regeln ändern, wenn Sie mod_rewrite in +.htaccess-Dateien verwenden, und wie Sie mit diesen Änderungen umgehen.

+ +
+Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung + +Virtuelle Hosts +Proxying +Verwendung von RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
\ No newline at end of file diff --git a/docs/manual/rewrite/htaccess.xml.es b/docs/manual/rewrite/htaccess.xml.es new file mode 100644 index 0000000000..59d25228ee --- /dev/null +++ b/docs/manual/rewrite/htaccess.xml.es @@ -0,0 +1,46 @@ + + + + + + + + + Rewrite + +mod_rewrite y archivos .htaccess + + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +la forma en que las reglas cambian cuando usa mod_rewrite en archivos .htaccess, +y cómo lidiar con estos cambios.

+ +
+Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo + +Hosts virtuales +Proxy +Uso de RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
diff --git a/docs/manual/rewrite/htaccess.xml.ja b/docs/manual/rewrite/htaccess.xml.ja new file mode 100644 index 0000000000..446389f932 --- /dev/null +++ b/docs/manual/rewrite/htaccess.xml.ja @@ -0,0 +1,46 @@ + + + + + + + + + Rewrite + +mod_rewrite と .htaccess ファイル + + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +.htaccess ファイルで mod_rewrite を使用する際のルールの変更点と、 +それらの変更への対処方法について説明します。

+ +
+モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング + +バーチャルホスト +プロキシ +RewriteMap の使用 +高度なテクニック +mod_rewrite を使わない場合 + +
diff --git a/docs/manual/rewrite/htaccess.xml.ko b/docs/manual/rewrite/htaccess.xml.ko new file mode 100644 index 0000000000..0c9841774b --- /dev/null +++ b/docs/manual/rewrite/htaccess.xml.ko @@ -0,0 +1,47 @@ + + + + + + + + + Rewrite + +mod_rewrite와 .htaccess 파일 + + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +.htaccess 파일에서 mod_rewrite를 사용할 때 +규칙이 변경되는 방식과 이러한 변경 사항을 처리하는 방법을 +설명합니다.

+ +
+모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 + +가상 호스트 +프록시 +RewriteMap 사용하기 +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
diff --git a/docs/manual/rewrite/htaccess.xml.meta b/docs/manual/rewrite/htaccess.xml.meta index 00ee9a1c1e..04d01a3853 100644 --- a/docs/manual/rewrite/htaccess.xml.meta +++ b/docs/manual/rewrite/htaccess.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/htaccess.xml.tr b/docs/manual/rewrite/htaccess.xml.tr new file mode 100644 index 0000000000..245b20d5d5 --- /dev/null +++ b/docs/manual/rewrite/htaccess.xml.tr @@ -0,0 +1,47 @@ + + + + + + + + + Rewrite + +mod_rewrite ve .htaccess dosyaları + + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +mod_rewrite modülünü .htaccess dosyalarında +kullandığınızda kuralların nasıl değiştiğini ve bu değişikliklerle +nasıl başa çıkacağınızı açıklar.

+ +
+Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme + +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
diff --git a/docs/manual/rewrite/htaccess.xml.zh-cn b/docs/manual/rewrite/htaccess.xml.zh-cn new file mode 100644 index 0000000000..0031a20f96 --- /dev/null +++ b/docs/manual/rewrite/htaccess.xml.zh-cn @@ -0,0 +1,46 @@ + + + + + + + + + Rewrite + +mod_rewrite 和 .htaccess 文件 + + + +

本文档是 mod_rewrite +参考文档的补充。它描述了在 +.htaccess 文件中使用 mod_rewrite 时规则的变化方式, +以及如何处理这些变化。

+ +
+模块文档 +mod_rewrite 简介 +重定向和重映射 + +虚拟主机 +代理 +使用 RewriteMap +高级技术 +何时不使用 mod_rewrite + +
diff --git a/docs/manual/rewrite/index.xml.de b/docs/manual/rewrite/index.xml.de new file mode 100644 index 0000000000..cfcb8541d0 --- /dev/null +++ b/docs/manual/rewrite/index.xml.de @@ -0,0 +1,86 @@ + + + + + + + + + + + Apache mod_rewrite + + + +

mod_rewrite bietet eine Möglichkeit, eingehende + URL-Anfragen dynamisch zu modifizieren, basierend auf Regeln mit + regulären Ausdrücken. Dies ermöglicht + es Ihnen, beliebige URLs auf Ihre interne URL-Struktur in jeder + gewünschten Weise abzubilden.

+ +

Es unterstützt eine unbegrenzte Anzahl von Regeln und eine + unbegrenzte Anzahl angehängter Regelbedingungen für jede Regel, + um einen wirklich flexiblen und leistungsfähigen Mechanismus zur + URL-Manipulation bereitzustellen. Die URL-Manipulationen können + von verschiedenen Tests abhängen: Servervariablen, Umgebungsvariablen, + HTTP-Header, Zeitstempel, externe Datenbankabfragen und verschiedene + andere externe Programme oder Handler können verwendet werden, um + eine granulare URL-Zuordnung zu erreichen.

+ +

Umschreibungsregeln können auf vollständige URLs angewendet werden, + einschließlich des Pfadinfo- und Query-String-Teils, und können im + Server-Kontext (httpd.conf), im VirtualHost-Kontext + (VirtualHost-Blöcke) + oder im Verzeichniskontext (.htaccess-Dateien und + Directory-Blöcke) + verwendet werden. Das umgeschriebene Ergebnis kann zu weiteren Regeln, + interner Unterverarbeitung, externer Anfrage-Umleitung oder + Proxy-Weiterleitung führen, abhängig davon, welche + Flags Sie an die Regeln anhängen.

+ +

Da mod_rewrite so leistungsfähig ist, kann es + tatsächlich recht komplex sein. Dieses Dokument ergänzt die + Referenzdokumentation und + versucht, einen Teil dieser Komplexität zu mildern und hochgradig + kommentierte Beispiele für gängige Szenarien bereitzustellen, die Sie + mit mod_rewrite bewältigen können. Wir versuchen aber + auch zu zeigen, wann Sie mod_rewrite nicht verwenden + sollten, und stattdessen andere Standard-Apache-Funktionen nutzen + sollten, um diese unnötige Komplexität zu vermeiden.

+ + +
+ +mod_rewrite-Referenzdokumentation +URLs dem Dateisystem zuordnen +mod_rewrite-Wiki +Glossar + +
\ No newline at end of file diff --git a/docs/manual/rewrite/index.xml.es b/docs/manual/rewrite/index.xml.es new file mode 100644 index 0000000000..54eea16e3c --- /dev/null +++ b/docs/manual/rewrite/index.xml.es @@ -0,0 +1,89 @@ + + + + + + + + + + + Apache mod_rewrite + + + +

mod_rewrite proporciona una forma de modificar las + solicitudes de URL entrantes, dinámicamente, basándose en reglas de expresiones + regulares. Esto le permite mapear URLs arbitrarias a + su estructura interna de URLs de la forma que desee.

+ +

Soporta un número ilimitado de reglas y un + número ilimitado de condiciones de regla adjuntas para cada regla, para + proporcionar un mecanismo de manipulación de URLs realmente flexible y potente. + Las manipulaciones de URL pueden depender de varias pruebas: + variables del servidor, variables de entorno, cabeceras HTTP, + marcas de tiempo, consultas a bases de datos externas, y varios otros + programas externos o manejadores, pueden usarse para lograr una coincidencia + de URL granular.

+ +

Las reglas de reescritura pueden operar sobre las URLs completas, incluyendo las partes + de path-info y cadena de consulta, y pueden usarse en contexto per-servidor + (httpd.conf), contexto per-virtualhost (bloques VirtualHost), o + contexto per-directorio (archivos .htaccess y bloques Directory). El + resultado reescrito puede llevar a más reglas, sub-procesamiento + interno, redirección de solicitud externa, o paso a través de + proxy, dependiendo de qué banderas + adjunte a las reglas.

+ +

Dado que mod_rewrite es tan potente, puede ser bastante + complejo. Este documento complementa la documentación de referencia, e + intenta aliviar algo de esa complejidad, y proporcionar ejemplos altamente + anotados de escenarios comunes que puede manejar con + mod_rewrite. Pero también intentamos mostrarle cuándo no debería + usar mod_rewrite, y usar otras características estándar de Apache en su lugar, + evitando así esta complejidad innecesaria.

+ + + +
+ +Documentación de referencia de +mod_rewrite +Mapeo de URLs al sistema de archivos +Wiki de +mod_rewrite +Glosario + + +
diff --git a/docs/manual/rewrite/index.xml.fr b/docs/manual/rewrite/index.xml.fr index 081ea84775..6169ca070a 100644 --- a/docs/manual/rewrite/index.xml.fr +++ b/docs/manual/rewrite/index.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -29,78 +29,76 @@ -

mod_rewrite permet de modifier les requêtes - entrantes dynamiquement, en fonction de règles manipulant des 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 + 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.

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

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

+ règles

-

mod_rewrite étant très puissant, il peut par - conséquent être très complexe. Ce document - complète la 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 + 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.

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

Documentation de -référence de mod_rewrite +référence de mod_rewrite Mise en correspondance des URLs -avec le système de fichiers +avec le système de fichiers wiki mod_rewrite Glossaire - diff --git a/docs/manual/rewrite/index.xml.ja b/docs/manual/rewrite/index.xml.ja new file mode 100644 index 0000000000..417b87bab8 --- /dev/null +++ b/docs/manual/rewrite/index.xml.ja @@ -0,0 +1,84 @@ + + + + + + + + + + + Apache mod_rewrite + + + +

mod_rewrite は、正規表現 + ルールに基づいて受信 URL リクエストを動的に変更する方法を提供します。 + これにより、任意の URL を内部 URL 構造に自由にマッピングできます。

+ +

各ルールに対して無制限の数のルールと無制限の数の + 付随するルール条件をサポートしており、非常に柔軟で強力な URL 操作 + メカニズムを提供します。URL 操作はさまざまなテストに依存できます: + サーバ変数、環境変数、HTTP ヘッダ、タイムスタンプ、外部データベース + 検索、およびさまざまな他の外部プログラムやハンドラを使用して、 + きめ細かい URL マッチングを実現できます。

+ +

書き換えルールは、完全な URL (パス情報とクエリ文字列部分を含む) + に対して動作でき、サーバ単位のコンテキスト + (httpd.conf)、バーチャルホスト単位のコンテキスト + (VirtualHost ブロック)、 + またはディレクトリ単位のコンテキスト (.htaccess ファイルと + Directory ブロック) + で使用できます。書き換えの結果は、ルールに付加する + フラグに応じて、さらなるルール処理、 + 内部サブ処理、外部リクエストリダイレクト、またはプロキシ + パススルーにつながります。

+ +

mod_rewrite は非常に強力であるため、かなり + 複雑になり得ます。このドキュメントは + リファレンスドキュメントを + 補足し、その複雑さを軽減し、mod_rewrite で扱う可能性のある + 一般的なシナリオの詳細な注釈付きの例を提供することを試みます。 + しかし同時に、mod_rewrite を使用すべきでない場合や、 + 代わりに他の標準的な Apache 機能を使用して不要な複雑さを避けるべき場合も + 示そうとしています。

+ + + +
+ +mod_rewrite リファレンスドキュメント +URL からファイルシステムへのマッピング +mod_rewrite +wiki +用語集 + + +
diff --git a/docs/manual/rewrite/index.xml.ko b/docs/manual/rewrite/index.xml.ko new file mode 100644 index 0000000000..853184eba8 --- /dev/null +++ b/docs/manual/rewrite/index.xml.ko @@ -0,0 +1,91 @@ + + + + + + + + + + + Apache mod_rewrite + + + +

mod_rewrite는 정규 + 표현식 규칙에 기반하여 들어오는 URL 요청을 동적으로 + 수정하는 방법을 제공합니다. 이를 통해 임의의 URL을 + 내부 URL 구조에 원하는 방식으로 매핑할 수 있습니다.

+ +

이것은 무제한의 규칙과 각 규칙에 대한 무제한의 + 첨부된 규칙 조건을 지원하여 정말로 유연하고 강력한 + URL 조작 메커니즘을 제공합니다. URL 조작은 다양한 + 테스트에 의존할 수 있습니다: 서버 변수, 환경 변수, + HTTP 헤더, 타임스탬프, 외부 데이터베이스 조회 및 + 다양한 기타 외부 프로그램이나 핸들러를 사용하여 + 세밀한 URL 매칭을 달성할 수 있습니다.

+ +

재작성 규칙은 경로 정보 및 쿼리 문자열 부분을 + 포함한 전체 URL에 대해 작동할 수 있으며, 서버별 + 컨텍스트(httpd.conf), 가상호스트별 + 컨텍스트(VirtualHost 블록) 또는 + 디렉토리별 컨텍스트(.htaccess 파일 및 + Directory 블록)에서 + 사용할 수 있습니다. 재작성된 결과는 규칙에 첨부하는 + 플래그에 따라 추가 규칙, + 내부 하위 처리, 외부 요청 리다이렉션 또는 프록시 + 패스스루로 이어질 수 있습니다.

+ +

mod_rewrite는 매우 강력하므로 + 상당히 복잡할 수 있습니다. 이 문서는 + 참조 문서를 + 보충하며, 이러한 복잡성을 완화하고 + mod_rewrite로 처리할 수 있는 일반적인 + 시나리오의 주석이 풍부한 예제를 제공하고자 합니다. + 하지만 mod_rewrite를 사용하지 말아야 할 + 때도 보여주며, 대신 다른 표준 Apache 기능을 사용하여 + 이러한 불필요한 복잡성을 피하도록 합니다.

+ + + +
+ +mod_rewrite 참조 +문서 +파일 시스템에 URL 매핑 +mod_rewrite +위키 +용어집 + + +
diff --git a/docs/manual/rewrite/index.xml.meta b/docs/manual/rewrite/index.xml.meta index 96567025f0..d372797c71 100644 --- a/docs/manual/rewrite/index.xml.meta +++ b/docs/manual/rewrite/index.xml.meta @@ -7,8 +7,13 @@ .. + de en + es fr + ja + ko + tr tr zh-cn diff --git a/docs/manual/rewrite/index.xml.tr b/docs/manual/rewrite/index.xml.tr index 3d6a47b305..4fbe73fad2 100644 --- a/docs/manual/rewrite/index.xml.tr +++ b/docs/manual/rewrite/index.xml.tr @@ -1,11 +1,7 @@ - - + + + + + + +Rewrite + + Einführung in Apache mod_rewrite + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es +beschreibt die grundlegenden Konzepte, die für die Verwendung von +mod_rewrite notwendig sind. Andere Dokumente gehen +mehr ins Detail, aber dieses Dokument soll dem Anfänger den Einstieg +erleichtern. +

+
+ +Moduldokumentation + +Umleitung und Neuzuordnung +Zugriffskontrolle +Virtuelle Hosts +Proxying +Verwendung von RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
Einführung +

Das Apache-Modul mod_rewrite ist ein sehr +leistungsfähiges und ausgereiftes Modul, das eine Möglichkeit bietet, +URL-Manipulationen durchzuführen. Damit können Sie nahezu alle Arten von +URL-Umschreibungen durchführen, die Sie möglicherweise benötigen. Es ist +jedoch etwas komplex und kann für Anfänger einschüchternd sein. Es besteht +auch die Tendenz, Umschreibungsregeln als magische Formeln zu behandeln +und sie zu verwenden, ohne wirklich zu verstehen, was sie tun.

+ +

Dieses Dokument versucht, ausreichend Hintergrundwissen zu vermitteln, +damit das Folgende verstanden und nicht nur blind kopiert wird. +

+ +

Denken Sie daran, dass viele gängige URL-Manipulationsaufgaben nicht +die volle Leistungsfähigkeit und Komplexität von mod_rewrite +erfordern. Für einfache Aufgaben siehe mod_alias und die +Dokumentation zur Zuordnung von URLs zum +Dateisystem.

+ +

Stellen Sie schließlich vor dem Fortfahren sicher, dass Sie die +Protokollebene von mod_rewrite mit der +LogLevel-Direktive auf eine der +Trace-Ebenen konfigurieren. Obwohl dies eine überwältigende Menge an +Informationen liefern kann, ist es unverzichtbar bei der Fehlersuche in +der mod_rewrite-Konfiguration, da es Ihnen genau zeigt, +wie jede Regel verarbeitet wird.

+ +
+ +
Reguläre Ausdrücke + +

mod_rewrite verwendet das Vokabular der Perl-kompatiblen regulären Ausdrücke. In +diesem Dokument versuchen wir nicht, eine detaillierte Referenz zu +regulären Ausdrücken zu liefern. Dafür empfehlen wir die PCRE-Manpages, die Perl-Manpage für reguläre +Ausdrücke und Mastering +Regular Expressions von Jeffrey Friedl (die dritte Auflage stammt +von 2006, aber die Syntax regulärer Ausdrücke ist im Wesentlichen +unverändert, und es bleibt die maßgebliche Referenz zu diesem Thema).

+ +

In diesem Dokument versuchen wir, genügend Regex-Vokabular zu +vermitteln, um Ihnen den Einstieg zu erleichtern, ohne Sie zu +überfordern, in der Hoffnung, dass RewriteRules wissenschaftliche Formeln sind und keine +magischen Beschwörungen.

+ +
Regex-Vokabular + +

Die folgenden sind die minimalen Bausteine, die Sie benötigen, um +reguläre Ausdrücke und RewriteRules +zu schreiben. Sie stellen sicherlich kein vollständiges Vokabular für +reguläre Ausdrücke dar, aber sie sind ein guter Ausgangspunkt und sollten +Ihnen helfen, grundlegende reguläre Ausdrücke zu lesen und eigene zu +schreiben.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
ZeichenBedeutungBeispiel
.Stimmt mit jedem einzelnen Zeichen übereinc.t stimmt mit cat, cot, + cut usw. überein
+Wiederholt die vorherige Übereinstimmung ein oder mehrmalsa+ stimmt mit a, aa, + aaa usw. überein
*Wiederholt die vorherige Übereinstimmung null oder mehrmalsa* stimmt mit allem überein, womit auch a+ + übereinstimmt, aber auch mit einem leeren String
?Macht die Übereinstimmung optionalcolou?r stimmt mit color und + colour überein
\Maskiert das nächste Zeichen\. stimmt mit . (Punkt) überein und nicht + mit jedem einzelnen Zeichen, wie oben erklärt
^Als Anker bezeichnet, stimmt mit dem Anfang des Strings überein^a stimmt mit einem String überein, der mit a beginnt
$Der andere Anker, stimmt mit dem Ende des Strings übereina$ stimmt mit einem String überein, der mit a endet
( )Gruppiert mehrere Zeichen zu einer Einheit und erfasst eine + Übereinstimmung zur Verwendung als Rückreferenz(ab)+ stimmt mit ababab überein - das heißt, + das + gilt für die Gruppe. Für mehr zu Rückreferenzen + siehe unten
[ ]Eine Zeichenklasse - stimmt mit einem der Zeichen übereinc[uoa]t stimmt mit cut, cot oder + cat überein
[^ ]Negative Zeichenklasse - stimmt mit jedem nicht angegebenen Zeichen übereinc[^/]t stimmt mit cat oder c=t überein, + aber nicht mit c/t
+ +

In mod_rewrite kann das Zeichen ! vor +einem regulären Ausdruck verwendet werden, um ihn zu negieren. Das heißt, +ein String gilt nur dann als übereinstimmend, wenn er nicht mit dem Rest +des Ausdrucks übereinstimmt.

+ +
+ +
Verfügbarkeit von Regex-Rückreferenzen + +

Hier ist eine wichtige Sache zu beachten: Wann immer Sie + Klammern in Pattern oder in einem der + CondPattern verwenden, werden intern Rückreferenzen + erstellt, die mit den Strings $N und %N + (siehe unten) verwendet werden können. Diese stehen für die + Erstellung des Substitution-Parameters einer + RewriteRule oder des + TestString-Parameters einer + RewriteCond zur Verfügung.

+

Erfassungen in den RewriteRule-Mustern stehen (kontraintuitiv) allen + vorhergehenden RewriteCond-Direktiven + zur Verfügung, da der RewriteRule-Ausdruck + vor den einzelnen Bedingungen ausgewertet wird.

+ +

Abbildung 1 zeigt, an welche Stellen die Rückreferenzen zur + Expansion übertragen werden und illustriert den Ablauf der + RewriteRule-/RewriteCond-Zuordnung. In den nächsten Kapiteln + werden wir erkunden, wie diese Rückreferenzen verwendet werden, + also machen Sie sich keine Sorgen, wenn es Ihnen zunächst etwas + fremd erscheint. +

+ +

+ Ablauf der RewriteRule- und RewriteCond-Zuordnung
+ Abbildung 1: Der Rückreferenz-Ablauf durch eine Regel.
+ In diesem Beispiel würde eine Anfrage für /test/1234 in /admin.foo?page=test&id=1234&host=admin.example.com umgewandelt. +

+ +
+
+ +
RewriteRule-Grundlagen +

Eine RewriteRule besteht +aus drei durch Leerzeichen getrennten Argumenten. Die Argumente sind:

+
    +
  1. Pattern: welche eingehenden URLs von der Regel betroffen sein sollen;
  2. +
  3. Substitution: wohin die übereinstimmenden Anfragen gesendet werden sollen;
  4. +
  5. [flags]: Optionen, die die umgeschriebene Anfrage beeinflussen.
  6. +
+ +

Das Pattern ist ein regulärer Ausdruck. +Es wird anfänglich (für die erste Umschreibungsregel oder bis eine Ersetzung +erfolgt) gegen den URL-Pfad der eingehenden Anfrage abgeglichen (der Teil +nach dem Hostnamen, aber vor einem Fragezeichen, das den Beginn eines +Query-Strings anzeigt) oder im Verzeichniskontext gegen den Pfad der +Anfrage relativ zum Verzeichnis, für das die Regel definiert ist. Sobald +eine Ersetzung erfolgt ist, werden die folgenden Regeln gegen den +ersetzten Wert abgeglichen. +

+ +

+ Syntax der RewriteRule-Direktive
+ Abbildung 2: Syntax der RewriteRule-Direktive. +

+ +

Die Substitution kann selbst eines von drei Dingen sein:

+ +
+
1. Ein vollständiger Dateisystempfad zu einer Ressource
+
+ +RewriteRule "^/games" "/usr/local/games/web/puzzles.html" + +

Dies bildet eine Anfrage auf einen beliebigen Ort in Ihrem Dateisystem ab, +ähnlich wie die Alias-Direktive.

+
+ +
2. Ein Web-Pfad zu einer Ressource
+
+ +RewriteRule "^/games$" "/puzzles.html" + +

Wenn DocumentRoot auf +/usr/local/apache2/htdocs gesetzt ist, würde diese Direktive +Anfragen für http://example.com/games auf den Pfad +/usr/local/apache2/htdocs/puzzles.html abbilden.

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

Dies weist den Client an, eine neue Anfrage für die angegebene URL zu +stellen.

+
+
+ +Beachten Sie, dass 1 und 2 exakt dieselbe Syntax haben. Der Unterschied besteht darin, dass bei 1 die oberste Ebene des Zielpfads (d.h. /usr/) im Dateisystem existiert, während dies bei 2 nicht der Fall ist (d.h. es gibt kein /bar/ als Verzeichnis auf der obersten Ebene im Dateisystem). + +

Die Substitution kann auch +Rückreferenzen auf Teile des eingehenden URL-Pfads enthalten, +die vom Pattern erfasst wurden. Betrachten Sie Folgendes:

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

Die Variable $1 wird durch den Text ersetzt, der vom +Ausdruck innerhalb der Klammern im Pattern erfasst wurde. +Beispielsweise würde eine Anfrage für +http://example.com/product/r14df/view auf den Pfad +/var/web/productdb/r14df abgebildet.

+ +

Wenn mehr als ein Ausdruck in Klammern vorhanden ist, stehen sie +in der Reihenfolge in den Variablen $1, $2, +$3 usw. zur Verfügung.

+ +
+ +
Umschreibungs-Flags +

Das Verhalten einer RewriteRule kann durch die Anwendung +eines oder mehrerer Flags am Ende der Regel modifiziert werden. +Beispielsweise kann das Übereinstimmungsverhalten einer Regel durch +die Anwendung des [NC]-Flags auf Groß-/Kleinschreibung +unempfindlich gemacht werden: +

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

Weitere Details zu den verfügbaren Flags, ihren Bedeutungen und +Beispiele finden Sie im Dokument Umschreibungs-Flags.

+ +
+ +
Umschreibungsbedingungen +

Eine oder mehrere RewriteCond-Direktiven +können verwendet werden, um die Typen von Anfragen einzuschränken, die der +nachfolgenden RewriteRule +unterliegen. Das erste Argument ist eine Variable, die eine Eigenschaft +der Anfrage beschreibt, das zweite Argument ist ein regulärer +Ausdruck, der mit der Variable übereinstimmen muss, und ein optionales +drittes Argument ist eine Liste von Flags, die die Art der Auswertung +der Übereinstimmung modifizieren.

+ +

+ Syntax der RewriteCond-Direktive
+ Abbildung 3: Syntax der RewriteCond-Direktive +

+ +

Um beispielsweise alle Anfragen von einem bestimmten IP-Bereich an +einen anderen Server zu senden, könnten Sie Folgendes verwenden:

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

Wenn mehr als eine RewriteCond +angegeben wird, müssen alle übereinstimmen, damit die +RewriteRule angewendet wird. +Um beispielsweise Anfragen abzulehnen, die das Wort "hack" in ihrem +Query-String enthalten, es sei denn, sie enthalten auch ein Cookie mit +dem Wort "go", könnten Sie Folgendes verwenden:

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

Beachten Sie, dass das Ausrufezeichen eine negative Übereinstimmung +angibt, sodass die Regel nur angewendet wird, wenn das Cookie nicht "go" +enthält.

+ +

Übereinstimmungen in den regulären Ausdrücken der +RewriteConds können als Teil +der Substitution in der +RewriteRule über die Variablen +%1, %2 usw. verwendet werden. Beispielsweise +leitet Folgendes die Anfrage abhängig vom für den Zugriff auf die Website +verwendeten Hostnamen in ein anderes Verzeichnis:

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

Wenn die Anfrage für http://example.com/foo/bar war, +dann enthält %1 den Wert example.com und +$1 den Wert foo/bar.

+ +
+ +
Umschreibungs-Maps + +

Die RewriteMap-Direktive +bietet eine Möglichkeit, sozusagen eine externe Funktion aufzurufen, +um Ihre Umschreibung durchzuführen. Dies wird im +ergänzenden RewriteMap-Dokument +ausführlicher besprochen.

+
+ +
.htaccess-Dateien + +

Umschreibungen werden typischerweise in der Hauptserverkonfiguration +(außerhalb eines Directory-Abschnitts) +oder innerhalb von VirtualHost-Containern +konfiguriert. Dies ist die einfachste Art, Umschreibungen durchzuführen, +und wird empfohlen. Es ist jedoch möglich, Umschreibungen innerhalb von +Directory-Abschnitten +oder .htaccess-Dateien +auf Kosten zusätzlicher Komplexität durchzuführen. Diese Technik wird +als verzeichnisbasierte Umschreibung bezeichnet.

+ +

Der Hauptunterschied zu serverweiten Umschreibungen besteht darin, dass +der Pfadpräfix des Verzeichnisses, das die .htaccess-Datei +enthält, vor dem Abgleich in der RewriteRule +entfernt wird. Zusätzlich sollte RewriteBase +verwendet werden, um sicherzustellen, dass die Anfrage korrekt zugeordnet wird.

+ +
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/intro.xml.es b/docs/manual/rewrite/intro.xml.es new file mode 100644 index 0000000000..78e49a2ad1 --- /dev/null +++ b/docs/manual/rewrite/intro.xml.es @@ -0,0 +1,394 @@ + + + + + + + + +Rewrite + + Introducción a Apache mod_rewrite + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +los conceptos básicos necesarios para el uso de +mod_rewrite. Otros documentos entran en mayor detalle, +pero este documento debería ayudar al principiante a mojarse los pies. +

+
+ +Documentación del módulo + +Redirección y remapeo +Control de acceso +Hosts virtuales +Proxy +Uso de RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
Introducción +

El módulo de Apache mod_rewrite es un módulo muy potente y +sofisticado que proporciona una forma de hacer manipulaciones de URL. Con +él, puede hacer casi todos los tipos de reescritura de URL que pueda necesitar. Es, +sin embargo, algo complejo, y puede ser intimidante para el principiante. +También hay una tendencia a tratar las reglas de reescritura como encantamientos mágicos, +usándolas sin realmente entender lo que hacen.

+ +

Este documento intenta dar suficiente contexto para que lo que +sigue sea entendido, en lugar de simplemente copiado a ciegas. +

+ +

Recuerde que muchas tareas comunes de manipulación de URL no requieren la +potencia y complejidad completas de mod_rewrite. Para tareas +simples, consulte mod_alias y la documentación +sobre mapeo de URLs al +sistema de archivos.

+ +

Finalmente, antes de continuar, asegúrese de configurar +el nivel de log de mod_rewrite a uno de los niveles de traza usando +la directiva LogLevel. Aunque esto +puede dar una cantidad abrumadora de información, es indispensable para +depurar problemas con la configuración de mod_rewrite, ya que +le dirá exactamente cómo se procesa cada regla.

+ +
+ +
Expresiones Regulares + +

mod_rewrite usa el vocabulario de Expresiones +Regulares Compatibles con Perl. En este documento, no intentamos +proporcionar una referencia detallada de expresiones regulares. Para eso, +recomendamos las páginas man de PCRE, la +página man de expresiones +regulares de Perl, y Mastering +Regular Expressions, de Jeffrey Friedl (la tercera edición es de +2006, pero la sintaxis de expresiones regulares es esencialmente la misma, y este +sigue siendo la referencia definitiva sobre el tema).

+ +

En este documento, intentamos proporcionar suficiente vocabulario de regex +para que pueda comenzar, sin ser abrumador, con la esperanza de que +las RewriteRules sean fórmulas +científicas, en lugar de encantamientos mágicos.

+ +
Vocabulario de Regex + +

Los siguientes son los bloques de construcción mínimos que necesitará, para +escribir expresiones regulares y RewriteRules. Ciertamente no +representan un vocabulario completo de expresiones regulares, pero son un buen +punto de partida, y deberían ayudarle a leer expresiones regulares básicas, así +como a escribir las suyas propias.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
CarácterSignificadoEjemplo
.Coincide con cualquier carácter individualc.t coincidirá con cat, cot, + cut, etc
+Repite la coincidencia anterior una o más vecesa+ coincide con a, aa, + aaa, etc
*Repite la coincidencia anterior cero o más vecesa* coincide con todo lo mismo que a+, + pero también coincidirá con una cadena vacía
?Hace la coincidencia opcionalcolou?r coincidirá con color y + colour
\Escapa el siguiente carácter\. coincidirá con . (punto) y no con cualquier + carácter individual como se explicó arriba
^Llamado ancla, coincide con el inicio de la cadena^a coincide con una cadena que comienza con a
$La otra ancla, coincide con el final de la cadenaa$ coincide con una cadena que termina con a
( )Agrupa varios caracteres en una sola unidad, y captura una coincidencia + para uso en una referencia inversa(ab)+ coincide con ababab - es decir, el + + se aplica al grupo. Para más sobre referencias inversas vea + más abajo
[ ]Una clase de caracteres - coincide con uno de los caracteresc[uoa]t coincide con cut, cot o + cat
[^ ]Clase de caracteres negativa - coincide con cualquier carácter no especificadoc[^/]t coincide con cat o c=t pero + no con c/t
+ +

En mod_rewrite el carácter ! puede usarse +antes de una expresión regular para negarla. Es decir, una cadena se +considerará que ha coincidido solo si no coincide con el resto de +la expresión.

+ +
+ +
Disponibilidad de Referencias Inversas de Regex + +

Una cosa importante que debe recordarse aquí: Siempre que + use paréntesis en Pattern o en uno de los + CondPattern, se crean referencias inversas internas + que pueden usarse con las cadenas $N y + %N (ver más abajo). Estas están disponibles para crear + el parámetro Substitution de una + RewriteRule o + el parámetro TestString de una + RewriteCond.

+

Las capturas en los patrones de RewriteRule están (contraintuitivamente) disponibles para + todas las directivas + RewriteCond precedentes, + porque la expresión de RewriteRule + se evalúa antes que las condiciones individuales.

+ +

La Figura 1 muestra a qué + ubicaciones se transfieren las referencias inversas para expansión, así + como ilustra el flujo de la coincidencia de RewriteRule, RewriteCond. + En los próximos capítulos, exploraremos cómo usar + estas referencias inversas, así que no se preocupe si le parece un poco extraño + al principio. +

+ +

+ Flujo de coincidencia de RewriteRule y RewriteCond
+ Figura 1: El flujo de referencias inversas a través de una regla.
+ En este ejemplo, una solicitud para /test/1234 sería transformada en /admin.foo?page=test&id=1234&host=admin.example.com. +

+ +
+
+ +
Conceptos Básicos de RewriteRule +

Una RewriteRule consiste +en tres argumentos separados por espacios. Los argumentos son

+
    +
  1. Pattern: qué URLs entrantes deben ser afectadas por la regla;
  2. +
  3. Substitution: a dónde deben enviarse las solicitudes coincidentes;
  4. +
  5. [flags]: opciones que afectan a la solicitud reescrita.
  6. +
+ +

El Pattern es una expresión regular. +Se compara inicialmente (para la primera regla de reescritura o hasta que ocurra una sustitución) +contra la ruta URL de la solicitud entrante (la parte después del +nombre de host pero antes de cualquier signo de interrogación que indique el inicio de una cadena +de consulta) o, en contexto per-directorio, contra la ruta de la solicitud relativa +al directorio para el cual se define la regla. Una vez que ha ocurrido una sustitución, +las reglas siguientes se comparan contra el valor +sustituido. +

+ +

+ Sintaxis de la directiva RewriteRule
+ Figura 2: Sintaxis de la directiva RewriteRule. +

+ + +

La Substitution puede ser una de tres cosas:

+ +
+
1. Una ruta completa del sistema de archivos a un recurso
+
+ +RewriteRule "^/games" "/usr/local/games/web/puzzles.html" + +

Esto mapea una solicitud a una ubicación arbitraria en su sistema de archivos, de forma +similar a la directiva Alias.

+
+ +
2. Una ruta web a un recurso
+
+ +RewriteRule "^/games$" "/puzzles.html" + +

Si DocumentRoot está configurado +como /usr/local/apache2/htdocs, entonces esta directiva +mapearía solicitudes para http://example.com/games a la +ruta /usr/local/apache2/htdocs/puzzles.html.

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

Esto le dice al cliente que haga una nueva solicitud a la URL especificada.

+
+
+ +Tenga en cuenta que 1 y 2 tienen exactamente la misma sintaxis. La diferencia entre ellos es que en el caso de 1, el nivel superior de la ruta destino (es decir, /usr/) existe en el sistema de archivos, mientras que en el caso de 2, no existe. (es decir, no hay /bar/ como directorio de nivel raíz en el sistema de archivos.) + +

La Substitution también puede +contener referencias inversas a partes de la ruta URL entrante +coincidida por el Pattern. Considere lo siguiente:

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

La variable $1 será reemplazada por cualquier texto +que haya coincidido con la expresión dentro de los paréntesis en +el Pattern. Por ejemplo, una solicitud +para http://example.com/product/r14df/view será mapeada +a la ruta /var/web/productdb/r14df.

+ +

Si hay más de una expresión entre paréntesis, están +disponibles en orden en las +variables $1, $2, $3, y así +sucesivamente.

+ + +
+ +
Banderas de Reescritura +

El comportamiento de una RewriteRule puede ser modificado por la +aplicación de una o más banderas al final de la regla. Por ejemplo, el +comportamiento de coincidencia de una regla puede hacerse insensible a mayúsculas/minúsculas mediante la +aplicación de la bandera [NC]: +

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

Para más detalles sobre las banderas disponibles, sus significados, y +ejemplos, consulte el documento de Banderas de Reescritura.

+ +
+ + +
Condiciones de Reescritura +

Una o más directivas RewriteCond +pueden usarse para restringir los tipos de solicitudes que estarán +sujetas a la +RewriteRule siguiente. El +primer argumento es una variable que describe una característica de la +solicitud, el segundo argumento es una expresión +regular que debe coincidir con la variable, y un tercer argumento opcional +es una lista de banderas que modifican cómo se evalúa la coincidencia.

+ +

+ Sintaxis de la directiva RewriteCond
+ Figura 3: Sintaxis de la directiva RewriteCond +

+ +

Por ejemplo, para enviar todas las solicitudes desde un rango de IP particular a un +servidor diferente, podría usar:

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

Cuando se especifica más de +una RewriteCond, +todas deben coincidir para que la +RewriteRule se aplique. +Por ejemplo, para denegar solicitudes que contengan la palabra "hack" en +su cadena de consulta, a menos que también contengan una cookie que contenga +la palabra "go", podría usar:

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

Note que el signo de exclamación especifica una coincidencia negativa, por lo que la regla solo se aplica si la cookie no contiene "go".

+ +

Las coincidencias en las expresiones regulares contenidas en +las RewriteConds pueden +usarse como parte de la Substitution en +la RewriteRule usando las +variables %1, %2, etc. Por ejemplo, esto +dirigirá la solicitud a un directorio diferente dependiendo del +nombre de host usado para acceder al sitio:

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

Si la solicitud fue para http://example.com/foo/bar, +entonces %1 contendrá example.com +y $1 contendrá foo/bar.

+ + + +
+ +
Mapas de reescritura + +

La directiva RewriteMap +proporciona una forma de llamar a una función externa, por así decirlo, para hacer su +reescritura por usted. Esto se discute con mayor detalle en la documentación complementaria de RewriteMap.

+
+ +
Archivos .htaccess + +

La reescritura se configura típicamente en la configuración principal del servidor +(fuera de cualquier sección Directory) o +dentro de contenedores VirtualHost. +Esta es la forma más fácil de hacer reescritura y es +recomendada. Sin embargo, es posible hacer reescritura +dentro de secciones Directory +o archivos .htaccess +a costa de algo de complejidad adicional. Esta técnica +se llama reescrituras per-directorio.

+ +

La principal diferencia con las reescrituras per-servidor es que el prefijo de ruta +del directorio que contiene el archivo .htaccess se +elimina antes de la coincidencia en +la RewriteRule. Además, se debería usar RewriteBase para asegurar que la solicitud se mapee correctamente.

+ +
+ +
diff --git a/docs/manual/rewrite/intro.xml.fr b/docs/manual/rewrite/intro.xml.fr index 75846f5783..da1c56f7fe 100644 --- a/docs/manual/rewrite/intro.xml.fr +++ b/docs/manual/rewrite/intro.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -89,8 +89,10 @@ 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.

+href="https://www.oreilly.com/library/view/mastering-regular-expressions/0596528124/">Mastering +Regular Expressions, by Jeffrey Friedl (la troisième édition date +de 2006, mais la syntaxe des expressions rationnelles n'a pas vraiment +changé, et cet ouvrage reste la référence en la matière).

Dans ce document, nous avons pour but de vous fournir suffisamment de vocabulaire des expressions rationnelles pour vous mettre le pied à @@ -129,6 +131,9 @@ précédent zéro ou plusieurs fois ?Rend la correspondance optionnelle. colou?r correspondra à color et colour. +\Échappe le caractère +suivant\. correspondra à . (point) et non pas à +tout caractère unique comme expliqué ci-dessus ^Appelé ancrage, correspond au début de la chaîne ^a correspond à une chaîne qui commence par @@ -408,4 +413,3 @@ requête est correctement mise en correspondance.

- diff --git a/docs/manual/rewrite/intro.xml.ja b/docs/manual/rewrite/intro.xml.ja new file mode 100644 index 0000000000..7d66424def --- /dev/null +++ b/docs/manual/rewrite/intro.xml.ja @@ -0,0 +1,383 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite 入門 + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +mod_rewrite の使用に必要な基本概念を説明します。 +他のドキュメントではさらに詳しく説明しますが、このドキュメントは +初心者が最初の一歩を踏み出すのに役立つはずです。 +

+
+ +モジュールドキュメント + +リダイレクトとリマッピング +アクセス制御 +バーチャルホスト +プロキシ +RewriteMap の使用 +高度なテクニック +mod_rewrite を使わない場合 + +
はじめに +

Apache モジュール mod_rewrite は、URL 操作を行う方法を +提供する非常に強力で洗練されたモジュールです。これを使用すると、 +必要なほぼすべての種類の URL 書き換えを行うことができます。 +ただし、やや複雑で、初心者には敷居が高く感じられるかもしれません。 +また、書き換えルールを実際に何をしているか理解せずに、魔法の呪文として +扱う傾向もあります。

+ +

このドキュメントは、以下の内容が単にコピーされるのではなく、 +理解されるための十分な背景を提供することを目指しています。 +

+ +

多くの一般的な URL 操作タスクは mod_rewrite の +フルパワーと複雑さを必要としないことを忘れないでください。シンプルな +タスクについては、mod_alias と +URL からファイルシステムへの +マッピングに関するドキュメントを参照してください。

+ +

最後に、先に進む前に、LogLevel +ディレクティブを使用して mod_rewrite のログレベルを +trace レベルのいずれかに設定してください。これにより圧倒的な量の情報が +得られますが、mod_rewrite 設定の問題をデバッグするのに +不可欠です。各ルールがどのように処理されるかを正確に教えてくれます。

+ +
+ +
正規表現 + +

mod_rewrite は Perl 互換 +正規表現の語彙を使用します。このドキュメントでは、正規表現の +詳細なリファレンスを提供しようとはしていません。そのためには、 +PCRE man ページ、 +Perl 正規表現 +man ページ、および +Jeffrey Friedl 著 +『詳説 正規表現』 (第 3 版は 2006 年のものですが、正規表現の +構文は本質的に変わっておらず、このテーマの決定的なリファレンスです) +を推奨します。

+ +

このドキュメントでは、圧倒されることなく始められるように、 +十分な正規表現の語彙を提供しようとしています。 +RewriteRule が魔法の呪文ではなく、 +科学的な公式であるようになることを願っています。

+ +
正規表現の語彙 + +

以下は、正規表現と RewriteRule を書くために必要な +最小限の構成要素です。これらは完全な正規表現の語彙を表すものでは +ありませんが、良い出発点であり、基本的な正規表現を読むだけでなく、 +自分で書くのにも役立つはずです。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
文字意味例
.任意の 1 文字にマッチc.t は cat、cot、 + cut 等にマッチ
+直前のマッチを 1 回以上繰り返すa+ は a、aa、 + aaa 等にマッチ
*直前のマッチを 0 回以上繰り返すa* は a+ がマッチするすべてにマッチするが、 + 空文字列にもマッチする
?マッチをオプションにするcolou?r は color と + colour にマッチ
\次の文字をエスケープ\. は上記で説明した任意の 1 文字ではなく、 + . (ドット) にマッチ
^アンカーと呼ばれ、文字列の先頭にマッチ^a は a で始まる文字列にマッチ
$もう一つのアンカーで、文字列の末尾にマッチa$ は a で終わる文字列にマッチ
( )複数の文字を 1 つの単位にグループ化し、バックリファレンスで + 使用するためのマッチをキャプチャ(ab)+ は ababab にマッチ - つまり、 + + がグループに適用される。バックリファレンスの + 詳細は以下を参照
[ ]文字クラス - いずれかの文字にマッチc[uoa]t は cut、cot、 + cat にマッチ
[^ ]否定文字クラス - 指定されていない任意の文字にマッチc[^/]t は cat や c=t に + マッチするが、c/t にはマッチしない
+ +

mod_rewrite では、正規表現の前に ! 文字を +使用して否定できます。つまり、式の残りの部分にマッチしない場合にのみ、 +文字列がマッチしたとみなされます。

+ +
+ +
正規表現バックリファレンスの利用 + +

ここで覚えておくべき重要なことがあります: Pattern 内または + CondPattern 内で括弧を使用するたびに、内部的にバックリファレンスが + 作成され、$N および %N という文字列で使用 + できます (以下を参照)。これらは + RewriteRule の + Substitution パラメータまたは + RewriteCond の + TestString パラメータの作成に使用できます。

+

RewriteRule パターン内の + キャプチャは、(直感に反して) すべての先行する + RewriteCond ディレクティブで + 利用可能です。これは、RewriteRule + 式が個々の条件よりも先に評価されるためです。

+ +

図 1 は、バックリファレンスが展開のためにどの場所に + 転送されるかを示すとともに、RewriteRule と RewriteCond の + マッチングのフローを図示しています。次の章では、これらの + バックリファレンスの使用方法を探りますので、最初は少し + 馴染みがないように感じても心配しないでください。 +

+ +

+ RewriteRule と RewriteCond マッチングのフロー
+ 図 1: ルールを通るバックリファレンスのフロー。
+ この例では、/test/1234 へのリクエストは /admin.foo?page=test&id=1234&host=admin.example.com に変換されます。 +

+ +
+
+ +
RewriteRule の基本 +

RewriteRule は、 +スペースで区切られた 3 つの引数で構成されます。引数は以下の通りです

+
    +
  1. Pattern: ルールの影響を受ける受信 URL;
  2. +
  3. Substitution: マッチするリクエストの送信先;
  4. +
  5. [flags]: 書き換えられたリクエストに影響するオプション。
  6. +
+ +

Pattern は正規表現です。 +最初 (最初の書き換えルールまたは置換が発生するまで) は、受信リクエストの +URL パス (ホスト名の後、クエリ文字列の開始を示す疑問符の前の部分) に対して +マッチされます。ディレクトリ単位のコンテキストでは、ルールが定義された +ディレクトリに対するリクエストの相対パスに対してマッチされます。 +置換が発生すると、後続のルールは置換された値に対してマッチされます。 +

+ +

+ RewriteRule ディレクティブの構文
+ 図 2: RewriteRule ディレクティブの構文 +

+ + +

Substitution 自体は以下の 3 つのいずれかです:

+ +
+
1. リソースへの完全なファイルシステムパス
+
+ +RewriteRule "^/games" "/usr/local/games/web/puzzles.html" + +

これは、Alias ディレクティブと +同様に、リクエストをファイルシステム上の任意の場所にマッピングします。

+
+ +
2. リソースへの Web パス
+
+ +RewriteRule "^/games$" "/puzzles.html" + +

DocumentRoot が +/usr/local/apache2/htdocs に設定されている場合、 +このディレクティブは http://example.com/games への +リクエストをパス /usr/local/apache2/htdocs/puzzles.html +にマッピングします。

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

これは、指定された URL に対する新しいリクエストを行うよう +クライアントに指示します。

+
+
+ +1 と 2 はまったく同じ構文であることに注意してください。違いは、1 の場合はターゲットパスのトップレベル (つまり /usr/) がファイルシステム上に存在するのに対し、2 の場合は存在しない (つまり、ファイルシステムのルートレベルディレクトリとして /bar/ が存在しない) ことです。 + +

Substitution には、Pattern でマッチした +受信 URL パスの部分へのバックリファレンスも含めることができます。 +以下を考えてみてください:

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

変数 $1 は、Pattern 内の括弧内の +式でマッチしたテキストに置き換えられます。例えば、 +http://example.com/product/r14df/view へのリクエストは +パス /var/web/productdb/r14df にマッピングされます。

+ +

括弧内の式が複数ある場合、変数 $1、$2、 +$3 等の順序で利用できます。

+ + +
+ +
書き換えフラグ +

RewriteRule の動作は、 +ルールの末尾に 1 つ以上のフラグを適用することで変更できます。例えば、 +ルールのマッチング動作は [NC] フラグの適用で +大文字小文字を区別しないようにできます: +

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

利用可能なフラグ、その意味、および例の詳細については、 +書き換えフラグドキュメントを参照してください。

+ +
+ + +
書き換え条件 +

1 つ以上の RewriteCond +ディレクティブを使用して、後続の +RewriteRule の対象となる +リクエストの種類を制限できます。最初の引数はリクエストの特性を +記述する変数、2 番目の引数は変数にマッチする必要がある +正規表現、3 番目のオプション引数はマッチの +評価方法を変更するフラグのリストです。

+ +

+ RewriteCond ディレクティブの構文
+ 図 3: RewriteCond ディレクティブの構文 +

+ +

例えば、特定の IP 範囲からのすべてのリクエストを別のサーバに +送信するには、以下を使用できます:

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

複数の RewriteCond が +指定された場合、RewriteRule +が適用されるには、すべてがマッチする必要があります。例えば、 +クエリ文字列に "hack" という単語を含むリクエストを拒否するが、 +"go" という単語を含む cookie がある場合は除外するには、以下を使用 +できます:

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

感嘆符は否定マッチを指定しており、cookie に "go" が含まれていない +場合にのみルールが適用されます。

+ +

RewriteCond 内の正規表現の +マッチは、RewriteRule の +Substitution で変数 %1、%2 等を +使用して使用できます。例えば、以下はサイトへのアクセスに使用された +ホスト名に応じて、リクエストを異なるディレクトリに振り分けます:

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

http://example.com/foo/bar へのリクエストの場合、 +%1 は example.com を含み、 +$1 は foo/bar を含みます。

+ + + +
+ +
書き換えマップ + +

RewriteMap ディレクティブは、 +書き換えを行うための外部関数を呼び出す方法を提供します。これについては +RewriteMap 補足ドキュメントでより詳細に +説明されています。

+
+ +
.htaccess ファイル + +

書き換えは通常、メインサーバ設定 +(Directory +セクション外) または +VirtualHost +コンテナ内で設定されます。これが書き換えの最も簡単な方法であり、 +推奨されます。ただし、追加の複雑さを伴いますが、 +Directory +セクションや .htaccess +ファイル内で書き換えを行うことも可能です。このテクニックは +ディレクトリ単位の書き換えと呼ばれます。

+ +

サーバ単位の書き換えとの主な違いは、.htaccess +ファイルを含むディレクトリのパスプレフィックスが +RewriteRule でのマッチング前に +削除されることです。さらに、リクエストが適切にマッピングされるように +RewriteBase を使用する +必要があります。

+ +
+ +
diff --git a/docs/manual/rewrite/intro.xml.ko b/docs/manual/rewrite/intro.xml.ko new file mode 100644 index 0000000000..1cf03e9c98 --- /dev/null +++ b/docs/manual/rewrite/intro.xml.ko @@ -0,0 +1,405 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite 소개 + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +mod_rewrite 사용에 필요한 기본 개념을 +설명합니다. 다른 문서에서 더 자세히 다루지만, 이 문서는 +초보자가 시작하는 데 도움이 될 것입니다. +

+
+ +모듈 문서 + +리다이렉션과 재매핑 +접근 제어 +가상 호스트 +프록시 +RewriteMap 사용하기 +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
소개 +

Apache 모듈 mod_rewrite는 URL 조작을 +수행하는 방법을 제공하는 매우 강력하고 정교한 모듈입니다. +이를 사용하면 필요한 거의 모든 유형의 URL 재작성을 수행할 수 +있습니다. 그러나 다소 복잡하며 초보자에게 위협적일 수 +있습니다. 또한 실제로 무엇을 하는지 이해하지 않고 재작성 +규칙을 마법의 주문처럼 취급하는 경향이 있습니다.

+ +

이 문서는 이후의 내용이 단순히 맹목적으로 복사되는 것이 +아니라 이해되도록 충분한 배경 지식을 제공하고자 합니다. +

+ +

많은 일반적인 URL 조작 작업에는 +mod_rewrite의 전체 기능과 복잡성이 필요하지 +않다는 것을 기억하십시오. 간단한 작업에는 +mod_alias와 +파일 시스템에 URL 매핑 +문서를 참조하십시오.

+ +

마지막으로 진행하기 전에 LogLevel 지시어를 사용하여 +mod_rewrite의 로그 레벨을 trace 레벨 중 +하나로 구성하십시오. 이는 압도적인 양의 정보를 제공할 수 +있지만, mod_rewrite 설정의 문제를 +디버깅하는 데 필수적입니다. 각 규칙이 어떻게 처리되는지 +정확히 알려주기 때문입니다.

+ +
+ +
정규 표현식 + +

mod_rewrite는 Perl +호환 정규 표현식 어휘를 사용합니다. 이 문서에서는 +정규 표현식에 대한 자세한 참조를 제공하지 않습니다. +이를 위해 PCRE 매뉴얼 +페이지, Perl +정규 표현식 매뉴얼 페이지 및 +Jeffrey +Friedl의 Mastering Regular Expressions(3판은 2006년에 +출판되었지만 정규 표현식 구문은 본질적으로 변경되지 않았으며 +이 주제에 대한 결정적인 참고 자료로 남아 있습니다)를 +권장합니다.

+ +

이 문서에서는 RewriteRule이 마법의 주문이 +아닌 과학적 공식이 되도록 압도적이지 않은 수준에서 시작하기에 +충분한 정규 표현식 어휘를 제공하고자 합니다.

+ +
정규 표현식 어휘 + +

다음은 정규 표현식과 RewriteRule을 작성하기 위해 +필요한 최소한의 구성 요소입니다. 이것들이 완전한 정규 표현식 +어휘를 나타내지는 않지만 시작하기에 좋은 출발점이며, 기본적인 +정규 표현식을 읽고 자신만의 것을 작성하는 데 도움이 될 +것입니다.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
문자의미예제
.임의의 단일 문자와 일치c.t는 cat, cot, + cut 등과 일치
+이전 일치를 한 번 이상 반복a+는 a, aa, + aaa 등과 일치
*이전 일치를 0번 이상 반복a*는 a+가 일치하는 모든 것과 + 일치하지만 빈 문자열과도 일치
?일치를 선택적으로 만듦colou?r는 color와 + colour에 일치
\다음 문자를 이스케이프\.는 위에서 설명한 임의의 단일 문자가 + 아닌 .(점)과 일치
^앵커라고 하며, 문자열의 시작과 일치^a는 a로 시작하는 문자열과 일치
$다른 앵커, 문자열의 끝과 일치a$는 a로 끝나는 문자열과 일치
( )여러 문자를 단일 단위로 그룹화하고 역참조에서 + 사용할 일치를 캡처(ab)+는 ababab과 일치 - + 즉, +가 그룹에 적용됨. + 역참조에 대한 자세한 내용은 아래를 + 참조
[ ]문자 클래스 - 문자 중 하나와 일치c[uoa]t는 cut, cot 또는 + cat과 일치
[^ ]부정 문자 클래스 - 지정되지 않은 모든 문자와 일치c[^/]t는 cat 또는 c=t와 + 일치하지만 c/t와는 일치하지 않음
+ +

mod_rewrite에서 ! 문자는 +정규 표현식 앞에 사용하여 부정할 수 있습니다. 즉, 문자열이 +나머지 표현식과 일치하지 않는 경우에만 일치한 것으로 +간주됩니다.

+ +
+ +
정규 표현식 역참조 사용 가능성 + +

여기서 기억해야 할 중요한 점이 있습니다: + Pattern이나 CondPattern 중 하나에서 + 괄호를 사용할 때마다 내부적으로 역참조가 생성되며 + 문자열 $N과 %N(아래 참조)으로 + 사용할 수 있습니다. 이것들은 + RewriteRule의 + Substitution 매개변수 또는 + RewriteCond의 + TestString 매개변수를 생성하는 데 사용할 수 + 있습니다.

+

RewriteRule + 패턴의 캡처는 (직관에 반하여) 모든 선행 + RewriteCond + 지시어에서 사용할 수 있습니다. + RewriteRule + 표현식이 개별 조건보다 먼저 평가되기 때문입니다.

+ +

그림 1은 역참조가 확장을 위해 전달되는 위치와 + RewriteRule, RewriteCond 매칭의 흐름을 보여줍니다. + 다음 장에서 이러한 역참조를 사용하는 방법을 탐구할 + 것이므로, 처음에 다소 생소하게 느껴져도 걱정하지 + 마십시오. +

+ +

+ RewriteRule과 RewriteCond 매칭의 흐름
+ 그림 1: 규칙을 통한 역참조 흐름.
+ 이 예제에서 /test/1234에 대한 요청은 /admin.foo?page=test&id=1234&host=admin.example.com으로 변환됩니다. +

+ +
+
+ +
RewriteRule 기본 +

RewriteRule은 +공백으로 구분된 세 개의 인수로 구성됩니다. 인수는 다음과 +같습니다:

+
    +
  1. Pattern: 규칙의 영향을 받는 들어오는 URL;
  2. +
  3. Substitution: 일치하는 요청이 전송되어야 할 곳;
  4. +
  5. [flags]: 재작성된 요청에 영향을 미치는 옵션.
  6. +
+ +

Pattern은 정규 표현식입니다. +처음에는(첫 번째 재작성 규칙이거나 치환이 발생하기 전까지) +들어오는 요청의 URL 경로(호스트명 뒤부터 쿼리 문자열의 +시작을 나타내는 물음표 앞까지의 부분) 또는 디렉토리별 +컨텍스트에서는 규칙이 정의된 디렉토리에 상대적인 요청 +경로와 비교됩니다. 치환이 발생하면 이후의 규칙은 치환된 +값과 비교됩니다. +

+ +

+ RewriteRule 지시어의 구문
+ 그림 2: RewriteRule 지시어의 구문. +

+ + +

Substitution은 자체적으로 다음 세 가지 중 +하나일 수 있습니다:

+ +
+
1. 자원에 대한 전체 파일 시스템 경로
+
+ +RewriteRule "^/games" "/usr/local/games/web/puzzles.html" + +

이것은 Alias +지시어와 마찬가지로 요청을 파일 시스템의 임의의 위치에 +매핑합니다.

+
+ +
2. 자원에 대한 웹 경로
+
+ +RewriteRule "^/games$" "/puzzles.html" + +

DocumentRoot가 +/usr/local/apache2/htdocs로 설정된 경우 이 +지시어는 http://example.com/games에 대한 요청을 +/usr/local/apache2/htdocs/puzzles.html 경로로 +매핑합니다.

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

이것은 클라이언트에게 지정된 URL에 대한 새 요청을 하도록 +지시합니다.

+
+
+ +1과 2는 정확히 동일한 구문을 가집니다. 차이점은 1의 경우 대상 경로의 최상위 수준(즉, /usr/)이 파일 시스템에 존재하는 반면, 2의 경우 존재하지 않는다는 것입니다. (즉, 파일 시스템에 /bar/라는 루트 수준 디렉토리가 없습니다.) + +

Substitution은 Pattern에 의해 +일치된 들어오는 URL 경로의 부분에 대한 +역참조를 포함할 수도 있습니다. 다음을 +고려하십시오:

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

변수 $1은 Pattern의 괄호 안의 +표현식에 의해 일치된 텍스트로 대체됩니다. 예를 들어, +http://example.com/product/r14df/view에 대한 +요청은 /var/web/productdb/r14df 경로에 +매핑됩니다.

+ +

괄호 안의 표현식이 둘 이상인 경우 변수 +$1, $2, $3 등의 +순서로 사용할 수 있습니다.

+ + +
+ +
재작성 플래그 +

RewriteRule의 +동작은 규칙 끝에 하나 이상의 플래그를 적용하여 수정할 수 +있습니다. 예를 들어, 규칙의 매칭 동작을 [NC] +플래그를 적용하여 대소문자를 구분하지 않도록 만들 수 +있습니다: +

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

사용 가능한 플래그, 그 의미 및 예제에 대한 자세한 +내용은 재작성 플래그 문서를 +참조하십시오.

+ +
+ + +
재작성 조건 +

하나 이상의 RewriteCond +지시어를 사용하여 다음 +RewriteRule의 대상이 +되는 요청 유형을 제한할 수 있습니다. 첫 번째 인수는 요청의 +특성을 설명하는 변수이고, 두 번째 인수는 변수와 일치해야 하는 +정규 표현식이며, 세 번째 선택적 인수는 +일치 평가 방식을 수정하는 플래그 목록입니다.

+ +

+ RewriteCond 지시어의 구문
+ 그림 3: RewriteCond 지시어의 구문 +

+ +

예를 들어, 특정 IP 범위의 모든 요청을 다른 서버로 +보내려면 다음을 사용할 수 있습니다:

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

둘 이상의 RewriteCond가 +지정된 경우 RewriteRule이 +적용되려면 모든 조건이 일치해야 합니다. 예를 들어, 쿼리 +문자열에 "hack"이라는 단어가 포함된 요청을 거부하되, "go"라는 +단어가 포함된 쿠키가 있는 경우는 제외하려면 다음을 사용할 수 +있습니다:

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

느낌표는 부정 일치를 지정하므로, 쿠키에 "go"가 포함되지 +않은 경우에만 규칙이 적용됩니다.

+ +

RewriteCond에 +포함된 정규 표현식의 일치는 변수 %1, +%2 등을 사용하여 +RewriteRule의 +Substitution의 일부로 사용할 수 있습니다. +예를 들어, 사이트에 접근하는 데 사용된 호스트명에 따라 +요청을 다른 디렉토리로 보내는 다음과 같습니다:

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

http://example.com/foo/bar에 대한 요청이면 +%1은 example.com을 포함하고 +$1은 foo/bar를 포함합니다.

+ + + +
+ +
재작성 맵 + +

RewriteMap 지시어는 +재작성을 수행할 외부 함수를 호출하는 방법을 제공합니다. +이에 대한 자세한 내용은 RewriteMap +보충 문서에서 논의됩니다.

+
+ +
.htaccess 파일 + +

재작성은 일반적으로 주 서버 설정( +Directory +섹션 외부)에서 또는 +VirtualHost +컨테이너 내에서 구성됩니다. 이것이 재작성을 수행하는 가장 +쉬운 방법이며 권장됩니다. 그러나 약간의 추가 복잡성을 +감수하면 +Directory +섹션이나 .htaccess +파일에서도 재작성을 수행할 수 있습니다. 이 기술을 +디렉토리별 재작성이라고 합니다.

+ +

서버별 재작성과의 주요 차이점은 .htaccess +파일이 포함된 디렉토리의 경로 접두사가 +RewriteRule에서 +매칭하기 전에 제거된다는 것입니다. 또한 +RewriteBase를 +사용하여 요청이 올바르게 매핑되도록 해야 합니다.

+ +
+ +
diff --git a/docs/manual/rewrite/intro.xml.meta b/docs/manual/rewrite/intro.xml.meta index ce245b2841..7a94bb1877 100644 --- a/docs/manual/rewrite/intro.xml.meta +++ b/docs/manual/rewrite/intro.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/intro.xml.tr b/docs/manual/rewrite/intro.xml.tr new file mode 100644 index 0000000000..36e1ebcfcd --- /dev/null +++ b/docs/manual/rewrite/intro.xml.tr @@ -0,0 +1,406 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite'a Giriş + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +mod_rewrite kullanımı için gerekli temel kavramları +açıklar. Diğer belgeler daha ayrıntılıdır, ancak bu belge +başlangıç yapmak isteyenlere yardımcı olmalıdır. +

+
+ +Modül belgeleri + +Yeniden yönlendirme ve yeniden eşleme +Erişim denetimi +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
Giriş +

Apache modülü mod_rewrite, URL değiştirmeleri +yapmanın bir yolunu sunan çok güçlü ve karmaşık bir modüldür. Bununla +ihtiyaç duyabileceğiniz neredeyse her türlü URL yeniden yazma işlemini +gerçekleştirebilirsiniz. Ancak biraz karmaşıktır ve yeni başlayanlar +için korkutucu olabilir. Yeniden yazma kurallarını, gerçekte ne +yaptıklarını anlamadan sihirli formüller olarak ele alma eğilimi de +vardır.

+ +

Bu belge, takip eden içeriğin körü körüne kopyalanmak yerine +anlaşılması için yeterli arka plan bilgisi sağlamaya çalışmaktadır. +

+ +

Birçok yaygın URL değiştirme görevinin mod_rewrite +modülünün tüm gücünü ve karmaşıklığını gerektirmediğini unutmayın. +Basit görevler için mod_alias modülüne ve URL'lerin dosya sistemine +eşlenmesi belgelerine bakın.

+ +

Son olarak, devam etmeden önce mod_rewrite +modülünün günlük seviyesini LogLevel +yönergesini kullanarak izleme seviyelerinden birine yapılandırmayı +unutmayın. Bu, bunaltıcı miktarda bilgi sağlasa da, +mod_rewrite yapılandırma sorunlarını ayıklamada +vazgeçilmezdir; çünkü her kuralın nasıl işlendiğini tam olarak +gösterir.

+ +
+ +
Düzenli İfadeler + +

mod_rewrite, Perl +Uyumlu Düzenli İfade sözvarlığını kullanır. Bu belgede, düzenli +ifadelere ayrıntılı bir başvuru sağlamaya çalışmıyoruz. Bunun için +PCRE kılavuz sayfalarını, +Perl düzenli ifade +kılavuz sayfasını ve Jeffrey +Friedl'ın Mastering Regular Expressions kitabını (üçüncü baskısı +2006'dandır, ancak düzenli ifade sözdizimi temelde değişmemiştir ve +bu konu hakkında kesin başvuru kaynağı olmaya devam etmektedir) +öneririz.

+ +

Bu belgede, bunaltıcı olmadan başlamanıza yetecek kadar düzenli +ifade sözvarlığı sağlamaya çalışıyoruz; böylece RewriteRule kuralları sihirli +formüller yerine bilimsel formüller olacaktır.

+ +
Düzenli ifade sözvarlığı + +

Düzenli ifadeler ve RewriteRule kuralları yazmak için +ihtiyaç duyacağınız asgari yapı taşları aşağıdadır. Bunlar kesinlikle +tam bir düzenli ifade sözvarlığını temsil etmez, ancak başlamak ve +temel düzenli ifadeleri okumak için iyi bir yerdir.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
KarakterAnlamÖrnek
.Herhangi bir tek karakterle eşleşirc.t; cat, cot, + cut vb. ile eşleşir
+Önceki eşleşmeyi bir veya daha fazla kez tekrarlara+; a, aa, + aaa vb. ile eşleşir
*Önceki eşleşmeyi sıfır veya daha fazla kez tekrarlara*; a+ ile aynı şeylerle eşleşir + ancak ayrıca boş dizgeyle de eşleşir
?Eşleşmeyi isteğe bağlı yaparcolou?r; color ve + colour ile eşleşir
\Sonraki karakteri kodlar\.; yukarıda açıklandığı gibi herhangi bir tek + karakter yerine . (nokta) ile eşleşir
^Çapa olarak adlandırılır, dizgenin başlangıcıyla eşleşir^a; a ile başlayan bir dizgeyle + eşleşir
$Diğer çapa, dizgenin sonuyla eşleşira$; a ile biten bir dizgeyle + eşleşir
( )Birkaç karakteri tek bir birime gruplar ve geri başvuruda + kullanılmak üzere bir eşleşme yakalar(ab)+; ababab ile eşleşir - yani + + gruba uygulanır. Geri başvurular hakkında daha + fazla bilgi için aşağıya + bakın
[ ]Bir karakter sınıfı - karakterlerden biriyle eşleşirc[uoa]t; cut, cot veya + cat ile eşleşir
[^ ]Olumsuz karakter sınıfı - belirtilmeyen herhangi bir + karakterle eşleşirc[^/]t; cat veya c=t + ile eşleşir ancak c/t ile eşleşmez
+ +

mod_rewrite modülünde ! karakteri +düzenli ifadeyi olumsuzlamak için kullanılabilir. Yani, bir dizge +yalnızca ifadenin geri kalanıyla eşleşmezse eşleşmiş sayılır.

+ +
+ +
Düzenli İfade Geri Başvuru +Kullanılabilirliği + +

Burada hatırlanması gereken önemli bir şey vardır: + Kalıp'ta veya CondPattern'lerden birinde + parantez kullandığınızda, $N ve %N + dizgeleriyle kullanılabilecek dahili geri başvurular oluşturulur + (aşağıya bakın). Bunlar, bir + RewriteRule + yönergesinin Değiştirme parametresini veya bir + RewriteCond + yönergesinin SınamaDizgesi parametresini oluşturmak + için kullanılabilir.

+

RewriteRule + kalıplarındaki yakalamalar (sezgiye aykırı olarak) kendinden + önceki tüm RewriteCond + yönergelerinde kullanılabilir; çünkü RewriteRule ifadesi bireysel + koşullardan önce değerlendirilir.

+ +

Şekil 1, geri başvuruların genişletilmek üzere hangi + konumlara aktarıldığını ve RewriteRule, RewriteCond eşleştirme + akışını gösterir. Sonraki bölümlerde bu geri başvuruların nasıl + kullanılacağını inceleyeceğiz; bu nedenle ilk başta biraz yabancı + görünürse endişelenmeyin. +

+ +

+ RewriteRule ve RewriteCond eşleştirme akışı
+ Şekil 1: Bir kural boyunca geri başvuru akışı.
+ Bu örnekte, /test/1234 için bir istek /admin.foo?page=test&id=1234&host=admin.example.com olarak dönüştürülecektir. +

+ +
+
+ +
RewriteRule Temelleri +

Bir RewriteRule, +boşluklarla ayrılmış üç argümandan oluşur. Argümanlar şunlardır:

+
    +
  1. Kalıp: hangi gelen URL'lerin kuraldan etkileneceği;
  2. +
  3. Değiştirme: eşleşen isteklerin nereye gönderileceği;
  4. +
  5. [bayraklar]: yeniden yazılmış isteği etkileyen +seçenekler.
  6. +
+ +

Kalıp bir düzenli ifadedir. +İlk başta (ilk yeniden yazma kuralı için veya bir değiştirme +gerçekleşene kadar) gelen isteğin URL yoluyla (konak adından sonra +ancak sorgu dizgesinin başlangıcını gösteren soru işaretinden önceki +kısım) veya dizin başına bağlamda kuralın tanımlandığı dizine göre +isteğin yoluyla eşleştirilir. Bir değiştirme gerçekleştikten sonra +izleyen kurallar değiştirilen değerle eşleştirilir. +

+ +

+ RewriteRule yönergesinin sözdizimi
+ Şekil 2: RewriteRule yönergesinin sözdizimi. +

+ + +

Değiştirme kendisi üç şeyden biri olabilir:

+ +
+
1. Bir kaynağa tam dosya sistemi yolu
+
+ +RewriteRule "^/games" "/usr/local/games/web/puzzles.html" + +

Bu, Alias yönergesine +benzer şekilde bir isteği dosya sistemindeki keyfi bir konuma +eşler.

+
+ +
2. Bir kaynağa web yolu
+
+ +RewriteRule "^/games$" "/puzzles.html" + +

DocumentRoot +/usr/local/apache2/htdocs olarak ayarlanmışsa, bu +yönerge http://example.com/games isteklerini +/usr/local/apache2/htdocs/puzzles.html yoluna +eşler.

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

Bu, istemciye belirtilen URL için yeni bir istek yapmasını +söyler.

+
+
+ +1 ve 2'nin sözdiziminin tamamen aynı olduğunu unutmayın. Aralarındaki fark, 1 durumunda hedef yolun en üst düzeyinin (yani /usr/) dosya sisteminde mevcut olması, 2 durumunda ise mevcut olmamasıdır (yani dosya sisteminde kök düzeyinde bir /bar/ dizini yoktur). + +

Değiştirme, Kalıp tarafından eşleşen gelen +URL yolunun bölümlerine geri başvurular da içerebilir. Şunu +ele alalım:

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

$1 değişkeni, Kalıp içindeki parantez +içindeki ifadeyle eşleşen metinle değiştirilir. Örneğin, +http://example.com/product/r14df/view isteği +/var/web/productdb/r14df yoluna eşlenir.

+ +

Parantez içinde birden fazla ifade varsa, bunlar sırasıyla +$1, $2, $3 ve sonraki +değişkenlerde kullanılabilir.

+ + +
+ +
Yeniden Yazma Bayrakları +

Bir RewriteRule +yönergesinin davranışı, kuralın sonuna bir veya daha fazla bayrak +uygulanarak değiştirilebilir. Örneğin, bir kuralın eşleştirme +davranışı [NC] bayrağı uygulanarak büyük/küçük harf +duyarsız yapılabilir: +

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

Kullanılabilir bayraklar, anlamları ve örnekleri hakkında daha +fazla ayrıntı için Yeniden Yazma Bayrakları +belgesine bakın.

+ +
+ + +
Yeniden Yazma Koşulları +

Ardından gelen RewriteRule yönergesine tabi +olacak istek türlerini kısıtlamak için bir veya daha fazla RewriteCond yönergesi +kullanılabilir. İlk argüman isteğin bir özelliğini tanımlayan bir +değişken, ikinci argüman değişkenle eşleşmesi gereken bir düzenli ifade ve üçüncü isteğe bağlı argüman +eşleşmenin nasıl değerlendirileceğini değiştiren bayrakların bir +listesidir.

+ +

+ RewriteCond yönergesinin sözdizimi
+ Şekil 3: RewriteCond yönergesinin sözdizimi +

+ +

Örneğin, belirli bir IP aralığından gelen tüm istekleri farklı +bir sunucuya göndermek için şunu kullanabilirsiniz:

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

Birden fazla RewriteCond +belirtildiğinde, RewriteRule +yönergesinin uygulanması için hepsinin eşleşmesi gerekir. Örneğin, +sorgu dizgelerinde "hack" sözcüğünü içeren istekleri reddetmek, ancak +"go" sözcüğünü içeren bir çerez taşıyanları hariç tutmak için şunu +kullanabilirsiniz:

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

Ünlem işaretinin olumsuz bir eşleşme belirttiğine dikkat edin; +kural yalnızca çerez "go" içermiyorsa uygulanır.

+ +

RewriteCond +yönergelerindeki düzenli ifadelerdeki eşleşmeler, RewriteRule yönergesindeki +Değiştirme'nin bir parçası olarak %1, +%2 vb. değişkenler kullanılarak kullanılabilir. Örneğin, +şu kural siteye erişmek için kullanılan konak adına bağlı olarak +isteği farklı bir dizine yönlendirecektir:

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

İstek http://example.com/foo/bar için ise +%1 değeri example.com ve $1 +değeri foo/bar olacaktır.

+ + + +
+ +
Yeniden yazma eşlemleri + +

RewriteMap yönergesi, +tabir yerindeyse yeniden yazma işleminizi yapacak harici bir işlev +çağırmanın bir yolunu sunar. Bu, RewriteMap ek belgelerinde daha ayrıntılı +olarak tartışılmaktadır.

+
+ +
.htaccess dosyaları + +

Yeniden yazma genellikle ana sunucu yapılandırma ayarında +(herhangi bir Directory bölümünün dışında) veya +VirtualHost +kapsayıcıları içinde yapılandırılır. Bu, yeniden yazma yapmanın en +kolay yoludur ve önerilir. Ancak yeniden yazmayı Directory bölümlerinde veya +.htaccess +dosyalarında bazı ek karmaşıklık pahasına yapmak mümkündür. Bu +tekniğe dizin başına yeniden yazma denir.

+ +

Sunucu başına yeniden yazmadan temel fark, .htaccess +dosyasını içeren dizinin yol önekinin, +RewriteRule yönergesinde +eşleştirmeden önce çıkarılmasıdır. Ayrıca, isteğin düzgün şekilde +eşlenmesini sağlamak için RewriteBase kullanılmalıdır.

+ +
+ +
diff --git a/docs/manual/rewrite/intro.xml.zh-cn b/docs/manual/rewrite/intro.xml.zh-cn new file mode 100644 index 0000000000..a584b9ee6b --- /dev/null +++ b/docs/manual/rewrite/intro.xml.zh-cn @@ -0,0 +1,372 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite 简介 + + +

本文档是 mod_rewrite +参考文档的补充。它描述了使用 +mod_rewrite 所需的基本概念。 +其他文档会更详细地介绍,但本文档应该能帮助初学者入门。 +

+
+ +模块文档 + +重定向和重映射 +访问控制 +虚拟主机 +代理 +使用 RewriteMap +高级技术 +何时不使用 mod_rewrite + +
介绍 +

Apache 模块 mod_rewrite 是一个非常强大且复杂的模块, +它提供了进行 URL 操作的方法。使用它,你几乎可以完成所有类型的 URL 重写。 +然而,它有一定的复杂性,可能会令初学者望而生畏。 +还有一种倾向是将重写规则视为魔法咒语,在不真正理解其作用的情况下使用它们。

+ +

本文档试图提供足够的背景知识,使接下来的内容被理解, +而不仅仅是盲目复制。 +

+ +

请记住,许多常见的 URL 操作任务不需要 mod_rewrite +的全部功能和复杂性。对于简单任务,请参阅 mod_alias +和关于将 URL 映射到文件系统的文档。

+ +

最后,在继续之前,请务必使用 +LogLevel +指令将 mod_rewrite 的日志级别配置为 trace 级别之一。 +虽然这可能会产生大量信息,但在调试 mod_rewrite +配置问题时它是不可或缺的,因为它会告诉你每条规则是如何被处理的。

+ +
+ +
正则表达式 + +

mod_rewrite 使用 Perl +兼容正则表达式词汇。在本文档中,我们不试图提供正则表达式的详细参考。 +为此,我们推荐 PCRE 手册页、 +Perl 正则表达式手册页 +以及 Jeffrey +Friedl 的《精通正则表达式》(第三版出版于 2006 年, +但正则表达式语法基本没有变化,它仍然是该主题的权威参考)。

+ +

在本文档中,我们试图提供足够的正则表达式词汇来帮助你入门, +而不会让你感到不知所措,希望 +RewriteRule +是科学公式,而不是魔法咒语。

+ +
正则表达式词汇 + +

以下是编写正则表达式和 +RewriteRule +所需的最基本构建块。它们当然不代表完整的正则表达式词汇, +但它们是一个好的起点,应该能帮助你阅读基本的正则表达式并编写自己的正则表达式。

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
字符含义示例
.匹配任意单个字符c.t 将匹配 cat、cot、 + cut 等
+重复前一个匹配一次或多次a+ 匹配 a、aa、 + aaa 等
*重复前一个匹配零次或多次a* 匹配 a+ 匹配的所有内容, + 但也会匹配空字符串
?使匹配变为可选colou?r 将匹配 color 和 + colour
\转义下一个字符\. 将匹配 .(点)而不是如上所述的 + 任意单个字符
^称为锚点,匹配字符串的开头^a 匹配以 a 开头的字符串
$另一个锚点,匹配字符串的结尾a$ 匹配以 a 结尾的字符串
( )将多个字符组合为一个单元,并捕获匹配以用于反向引用(ab)+ 匹配 ababab——即 + + 应用于整个组。关于反向引用的更多信息见 + 下文
[ ]字符类——匹配其中一个字符c[uoa]t 匹配 cut、cot 或 + cat
[^ ]否定字符类——匹配未指定的任意字符c[^/]t 匹配 cat 或 c=t + 但不匹配 c/t
+ +

在 mod_rewrite 中,! +字符可以在正则表达式前使用来否定它。也就是说, +只有当字符串不匹配表达式的其余部分时,才认为匹配成功。

+ +
+ +
正则表达式反向引用的可用性 + +

这里有一个重要的事情要记住:每当你在模式或某个 + CondPattern 中使用括号时,都会在内部创建反向引用, + 可以使用字符串 $N 和 %N(见下文)来引用。 + 这些可用于创建 + RewriteRule 的 + 替换参数或 + RewriteCond 的 + TestString 参数。

+

RewriteRule + 模式中的捕获(看似违反直觉地)可供所有前面的 + RewriteCond 指令使用, + 因为 RewriteRule + 表达式在各个条件之前就已被求值。

+ +

图 1 显示了反向引用被传递到哪些位置进行展开, + 并说明了 RewriteRule 和 RewriteCond 匹配的流程。 + 在接下来的章节中,我们将探索如何使用这些反向引用, + 所以如果你一开始觉得有些陌生,不必担心。 +

+ +

+ RewriteRule 和 RewriteCond 匹配流程
+ 图 1:反向引用在规则中的流向。
+ 在此示例中,对 /test/1234 的请求将被转换为 /admin.foo?page=test&id=1234&host=admin.example.com。 +

+ +
+
+ +
RewriteRule 基础 +

RewriteRule +由三个以空格分隔的参数组成。这些参数是:

+
    +
  1. Pattern:哪些传入的 URL 应受此规则影响;
  2. +
  3. Substitution:匹配的请求应被发送到哪里;
  4. +
  5. [flags]:影响重写请求的选项。
  6. +
+ +

Pattern 是一个正则表达式。 +它最初(对于第一条重写规则或直到发生替换为止)与传入请求的 URL 路径 +(主机名之后但问号之前的部分,问号表示查询字符串的开始)进行匹配, +或者在目录级上下文中与请求相对于定义规则的目录的路径进行匹配。 +一旦发生替换,后续规则将与替换后的值进行匹配。 +

+ +

+ RewriteRule 指令的语法
+ 图 2:RewriteRule 指令的语法。 +

+ + +

Substitution 本身可以是以下三种之一:

+ +
+
1. 资源的完整文件系统路径
+
+ +RewriteRule "^/games" "/usr/local/games/web/puzzles.html" + +

这将请求映射到文件系统上的任意位置, +类似于 Alias 指令。

+
+ +
2. 资源的 Web 路径
+
+ +RewriteRule "^/games$" "/puzzles.html" + +

如果 DocumentRoot 设置为 +/usr/local/apache2/htdocs,则此指令会将对 +http://example.com/games 的请求映射到路径 +/usr/local/apache2/htdocs/puzzles.html。

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

这告诉客户端对指定 URL 发出新的请求。

+
+
+ +请注意 1 和 2 +的语法完全相同。它们之间的区别在于,对于 1, +目标路径的顶层(即 /usr/)存在于文件系统上, +而对于 2,它不存在。 +(即文件系统中没有 /bar/ 作为根级目录。) + +

Substitution 还可以包含对传入 URL 路径中由 +Pattern 匹配的部分的反向引用。 +请看以下示例:

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

变量 $1 将被替换为 Pattern +中括号内的表达式所匹配的任何文本。例如,对 +http://example.com/product/r14df/view 的请求将被映射到路径 +/var/web/productdb/r14df。

+ +

如果括号中有多个表达式,它们将按顺序出现在变量 +$1、$2、$3 等中。

+ + +
+ +
重写标志 +

RewriteRule +的行为可以通过在规则末尾应用一个或多个标志来修改。 +例如,可以通过应用 [NC] +标志使规则的匹配行为不区分大小写: +

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

有关可用标志、其含义和示例的更多详细信息, +请参阅重写标志文档。

+ +
+ + +
重写条件 +

一个或多个 RewriteCond +指令可用于限制将受后续 +RewriteRule 影响的请求类型。 +第一个参数是描述请求特征的变量, +第二个参数是必须匹配该变量的正则表达式, +第三个可选参数是修改匹配评估方式的标志列表。

+ +

+ RewriteCond 指令的语法
+ 图 3:RewriteCond 指令的语法 +

+ +

例如,要将来自特定 IP 范围的所有请求发送到不同的服务器, +你可以使用:

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

当指定了多个 RewriteCond 时, +它们必须全部匹配才能应用 +RewriteRule。 +例如,要拒绝查询字符串中包含"hack"一词的请求, +除非它们还包含含有"go"一词的 cookie,你可以使用:

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

请注意,感叹号指定否定匹配, +因此只有当 cookie 不包含"go"时才应用该规则。

+ +

RewriteCond +中正则表达式的匹配结果可以作为 +RewriteRule 中 +Substitution 的一部分,使用变量 %1、 +%2 等。例如,这将根据用于访问站点的主机名 +将请求定向到不同的目录:

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

如果请求是 http://example.com/foo/bar, +则 %1 将包含 example.com, +$1 将包含 foo/bar。

+ + + +
+ +
重写映射 + +

RewriteMap +指令提供了一种调用外部函数来为你执行重写的方法。 +这在 RewriteMap 补充文档中有更详细的讨论。

+
+ +
.htaccess 文件 + +

重写通常在主服务器配置中(在任何 +Directory +配置段之外)或在 +VirtualHost +容器中配置。这是执行重写的最简单方式,也是推荐的方式。 +但是,也可以在 +Directory +配置段或 .htaccess +文件中执行重写,但会增加一些额外的复杂性。 +这种技术称为目录级重写。

+ +

与服务器级重写的主要区别在于, +包含 .htaccess 文件的目录路径前缀在 +RewriteRule +中匹配之前会被去除。此外,应使用 +RewriteBase +来确保请求被正确映射。

+ +
+ +
diff --git a/docs/manual/rewrite/proxy.xml.de b/docs/manual/rewrite/proxy.xml.de new file mode 100644 index 0000000000..5dedb4cc15 --- /dev/null +++ b/docs/manual/rewrite/proxy.xml.de @@ -0,0 +1,106 @@ + + + + + + + + + Rewrite + +Verwendung von mod_rewrite für Proxying + + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es beschreibt, +wie man das [P]-Flag der RewriteRule verwendet, um Inhalte an einen anderen +Server weiterzuleiten. Es werden verschiedene Rezepte bereitgestellt, die +gängige Szenarien beschreiben.

+ +
+Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung +Zugriffskontrolle +Virtuelle Hosts + +Verwendung von RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
+ + Proxying von Inhalten mit mod_rewrite + +
+
Beschreibung:
+ +
+

+ mod_rewrite bietet das [P]-Flag, mit dem URLs über + mod_proxy an einen anderen Server weitergeleitet werden + können. Hier werden zwei Beispiele gegeben. In einem Beispiel wird eine + URL direkt an einen anderen Server weitergeleitet und so ausgeliefert, + als wäre sie eine lokale URL. Im anderen Beispiel leiten wir fehlende + Inhalte an einen Backend-Server weiter.

+
+ +
Lösung:
+ +
+

Um eine URL einfach einem anderen Server zuzuordnen, verwenden + wir das [P]-Flag wie folgt:

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

Im zweiten Beispiel leiten wir die Anfrage nur weiter, wenn wir + die Ressource nicht lokal finden können. Dies kann sehr nützlich sein, + wenn Sie von einem Server zu einem anderen migrieren und sich nicht + sicher sind, ob alle Inhalte bereits migriert wurden.

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

In jedem Fall fügen wir eine ProxyPassReverse-Direktive hinzu, um + sicherzustellen, dass alle vom Backend ausgegebenen Umleitungen + korrekt an den Client weitergeleitet werden.

+ +

Erwägen Sie, wann immer möglich, ProxyPass oder ProxyPassMatch anstelle von + mod_rewrite zu verwenden.

+
+
+ +
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/proxy.xml.es b/docs/manual/rewrite/proxy.xml.es new file mode 100644 index 0000000000..c11807f1e6 --- /dev/null +++ b/docs/manual/rewrite/proxy.xml.es @@ -0,0 +1,104 @@ + + + + + + + + + Rewrite + +Uso de mod_rewrite para Proxy + + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +cómo usar la bandera [P] de RewriteRule para hacer proxy de contenido a otro servidor. +Se proporcionan varias recetas que describen escenarios comunes.

+ +
+Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo +Control de acceso +Hosts virtuales + +Uso de RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
+ + Hacer proxy de contenido con mod_rewrite + +
+
Descripción:
+ +
+

+ mod_rewrite proporciona la bandera [P], que permite pasar URLs, + a través de mod_proxy, a otro servidor. Aquí se dan dos ejemplos. En + un ejemplo, una URL se pasa directamente a otro servidor, y se sirve + como si fuera una URL local. En el otro ejemplo, hacemos proxy del + contenido faltante a un servidor backend.

+
+ +
Solución:
+ +
+

Para simplemente mapear una URL a otro servidor, usamos la bandera [P], de la + siguiente manera:

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

En el segundo ejemplo, hacemos proxy de la solicitud solo si no podemos encontrar + el recurso localmente. Esto puede ser muy útil cuando está migrando + de un servidor a otro, y no está seguro de si todo el contenido + ha sido migrado todavía.

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

En cada caso, añadimos una directiva ProxyPassReverse para asegurar + que cualquier redirección emitida por el backend se pase correctamente al + cliente.

+ +

Considere usar ProxyPass o ProxyPassMatch siempre que sea posible en + preferencia a mod_rewrite.

+
+
+ +
+ +
diff --git a/docs/manual/rewrite/proxy.xml.ja b/docs/manual/rewrite/proxy.xml.ja new file mode 100644 index 0000000000..94f6ab9511 --- /dev/null +++ b/docs/manual/rewrite/proxy.xml.ja @@ -0,0 +1,103 @@ + + + + + + + + + Rewrite + +mod_rewrite によるプロキシ + + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +RewriteRule の [P] フラグを使用して他のサーバにコンテンツをプロキシする方法を +説明します。一般的なシナリオを説明するレシピがいくつか提供されています。

+ +
+モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング +アクセス制御 +バーチャルホスト + +RewriteMap の使用 +高度なテクニック +mod_rewrite を使わない場合 + +
+ + mod_rewrite によるコンテンツのプロキシ + +
+
説明:
+ +
+

+ mod_rewrite は [P] フラグを提供しており、URL を + mod_proxy 経由で他のサーバに渡すことができます。ここでは + 2 つの例を示します。1 つ目の例では、URL を直接別のサーバに渡し、 + ローカル URL であるかのように提供します。もう 1 つの例では、 + 見つからないコンテンツをバックエンドサーバにプロキシします。

+
+ +
解決方法:
+ +
+

単純に URL を別のサーバにマッピングするには、次のように + [P] フラグを使用します:

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

2 つ目の例では、リソースがローカルに見つからない場合にのみ + リクエストをプロキシします。これは、あるサーバから別のサーバに + 移行中で、すべてのコンテンツが移行済みかどうかわからない場合に + 非常に便利です。

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

どちらの場合も、バックエンドから発行されるリダイレクトが + 正しくクライアントに渡されるように ProxyPassReverse ディレクティブを + 追加しています。

+ +

可能な限り mod_rewrite よりも ProxyPass や ProxyPassMatch の使用を検討してください。

+
+
+ +
+ +
diff --git a/docs/manual/rewrite/proxy.xml.ko b/docs/manual/rewrite/proxy.xml.ko new file mode 100644 index 0000000000..05ddd83907 --- /dev/null +++ b/docs/manual/rewrite/proxy.xml.ko @@ -0,0 +1,106 @@ + + + + + + + + + Rewrite + +프록시를 위한 mod_rewrite 사용 + + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +RewriteRule의 [P] 플래그를 사용하여 다른 서버로 콘텐츠를 +프록시하는 방법을 설명합니다. 일반적인 시나리오를 설명하는 +여러 레시피가 제공됩니다.

+ +
+모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 +접근 제어 +가상 호스트 + +RewriteMap 사용하기 +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
+ + mod_rewrite를 사용한 콘텐츠 프록시 + +
+
설명:
+ +
+

+ mod_rewrite는 [P] 플래그를 제공하여 + mod_proxy를 통해 URL을 다른 서버로 + 전달할 수 있게 합니다. 여기에 두 가지 예제가 있습니다. + 한 예제에서는 URL이 다른 서버로 직접 전달되어 로컬 + URL인 것처럼 제공됩니다. 다른 예제에서는 누락된 + 콘텐츠를 백엔드 서버로 프록시합니다.

+
+ +
해결책:
+ +
+

URL을 다른 서버에 단순히 매핑하려면 다음과 같이 + [P] 플래그를 사용합니다:

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

두 번째 예제에서는 로컬에서 자원을 찾을 수 없는 + 경우에만 요청을 프록시합니다. 이것은 한 서버에서 다른 + 서버로 마이그레이션하고 있으며 모든 콘텐츠가 아직 + 마이그레이션되었는지 확신할 수 없을 때 매우 유용합니다.

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

각 경우에 백엔드에서 발행한 리다이렉트가 클라이언트에 + 올바르게 전달되도록 ProxyPassReverse 지시어를 + 추가합니다.

+ +

mod_rewrite 대신 가능하면 + ProxyPass 또는 + ProxyPassMatch를 + 사용하는 것을 고려하십시오.

+
+
+ +
+ +
diff --git a/docs/manual/rewrite/proxy.xml.meta b/docs/manual/rewrite/proxy.xml.meta index 07ad4e7e07..9fbb14b781 100644 --- a/docs/manual/rewrite/proxy.xml.meta +++ b/docs/manual/rewrite/proxy.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/proxy.xml.tr b/docs/manual/rewrite/proxy.xml.tr new file mode 100644 index 0000000000..2e68ebd9c5 --- /dev/null +++ b/docs/manual/rewrite/proxy.xml.tr @@ -0,0 +1,105 @@ + + + + + + + + + Rewrite + +Vekil Kullanımı için mod_rewrite + + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +İçeriği başka bir sunucuya vekil olarak iletmek için RewriteRule'un [P] +bayrağının nasıl kullanılacağını açıklar. Yaygın senaryoları anlatan +birkaç tarif sunulmuştur.

+ +
+Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme +Erişim denetimi +Sanal konaklar + +RewriteMap Kullanımı +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
+ + mod_rewrite ile İçerik Vekilleme + +
+
Açıklama:
+ +
+

+ mod_rewrite, URL'lerin mod_proxy + aracılığıyla başka bir sunucuya iletilmesini sağlayan [P] bayrağını + sunar. Burada iki örnek verilmiştir. Birinde, bir URL doğrudan başka + bir sunucuya iletilir ve yerel bir URL gibi sunulur. Diğerinde, + eksik içeriği bir arka uç sunucusuna vekil olarak iletiriz.

+
+ +
Çözüm:
+ +
+

Bir URL'yi başka bir sunucuya basitçe eşlemek için [P] + bayrağını şu şekilde kullanırız:

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

İkinci örnekte, isteği yalnızca kaynağı yerel olarak + bulamadığımızda vekil olarak iletiriz. Bu, bir sunucudan diğerine + geçiş yaparken ve tüm içeriğin taşınıp taşınmadığından emin + olmadığınızda çok yararlı olabilir.

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

Her iki durumda da, arka uç tarafından verilen + yönlendirmelerin istemciye doğru şekilde iletilmesini sağlamak + için bir ProxyPassReverse + yönergesi ekliyoruz.

+ +

Mümkün olduğunda mod_rewrite yerine ProxyPass veya ProxyPassMatch kullanmayı + değerlendirin.

+
+
+ +
+ +
diff --git a/docs/manual/rewrite/proxy.xml.zh-cn b/docs/manual/rewrite/proxy.xml.zh-cn new file mode 100644 index 0000000000..dbc5d1f1ac --- /dev/null +++ b/docs/manual/rewrite/proxy.xml.zh-cn @@ -0,0 +1,100 @@ + + + + + + + + + Rewrite + +使用 mod_rewrite 进行代理 + + + +

本文档是 mod_rewrite +参考文档的补充。它描述了如何使用 +RewriteRule 的 [P] 标志将内容代理到另一台服务器。 +提供了若干描述常见场景的配置方案。

+ +
+模块文档 +mod_rewrite 简介 +重定向和重映射 +访问控制 +虚拟主机 + +使用 RewriteMap +高级技术 +何时不使用 mod_rewrite + +
+ + 使用 mod_rewrite 代理内容 + +
+
描述:
+ +
+

+ mod_rewrite 提供了 [P] 标志,允许 URL 通过 + mod_proxy 传递到另一台服务器。这里给出两个示例。 + 在一个示例中,URL 被直接传递到另一台服务器,并像本地 URL 一样提供服务。 + 在另一个示例中,我们将缺失的内容代理到后端服务器。

+
+ +
解决方案:
+ +
+

要简单地将 URL 映射到另一台服务器,我们使用 [P] 标志,如下所示:

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

在第二个示例中,我们仅在本地找不到资源时才代理请求。 + 当你从一台服务器迁移到另一台服务器,而不确定所有内容是否已迁移完毕时, + 这非常有用。

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

在每种情况下,我们都添加了一个 ProxyPassReverse 指令, + 以确保后端发出的任何重定向都能正确地传递给客户端。

+ +

请尽可能考虑使用 ProxyPass 或 ProxyPassMatch 来代替 + mod_rewrite。

+
+
+ +
+ +
diff --git a/docs/manual/rewrite/remapping.xml.de b/docs/manual/rewrite/remapping.xml.de new file mode 100644 index 0000000000..26ecac8a2e --- /dev/null +++ b/docs/manual/rewrite/remapping.xml.de @@ -0,0 +1,668 @@ + + + + + + + + + Rewrite + +Umleitung und Neuzuordnung mit mod_rewrite + + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es beschreibt, +wie Sie mod_rewrite verwenden können, um Anfragen +umzuleiten und neu zuzuordnen. Dies beinhaltet viele Beispiele für gängige +Verwendungen von mod_rewrite, einschließlich detaillierter +Beschreibungen, wie jedes einzelne funktioniert.

+ +Beachten Sie, dass viele dieser Beispiele nicht unverändert in Ihrer +speziellen Serverkonfiguration funktionieren werden. Es ist daher wichtig, dass Sie +sie verstehen, anstatt die Beispiele einfach auszuschneiden und in Ihre +Konfiguration einzufügen. + +
+Moduldokumentation +Einführung in mod_rewrite + +Zugriffskontrolle +Virtuelle Hosts +Proxying +Verwendung von RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
+ + Von Alt zu Neu (intern) + +
+
Beschreibung:
+ +
+

Angenommen, wir haben kürzlich die Seite + foo.html in bar.html umbenannt und + möchten nun die alte URL aus Gründen der Abwärtskompatibilität + weiterhin bereitstellen. Dabei sollen die Benutzer der alten URL + jedoch nicht bemerken, dass die Seite umbenannt wurde - das heißt, + die Adresse soll sich in ihrem Browser nicht ändern.

+
+ +
Lösung:
+ +
+

Wir schreiben die alte URL intern auf die neue um, mit der + folgenden Regel:

+ + +RewriteEngine on +RewriteRule "^/foo\.html$" "/bar.html" [PT] + +
+
+ +
+ +
+ + Umschreiben von Alt zu Neu (extern) + +
+
Beschreibung:
+ +
+

Angenommen erneut, dass wir kürzlich die Seite + foo.html in bar.html umbenannt haben und + nun die alte URL aus Gründen der Abwärtskompatibilität weiterhin + bereitstellen möchten. Diesmal möchten wir aber, dass die Benutzer + der alten URL auf die neue hingewiesen werden, d.h. die + Adresszeile ihres Browsers soll sich ebenfalls ändern.

+
+ +
Lösung:
+ +
+

Wir erzwingen eine HTTP-Umleitung auf die neue URL, was zu einer + Änderung der Browser-Adresszeile und damit der Ansicht der Benutzer + führt:

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

In diesem Beispiel können wir im Gegensatz zum + internen Beispiel oben einfach die + Redirect-Direktive verwenden. mod_rewrite wurde in + diesem früheren Beispiel verwendet, um die Umleitung vor dem Client + zu verbergen:

+ + +Redirect "/foo.html" "/bar.html" + + +
+
+ +
+ +
+ + Ressource auf einen anderen Server verschoben + +
+
Beschreibung:
+ +
+

Wenn eine Ressource auf einen anderen Server verschoben wurde, + möchten Sie möglicherweise, dass URLs für eine gewisse Zeit weiterhin + auf dem alten Server funktionieren, während die Benutzer ihre + Lesezeichen aktualisieren.

+
+ +
Lösung:
+ +
+

Sie können mod_rewrite verwenden, um diese URLs + auf den neuen Server umzuleiten, aber Sie könnten auch die Redirect- + oder RedirectMatch-Direktive in Betracht ziehen.

+ + +#Mit mod_rewrite +RewriteEngine on +RewriteRule "^/docs/(.+)" "http://new.example.com/docs/$1" [R,L] + + + +#Mit RedirectMatch +RedirectMatch "^/docs/(.*)" "http://new.example.com/docs/$1" + + + +#Mit Redirect +Redirect "/docs/" "http://new.example.com/docs/" + +
+
+ +
+ +
+ + Von statisch zu dynamisch + +
+
Beschreibung:
+ +
+

Wie können wir eine statische Seite + foo.html nahtlos in eine dynamische Variante + foo.cgi umwandeln, d.h. ohne dass der + Browser/Benutzer es bemerkt?

+
+ +
Lösung:
+ +
+

Wir schreiben die URL einfach auf das CGI-Skript um und + erzwingen, dass der Handler cgi-script ist, + damit es als CGI-Programm ausgeführt wird. So führt eine Anfrage + an /~quux/foo.html intern zum Aufruf von + /~quux/foo.cgi.

+ + +RewriteEngine on +RewriteBase "/~quux/" +RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script] + +
+
+ +
+ +
+ + Abwärtskompatibilität bei Änderung der Dateiendung + +
+
Beschreibung:
+ +
+

Wie können wir URLs abwärtskompatibel machen (virtuell weiterhin + existierend), nachdem document.YYYY zu + document.XXXX migriert wurde, z.B. nach der Konvertierung + einer Reihe von .html-Dateien nach .php?

+
+ +
Lösung:
+ +
+

Die URL wird nur dann von der alten auf die neue Endung + umgeschrieben, wenn die Zieldatei mit der neuen Endung existiert + und die Originaldatei mit der alten Endung nicht existiert. + Andernfalls bleibt die URL unverändert.

+ + +# Abwärtskompatibilitäts-Regelsatz für +# Umschreibung von document.html zu document.php +# wenn und nur wenn document.php existiert +<Directory "/var/www/htdocs"> + RewriteEngine on + RewriteBase "/var/www/htdocs" + + RewriteCond "$1.php" -f + RewriteCond "$1.html" !-f + RewriteRule "^(.*).html$" "$1.php" +</Directory> + +
+ +
Diskussion
+
+

Dieses Beispiel nutzt eine oft übersehene Funktion von + mod_rewrite, indem es die Ausführungsreihenfolge des + Regelsatzes ausnutzt. Insbesondere wertet mod_rewrite + die linke Seite der RewriteRule aus, bevor es die + RewriteCond-Direktiven auswertet. Folglich ist $1 bereits definiert, + wenn die RewriteCond-Direktiven ausgewertet werden. Dies ermöglicht + es uns, die Existenz der Original- (document.html) und + Zieldatei (document.php) unter Verwendung desselben + Basisdateinamens zu prüfen.

+ +

Dieser Regelsatz ist für die Verwendung im Verzeichniskontext + (in einem <Directory>-Block oder in einer .htaccess-Datei) + konzipiert, sodass die -f-Prüfungen im korrekten + Verzeichnispfad suchen. Möglicherweise müssen Sie eine RewriteBase-Direktive setzen, um das + Verzeichnis anzugeben, in dem Sie arbeiten.

+
+
+ +
+ +
+ +Kanonische Hostnamen + +
+
Beschreibung:
+ +
Das Ziel dieser Regel ist es, die Verwendung eines bestimmten + Hostnamens zu erzwingen, anstelle anderer Hostnamen, die für den + Zugriff auf dieselbe Website verwendet werden könnten. Wenn Sie + beispielsweise die Verwendung von www.example.com + anstelle von example.com erzwingen möchten, + können Sie eine Variante des folgenden Rezepts verwenden.
+ +
Lösung:
+ +
+ +

Der allerbeste Weg, dies zu lösen, verwendet gar nicht mod_rewrite, +sondern die Redirect-Direktive +in einem virtuellen Host für den nicht-kanonischen Hostnamen.

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

Alternativ können Sie dies mit der +If-Direktive +erreichen: (ab Version 2.4)

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

Oder, um beispielsweise einen Teil Ihrer Website auf HTTPS umzuleiten, +könnten Sie Folgendes tun:

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

Wenn Sie aus irgendeinem Grund dennoch mod_rewrite +verwenden möchten - zum Beispiel, wenn Sie dies mit einer größeren Menge +von RewriteRules benötigen - können Sie eines der folgenden Rezepte +verwenden.

+ +

Für Websites, die auf einem anderen Port als 80 laufen:

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

Und für eine Website auf Port 80:

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

+ Wenn Sie dies generisch für alle Domainnamen tun möchten - das + heißt, wenn Sie example.com für alle möglichen + Werte von example.com auf + www.example.com umleiten möchten, können Sie + das folgende Rezept verwenden:

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

Diese Regelsätze funktionieren sowohl in Ihrer + Hauptserverkonfigurationsdatei als auch in einer .htaccess-Datei, + die im DocumentRoot des Servers + abgelegt wird.

+
+
+ +
+ +
+ + Suche nach Seiten in mehr als einem Verzeichnis + +
+
Beschreibung:
+ +
+

Eine bestimmte Ressource könnte an einem von mehreren Orten + existieren, und wir möchten an diesen Orten nach der Ressource + suchen, wenn sie angefordert wird. Vielleicht haben wir kürzlich + unsere Verzeichnisstruktur umorganisiert und Inhalte auf mehrere + Orte verteilt.

+
+ +
Lösung:
+ +
+

Der folgende Regelsatz sucht in zwei Verzeichnissen nach der + Ressource und versucht, falls sie an keinem der beiden Orte + gefunden wird, sie einfach vom angeforderten Ort auszuliefern.

+ + +RewriteEngine on + +# zuerst versuchen, es in dir1/ zu finden... +# ...und wenn gefunden, anhalten und zufrieden sein: +RewriteCond "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}" -f +RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir1/$1" [L] + +# dann versuchen, es in dir2/ zu finden... +# ...und wenn gefunden, anhalten und zufrieden sein: +RewriteCond "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}" -f +RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir2/$1" [L] + +# sonst weiter zu anderen Alias- oder ScriptAlias-Direktiven usw. +RewriteRule "^" "-" [PT] + +
+
+ +
+ +
+ + Umleitung auf geografisch verteilte Server + +
+
Beschreibung:
+ +
+

Wir haben zahlreiche Spiegelserver unserer Website und möchten + Besucher auf denjenigen umleiten, der sich in dem Land befindet, in + dem sie sich aufhalten.

+
+ +
Lösung:
+ +
+

Anhand des Hostnamens des anfragenden Clients bestimmen wir, aus + welchem Land er kommt. Wenn wir keine Auflösung seiner IP-Adresse + durchführen können, greifen wir auf einen Standardserver zurück.

+

Wir verwenden eine RewriteMap-Direktive, + um eine Liste der gewünschten Server zu erstellen.

+ + +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## +
+
+ +
Diskussion
+
+ Dieser Regelsatz setzt voraus, dass + HostNameLookups auf on + gesetzt ist, was einen erheblichen Leistungseinbruch bedeuten kann. + +

Die RewriteCond-Direktive + erfasst den letzten Teil des Hostnamens des anfragenden Clients - den + Ländercode - und die nachfolgende RewriteRule verwendet diesen Wert, + um den entsprechenden Spiegelhost in der Map-Datei nachzuschlagen.

+
+
+ +
+ +
+ +Kanonische URLs + +
+
Beschreibung:
+ +
+

Auf manchen Webservern gibt es mehr als eine URL für eine + Ressource. Normalerweise gibt es kanonische URLs (die tatsächlich + verwendet und verteilt werden) und solche, die nur Abkürzungen, + interne Adressen usw. sind. Unabhängig davon, welche URL der + Benutzer mit der Anfrage angegeben hat, sollte er schließlich die + kanonische URL in der Adresszeile seines Browsers sehen.

+
+ +
Lösung:
+ +
+

Wir führen eine externe HTTP-Umleitung für alle nicht-kanonischen + URLs durch, um sie in der Adressanzeige des Browsers und für alle + nachfolgenden Anfragen zu korrigieren. Im folgenden Beispiel-Regelsatz + ersetzen wir /puppies und /canines + durch die kanonische URL /dogs.

+ + +RewriteRule "^/(puppies|canines)/(.*)" "/dogs/$2" [R] + +
+ +
Diskussion:
+
+ Dies sollte eigentlich mit Redirect- oder RedirectMatch-Direktiven + erreicht werden: + + +RedirectMatch "^/(puppies|canines)/(.*)" "/dogs/$2" + +
+
+ +
+ +
+ + Verschobenes <code>DocumentRoot</code> + +
+
Beschreibung:
+ +
+

Normalerweise entspricht das DocumentRoot +des Webservers direkt der URL "/". Aber oft sind diese Daten +nicht wirklich von höchster Priorität. Beispielsweise möchten Sie +vielleicht, dass Besucher beim ersten Betreten einer Website in ein +bestimmtes Unterverzeichnis /about/ geleitet werden. Dies +kann mit dem folgenden Regelsatz erreicht werden:

+
+ +
Lösung:
+ +
+

Wir leiten die URL / nach + /about/ um: +

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

Beachten Sie, dass dies auch mit der RedirectMatch-Direktive gehandhabt werden +kann:

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

Beachten Sie auch, dass das Beispiel nur die Stamm-URL umschreibt. +Das heißt, es schreibt eine Anfrage für http://example.com/ +um, aber nicht eine Anfrage für http://example.com/page.html. +Wenn Sie tatsächlich Ihr Document Root geändert haben - das heißt, wenn +alle Ihre Inhalte tatsächlich in diesem Unterverzeichnis +liegen - ist es wesentlich besser, einfach Ihre +DocumentRoot-Direktive zu ändern +oder alle Inhalte ein Verzeichnis nach oben zu verschieben, anstatt URLs +umzuschreiben.

+
+
+ +
+ +
+Fallback-Ressource + +
+
Beschreibung:
+
Sie möchten, dass eine einzelne Ressource (beispielsweise eine bestimmte +Datei wie index.php) alle Anfragen behandelt, die an ein bestimmtes +Verzeichnis gerichtet sind, mit Ausnahme derjenigen, die an eine vorhandene +Ressource wie ein Bild oder eine CSS-Datei gehen sollen.
+ +
Lösung:
+
+

Ab Version 2.2.16 sollten Sie hierfür die FallbackResource-Direktive verwenden:

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

In älteren Versionen von Apache oder wenn Ihre Anforderungen +komplizierter sind, können Sie eine Variante des folgenden +Umschreibungssatzes verwenden, um dasselbe zu erreichen:

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

Wenn Sie andererseits die angeforderte URI als Query-String-Argument +an index.php übergeben möchten, können Sie diese RewriteRule ersetzen +durch:

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

Beachten Sie, dass diese Regelsätze sowohl in einer +.htaccess-Datei als auch in einem <Directory>-Block +verwendet werden können.

+ +
+ +
+ +
+ +
+Query-String umschreiben + +
+
Beschreibung:
+
Sie möchten einen bestimmten Wert aus einem Query-String erfassen +und ihn entweder ersetzen oder in eine andere Komponente der URL +einbinden.
+ +
Lösungen:
+
+

Viele der Lösungen in diesem Abschnitt verwenden dieselbe Bedingung, +die den übereinstimmenden Wert in der Rückreferenz %2 belässt. %1 ist der +Anfang des Query-Strings (bis zum interessierenden Schlüssel) und %3 ist +der Rest. Diese Bedingung ist etwas komplex, um Flexibilität zu gewährleisten +und doppelte '&&' in den Ersetzungen zu vermeiden.

+
    +
  • Diese Lösung entfernt den übereinstimmenden Schlüssel und Wert: + + +# mykey=??? entfernen +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1?%1%3" + +
  • + +
  • Diese Lösung verwendet den erfassten Wert in der URL-Ersetzung + und verwirft den Rest des ursprünglichen Query-Strings durch Anhängen + eines '?': + + +# Vom Query-String in PATH_INFO kopieren +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1/products/%2/?" [PT] + +
  • + +
  • Diese Lösung prüft den erfassten Wert in einer nachfolgenden Bedingung: + + +# Den Wert von mykey im Query-String erfassen +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteCond "%2" !=not-so-secret-value +RewriteRule "(.*)" "-" [F] + +
  • + +
  • Diese Lösung zeigt die Umkehrung der vorherigen und kopiert + Pfadkomponenten (möglicherweise PATH_INFO) aus der URL in den + Query-String. + +# Die gewünschte URL könnte /products/kitchen-sink sein, und das Skript erwartet +# /path?products=kitchen-sink. +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT] + +
  • +
+ +
+ +
+
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/remapping.xml.es b/docs/manual/rewrite/remapping.xml.es new file mode 100644 index 0000000000..1aeb72109f --- /dev/null +++ b/docs/manual/rewrite/remapping.xml.es @@ -0,0 +1,657 @@ + + + + + + + + + Rewrite + +Redirección y Remapeo con mod_rewrite + + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +cómo puede usar mod_rewrite para redirigir y remapear +solicitudes. Esto incluye muchos ejemplos de usos comunes de mod_rewrite, +incluyendo descripciones detalladas de cómo funciona cada uno.

+ +Tenga en cuenta que muchos de estos ejemplos no funcionarán sin cambios en su +configuración particular del servidor, por lo que es importante que los +entienda, en lugar de simplemente copiar y pegar los ejemplos en su +configuración. + +
+Documentación del módulo +Introducción a mod_rewrite + +Control de acceso +Hosts virtuales +Proxy +Uso de RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
+ + De Antiguo a Nuevo (interno) + +
+
Descripción:
+ +
+

Supongamos que hemos renombrado recientemente la página + foo.html a bar.html y ahora queremos + proporcionar la antigua URL por compatibilidad hacia atrás. Sin embargo, + queremos que los usuarios de la antigua URL ni siquiera se den cuenta de que + la página fue renombrada - es decir, no queremos que la dirección + cambie en su navegador.

+
+ +
Solución:
+ +
+

Reescribimos la antigua URL a la nueva internamente mediante la + siguiente regla:

+ + +RewriteEngine on +RewriteRule "^/foo\.html$" "/bar.html" [PT] + +
+
+ +
+ +
+ + Reescritura de Antiguo a Nuevo (externo) + +
+
Descripción:
+ +
+

Supongamos de nuevo que hemos renombrado recientemente la página + foo.html a bar.html y ahora queremos + proporcionar la antigua URL por compatibilidad hacia atrás. Pero esta + vez queremos que los usuarios de la antigua URL reciban una indicación de + la nueva, es decir, que el campo de Ubicación de su navegador también + cambie.

+
+ +
Solución:
+ +
+

Forzamos una redirección HTTP a la nueva URL que lleva a un + cambio del navegador y por lo tanto de la vista del usuario:

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

En este ejemplo, a diferencia del ejemplo interno anterior, podemos simplemente + usar la directiva Redirect. mod_rewrite se usó en ese ejemplo + anterior para ocultar la redirección del cliente:

+ + +Redirect "/foo.html" "/bar.html" + + +
+
+ +
+ +
+ + Recurso Movido a Otro Servidor + +
+
Descripción:
+ +
+

Si un recurso se ha movido a otro servidor, puede desear que + las URLs continúen funcionando por un tiempo en el antiguo servidor mientras + la gente actualiza sus marcadores.

+
+ +
Solución:
+ +
+

Puede usar mod_rewrite para redirigir estas URLs + al nuevo servidor, pero también podría considerar usar la directiva Redirect + o RedirectMatch.

+ + +#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/" + +
+
+ +
+ +
+ + De Estático a Dinámico + +
+
Descripción:
+ +
+

¿Cómo podemos transformar una página estática + foo.html en una variante dinámica + foo.cgi de manera transparente, es decir, sin que + el navegador/usuario lo note.

+
+ +
Solución:
+ +
+

Simplemente reescribimos la URL al script CGI y forzamos el + manejador a ser cgi-script para que se + ejecute como un programa CGI. + De esta manera, una solicitud a /~quux/foo.html + internamente lleva a la invocación de + /~quux/foo.cgi.

+ + +RewriteEngine on +RewriteBase "/~quux/" +RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script] + +
+
+ +
+ +
+ + Compatibilidad hacia atrás para cambio de extensión de archivo + +
+
Descripción:
+ +
+

¿Cómo podemos hacer URLs retrocompatibles (aún + existentes virtualmente) después de migrar document.YYYY + a document.XXXX, por ejemplo, después de traducir un + grupo de archivos .html a .php?

+
+ +
Solución:
+ +
+

La URL se reescribe de la antigua extensión a la nueva + solo si el archivo destino con la nueva extensión existe + y el archivo original con la antigua extensión no existe. + De lo contrario, la URL se deja sin cambios.

+ + +# 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> + +
+ +
Discusión
+
+

Este ejemplo usa una característica a menudo pasada por alto de mod_rewrite, + aprovechando el orden de ejecución del conjunto de reglas. En + particular, mod_rewrite evalúa el lado izquierdo de la + RewriteRule antes de evaluar las directivas RewriteCond. + En consecuencia, $1 ya está definido para el momento en que las directivas + RewriteCond se evalúan. Esto nos permite probar la existencia + del archivo original (document.html) y destino + (document.php) usando el mismo nombre de archivo base.

+ +

Este conjunto de reglas está diseñado para usarse en un contexto per-directorio (en un + bloque <Directory> o en un archivo .htaccess), de modo que las + verificaciones -f busquen en la ruta de directorio correcta. + Puede necesitar establecer una directiva RewriteBase para especificar la + base de directorio en la que está trabajando.

+
+
+ +
+ +
+ +Nombres de Host Canónicos + +
+
Descripción:
+ +
El objetivo de esta regla es forzar el uso de un nombre de + host particular, en preferencia a otros nombres de host que pueden usarse para + alcanzar el mismo sitio. Por ejemplo, si desea forzar el uso + de www.example.com en lugar de + example.com, podría usar una variante de la + siguiente receta.
+ +
Solución:
+ +
+ +

La mejor manera de resolver esto no involucra mod_rewrite en absoluto, +sino que usa la directiva Redirect +colocada en un host virtual para el o los nombres de host no canónicos.

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

Alternativamente puede lograr esto usando la +directiva If: +(2.4 y posterior)

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

O, por ejemplo, para redirigir una porción de su sitio a HTTPS, podría +hacer lo siguiente:

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

Si, por cualquier razón, aún desea usar mod_rewrite +- si, por ejemplo, necesita que esto funcione con un conjunto más grande de RewriteRules - +podría usar una de las recetas siguientes.

+ +

Para sitios ejecutándose en un puerto distinto al 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] + + +

Y para un sitio ejecutándose en el puerto 80

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

+ Si quisiera hacer esto genéricamente para todos los nombres de dominio - es + decir, si quiere redirigir example.com a + www.example.com para todos los valores posibles de + example.com, podría usar la siguiente + receta:

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

Estos conjuntos de reglas funcionarán tanto en su archivo de configuración principal + del servidor, como en un archivo .htaccess colocado en el DocumentRoot del servidor.

+
+
+ +
+ +
+ + Búsqueda de páginas en más de un directorio + +
+
Descripción:
+ +
+

Un recurso particular podría existir en uno de varios lugares, y + queremos buscar en esos lugares el recurso cuando se + solicita. Quizás hemos reorganizado recientemente nuestra estructura de + directorios, dividiendo el contenido en varias ubicaciones.

+
+ +
Solución:
+ +
+

El siguiente conjunto de reglas busca en dos directorios para encontrar el + recurso, y, si no lo encuentra en ninguno de los dos, intentará + simplemente servirlo desde la ubicación solicitada.

+ + +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] + +
+
+ +
+ +
+ + Redirección a Servidores Distribuidos Geográficamente + +
+
Descripción:
+ +
+

Tenemos numerosos espejos de nuestro sitio web, y queremos redirigir + a la gente al que está ubicado en el país donde se + encuentran.

+
+ +
Solución:
+ +
+

Mirando el nombre de host del cliente solicitante, determinamos + de qué país provienen. Si no podemos hacer una búsqueda de su + dirección IP, recurrimos a un servidor predeterminado.

+

Usaremos una directiva RewriteMap + para construir una lista de servidores que deseamos usar.

+ + +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 -- Mapa de Multiplexación
+
+de http://www.example.de/
+uk http://www.example.uk/
+com http://www.example.com/
+##EOF## +
+
+ +
Discusión
+
+ Este conjunto de reglas depende de que + HostNameLookups + esté configurado como on, lo que puede ser + un impacto significativo en el rendimiento. + +

La directiva RewriteCond + captura la última parte del nombre de host del + cliente solicitante - el código de país - y la siguiente RewriteRule + usa ese valor para buscar el host espejo apropiado en el archivo + de mapa.

+
+
+ +
+ +
+ +URLs Canónicas + +
+
Descripción:
+ +
+

En algunos servidores web hay más de una URL para un + recurso. Generalmente hay URLs canónicas (que son las que realmente + se usan y distribuyen) y aquellas que son solo + atajos, internas, etc. Independientemente de qué URL + proporcionó el usuario con la solicitud, finalmente debería ver la + canónica en la barra de direcciones de su navegador.

+
+ +
Solución:
+ +
+

Hacemos una redirección HTTP externa para todas las + URLs no canónicas para corregirlas en la vista de ubicación del navegador y + para todas las solicitudes posteriores. En el conjunto de reglas de ejemplo + reemplazamos /puppies y /canines + por el canónico /dogs.

+ + +RewriteRule "^/(puppies|canines)/(.*)" "/dogs/$2" [R] + +
+ +
Discusión:
+
+ Esto realmente debería lograrse con directivas Redirect o RedirectMatch: + + +RedirectMatch "^/(puppies|canines)/(.*)" "/dogs/$2" + +
+
+ +
+ +
+ + <code>DocumentRoot</code> Movido + +
+
Descripción:
+ +
+

Generalmente el DocumentRoot +del servidor web se relaciona directamente con la URL "/". +Pero a menudo estos datos no son realmente de máxima prioridad. Por ejemplo, +puede desear que los visitantes, al entrar por primera vez a un sitio, vayan a un +subdirectorio particular /about/. Esto puede lograrse +usando el siguiente conjunto de reglas:

+
+ +
Solución:
+ +
+

Redirigimos la URL / a + /about/: +

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

Tenga en cuenta que esto también puede manejarse usando la directiva RedirectMatch:

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

Tenga en cuenta también que el ejemplo solo reescribe la URL raíz. Es decir, reescribe +una solicitud para http://example.com/, pero no una +solicitud para http://example.com/page.html. Si de hecho ha +cambiado la raíz de documentos - es decir, si todo su +contenido está en ese subdirectorio, es muy preferible +simplemente cambiar su directiva DocumentRoot, +o mover todo el contenido un directorio arriba, +en lugar de reescribir URLs.

+
+
+ +
+ +
+Recurso de Respaldo + +
+
Descripción:
+
Desea que un solo recurso (digamos, un cierto archivo, como index.php) maneje +todas las solicitudes que lleguen a un directorio particular, excepto aquellas +que deberían ir a un recurso existente como una imagen, o un archivo css.
+ +
Solución:
+
+

A partir de la versión 2.2.16, debería usar la directiva FallbackResource para esto:

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

Sin embargo, en versiones anteriores de Apache, o si sus necesidades son más +complicadas que esto, puede usar una variación del siguiente conjunto de +reescritura para lograr lo mismo:

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

Si, por otro lado, desea pasar la URI solicitada como un argumento de +cadena de consulta a index.php, puede reemplazar esa RewriteRule con:

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

Tenga en cuenta que estos conjuntos de reglas pueden usarse en un archivo .htaccess, +así como en un bloque <Directory>.

+ +
+ +
+ +
+ +
+Reescribir cadena de consulta + +
+
Descripción:
+
Desea capturar un valor particular de una cadena de consulta +y reemplazarlo o incorporarlo en otro componente +de la URL.
+ +
Soluciones:
+
+

Muchas de las soluciones en esta sección usarán la misma condición, +que deja el valor coincidente en la referencia inversa %2. %1 es el inicio +de la cadena de consulta (hasta la clave de interés), y %3 es el resto. Esta +condición es un poco compleja por flexibilidad y para evitar doble '&&' en las +sustituciones.

+
    +
  • Esta solución elimina la clave y valor coincidentes: + + +# Remove mykey=??? +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1?%1%3" + +
  • + +
  • Esta solución usa el valor capturado en la sustitución de URL, + descartando el resto de la consulta original añadiendo un '?': + + +# Copy from query string to PATH_INFO +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1/products/%2/?" [PT] + +
  • + +
  • Esta solución verifica el valor capturado en una condición posterior: + + +# Capture the value of mykey in the query string +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteCond "%2" !=not-so-secret-value +RewriteRule "(.*)" "-" [F] + +
  • + +
  • Esta solución muestra lo inverso de las anteriores, copiando + componentes de ruta (quizás PATH_INFO) de la URL a la cadena de consulta. + +# The desired URL might be /products/kitchen-sink, and the script expects +# /path?products=kitchen-sink. +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT] + +
  • +
+ +
+ +
+
+ + +
diff --git a/docs/manual/rewrite/remapping.xml.ja b/docs/manual/rewrite/remapping.xml.ja new file mode 100644 index 0000000000..9febb2c25d --- /dev/null +++ b/docs/manual/rewrite/remapping.xml.ja @@ -0,0 +1,648 @@ + + + + + + + + + Rewrite + +mod_rewrite によるリダイレクトとリマッピング + + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +mod_rewrite を使用してリクエストをリダイレクトおよびリマッピング +する方法を説明します。mod_rewrite の一般的な使用例を多数含んでおり、 +それぞれの動作についての詳細な説明も含まれています。

+ +これらの例の多くは、特定のサーバ設定ではそのまま +動作しないことに注意してください。そのため、単にコピー&ペーストするのではなく、 +内容を理解することが重要です。 + +
+モジュールドキュメント +mod_rewrite 入門 + +アクセス制御 +バーチャルホスト +プロキシ +RewriteMap の使用 +高度なテクニック +mod_rewrite を使わない場合 + +
+ + 旧 URL から新 URL へ (内部) + +
+
説明:
+ +
+

最近ページ foo.html を bar.html に + リネームし、後方互換性のために旧 URL も提供したいとします。 + ただし、旧 URL のユーザにはページがリネームされたことを + 気づかせたくありません - つまり、ブラウザのアドレスが + 変更されないようにします。

+
+ +
解決方法:
+ +
+

以下のルールで旧 URL を内部的に新しいものに書き換えます:

+ + +RewriteEngine on +RewriteRule "^/foo\.html$" "/bar.html" [PT] + +
+
+ +
+ +
+ + 旧 URL から新 URL への書き換え (外部) + +
+
説明:
+ +
+

再び、最近ページ foo.html を bar.html + にリネームし、後方互換性のために旧 URL を提供したいとします。 + しかし今回は、旧 URL のユーザに新しい URL を知らせたい、 + つまりブラウザの Location フィールドも変更されるようにしたいとします。

+
+ +
解決方法:
+ +
+

新しい URL への HTTP リダイレクトを強制し、ブラウザと + ユーザの表示を変更します:

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

この例では、上記の内部の例と + 対比して、単純に Redirect ディレクティブを使用できます。 + mod_rewrite は、前の例でクライアントからリダイレクトを + 隠すために使用されました:

+ + +Redirect "/foo.html" "/bar.html" + + +
+
+ +
+ +
+ + リソースの別サーバへの移動 + +
+
説明:
+ +
+

リソースが別のサーバに移動した場合、人々がブックマークを + 更新する間、旧サーバでも URL がしばらく機能し続けるように + したいとします。

+
+ +
解決方法:
+ +
+

mod_rewrite を使用してこれらの URL を新しいサーバに + リダイレクトできますが、Redirect や RedirectMatch ディレクティブの + 使用も検討してください。

+ + +#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/" + +
+
+ +
+ +
+ + 静的から動的へ + +
+
説明:
+ +
+

静的ページ foo.html を動的バリアント + foo.cgi にシームレスに、つまりブラウザ/ユーザに + 気づかれずに変換するにはどうすればよいでしょうか。

+
+ +
解決方法:
+ +
+

URL を CGI スクリプトに書き換え、ハンドラを + cgi-script に強制して、CGI プログラムとして + 実行されるようにします。 + これにより、/~quux/foo.html へのリクエストは + 内部的に /~quux/foo.cgi の呼び出しに + つながります。

+ + +RewriteEngine on +RewriteBase "/~quux/" +RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script] + +
+
+ +
+ +
+ + ファイル拡張子変更の後方互換性 + +
+
説明:
+ +
+

document.YYYY から document.XXXX への + 移行後、例えば .html ファイル群を .php に + 変換した後に、URL の後方互換性 (仮想的にまだ存在する状態) を + どのように保つことができるでしょうか?

+
+ +
解決方法:
+ +
+

URL は旧拡張子から新拡張子に書き換えられますが、新拡張子の + ターゲットファイルが存在し、かつ旧拡張子の元のファイルが + 存在しない場合のみです。それ以外の場合、URL はそのまま + 変更されません。

+ + +# 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> + +
+ +
議論
+
+

この例では、mod_rewrite のあまり知られていない + 機能を利用しています。ルールセットの実行順序を活用しています。 + 具体的には、mod_rewrite は RewriteCond ディレクティブを + 評価する前に RewriteRule の左辺を評価します。 + そのため、RewriteCond ディレクティブが評価される時点で + $1 はすでに定義されています。これにより、同じベースファイル名を使用して + 元のファイル (document.html) とターゲットファイル + (document.php) の存在を確認できます。

+ +

このルールセットはディレクトリ単位のコンテキスト + (<Directory> ブロックまたは .htaccess ファイル内) で + 使用するよう設計されているため、-f チェックは + 正しいディレクトリパスを参照します。作業しているディレクトリベースを + 指定するために RewriteBase + ディレクティブを設定する必要があるかもしれません。

+
+
+ +
+ +
+ +正規ホスト名 + +
+
説明:
+ +
このルールの目的は、同じサイトに到達するために使用される + 可能性のある他のホスト名よりも、特定のホスト名の使用を強制 + することです。例えば、example.com の代わりに + www.example.com の使用を強制したい場合は、 + 以下のレシピのバリアントを使用できます。
+ +
解決方法:
+ +
+ +

最善の方法は mod_rewrite をまったく使わず、 +非正規のホスト名用のバーチャルホストに配置した Redirect ディレクティブを使用する +ことです。

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

あるいは、If +ディレクティブを使用して実現することもできます: +(2.4 以降)

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

あるいは、例えばサイトの一部を HTTPS にリダイレクトするには、 +以下のようにします:

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

何らかの理由でまだ mod_rewrite を使用したい場合 - +例えば、より大きな RewriteRule のセットと組み合わせる必要がある場合 - +以下のレシピのいずれかを使用できます。

+ +

ポート 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] + + +

ポート 80 で実行されているサイトの場合:

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

+ すべてのドメイン名に対してこれを汎用的に行いたい場合 - + つまり、example.com のすべての可能な値に対して + example.com を www.example.com + にリダイレクトしたい場合 - 以下のレシピを使用できます:

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

これらのルールセットは、メインサーバ設定ファイルまたはサーバの + DocumentRoot に配置した + .htaccess ファイルのいずれでも動作します。

+
+
+ +
+ +
+ + 複数のディレクトリでのページ検索 + +
+
説明:
+ +
+

特定のリソースが複数の場所に存在する可能性があり、 + リクエスト時にそれらの場所でリソースを検索したいとします。 + おそらく最近ディレクトリ構造を再編成し、コンテンツを + 複数の場所に分割したためです。

+
+ +
解決方法:
+ +
+

以下のルールセットは 2 つのディレクトリでリソースを検索し、 + どちらにも見つからない場合は、リクエストされた場所からそのまま + 提供しようとします。

+ + +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] + +
+
+ +
+ +
+ + 地理的に分散されたサーバへのリダイレクト + +
+
説明:
+ +
+

ウェブサイトの多数のミラーがあり、アクセス元の国に最も近い + ミラーにリダイレクトしたいとします。

+
+ +
解決方法:
+ +
+

リクエスト元のクライアントのホスト名を参照して、どの国から + アクセスしているかを判定します。IP アドレスの検索ができない場合は、 + デフォルトサーバにフォールバックします。

+

使用したいサーバのリストを構築するために RewriteMap ディレクティブを + 使用します。

+ + +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 -- マルチプレクシングマップ
+
+de http://www.example.de/
+uk http://www.example.uk/
+com http://www.example.com/
+##EOF## +
+
+ +
議論
+
+ このルールセットは + HostNameLookups が + on に設定されていることに依存しており、 + パフォーマンスに大きな影響を与える可能性があります。 + +

RewriteCond + ディレクティブは、リクエスト元のクライアントのホスト名の最後の + 部分 (国コード) をキャプチャし、後続の RewriteRule はその値を + 使用してマップファイルから適切なミラーホストを検索します。

+
+
+ +
+ +
+ +正規 URL + +
+
説明:
+ +
+

一部のウェブサーバでは、リソースに対して複数の URL が存在します。 + 通常、正規の URL (実際に使用および配布される URL) と、単なる + ショートカット、内部用の URL 等があります。ユーザがリクエストで + どの URL を提供したかに関係なく、最終的にブラウザのアドレスバーに + 正規の URL が表示されるようにしたいとします。

+
+ +
解決方法:
+ +
+

すべての非正規 URL に対して外部 HTTP リダイレクトを行い、 + ブラウザの表示を修正し、以降のすべてのリクエストに反映させます。 + 以下のルールセット例では、/puppies と + /canines を正規の /dogs に + 置き換えます。

+ + +RewriteRule "^/(puppies|canines)/(.*)" "/dogs/$2" [R] + +
+ +
議論:
+
+ これは実際には Redirect または RedirectMatch ディレクティブで + 実現すべきです: + + +RedirectMatch "^/(puppies|canines)/(.*)" "/dogs/$2" + +
+
+ +
+ +
+ + <code>DocumentRoot</code> の移動 + +
+
説明:
+ +
+

通常、ウェブサーバの DocumentRoot +は URL "/" に直接対応します。 +しかし、このデータが最優先ではない場合も多くあります。例えば、 +訪問者がサイトに最初にアクセスしたときに特定のサブディレクトリ +/about/ に移動させたい場合があります。これは以下の +ルールセットで実現できます:

+
+ +
解決方法:
+ +
+

URL / を /about/ にリダイレクトします: +

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

これは RedirectMatch +ディレクティブでも処理できることに注意してください:

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

この例はルート URL のみを書き換えることに注意してください。つまり、 +http://example.com/ へのリクエストは書き換えますが、 +http://example.com/page.html へのリクエストは書き換えません。 +実際にドキュメントルートを変更した場合 - つまり、コンテンツの +すべてが実際にそのサブディレクトリにある場合 - URL を +書き換えるよりも、単に DocumentRoot +ディレクティブを変更するか、すべてのコンテンツを 1 つ上のディレクトリに +移動する方がはるかに望ましいです。

+
+
+ +
+ +
+フォールバックリソース + +
+
説明:
+
特定のディレクトリに来るすべてのリクエストを単一のリソース +(例えば特定のファイル、index.php など) で処理したいが、 +画像や CSS ファイルなどの既存のリソースへのリクエストは +そのまま処理したいとします。
+ +
解決方法:
+
+

バージョン 2.2.16 以降では、このために FallbackResource ディレクティブを +使用してください:

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

ただし、以前のバージョンの Apache や、これよりも複雑なニーズがある +場合は、以下の書き換えセットのバリエーションを使用して同じことを +実現できます:

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

一方、リクエストされた URI をクエリ文字列引数として index.php に +渡したい場合は、その RewriteRule を以下に置き換えることができます:

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

これらのルールセットは .htaccess ファイルでも +<Directory> ブロックでも使用できることに注意してください。

+ +
+ +
+ +
+ +
+クエリ文字列の書き換え + +
+
説明:
+
クエリ文字列から特定の値をキャプチャし、それを置換するか +URL の別のコンポーネントに組み込みたいとします。
+ +
解決方法:
+
+

このセクションの多くの解決方法は同じ条件を使用し、マッチした値を +%2 バックリファレンスに残します。%1 はクエリ文字列の先頭 (対象キーまで)、 +%3 は残りの部分です。この条件は、柔軟性のため、また置換で二重の +'&&' を避けるためにやや複雑です。

+
    +
  • この方法はマッチするキーと値を削除します: + + +# Remove mykey=??? +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1?%1%3" + +
  • + +
  • この方法はキャプチャした値を URL 置換で使用し、'?' を追加して + 元のクエリの残りを破棄します: + + +# Copy from query string to PATH_INFO +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1/products/%2/?" [PT] + +
  • + +
  • この方法は後続の条件でキャプチャした値を確認します: + + +# Capture the value of mykey in the query string +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteCond "%2" !=not-so-secret-value +RewriteRule "(.*)" "-" [F] + +
  • + +
  • この方法は前の方法の逆で、URL からパスコンポーネント + (おそらく PATH_INFO) をクエリ文字列にコピーします: + +# The desired URL might be /products/kitchen-sink, and the script expects +# /path?products=kitchen-sink. +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT] + +
  • +
+ +
+ +
+
+ + +
diff --git a/docs/manual/rewrite/remapping.xml.ko b/docs/manual/rewrite/remapping.xml.ko new file mode 100644 index 0000000000..2872ace4de --- /dev/null +++ b/docs/manual/rewrite/remapping.xml.ko @@ -0,0 +1,662 @@ + + + + + + + + + Rewrite + +mod_rewrite를 사용한 리다이렉션과 재매핑 + + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +mod_rewrite를 사용하여 요청을 리다이렉트하고 +재매핑하는 방법을 설명합니다. 여기에는 +mod_rewrite의 일반적인 사용 예제가 많이 +포함되어 있으며, 각각이 어떻게 작동하는지에 대한 자세한 +설명이 있습니다.

+ +이 예제들 중 많은 것이 특정 서버 설정에서 +그대로 작동하지 않을 수 있으므로, 단순히 예제를 복사하여 +설정에 붙여넣기보다는 이해하는 것이 중요합니다. + +
+모듈 문서 +mod_rewrite 소개 + +접근 제어 +가상 호스트 +프록시 +RewriteMap 사용하기 +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
+ + 이전에서 새로운 것으로 (내부) + +
+
설명:
+ +
+

최근에 foo.html 페이지를 + bar.html로 이름을 변경했고 이전 URL을 + 하위 호환성을 위해 제공하고자 한다고 가정합니다. + 그러나 이전 URL의 사용자가 페이지 이름이 변경된 것을 + 인식하지 못하게 하고 싶습니다. 즉, 브라우저에서 + 주소가 변경되지 않아야 합니다.

+
+ +
해결책:
+ +
+

다음 규칙을 통해 이전 URL을 새 URL로 내부적으로 + 재작성합니다:

+ + +RewriteEngine on +RewriteRule "^/foo\.html$" "/bar.html" [PT] + +
+
+ +
+ +
+ + 이전에서 새로운 것으로 재작성 (외부) + +
+
설명:
+ +
+

다시 최근에 foo.html 페이지를 + bar.html로 이름을 변경했고 이전 URL을 + 하위 호환성을 위해 제공하고자 한다고 가정합니다. + 그러나 이번에는 이전 URL의 사용자에게 새 URL을 + 알려주고 싶습니다. 즉, 브라우저의 위치 필드도 + 변경되어야 합니다.

+
+ +
해결책:
+ +
+

브라우저와 사용자의 보기를 변경하는 새 URL로의 + HTTP 리다이렉트를 강제합니다:

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

이 예제에서는 위의 내부 + 예제와 대조적으로 단순히 Redirect 지시어를 사용할 수 + 있습니다. mod_rewrite는 클라이언트로부터 + 리다이렉트를 숨기기 위해 이전 예제에서 사용되었습니다:

+ + +Redirect "/foo.html" "/bar.html" + + +
+
+ +
+ +
+ + 다른 서버로 이동한 자원 + +
+
설명:
+ +
+

자원이 다른 서버로 이동한 경우, 사람들이 북마크를 + 업데이트하는 동안 이전 서버에서 URL이 한동안 계속 + 작동하기를 원할 수 있습니다.

+
+ +
해결책:
+ +
+

mod_rewrite를 사용하여 이러한 URL을 + 새 서버로 리다이렉트할 수 있지만, Redirect 또는 + RedirectMatch 지시어를 사용하는 것도 고려할 수 + 있습니다.

+ + +#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/" + +
+
+ +
+ +
+ + 정적에서 동적으로 + +
+
설명:
+ +
+

정적 페이지 foo.html을 동적 변형인 + foo.cgi로 브라우저/사용자가 인식하지 + 못하도록 매끄럽게 변환하는 방법입니다.

+
+ +
해결책:
+ +
+

URL을 CGI 스크립트로 재작성하고 핸들러를 + cgi-script로 강제하여 CGI 프로그램으로 + 실행합니다. 이렇게 하면 /~quux/foo.html에 + 대한 요청이 내부적으로 /~quux/foo.cgi의 + 호출로 이어집니다.

+ + +RewriteEngine on +RewriteBase "/~quux/" +RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script] + +
+
+ +
+ +
+ + 파일 확장자 변경에 대한 하위 호환성 + +
+
설명:
+ +
+

document.YYYY에서 + document.XXXX로 마이그레이션한 후, + 예를 들어 .html 파일 묶음을 + .php로 변환한 후, URL을 하위 호환되게 + (여전히 가상으로 존재) 만드는 방법은 무엇입니까?

+
+ +
해결책:
+ +
+

새 확장자를 가진 대상 파일이 존재하고 이전 + 확장자를 가진 원래 파일이 존재하지 않는 경우에만 + 이전 확장자에서 새 확장자로 URL을 재작성합니다. + 그렇지 않으면 URL은 변경되지 않습니다.

+ + +# 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> + +
+ +
토론
+
+

이 예제는 mod_rewrite의 종종 간과되는 + 기능을 사용하며, 규칙 세트의 실행 순서를 활용합니다. + 특히 mod_rewrite는 RewriteCond 지시어를 + 평가하기 전에 RewriteRule의 왼쪽을 먼저 평가합니다. + 따라서 RewriteCond 지시어가 평가될 때 $1이 이미 + 정의됩니다. 이를 통해 동일한 기본 파일명을 사용하여 + 원본(document.html)과 대상 + (document.php) 파일의 존재를 테스트할 수 + 있습니다.

+ +

이 규칙 세트는 디렉토리별 컨텍스트(<Directory> + 블록 또는 .htaccess 파일)에서 사용하도록 설계되어 + -f 검사가 올바른 디렉토리 경로를 확인합니다. + 작업 중인 디렉토리 기본을 지정하기 위해 RewriteBase 지시어를 + 설정해야 할 수 있습니다.

+
+
+ +
+ +
+ +정규 호스트명 + +
+
설명:
+ +
이 규칙의 목표는 사이트에 도달하는 데 사용할 수 + 있는 다른 호스트명 대신 특정 호스트명의 사용을 + 강제하는 것입니다. 예를 들어, + example.com 대신 + www.example.com의 사용을 강제하려면 + 다음 레시피의 변형을 사용할 수 있습니다.
+ +
해결책:
+ +
+ +

이를 해결하는 가장 좋은 방법은 mod_rewrite를 +전혀 사용하지 않고, 비정규 호스트명에 대한 가상 호스트에 +Redirect 지시어를 +배치하는 것입니다.

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

If +지시어를 사용하여 이를 수행할 수도 있습니다: +(2.4 이상)

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

또는 예를 들어 사이트의 일부를 HTTPS로 리다이렉트하려면 +다음과 같이 할 수 있습니다:

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

어떤 이유로든 여전히 mod_rewrite를 +사용하고 싶다면 - 예를 들어, 더 큰 RewriteRules 세트와 +함께 사용해야 하는 경우 - 아래 레시피 중 하나를 사용할 수 +있습니다.

+ +

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

그리고 포트 80에서 실행되는 사이트의 경우:

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

+ 모든 도메인 이름에 대해 이를 일반적으로 수행하고 + 싶다면 - 즉, 모든 가능한 값의 + example.com에 대해 + example.com을 + www.example.com으로 리다이렉트하려면 + 다음 레시피를 사용할 수 있습니다:

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

이 규칙 세트는 주 서버 설정 파일이나 서버의 + DocumentRoot에 놓인 + .htaccess 파일에서 모두 작동합니다.

+
+
+ +
+ +
+ + 여러 디렉토리에서 페이지 검색 + +
+
설명:
+ +
+

특정 자원이 여러 위치 중 하나에 존재할 수 있으며, + 요청 시 해당 위치에서 자원을 찾고자 합니다. 아마도 + 최근에 디렉토리 구조를 재편하여 콘텐츠를 여러 + 위치로 나누었을 것입니다.

+
+ +
해결책:
+ +
+

다음 규칙 세트는 두 디렉토리에서 자원을 검색하고, + 어느 곳에서도 찾지 못하면 요청된 위치에서 그대로 + 제공하려고 시도합니다.

+ + +RewriteEngine on + +# 먼저 dir1/에서 찾아봅니다... +# ...찾으면 멈추고 만족합니다: +RewriteCond "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}" -f +RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir1/$1" [L] + +# 다음으로 dir2/에서 찾아봅니다... +# ...찾으면 멈추고 만족합니다: +RewriteCond "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}" -f +RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir2/$1" [L] + +# 그렇지 않으면 다른 Alias 또는 ScriptAlias 지시어 등을 +# 위해 계속합니다. +RewriteRule "^" "-" [PT] + +
+
+ +
+ +
+ + 지리적으로 분산된 서버로의 리다이렉션 + +
+
설명:
+ +
+

웹사이트의 여러 미러가 있으며, 사용자가 위치한 + 국가에 있는 미러로 사용자를 리다이렉트하고자 합니다.

+
+ +
해결책:
+ +
+

요청하는 클라이언트의 호스트명을 확인하여 어느 + 국가에서 오는지 판단합니다. IP 주소 조회가 불가능한 + 경우 기본 서버로 폴백합니다.

+

RewriteMap + 지시어를 사용하여 사용할 서버 목록을 작성합니다.

+ + +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 -- 멀티플렉싱 맵
+
+de http://www.example.de/
+uk http://www.example.uk/
+com http://www.example.com/
+##EOF## +
+
+ +
토론
+
+ 이 규칙 세트는 + HostNameLookups가 + on으로 설정되어 있어야 하며, 이는 상당한 + 성능 저하를 초래할 수 있습니다. + +

RewriteCond + 지시어는 요청하는 클라이언트의 호스트명의 마지막 + 부분인 국가 코드를 캡처하고, 다음 RewriteRule은 + 해당 값을 사용하여 맵 파일에서 적절한 미러 호스트를 + 조회합니다.

+
+
+ +
+ +
+ +정규 URL + +
+
설명:
+ +
+

일부 웹 서버에는 하나의 자원에 대해 둘 이상의 + URL이 있습니다. 보통 실제로 사용되고 배포되는 + 정규 URL이 있고, 단축키, 내부용 등의 URL이 있습니다. + 사용자가 요청과 함께 어떤 URL을 제공했는지에 + 관계없이 최종적으로 브라우저 주소 표시줄에 + 정규 URL이 표시되어야 합니다.

+
+ +
해결책:
+ +
+

모든 비정규 URL에 대해 외부 HTTP 리다이렉트를 + 수행하여 브라우저의 위치 보기와 모든 후속 요청에서 + 이를 수정합니다. 아래 예제 규칙 세트에서 + /puppies와 /canines를 + 정규 /dogs로 대체합니다.

+ + +RewriteRule "^/(puppies|canines)/(.*)" "/dogs/$2" [R] + +
+ +
토론:
+
+ 이것은 실제로 Redirect 또는 RedirectMatch 지시어로 + 수행해야 합니다: + + +RedirectMatch "^/(puppies|canines)/(.*)" "/dogs/$2" + +
+
+ +
+ +
+ + 이동된 <code>DocumentRoot</code> + +
+
설명:
+ +
+

보통 웹 서버의 DocumentRoot는 +URL "/"에 직접 관련됩니다. 그러나 종종 이 데이터는 +실제로 최상위 우선 순위가 아닙니다. 예를 들어, 사이트에 +처음 방문하는 방문자가 특정 하위 디렉토리 +/about/으로 이동하기를 원할 수 있습니다. +다음 규칙 세트를 사용하여 이를 수행할 수 있습니다:

+
+ +
해결책:
+ +
+

URL /를 /about/으로 + 리다이렉트합니다:

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

이것은 RedirectMatch +지시어를 사용하여도 처리할 수 있습니다:

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

또한 이 예제는 루트 URL만 재작성합니다. 즉, +http://example.com/에 대한 요청만 재작성하고 +http://example.com/page.html에 대한 요청은 +재작성하지 않습니다. 실제로 문서 루트를 변경한 경우 - +즉, 모든 콘텐츠가 실제로 해당 +하위 디렉토리에 있는 경우 - URL을 재작성하는 것보다 +DocumentRoot 지시어를 +변경하거나 모든 콘텐츠를 한 디렉토리 위로 이동하는 것이 +훨씬 좋습니다.

+
+
+ +
+ +
+대체 자원 + +
+
설명:
+
특정 디렉토리로 오는 모든 요청을 단일 자원(예를 들어 +index.php와 같은 특정 파일)으로 처리하고 싶지만, 이미지나 +css 파일과 같은 기존 자원에 대한 요청은 제외하고자 합니다.
+ +
해결책:
+
+

버전 2.2.16부터 이를 위해 FallbackResource 지시어를 +사용해야 합니다:

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

그러나 이전 버전의 Apache에서 또는 요구 사항이 이보다 +더 복잡한 경우 동일한 것을 달성하기 위해 다음 재작성 +세트의 변형을 사용할 수 있습니다:

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

반면에, 요청된 URI를 index.php에 쿼리 문자열 인수로 +전달하려면 해당 RewriteRule을 다음으로 대체할 수 있습니다:

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

이 규칙 세트는 .htaccess 파일뿐만 아니라 +<Directory> 블록에서도 사용할 수 있습니다.

+ +
+ +
+ +
+ +
+쿼리 문자열 재작성 + +
+
설명:
+
쿼리 문자열에서 특정 값을 캡처하여 대체하거나 +URL의 다른 구성 요소에 통합하고자 합니다.
+ +
해결책:
+
+

이 섹션의 많은 해결책은 일치된 값을 %2 역참조에 +남기는 동일한 조건을 사용합니다. %1은 쿼리 문자열의 +시작(관심 키까지)이고, %3은 나머지입니다. 이 조건은 +유연성을 위해 그리고 치환에서 이중 +'&&'을 피하기 위해 다소 복잡합니다.

+
    +
  • 이 해결책은 일치하는 키와 값을 제거합니다: + + +# Remove mykey=??? +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1?%1%3" + +
  • + +
  • 이 해결책은 캡처된 값을 URL 치환에 사용하고 + 나머지 원래 쿼리를 '?'를 추가하여 버립니다: + + +# Copy from query string to PATH_INFO +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1/products/%2/?" [PT] + +
  • + +
  • 이 해결책은 후속 조건에서 캡처된 값을 확인합니다: + + +# Capture the value of mykey in the query string +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteCond "%2" !=not-so-secret-value +RewriteRule "(.*)" "-" [F] + +
  • + +
  • 이 해결책은 이전 것들의 반대로, URL에서 경로 + 구성 요소(아마도 PATH_INFO)를 쿼리 문자열로 복사합니다. + +# The desired URL might be /products/kitchen-sink, and the script expects +# /path?products=kitchen-sink. +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT] + +
  • +
+ +
+ +
+
+ + +
diff --git a/docs/manual/rewrite/remapping.xml.meta b/docs/manual/rewrite/remapping.xml.meta index fc4dfefebf..cc29dd58d1 100644 --- a/docs/manual/rewrite/remapping.xml.meta +++ b/docs/manual/rewrite/remapping.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/remapping.xml.tr b/docs/manual/rewrite/remapping.xml.tr new file mode 100644 index 0000000000..84009599ef --- /dev/null +++ b/docs/manual/rewrite/remapping.xml.tr @@ -0,0 +1,665 @@ + + + + + + + + + Rewrite + +mod_rewrite ile Yeniden Yönlendirme ve Yeniden Eşleme + + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +İstekleri yeniden yönlendirmek ve yeniden eşlemek için +mod_rewrite modülünü nasıl kullanabileceğinizi +açıklar. Her birinin nasıl çalıştığının ayrıntılı açıklamalarını +içeren birçok mod_rewrite kullanım örneği +sunar.

+ +Bu örneklerin birçoğunun sizin sunucu yapılandırmanızda +değişiklik yapılmadan çalışmayacağını unutmayın; bu nedenle örnekleri +yapılandırmanıza kopyalayıp yapıştırmak yerine anlamanız +önemlidir. + +
+Modül belgeleri +mod_rewrite'a giriş + +Erişim denetimi +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
+ + Eskiden Yeniye (dahili) + +
+
Açıklama:
+ +
+

foo.html sayfasını yakın zamanda + bar.html olarak yeniden adlandırdığımızı ve şimdi + geriye dönük uyumluluk için eski URL'yi sağlamak istediğimizi + varsayalım. Ancak eski URL kullanıcılarının sayfanın yeniden + adlandırıldığını fark etmemesini istiyoruz - yani adresin + tarayıcılarında değişmesini istemiyoruz.

+
+ +
Çözüm:
+ +
+

Eski URL'yi aşağıdaki kuralla dahili olarak yenisine yeniden + yazıyoruz:

+ + +RewriteEngine on +RewriteRule "^/foo\.html$" "/bar.html" [PT] + +
+
+ +
+ +
+ + Eskiden Yeniye Yeniden Yazma (harici) + +
+
Açıklama:
+ +
+

Yine foo.html sayfasını yakın zamanda + bar.html olarak yeniden adlandırdığımızı ve şimdi + geriye dönük uyumluluk için eski URL'yi sağlamak istediğimizi + varsayalım. Ancak bu sefer eski URL kullanıcılarının yeni URL + hakkında bilgilendirilmesini istiyoruz, yani tarayıcılarının + Konum alanı da değişmeli.

+
+ +
Çözüm:
+ +
+

Tarayıcının ve dolayısıyla kullanıcının görünümünün + değişmesini sağlayan yeni URL'ye bir HTTP yönlendirmesi + zorluyoruz:

+ + +RewriteEngine on +RewriteRule "^/foo\.html$" "bar.html" [R] + +
+ +
Tartışma
+ +
+

Bu örnekte, dahili örneğin + aksine, basitçe Redirect yönergesini kullanabiliriz. Önceki + örnekte mod_rewrite, yönlendirmeyi istemciden + gizlemek için kullanılmıştı:

+ + +Redirect "/foo.html" "/bar.html" + + +
+
+ +
+ +
+ + Başka Bir Sunucuya Taşınan Kaynak + +
+
Açıklama:
+ +
+

Bir kaynak başka bir sunucuya taşındıysa, insanlar yer + imlerini güncellerken URL'lerin eski sunucuda bir süre daha + çalışmasını isteyebilirsiniz.

+
+ +
Çözüm:
+ +
+

Bu URL'leri yeni sunucuya yönlendirmek için + mod_rewrite kullanabilirsiniz, ancak Redirect + veya RedirectMatch yönergesini kullanmayı da + düşünebilirsiniz.

+ + +#mod_rewrite ile +RewriteEngine on +RewriteRule "^/docs/(.+)" "http://new.example.com/docs/$1" [R,L] + + + +#RedirectMatch ile +RedirectMatch "^/docs/(.*)" "http://new.example.com/docs/$1" + + + +#Redirect ile +Redirect "/docs/" "http://new.example.com/docs/" + +
+
+ +
+ +
+ + Statikten Devingene + +
+
Açıklama:
+ +
+

Statik bir sayfa olan foo.html'yi devingen bir + varyant olan foo.cgi'ye tarayıcı/kullanıcı fark + etmeden sorunsuz bir şekilde nasıl dönüştürebiliriz?

+
+ +
Çözüm:
+ +
+

URL'yi CGI betiğine yeniden yazar ve işleyiciyi + cgi-script olarak zorlayarak bir CGI programı + olarak yürütülmesini sağlarız. Böylece + /~quux/foo.html isteği dahili olarak + /~quux/foo.cgi'nin çağrılmasına yol açar.

+ + +RewriteEngine on +RewriteBase "/~quux/" +RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script] + +
+
+ +
+ +
+ + Dosya Uzantısı Değişikliği için Geriye Dönük Uyumluluk + +
+
Açıklama:
+ +
+

document.YYYY'den document.XXXX'e + geçiş yaptıktan sonra, örneğin bir dizi .html + dosyasını .php'ye çevirdikten sonra URL'leri nasıl + geriye dönük uyumlu (sanal olarak hâlâ mevcut) yapabiliriz?

+
+ +
Çözüm:
+ +
+

URL, yeni uzantılı hedef dosya mevcutsa ve eski uzantılı + orijinal dosya mevcut değilse eski uzantıdan yeni uzantıya + yeniden yazılır. Aksi takdirde URL değiştirilmeden bırakılır.

+ + +# document.html'yi document.php'ye yeniden yazma +# için geriye dönük uyumluluk kural kümesi +# yalnızca document.php varsa +<Directory "/var/www/htdocs"> + RewriteEngine on + RewriteBase "/var/www/htdocs" + + RewriteCond "$1.php" -f + RewriteCond "$1.html" !-f + RewriteRule "^(.*).html$" "$1.php" +</Directory> + +
+ +
Tartışma
+
+

Bu örnek, mod_rewrite modülünün genellikle + gözden kaçan bir özelliğini kullanır: kural kümesinin yürütme + sırasından yararlanır. Özellikle, mod_rewrite + RewriteCond yönergelerini değerlendirmeden önce RewriteRule'un + sol tarafını değerlendirir. Sonuç olarak, RewriteCond yönergeleri + değerlendirildiğinde $1 zaten tanımlanmış olur. Bu, aynı temel + dosya adını kullanarak orijinal (document.html) ve + hedef (document.php) dosyaların varlığını + sınamamıza olanak tanır.

+ +

Bu kural kümesi dizin başına bağlamda (bir <Directory> + bloğunda veya bir .htaccess dosyasında) kullanılmak üzere + tasarlanmıştır; böylece -f kontrolleri doğru dizin + yoluna bakar. Çalıştığınız dizin tabanını belirtmek için bir + RewriteBase yönergesi + ayarlamanız gerekebilir.

+
+
+ +
+ +
+ +Kurallı Konak Adları + +
+
Açıklama:
+ +
Bu kuralın amacı, aynı siteye erişmek için kullanılabilecek + diğer konak adları yerine belirli bir konak adının + kullanılmasını zorlamaktır. Örneğin, + example.com yerine + www.example.com kullanılmasını zorlamak + istiyorsanız aşağıdaki tarifin bir varyantını + kullanabilirsiniz.
+ +
Çözüm:
+ +
+ +

Bunu çözmenin en iyi yolu mod_rewrite kullanmak +değil, kurallı olmayan konak ad(lar)ı için bir sanal konağa yerleştirilmiş +Redirect yönergesini +kullanmaktır.

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

Bunu alternatif olarak If yönergesini kullanarak da +gerçekleştirebilirsiniz: (2.4 ve sonrası)

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

Veya örneğin, sitenizin bir bölümünü HTTPS'ye yönlendirmek için +şunları yapabilirsiniz:

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

Herhangi bir nedenle hâlâ mod_rewrite kullanmak +istiyorsanız - örneğin buna daha büyük bir RewriteRules kümesiyle +birlikte ihtiyaç duyuyorsanız - aşağıdaki tariflerden birini +kullanabilirsiniz.

+ +

80 dışında bir bağlantı noktasında çalışan siteler için:

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

80 bağlantı noktasında çalışan bir site için

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

+ Bunu tüm alan adları için genel olarak yapmak istiyorsanız - + yani tüm olası example.com değerleri için + example.com'u + www.example.com'a yönlendirmek istiyorsanız - + aşağıdaki tarifi kullanabilirsiniz:

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

Bu kural kümeleri, ana sunucu yapılandırma dosyanızda veya + sunucunun DocumentRoot + dizinine yerleştirilen bir .htaccess dosyasında + çalışacaktır.

+
+
+ +
+ +
+ + Birden Fazla Dizinde Sayfa Arama + +
+
Açıklama:
+ +
+

Belirli bir kaynak birkaç yerden birinde olabilir ve + istendiğinde bu yerlerde kaynağı aramak istiyoruz. Belki yakın + zamanda dizin yapımızı yeniden düzenledik ve içeriği birkaç + konuma böldük.

+
+ +
Çözüm:
+ +
+

Aşağıdaki kural kümesi, kaynağı bulmak için iki dizinde + arama yapar ve hiçbirinde bulamazsa istenen konumdan sunmayı + dener.

+ + +RewriteEngine on + +# önce dir1/ içinde bulmayı dene +# ...ve bulunursa dur ve mutlu ol: +RewriteCond "%{DOCUMENT_ROOT}/dir1/%{REQUEST_URI}" -f +RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir1/$1" [L] + +# sonra dir2/ içinde bulmayı dene +# ...ve bulunursa dur ve mutlu ol: +RewriteCond "%{DOCUMENT_ROOT}/dir2/%{REQUEST_URI}" -f +RewriteRule "^(.+)" "%{DOCUMENT_ROOT}/dir2/$1" [L] + +# yoksa diğer Alias veya ScriptAlias yönergeleri vb. için devam et. +RewriteRule "^" "-" [PT] + +
+
+ +
+ +
+ + Coğrafi Olarak Dağıtılmış Sunuculara Yönlendirme + +
+
Açıklama:
+ +
+

Web sitemizin çok sayıda yansısı var ve insanları bulundukları + ülkedeki yansıya yönlendirmek istiyoruz.

+
+ +
Çözüm:
+ +
+

İstemcinin konak adına bakarak hangi ülkeden geldiklerini + belirliyoruz. IP adreslerini çözümleyemezsek öntanımlı bir + sunucuya geri dönüyoruz.

+

Kullanmak istediğimiz sunucuların listesini oluşturmak için + bir RewriteMap + yönergesi kullanacağız.

+ + +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 -- Çoğullama Eşlem Dosyası
+
+de http://www.example.de/
+uk http://www.example.uk/
+com http://www.example.com/
+##EOF## +
+
+ +
Tartışma
+
+ Bu kural kümesi, HostNameLookups yönergesinin + on olarak ayarlanmasına dayanır; bu da önemli bir + performans etkisi olabilir. + +

RewriteCond + yönergesi, istemcinin konak adının son bölümünü - ülke kodunu - + yakalar ve ardından gelen RewriteRule bu değeri eşlem dosyasında + uygun yansı konağını aramak için kullanır.

+
+
+ +
+ +
+ +Kurallı URL'ler + +
+
Açıklama:
+ +
+

Bazı web sunucularında bir kaynak için birden fazla URL + bulunur. Genellikle kurallı URL'ler (gerçekten kullanılan ve + dağıtılan) ve kısayollar, dahili URL'ler vb. vardır. Kullanıcı + istekle hangi URL'yi sağlamış olursa olsun, sonunda tarayıcı + adres çubuğunda kurallı olanı görmelidir.

+
+ +
Çözüm:
+ +
+

Tüm kurallı olmayan URL'leri tarayıcının Konum görünümünde + düzeltmek ve sonraki tüm istekler için harici bir HTTP + yönlendirmesi yapıyoruz. Aşağıdaki örnek kural kümesinde + /puppies ve /canines yollarını + kurallı /dogs ile değiştiriyoruz.

+ + +RewriteRule "^/(puppies|canines)/(.*)" "/dogs/$2" [R] + +
+ +
Tartışma:
+
+ Bu gerçekten Redirect veya RedirectMatch yönergeleriyle + gerçekleştirilmelidir: + + +RedirectMatch "^/(puppies|canines)/(.*)" "/dogs/$2" + +
+
+ +
+ +
+ + Taşınmış <code>DocumentRoot</code> + +
+
Açıklama:
+ +
+

Genellikle web sunucusunun DocumentRoot dizini doğrudan +"/" URL'siyle ilişkilidir. Ancak çoğu zaman bu veriler +gerçekten en üst düzey önceliğe sahip değildir. Örneğin, siteye ilk +giren ziyaretçilerin belirli bir /about/ alt dizinine +yönlendirilmesini isteyebilirsiniz. Bu, aşağıdaki kural kümesi +kullanılarak gerçekleştirilebilir:

+
+ +
Çözüm:
+ +
+

/ URL'sini /about/ adresine + yönlendiriyoruz:

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

Bunun RedirectMatch +yönergesi kullanılarak da ele alınabileceğini unutmayın:

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

Ayrıca örneğin yalnızca kök URL'yi yeniden yazdığını unutmayın. +Yani http://example.com/ isteğini yeniden yazar ancak +http://example.com/page.html isteğini yeniden yazmaz. +Belge kökünüzü gerçekten değiştirdiyseniz - yani tüm içeriğiniz +aslında o alt dizindeyse - DocumentRoot yönergesini değiştirmek veya +tüm içeriği bir dizin yukarı taşımak, URL'leri yeniden yazmaktan +çok daha tercih edilir.

+
+
+ +
+ +
+Yedek Kaynak + +
+
Açıklama:
+
Belirli bir dizine gelen tüm istekleri, bir resim veya css +dosyası gibi mevcut bir kaynağa gitmesi gerekenler dışında tek bir +kaynağın (örneğin index.php gibi belirli bir dosyanın) işlemesini +istiyorsunuz.
+ +
Çözüm:
+
+

2.2.16 sürümünden itibaren bunun için FallbackResource yönergesini +kullanmalısınız:

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

Ancak Apache'nin önceki sürümlerinde veya ihtiyaçlarınız bundan +daha karmaşıksa, aynı şeyi gerçekleştirmek için aşağıdaki yeniden +yazma kümesinin bir varyasyonunu kullanabilirsiniz:

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

Diğer taraftan, istenen URI'yi index.php'ye sorgu dizgesi +argümanı olarak geçirmek isterseniz, o RewriteRule'u şununla +değiştirebilirsiniz:

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

Bu kural kümelerinin bir .htaccess dosyasında ve +bir <Directory> bloğunda da kullanılabileceğini unutmayın.

+ +
+ +
+ +
+ +
+Sorgu Dizgesini Yeniden Yazma + +
+
Açıklama:
+
Bir sorgu dizgesinden belirli bir değeri yakalamak ve onu +değiştirmek veya URL'nin başka bir bileşenine dahil etmek +istiyorsunuz.
+ +
Çözümler:
+
+

Bu bölümdeki çözümlerin birçoğu aynı koşulu kullanır; bu koşul +eşleşen değeri %2 geri başvurusunda bırakır. %1 sorgu dizgesinin +başlangıcıdır (ilgili anahtara kadar) ve %3 geri kalanıdır. Bu +koşul, esneklik ve değiştirmelerde çift '&&' oluşmasını +önlemek için biraz karmaşıktır.

+
    +
  • Bu çözüm eşleşen anahtarı ve değeri kaldırır: + + +# mykey=??? öğesini kaldır +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1?%1%3" + +
  • + +
  • Bu çözüm, yakalanan değeri URL değiştirmesinde kullanır ve + sonuna '?' ekleyerek orijinal sorgu dizgesinin geri kalanını + atar: + + +# Sorgu dizgesinden PATH_INFO'ya kopyala +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1/products/%2/?" [PT] + +
  • + +
  • Bu çözüm, yakalanan değeri sonraki bir koşulda kontrol eder: + + +# Sorgu dizgesindeki mykey değerini yakala +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteCond "%2" !=not-so-secret-value +RewriteRule "(.*)" "-" [F] + +
  • + +
  • Bu çözüm, önceki çözümlerin tersini gösterir: yol bileşenlerini + (belki PATH_INFO) URL'den sorgu dizgesine kopyalar. + +# İstenen URL /products/kitchen-sink olabilir ve betik +# /path?products=kitchen-sink bekler. +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT] + +
  • +
+ +
+ +
+
+ + +
diff --git a/docs/manual/rewrite/remapping.xml.zh-cn b/docs/manual/rewrite/remapping.xml.zh-cn new file mode 100644 index 0000000000..4f0b27730d --- /dev/null +++ b/docs/manual/rewrite/remapping.xml.zh-cn @@ -0,0 +1,622 @@ + + + + + + + + + Rewrite + +使用 mod_rewrite 进行重定向和重映射 + + + +

本文档是 mod_rewrite +参考文档的补充。它描述了如何使用 +mod_rewrite 来重定向和重映射请求。 +其中包括许多 mod_rewrite 的常见用法示例, +以及每个示例工作原理的详细描述。

+ +请注意,这些示例中的许多不会在你的特定服务器配置中直接生效, +因此理解它们非常重要,而不仅仅是将示例复制粘贴到你的配置中。 + +
+模块文档 +mod_rewrite 简介 + +访问控制 +虚拟主机 +代理 +使用 RewriteMap +高级技术 +何时不使用 mod_rewrite + +
+ + 从旧到新(内部) + +
+
描述:
+ +
+

假设我们最近将页面 foo.html 重命名为 + bar.html,现在希望提供旧 URL 以实现向后兼容。 + 但是,我们希望旧 URL 的用户甚至不会注意到页面已被重命名—— + 也就是说,我们不希望浏览器中的地址发生变化。

+
+ +
解决方案:
+ +
+

我们通过以下规则在内部将旧 URL 重写为新 URL:

+ + +RewriteEngine on +RewriteRule "^/foo\.html$" "/bar.html" [PT] + +
+
+ +
+ +
+ + 从旧到新的重写(外部) + +
+
描述:
+ +
+

再次假设我们最近将页面 foo.html 重命名为 + bar.html,现在希望提供旧 URL 以实现向后兼容。 + 但这次我们希望旧 URL 的用户能看到新 URL 的提示, + 即他们的浏览器地址栏也应该改变。

+
+ +
解决方案:
+ +
+

我们强制进行 HTTP 重定向到新 URL, + 这会导致浏览器以及用户视图的变化:

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

在本示例中,与上面的内部示例不同, + 我们可以简单地使用 Redirect 指令。在前面的示例中使用 + mod_rewrite 是为了对客户端隐藏重定向:

+ + +Redirect "/foo.html" "/bar.html" + + +
+
+ +
+ +
+ + 资源已移至另一台服务器 + +
+
描述:
+ +
+

如果资源已移至另一台服务器,你可能希望 URL + 在旧服务器上继续工作一段时间,以便人们更新书签。

+
+ +
解决方案:
+ +
+

你可以使用 mod_rewrite 将这些 URL + 重定向到新服务器,但也可以考虑使用 Redirect 或 RedirectMatch 指令。

+ + +#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/" + +
+
+ +
+ +
+ + 从静态到动态 + +
+
描述:
+ +
+

如何以无缝的方式(即浏览器/用户不会注意到)将静态页面 + foo.html 转换为动态变体 foo.cgi。

+
+ +
解决方案:
+ +
+

我们只需将 URL 重写为 CGI 脚本并强制处理程序为 + cgi-script,使其作为 CGI 程序执行。 + 这样,对 /~quux/foo.html 的请求在内部会导致调用 + /~quux/foo.cgi。

+ + +RewriteEngine on +RewriteBase "/~quux/" +RewriteRule "^foo\.html$" "foo.cgi" [H=cgi-script] + +
+
+ +
+ +
+ + 文件扩展名更改的向后兼容性 + +
+
描述:
+ +
+

在将 document.YYYY 迁移到 + document.XXXX(例如将一批 .html + 文件翻译为 .php)之后, + 如何使 URL 保持向后兼容(仍然虚拟存在)?

+
+ +
解决方案:
+ +
+

仅当具有新扩展名的目标文件存在而具有旧扩展名的原始文件不存在时, + 才将 URL 从旧扩展名重写为新扩展名。否则,URL 保持不变。

+ + +# 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> + +
+ +
讨论
+
+

此示例使用了 mod_rewrite 的一个经常被忽视的特性, + 利用了规则集的执行顺序。特别是,mod_rewrite + 在求值 RewriteCond 指令之前先求值 RewriteRule 的左侧。 + 因此,在求值 RewriteCond 指令时 $1 已经被定义。 + 这使我们能够使用相同的基础文件名来测试原始文件 + (document.html)和目标文件 + (document.php)的存在性。

+ +

此规则集设计用于目录级上下文 + (在 <Directory> 块或 .htaccess 文件中), + 以便 -f 检查正确的目录路径。 + 你可能需要设置 RewriteBase + 指令来指定你正在使用的目录基准。

+
+
+ +
+ +
+ +规范主机名 + +
+
描述:
+ +
此规则的目标是强制使用特定的主机名, + 而不是可能用来到达同一站点的其他主机名。 + 例如,如果你希望强制使用 + www.example.com 而不是 + example.com,你可以使用以下方案的变体。
+ +
解决方案:
+ +
+ +

最佳方式根本不涉及 mod_rewrite, +而是使用放置在非规范主机名虚拟主机中的 +Redirect 指令。

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

你也可以使用 +If +指令来完成(2.4 及更高版本):

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

或者,例如,要将站点的一部分重定向到 HTTPS,你可以执行以下操作:

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

如果出于某种原因你仍然想使用 mod_rewrite—— +例如,你需要它与一组更大的 RewriteRule 一起使用—— +你可以使用以下方案之一。

+ +

对于运行在非 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] + + +

对于运行在 80 端口上的站点:

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

+ 如果你希望对所有域名通用地执行此操作——也就是说, + 如果你想将 example.com 重定向到 + www.example.com,其中 + example.com 可以是任何值, + 你可以使用以下方案:

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

这些规则集可以在主服务器配置文件中使用, + 也可以在放置于服务器 DocumentRoot 中的 + .htaccess 文件中使用。

+
+
+ +
+ +
+ + 在多个目录中搜索页面 + +
+
描述:
+ +
+

某个特定资源可能存在于多个位置, + 我们希望在请求时在这些位置中查找该资源。 + 也许我们最近重新整理了目录结构,将内容分散到多个位置。

+
+ +
解决方案:
+ +
+

以下规则集在两个目录中搜索资源, + 如果在两个位置都找不到,则尝试从请求的位置直接提供。

+ + +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] + +
+
+ +
+ +
+ + 重定向到地理分布式服务器 + +
+
描述:
+ +
+

我们的网站有多个镜像, + 希望将用户重定向到距其所在国家最近的镜像。

+
+ +
解决方案:
+ +
+

查看请求客户端的主机名,确定他们来自哪个国家。 + 如果无法查找其 IP 地址,则回退到默认服务器。

+

我们将使用 RewriteMap + 指令来构建我们希望使用的服务器列表。

+ + +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 -- 多路复用映射
+
+de http://www.example.de/
+uk http://www.example.uk/
+com http://www.example.com/
+##EOF## +
+
+ +
讨论
+
+ 此规则集依赖于 + HostNameLookups + 设置为 on,这可能会对性能产生显著影响。 + +

RewriteCond + 捕获请求客户端主机名的最后部分——国家代码——后续的 RewriteRule + 使用该值在映射文件中查找适当的镜像主机。

+
+
+ +
+ +
+ +规范 URL + +
+
描述:
+ +
+

在某些 Web 服务器上,一个资源可能有多个 URL。 + 通常有规范 URL(即实际使用和分发的 URL) + 和只是快捷方式、内部 URL 等的 URL。 + 无论用户在请求中提供的是哪个 URL, + 他们最终应在浏览器地址栏中看到规范 URL。

+
+ +
解决方案:
+ +
+

我们对所有非规范 URL 执行外部 HTTP 重定向, + 以在浏览器的地址视图中修正它们,并用于所有后续请求。 + 在下面的示例规则集中,我们将 /puppies 和 + /canines 替换为规范的 /dogs。

+ + +RewriteRule "^/(puppies|canines)/(.*)" "/dogs/$2" [R] + +
+ +
讨论:
+
+ 这实际上应该使用 Redirect 或 RedirectMatch 指令来完成: + + +RedirectMatch "^/(puppies|canines)/(.*)" "/dogs/$2" + +
+
+ +
+ +
+ + 移动的 <code>DocumentRoot</code> + +
+
描述:
+ +
+

通常 Web 服务器的 DocumentRoot +直接对应 URL "/"。 +但这些数据通常不是最高优先级的内容。例如, +你可能希望访客在首次进入站点时转到特定子目录 /about/。 +这可以使用以下规则集来实现:

+
+ +
解决方案:
+ +
+

我们将 URL / 重定向到 /about/: +

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

请注意,这也可以使用 +RedirectMatch 指令来处理:

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

还要注意,此示例仅重写根 URL。也就是说, +它重写对 http://example.com/ 的请求, +但不会重写对 http://example.com/page.html 的请求。 +如果你确实更改了文档根目录——也就是说,如果你的所有内容 +实际上都在该子目录中,那么最好直接更改 +DocumentRoot 指令, +或将所有内容向上移动一个目录,而不是重写 URL。

+
+
+ +
+ +
+回退资源 + +
+
描述:
+
你希望单个资源(例如某个文件,如 index.php)处理所有进入特定目录的请求, +但已存在的资源(如图片或 CSS 文件)除外。
+ +
解决方案:
+
+

从 2.2.16 版本开始,你应该使用 +FallbackResource 指令来完成:

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

但是,在早期版本的 Apache 中,或者如果你的需求比这更复杂, +你可以使用以下重写集的变体来实现相同的目的:

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

另一方面,如果你希望将请求的 URI 作为查询字符串参数传递给 index.php, +你可以将该 RewriteRule 替换为:

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

请注意,这些规则集可以在 .htaccess 文件中使用, +也可以在 <Directory> 块中使用。

+ +
+ +
+ +
+ +
+重写查询字符串 + +
+
描述:
+
你想从查询字符串中捕获特定值,并替换它或将其合并到 URL 的另一个组件中。
+ +
解决方案:
+
+

本节中的许多解决方案都使用相同的条件, +该条件将匹配的值留在 %2 反向引用中。%1 是查询字符串的开头 +(直到感兴趣的键),%3 是剩余部分。 +此条件稍微复杂是为了灵活性和避免替换中出现双 '&&'。

+
    +
  • 此解决方案移除匹配的键和值: + + +# Remove mykey=??? +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1?%1%3" + +
  • + +
  • 此解决方案在 URL 替换中使用捕获的值, + 通过附加 '?' 来丢弃其余的原始查询: + + +# Copy from query string to PATH_INFO +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteRule "(.*)" "$1/products/%2/?" [PT] + +
  • + +
  • 此解决方案在后续条件中检查捕获的值: + + +# Capture the value of mykey in the query string +RewriteCond "%{QUERY_STRING}" "(.*(?:^|&))mykey=([^&]*)&?(.*)&?$" +RewriteCond "%2" !=not-so-secret-value +RewriteRule "(.*)" "-" [F] + +
  • + +
  • 此解决方案展示了前面方案的逆操作, + 将路径组件(可能是 PATH_INFO)从 URL 复制到查询字符串中。 + +# The desired URL might be /products/kitchen-sink, and the script expects +# /path?products=kitchen-sink. +RewriteRule "^/?path/([^/]+)/([^/]+)" "/path?$1=$2" [PT] + +
  • +
+ +
+ +
+
+ + +
diff --git a/docs/manual/rewrite/rewritemap.xml.de b/docs/manual/rewrite/rewritemap.xml.de new file mode 100644 index 0000000000..be1b101d3b --- /dev/null +++ b/docs/manual/rewrite/rewritemap.xml.de @@ -0,0 +1,503 @@ + + + + + + + Rewrite + Verwendung von RewriteMap + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es beschreibt +die Verwendung der RewriteMap-Direktive +und bietet Beispiele für jeden der verschiedenen +RewriteMap-Typen.

+ + Beachten Sie, dass viele dieser Beispiele nicht unverändert in Ihrer +speziellen Serverkonfiguration funktionieren werden. Es ist daher wichtig, dass Sie +sie verstehen, anstatt die Beispiele einfach auszuschneiden und in Ihre +Konfiguration einzufügen. + +
+ Moduldokumentation + Einführung in mod_rewrite + Umleitung und Neuzuordnung + Zugriffskontrolle + Virtuelle Hosts + Proxying + Fortgeschrittene Techniken + Wann man mod_rewrite nicht verwenden sollte + +
+ Einführung + +

+ Die RewriteMap-Direktive + definiert eine externe Funktion, die im Kontext von + RewriteRule- oder + RewriteCond-Direktiven + aufgerufen werden kann, um Umschreibungen durchzuführen, die zu + kompliziert oder zu spezialisiert sind, um allein mit regulären + Ausdrücken durchgeführt zu werden. Die Quelle für diese Nachschlagung + kann einer der in den folgenden Abschnitten aufgeführten Typen sein, + die auch in der + RewriteMap-Referenzdokumentation + aufgezählt sind.

+ +

Die Syntax der RewriteMap-Direktive + lautet wie folgt:

+ + +RewriteMap MapName MapType:MapSource + + +

Der MapName ist ein + beliebiger Name, den Sie der Map zuweisen und den Sie später in + Direktiven verwenden. Argumente werden der Map über die folgende + Syntax übergeben:

+ +

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

+ +

Wenn ein solches Konstrukt auftritt, wird die Map MapName + konsultiert und der Schlüssel LookupKey nachgeschlagen. + Wenn der Schlüssel gefunden wird, wird das Map-Funktions-Konstrukt + durch SubstValue ersetzt. Wenn der Schlüssel nicht gefunden + wird, wird es durch DefaultValue oder durch den leeren + String ersetzt, falls kein DefaultValue angegeben wurde.

+ +

Sie können beispielsweise eine + RewriteMap wie folgt + definieren:

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

Sie können diese Map dann in einer + RewriteRule wie folgt + verwenden:

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

Ein Standardwert kann für den Fall angegeben werden, dass nichts in +der Map gefunden wird:

+ + +RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}" + + +Verzeichniskontext und .htaccess-Kontext +

+Die RewriteMap-Direktive darf nicht +in Directory-Abschnitten oder +.htaccess-Dateien verwendet werden. Sie müssen die Map im Server- +oder VirtualHost-Kontext deklarieren. Sie können die Map, einmal erstellt, in +Ihren RewriteRule- und +RewriteCond-Direktiven in diesen +Geltungsbereichen verwenden. Sie können sie nur nicht in diesen Geltungsbereichen +deklarieren.

+
+ +

Die folgenden Abschnitte beschreiben die verschiedenen MapTypes, +die verwendet werden können, und geben Beispiele für jeden.

+
+ +
+ int: Interne Funktion + +

Wenn ein MapType von int verwendet wird, ist die + MapSource eine der verfügbaren internen + RewriteMap-Funktionen. + Modulautoren können zusätzliche interne Funktionen bereitstellen, + indem sie diese mit der ap_register_rewrite_mapfunc-API + registrieren. Die standardmäßig bereitgestellten Funktionen sind: +

+ +
    +
  • toupper:
    + Konvertiert den Schlüssel in Großbuchstaben.
  • +
  • tolower:
    + Konvertiert den Schlüssel in Kleinbuchstaben.
  • +
  • escape:
    + Übersetzt Sonderzeichen im Schlüssel in + Hex-Kodierungen.
  • +
  • unescape:
    + Übersetzt Hex-Kodierungen im Schlüssel zurück in + Sonderzeichen.
  • +
+ +

+ Um eine dieser Funktionen zu verwenden, erstellen Sie eine + RewriteMap, die auf die + int-Funktion verweist, und verwenden Sie diese dann in Ihrer + RewriteRule: +

+ +

Eine URI auf eine komplett kleingeschriebene Version umleiten

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

Bitte beachten Sie, dass das hier angebotene Beispiel nur zur + Veranschaulichung dient und keine Empfehlung ist. Wenn Sie URLs + unabhängig von der Groß-/Kleinschreibung machen möchten, ziehen Sie + stattdessen die Verwendung von mod_speling in + Betracht. +

+
+ +
+ +
+ txt: Klartext-Maps + +

Wenn ein MapType von txt verwendet wird, ist die + MapSource ein Dateisystempfad zu einer Klartext-Zuordnungsdatei, + die ein durch Leerzeichen getrenntes Schlüssel/Wert-Paar pro Zeile + enthält. Optional kann eine Zeile einen Kommentar enthalten, der + mit einem '#'-Zeichen beginnt.

+ +

Eine gültige Text-Rewrite-Map-Datei hat die folgende Syntax:

+ + + # Kommentarzeile
+ MatchingKey SubstValue
+ MatchingKey SubstValue # Kommentar
+
+ +

Wenn die RewriteMap + aufgerufen wird, wird das Argument im ersten Argument einer Zeile + gesucht und, falls gefunden, der Ersetzungswert zurückgegeben.

+ +

Beispielsweise können wir eine Map-Datei verwenden, um + Produktnamen in Produkt-IDs für leichter zu merkende URLs + zu übersetzen, mit dem folgenden Rezept:

+

Produkt-zu-ID-Konfiguration

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

Wir nehmen hier an, dass das prods.php-Skript weiß, + was zu tun ist, wenn es ein Argument von id=NOTFOUND + erhält, wenn ein Produkt nicht in der Nachschlagetabelle gefunden + wird.

+ +

Die Datei /etc/apache2/productmap.txt enthält dann + Folgendes:

+ + Produkt-zu-ID-Map +##
+## productmap.txt - Produkt-zu-ID-Map-Datei
+##
+
+television 993
+stereo 198
+fishingrod 043
+basketball 418
+telephone 328 +
+ +

Wenn also http://example.com/product/television + angefordert wird, wird die RewriteRule + angewendet und die Anfrage intern auf + /prods.php?id=993 abgebildet.

+ + Hinweis: .htaccess-Dateien + Das gegebene Beispiel ist für die Verwendung im Server- oder + VirtualHost-Kontext konzipiert. Wenn Sie dies in einer + .htaccess-Datei verwenden möchten, müssen Sie den + führenden Schrägstrich aus dem Umschreibungsmuster entfernen, damit + es übereinstimmt: + +RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT] + + + + Zwischengespeicherte Nachschlagungen +

+ Die nachgeschlagenen Schlüssel werden von httpd zwischengespeichert, + bis sich die mtime (Änderungszeit) der Map-Datei ändert + oder der httpd-Server neu gestartet wird. Dies gewährleistet eine + bessere Leistung bei Maps, die von vielen Anfragen aufgerufen werden. +

+
+ +
+
+ rnd: Zufälliger Klartext + +

Wenn ein MapType von rnd verwendet wird, ist die + MapSource ein Dateisystempfad zu einer Klartext-Zuordnungsdatei, + wobei jede Zeile einen Schlüssel und einen oder mehrere durch + | getrennte Werte enthält. Einer dieser Werte wird + zufällig ausgewählt, wenn der Schlüssel übereinstimmt.

+ +

Sie können beispielsweise die folgende Map-Datei und Direktiven + verwenden, um eine zufällige Lastverteilung zwischen mehreren + Backend-Servern über einen Reverse-Proxy bereitzustellen. Bilder + werden an einen der Server im 'static'-Pool gesendet, während alles + andere an einen der Server im 'dynamic'-Pool gesendet wird.

+ + Rewrite-Map-Datei +##
+## map.txt -- Umschreibungs-Map
+##
+
+static www1|www2|www3|www4
+dynamic www5|www6 +
+

Konfigurationsdirektiven

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

Wenn also ein Bild angefordert wird und die erste dieser Regeln + übereinstimmt, schlägt RewriteMap + den String static in der Map-Datei nach, die einen der + angegebenen Hostnamen zufällig zurückgibt, der dann im + RewriteRule-Ziel verwendet wird.

+ +

Wenn Sie möchten, dass einer der Server häufiger ausgewählt wird + (zum Beispiel, wenn einer der Server mehr Speicher hat und daher mehr + Anfragen verarbeiten kann), listen Sie ihn einfach häufiger in der + Map-Datei auf.

+ + +static www1|www1|www2|www3|www4 + + +
+ +
+ dbm: DBM-Hash-Datei + +

Wenn ein MapType von dbm verwendet wird, ist die + MapSource ein Dateisystempfad zu einer DBM-Datenbankdatei, die + Schlüssel/Wert-Paare für die Zuordnung enthält. Dies funktioniert + genau wie die txt-Map, ist aber viel schneller, da eine + DBM indiziert ist, während eine Textdatei dies nicht ist. Dies + ermöglicht einen schnelleren Zugriff auf den gewünschten Schlüssel.

+ +

Sie können optional einen bestimmten DBM-Typ angeben:

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

Der Typ kann sdbm, gdbm, + ndbm oder db sein. Es wird jedoch + empfohlen, einfach das mit dem Apache HTTP Server mitgelieferte + Dienstprogramm httxt2dbm + zu verwenden, da es die korrekte DBM-Bibliothek verwendet, die mit + der beim Bau von httpd selbst verwendeten übereinstimmt.

+ +

Um eine DBM-Datei zu erstellen, erstellen Sie zunächst eine + Text-Map-Datei wie im Abschnitt txt beschrieben. + Führen Sie dann httxt2dbm aus:

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

Sie können dann die resultierende Datei in Ihrer +RewriteMap-Direktive +referenzieren:

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

Beachten Sie, dass bei einigen DBM-Typen mehr als eine Datei mit +einem gemeinsamen Basisnamen erzeugt wird. Beispielsweise können zwei +Dateien namens mapfile.map.dir und +mapfile.map.pag vorhanden sein. Dies ist normal, und Sie +müssen nur den Basisnamen mapfile.map in Ihrer +RewriteMap-Direktive +verwenden.

+
+ +Zwischengespeicherte Nachschlagungen +

+Die nachgeschlagenen Schlüssel werden von httpd zwischengespeichert, bis +sich die mtime (Änderungszeit) der Map-Datei ändert oder der +httpd-Server neu gestartet wird. Dies gewährleistet eine bessere Leistung +bei Maps, die von vielen Anfragen aufgerufen werden. +

+
+ +
+ +
prg: Externes Umschreibungsprogramm + +

Wenn ein MapType von prg verwendet wird, ist die + MapSource ein Dateisystempfad zu einem ausführbaren Programm, das + das Zuordnungsverhalten bereitstellt. Dies kann eine kompilierte + Binärdatei oder ein Programm in einer interpretierten Sprache wie + Python oder Perl sein.

+ +

Dieses Programm wird einmal beim Start des Apache HTTP Servers + gestartet und kommuniziert dann mit der Umschreibungs-Engine über + STDIN und STDOUT. Für jede Map-Funktions-Nachschlagung + wird der Schlüssel auf das STDIN des Programms geschrieben, + gefolgt von einem Zeilenumbruch. Das Programm sollte eine Zeile von + STDIN lesen (bis einschließlich des Zeilenumbruchs) und + seine Antwort als einzelne durch einen Zeilenumbruch abgeschlossene + Zeile auf STDOUT schreiben. Schlüssel enthalten niemals + Zeilenumbrüche; wenn ein Schlüssel mit einem Zeilenumbruch angetroffen + wird, schlägt die Nachschlagung fehl.

+ +

Wenn es keinen entsprechenden Nachschlagewert gibt, sollte das + Map-Programm den vierstelligen String "NULL" zurückgeben, + um dies anzuzeigen. Beachten Sie, dass dieser Vergleich + Groß-/Kleinschreibung ignoriert, sodass "null", "Null" usw. ebenfalls + als fehlgeschlagene Nachschlagung behandelt werden. Folglich ist es + nicht möglich, dass ein Zuordnungsprogramm den literalen String "NULL" + als zugeordneten Wert zurückgibt.

+ +

Das STDERR des Programms wird vom httpd-Elternprozess + geerbt, sodass alles, was das Programm auf STDERR schreibt, + an derselben Stelle wie die eigene Fehlerausgabe von httpd erscheint + (typischerweise das ErrorLog).

+ +

Externe Umschreibungsprogramme werden nicht gestartet, wenn sie in + einem Kontext definiert sind, der RewriteEngine nicht auf on + gesetzt hat.

+ +

Standardmäßig werden externe Umschreibungsprogramme als der + Benutzer:Gruppe ausgeführt, der httpd gestartet hat. Auf + UNIX-Systemen kann dies geändert werden, indem Benutzername und + Gruppenname als drittes Argument an + RewriteMap im Format + username:groupname übergeben werden.

+ +

Diese Funktion nutzt den rewrite-map-Mutex, der + für eine zuverlässige Kommunikation mit dem Programm erforderlich ist. + Der Mutex-Mechanismus und die Sperrdatei können mit der + Mutex-Direktive konfiguriert + werden.

+ +

Hier wird ein einfaches Beispiel gezeigt, das alle Bindestriche + in einem Anfrage-URI durch Unterstriche ersetzt.

+ +

Umschreibungskonfiguration

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

dash2under.py

+ +#!/usr/bin/env python3 +import sys + +for line in sys.stdin: + print(line.strip().replace('-', '_'), flush=True) + + +Vorsicht! +
    +
  • Halten Sie Ihr Rewrite-Map-Programm so einfach wie möglich. Wenn das +Programm hängt, wartet httpd unbegrenzt auf eine Antwort von der Map, +was wiederum dazu führt, dass httpd nicht mehr auf Anfragen reagiert.
  • +
  • Stellen Sie sicher, dass Sie die Pufferung in Ihrem Programm +deaktivieren. Im obigen Python-Beispiel geschieht dies durch Übergabe von +flush=True an print(). Gepufferte I/O bewirkt, +dass httpd auf die Ausgabe wartet und daher hängen bleibt.
  • +
  • Denken Sie daran, dass nur eine Kopie des Programms existiert, die +beim Serverstart gestartet wird. Alle Anfragen müssen durch diesen einen +Engpass gehen. Dies kann bei vielen Anfragen oder bei einem sehr langsamen +Skript zu erheblichen Verlangsamungen führen.
  • +
  • Wenn das Zuordnungsprogramm beendet wird, wird es nicht automatisch +neu gestartet. Nachfolgende Nachschlagungen werden fehlschlagen, bis der +Server neu gestartet wird.
  • +
  • Das Zuordnungsprogramm wird bei jedem Server-Neustart (ob +graceful oder nicht) beendet und neu gestartet, unabhängig davon, +ob sich die zugehörigen Konfigurationsdirektiven geändert haben. Beim +Herunterfahren wird dem Programm SIGTERM gesendet; wenn +es nicht innerhalb von 3 Sekunden beendet wird, wird SIGKILL +gesendet.
  • +
+
+ +
+ +
+ dbd oder fastdbd: SQL-Abfrage + +

Wenn ein MapType von dbd oder fastdbd + verwendet wird, ist die MapSource eine SQL-SELECT-Anweisung, die + ein einzelnes Argument entgegennimmt und einen einzelnen Wert + zurückgibt.

+ +

mod_dbd muss so konfiguriert werden, dass es auf + die richtige Datenbank zeigt, damit diese Anweisung ausgeführt werden + kann.

+ +

Es gibt zwei Formen dieses MapType. Bei Verwendung eines MapType + von dbd wird die Abfrage bei jeder Map-Anfrage ausgeführt, + während bei fastdbd die Datenbank-Nachschlagungen intern + zwischengespeichert werden. Obwohl fastdbd effizienter + und daher schneller ist, werden Änderungen an der Datenbank erst nach + einem Neustart des Servers übernommen.

+ +

Wenn eine Abfrage mehr als eine Zeile zurückgibt, wird eine + zufällige Zeile aus der Ergebnismenge verwendet.

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

Der Abfragename wird als Label für eine vorbereitete + SQL-Anweisung an den Datenbanktreiber übergeben und muss daher alle + Regeln (wie Groß-/Kleinschreibung) einhalten, die Ihre Datenbank + erfordert.

+ +
+
+ Zusammenfassung + +

Die RewriteMap-Direktive + kann mehrfach vorkommen. Verwenden Sie für jede Zuordnungsfunktion eine + RewriteMap-Direktive, um + ihre Umschreibungs-Map-Datei zu deklarieren.

+ +

Obwohl Sie eine Map nicht im Verzeichniskontext + (.htaccess-Dateien oder + Directory-Blöcke) + deklarieren können, ist es möglich, diese Map im + Verzeichniskontext zu verwenden.

+ +
+
\ No newline at end of file diff --git a/docs/manual/rewrite/rewritemap.xml.es b/docs/manual/rewrite/rewritemap.xml.es new file mode 100644 index 0000000000..aab13ac625 --- /dev/null +++ b/docs/manual/rewrite/rewritemap.xml.es @@ -0,0 +1,486 @@ + + + + + + + Rewrite + Uso de RewriteMap + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +el uso de la directiva RewriteMap, +y proporciona ejemplos de cada uno de los diversos tipos de RewriteMap.

+ + Tenga en cuenta que muchos de estos ejemplos no funcionarán sin cambios en su +configuración particular del servidor, por lo que es importante que los +entienda, en lugar de simplemente copiar y pegar los ejemplos en su +configuración. + +
+ Documentación del módulo + Introducción a mod_rewrite + Redirección y remapeo + Control de acceso + Hosts virtuales + Proxy + Técnicas avanzadas + Cuándo no usar mod_rewrite + +
+ Introducción + +

+ La directiva RewriteMap + define una función externa que puede ser llamada en el contexto de + directivas RewriteRule o + RewriteCond para + realizar reescrituras que son demasiado complicadas, o demasiado especializadas para ser + realizadas solo con expresiones regulares. La fuente de esta búsqueda puede + ser cualquiera de los tipos listados en las secciones siguientes, y enumerados en + la documentación de referencia de RewriteMap.

+ +

La sintaxis de la directiva RewriteMap + es la siguiente:

+ + +RewriteMap MapName MapType:MapSource + + +

El MapName es un + nombre arbitrario que asigna al mapa, y que usará en + directivas más adelante. Los argumentos se pasan al mapa a través de la + siguiente sintaxis:

+ +

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

+ +

Cuando se encuentra tal construcción, se consulta el mapa MapName + y se busca la clave LookupKey. Si la + clave se encuentra, la construcción de función de mapa se sustituye por + SubstValue. Si la clave no se encuentra entonces se + sustituye por DefaultValue o por la cadena vacía + si no se especificó DefaultValue.

+ +

Por ejemplo, puede definir un + RewriteMap como:

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

Entonces podrá usar este mapa en una + RewriteRule de la siguiente manera:

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

Se puede especificar un valor predeterminado en caso de que no se encuentre nada +en el mapa:

+ + +RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}" + + +Contexto per-directorio y .htaccess +

+La directiva RewriteMap no puede usarse +en secciones Directory ni en +archivos .htaccess. Debe +declarar el mapa en contexto de servidor o virtualhost. Puede usar el mapa, +una vez creado, en sus directivas RewriteRule y +RewriteCond en esos +ámbitos. Simplemente no puede declararlo en esos ámbitos.

+
+ +

Las secciones siguientes describen los diversos MapTypes que +pueden usarse, y dan ejemplos de cada uno.

+
+ +
+ int: Función Interna + +

Cuando se usa un MapType de int, el MapSource es una + de las funciones internas disponibles de RewriteMap. + Los autores de módulos pueden proporcionar + funciones internas adicionales registrándolas con la + API ap_register_rewrite_mapfunc. + Las funciones que se proporcionan por defecto son: +

+ +
    +
  • toupper:
    + Convierte la clave a todo mayúsculas.
  • +
  • tolower:
    + Convierte la clave a todo minúsculas.
  • +
  • escape:
    + Traduce caracteres especiales en la clave a + codificaciones hexadecimales.
  • +
  • unescape:
    + Traduce codificaciones hexadecimales en la clave de vuelta a + caracteres especiales.
  • +
+ +

+ Para usar una de estas funciones, cree un RewriteMap que referencie + la función int, y luego úselo en su RewriteRule: +

+ +

Redirigir una URI a una versión toda en minúsculas de sí misma

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

Por favor tenga en cuenta que el ejemplo ofrecido aquí es para + fines ilustrativos únicamente, y no es una recomendación. Si desea + hacer URLs insensibles a mayúsculas/minúsculas, considere usar + mod_speling en su lugar. +

+
+ +
+ +
+ txt: Mapas de texto plano + +

Cuando se usa un MapType de txt, el MapSource es una ruta del sistema de archivos a un + archivo de mapeo de texto plano, que contiene un par clave/valor separado por espacios + por línea. Opcionalmente, una línea puede contener un comentario, comenzando con + un carácter '#'.

+ +

Un archivo de mapa de reescritura de texto válido tendrá la siguiente sintaxis:

+ + + # Línea de comentario
+ MatchingKey SubstValue
+ MatchingKey SubstValue # comentario
+
+ +

Cuando se invoca el RewriteMap, + el argumento se busca en el + primer argumento de una línea, y, si se encuentra, se devuelve el valor de + sustitución.

+ +

Por ejemplo, podemos usar un archivo de mapa para traducir nombres de productos a + IDs de productos para URLs más fáciles de recordar, usando la siguiente + receta:

+

Configuración de Producto a ID

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

Asumimos aquí que el script prods.php sabe qué + hacer cuando recibe un argumento de id=NOTFOUND cuando + un producto no se encuentra en el mapa de búsqueda.

+ +

El archivo /etc/apache2/productmap.txt entonces contiene + lo siguiente:

+ + Mapa de Producto a ID +##
+## productmap.txt - Archivo de mapa de Producto a ID
+##
+
+television 993
+stereo 198
+fishingrod 043
+basketball 418
+telephone 328 +
+ +

Así, cuando se solicita http://example.com/product/television, + se aplica la RewriteRule, + y la solicitud + se mapea internamente a /prods.php?id=993.

+ + Nota: archivos .htaccess + El ejemplo dado está diseñado para usarse en contexto de servidor o virtualhost. + Si planea usarlo en un archivo .htaccess, + necesitará eliminar la barra inicial del patrón de + reescritura para que coincida con algo: + +RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT] + + + + Búsquedas en caché +

+ Las claves buscadas son almacenadas en caché por httpd hasta que el mtime + (tiempo de modificación) del archivo de mapa cambia, o el servidor httpd se + reinicia. Esto asegura un mejor rendimiento en mapas que son llamados + por muchas solicitudes. +

+
+ +
+
+ rnd: Texto Plano Aleatorizado + +

Cuando se usa un MapType de rnd, el MapSource es una + ruta del sistema de archivos a un archivo de mapeo de texto plano, cada línea del cual + contiene una clave, y uno o más valores separados por |. + Uno de estos valores se elegirá al azar si la clave + coincide.

+ +

Por ejemplo, puede usar el siguiente archivo de mapa + y directivas para proporcionar un balanceo de carga aleatorio entre + varios servidores backend, a través de un proxy inverso. Las imágenes se envían + a uno de los servidores en el grupo 'static', mientras que todo + lo demás se envía a uno del grupo 'dynamic'.

+ + Archivo de mapa de reescritura +##
+## map.txt -- mapa de reescritura
+##
+
+static www1|www2|www3|www4
+dynamic www5|www6 +
+

Directivas de configuración

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

Así, cuando se solicita una imagen y la primera de estas reglas + coincide, RewriteMap busca la cadena + static en el archivo de mapa, que devuelve uno de los + nombres de host especificados al azar, que luego se usa en el + destino de la RewriteRule.

+ +

Si quisiera que uno de los servidores sea más probable de ser elegido + (por ejemplo, si uno de los servidores tiene más memoria que los otros, + y por lo tanto puede manejar más solicitudes) simplemente listelo más veces en el + archivo de mapa.

+ + +static www1|www1|www2|www3|www4 + + +
+ +
+ dbm: Archivo Hash DBM + +

Cuando se usa un MapType de dbm, el MapSource es una + ruta del sistema de archivos a un archivo de base de datos DBM que contiene pares clave/valor para + ser usados en el mapeo. Esto funciona exactamente igual que el + mapa txt, pero es mucho más rápido, porque un DBM está indexado, + mientras que un archivo de texto no. Esto permite un acceso más rápido a la + clave deseada.

+ +

Opcionalmente puede especificar un tipo particular de dbm:

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

El tipo puede ser sdbm, gdbm, ndbm + o db. + Sin embargo, se recomienda que simplemente use la utilidad httxt2dbm que se + proporciona con Apache HTTP Server, ya que usará la biblioteca DBM correcta, + que coincida con la que se usó cuando se compiló httpd mismo.

+ +

Para crear un archivo dbm, primero cree un archivo de mapa de texto como se describe + en la sección txt. Luego ejecute + httxt2dbm:

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

Luego puede referenciar el archivo resultante en su +directiva RewriteMap:

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

Tenga en cuenta que con algunos tipos de dbm, se genera más de un archivo, con +un nombre base común. Por ejemplo, puede tener dos archivos llamados +mapfile.map.dir y mapfile.map.pag. Esto es +normal, y solo necesita usar el nombre base mapfile.map en +su directiva RewriteMap.

+
+ +Búsquedas en caché +

+Las claves buscadas son almacenadas en caché por httpd hasta que el mtime +(tiempo de modificación) del archivo de mapa cambia, o el servidor httpd se +reinicia. Esto asegura un mejor rendimiento en mapas que son llamados +por muchas solicitudes. +

+
+ +
+ +
prg: Programa de Reescritura Externo + +

Cuando se usa un MapType de prg, el MapSource es una + ruta del sistema de archivos a un programa ejecutable que proporcionará el + comportamiento de mapeo. Puede ser un archivo binario compilado, o un programa + en un lenguaje interpretado como Python o Perl.

+ +

Este programa se inicia una vez, cuando se inicia Apache HTTP Server, + y luego se comunica con el motor de reescritura a través de + STDIN y STDOUT. Para cada búsqueda de función de mapa, + la clave se escribe en el STDIN del programa, + seguida de un carácter de nueva línea. El programa debería leer una línea + de STDIN (hasta e incluyendo la nueva línea), y + escribir su respuesta como una única línea terminada en nueva línea en + STDOUT. Las claves nunca contendrán caracteres de nueva línea; + si se encuentra una clave que contenga una nueva línea, la búsqueda + fallará.

+ +

Si no hay un valor de búsqueda correspondiente, el programa de mapa + debería devolver la cadena de cuatro caracteres "NULL" para + indicar esto. Tenga en cuenta que esta comparación no distingue entre mayúsculas y minúsculas, así que + "null", "Null", etc. también se tratan como una búsqueda fallida. Como + consecuencia, no es posible que un programa de mapeo devuelva + la cadena literal "NULL" como valor mapeado.

+ +

El STDERR del programa se hereda del + proceso padre de httpd, por lo que cualquier cosa que el programa escriba en + STDERR terminará en el mismo lugar que la propia + salida de errores de httpd (típicamente el ErrorLog).

+ +

Los programas de reescritura externos no se inician si están definidos en + un contexto que no tiene RewriteEngine establecido a + on.

+ +

Por defecto, los programas de reescritura externos se ejecutan como el + usuario:grupo que inició httpd. Esto puede cambiarse en sistemas UNIX + pasando nombre de usuario y nombre de grupo como tercer argumento a + RewriteMap en el + formato username:groupname.

+ +

Esta característica utiliza el mutex rewrite-map, + que es necesario para una comunicación fiable con el programa. + El mecanismo de mutex y el archivo de bloqueo pueden configurarse con la + directiva Mutex.

+ +

Aquí se muestra un ejemplo simple que reemplazará todos los guiones con + guiones bajos en una URI de solicitud.

+ +

Configuración de reescritura

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

dash2under.py

+ +#!/usr/bin/env python3 +import sys + +for line in sys.stdin: + print(line.strip().replace('-', '_'), flush=True) + + +¡Precaución! +
    +
  • Mantenga su programa de mapa de reescritura lo más simple posible. Si el programa +se cuelga, causará que httpd espere indefinidamente por una respuesta del +mapa, lo que a su vez causará que httpd deje de responder a +solicitudes.
  • +
  • Asegúrese de desactivar el buffering en su programa. En el ejemplo de Python +anterior, esto se hace pasando flush=True a +print(). La E/S con buffer causará que httpd espere la +salida, y por lo tanto se colgará.
  • +
  • Recuerde que solo hay una copia del programa, iniciada al +arrancar el servidor. Todas las solicitudes necesitarán pasar por este único cuello de botella. +Esto puede causar ralentizaciones significativas si muchas solicitudes deben pasar por +este proceso, o si el script en sí es muy lento.
  • +
  • Si el programa de mapeo termina, no se reiniciará automáticamente. +Las búsquedas posteriores fallarán hasta que el servidor sea +reiniciado.
  • +
  • El programa de mapeo siempre se mata y reinicia en cualquier +reinicio del servidor (graceful o de otro tipo), independientemente de si las +directivas de configuración relacionadas han cambiado. Al apagar, se envía +SIGTERM al programa; si no sale dentro de 3 segundos, se +le envía SIGKILL.
  • +
+
+ +
+ + +
+ dbd o fastdbd: Consulta SQL + +

Cuando se usa un MapType de dbd o fastdbd, + el MapSource es una sentencia SQL SELECT que toma un solo + argumento y devuelve un solo valor.

+ +

mod_dbd necesitará estar configurado para apuntar a + la base de datos correcta para que esta sentencia se ejecute.

+ +

Hay dos formas de este MapType. + Usar un MapType de dbd causa que la consulta se + ejecute con cada solicitud de mapa, mientras que usar fastdbd + almacena en caché las búsquedas de base de datos internamente. Así, mientras que + fastdbd es más eficiente, y por lo tanto más rápido, no + reflejará los cambios en la base de datos hasta que el servidor sea + reiniciado.

+ +

Si una consulta devuelve más de una fila, se usa una fila aleatoria del + conjunto de resultados.

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

El nombre de la consulta se pasa al controlador de base de datos como una etiqueta para + una sentencia SQL preparada, y por lo tanto necesitará seguir cualquier regla + (como sensibilidad a mayúsculas/minúsculas) requerida por su base de datos.

+ +
+
+ Resumen + +

La directiva RewriteMap puede + aparecer más de una vez. Para cada función de mapeo use una + directiva RewriteMap para declarar + su archivo de mapa de reescritura.

+ +

Aunque no puede declarar un mapa en + contexto per-directorio (archivos .htaccess o + bloques Directory) es + posible usar este mapa en contexto per-directorio.

+ +
+
diff --git a/docs/manual/rewrite/rewritemap.xml.ja b/docs/manual/rewrite/rewritemap.xml.ja new file mode 100644 index 0000000000..558a049963 --- /dev/null +++ b/docs/manual/rewrite/rewritemap.xml.ja @@ -0,0 +1,475 @@ + + + + + + + + + Rewrite + RewriteMap の使用 + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +RewriteMap ディレクティブの使用方法を +説明し、さまざまな RewriteMap +タイプの例を提供します。

+ + これらの例の多くは、特定のサーバ設定ではそのまま +動作しないことに注意してください。そのため、単にコピー&ペーストするのではなく、 +内容を理解することが重要です。 + +
+ モジュールドキュメント + mod_rewrite 入門 + リダイレクトとリマッピング + アクセス制御 + バーチャルホスト + プロキシ + 高度なテクニック + mod_rewrite を使わない場合 + +
+ はじめに + +

+ RewriteMap ディレクティブは、 + RewriteRule または + RewriteCond ディレクティブの + コンテキストで呼び出せる外部関数を定義し、正規表現だけでは実行が + 複雑すぎたり特殊すぎたりする書き換えを行います。この検索のソースは、 + 以下のセクションに記載されているタイプのいずれかで、 + RewriteMap リファレンス + ドキュメントに列挙されています。

+ +

RewriteMap + ディレクティブの構文は以下の通りです:

+ + +RewriteMap MapName MapType:MapSource + + +

MapName は、 + マップに割り当てる任意の名前で、後のディレクティブで使用します。 + 引数は以下の構文でマップに渡されます:

+ +

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

+ +

このような構文が出現すると、マップ MapName が参照され、 + キー LookupKey が検索されます。キーが見つかった場合、 + マップ関数の構文は SubstValue で置換されます。キーが + 見つからなかった場合は、DefaultValue で置換されるか、 + DefaultValue が指定されていない場合は空文字列で + 置換されます。

+ +

例えば、RewriteMap を + 以下のように定義できます:

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

その後、このマップを RewriteRule + で以下のように使用できます:

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

マップで何も見つからなかった場合に備えて、デフォルト値を指定 +できます:

+ + +RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}" + + +ディレクトリ単位および .htaccess コンテキスト +

+RewriteMap ディレクティブは +Directory セクションや +.htaccess ファイルでは使用できません。マップはサーバまたは +バーチャルホストのコンテキストで宣言する必要があります。作成したマップは、 +それらのスコープ内の RewriteRule +および RewriteCond +ディレクティブで使用できます。それらのスコープでマップを +宣言することはできません。

+
+ +

以下のセクションでは、使用可能なさまざまな MapType を +説明し、それぞれの例を示します。

+
+ +
+ int: 内部関数 + +

MapType に int を使用すると、MapSource は利用可能な + 内部 RewriteMap 関数の + いずれかになります。モジュール作成者は、 + ap_register_rewrite_mapfunc API を使用して追加の内部 + 関数を登録できます。 + デフォルトで提供される関数は以下の通りです: +

+ +
    +
  • toupper:
    + キーをすべて大文字に変換します。
  • +
  • tolower:
    + キーをすべて小文字に変換します。
  • +
  • escape:
    + キー内の特殊文字を 16 進エンコーディングに変換します。
  • +
  • unescape:
    + キー内の 16 進エンコーディングを特殊文字に戻します。
  • +
+ +

+ これらの関数のいずれかを使用するには、int 関数を参照する + RewriteMap を作成し、 + RewriteRule で使用します: +

+ +

URI をすべて小文字のバージョンにリダイレクト

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

ここで提供されている例は説明目的のみであり、推奨ではありません。 + URL を大文字小文字を区別しないようにしたい場合は、代わりに + mod_speling の使用を検討してください。 +

+
+ +
+ +
+ txt: プレーンテキストマップ + +

MapType に txt を使用すると、MapSource はプレーンテキストの + マッピングファイルへのファイルシステムパスで、1 行に 1 つのスペース区切りの + キー/値ペアが含まれます。オプションで、'#' 文字で始まるコメント行を + 含めることができます。

+ +

有効なテキスト書き換えマップファイルの構文は以下の通りです:

+ + + # コメント行
+ MatchingKey SubstValue
+ MatchingKey SubstValue # コメント
+
+ +

RewriteMap が呼び出されると、 + 引数が各行の最初の引数から検索され、見つかった場合は置換値が + 返されます。

+ +

例えば、マップファイルを使用して製品名を製品 ID に変換し、 + 覚えやすい URL を実現するには、以下のレシピを使用できます:

+

製品から ID への設定

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

ここでは、prods.php スクリプトが + id=NOTFOUND という引数を受け取った場合の処理を + 理解していると仮定しています (検索マップで製品が見つからなかった場合)。

+ +

ファイル /etc/apache2/productmap.txt には + 以下が含まれます:

+ + 製品から ID へのマップ +##
+## productmap.txt - 製品から ID へのマップファイル
+##
+
+television 993
+stereo 198
+fishingrod 043
+basketball 418
+telephone 328 +
+ +

したがって、http://example.com/product/television が + リクエストされると、RewriteRule + が適用され、リクエストは内部的に /prods.php?id=993 + にマッピングされます。

+ + 注: .htaccess ファイル + この例はサーバまたはバーチャルホストのスコープで使用するよう + 作成されています。.htaccess ファイルで使用する場合は、 + 何かにマッチするように書き換えパターンから先頭のスラッシュを + 削除する必要があります: + +RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT] + + + + キャッシュされた検索 +

+ 検索されたキーは、マップファイルの mtime (変更時刻) が + 変更されるか、httpd サーバが再起動されるまで httpd にキャッシュ + されます。これにより、多くのリクエストで呼び出されるマップの + パフォーマンスが向上します。 +

+
+ +
+
+ rnd: ランダム化プレーンテキスト + +

MapType に rnd を使用すると、MapSource はプレーンテキストの + マッピングファイルへのファイルシステムパスで、各行にはキーと + | で区切られた 1 つ以上の値が含まれます。キーが + マッチすると、これらの値の 1 つがランダムに選択されます。

+ +

例えば、以下のマップファイルとディレクティブを使用して、 + リバースプロキシ経由で複数のバックエンドサーバ間のランダムな + ロードバランシングを提供できます。画像は 'static' プール内の + サーバの 1 つに送信され、それ以外は 'dynamic' プールの 1 つに + 送信されます。

+ + 書き換えマップファイル +##
+## map.txt -- 書き換えマップ
+##
+
+static www1|www2|www3|www4
+dynamic www5|www6 +
+

設定ディレクティブ

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

画像がリクエストされ、最初のルールがマッチすると、 + RewriteMap はマップファイルで + 文字列 static を検索し、指定されたホスト名の 1 つを + ランダムに返します。それが RewriteRule + のターゲットで使用されます。

+ +

サーバの 1 つがより多く選択されるようにしたい場合 + (例えば、サーバの 1 つがより多くのメモリを持ち、より多くの + リクエストを処理できる場合)、マップファイルにそのサーバを + 複数回記述してください。

+ + +static www1|www1|www2|www3|www4 + + +
+ +
+ dbm: DBM ハッシュファイル + +

MapType に dbm を使用すると、MapSource はマッピングで + 使用されるキー/値ペアを含む DBM データベースファイルへの + ファイルシステムパスです。これは txt マップと + まったく同じように動作しますが、DBM はインデックス化されており + テキストファイルはそうではないため、はるかに高速です。これにより、 + 目的のキーへのアクセスが高速になります。

+ +

特定の dbm タイプをオプションで指定できます:

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

タイプは sdbm、gdbm、ndbm、 + または db です。 + ただし、Apache HTTP Server に付属の httxt2dbm ユーティリティを + 使用することを推奨します。httpd 自体のビルド時に使用されたものと + マッチする正しい DBM ライブラリを使用するためです。

+ +

dbm ファイルを作成するには、まず txt セクションで + 説明されているテキストマップファイルを作成し、次に + httxt2dbm を実行します:

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

その後、RewriteMap +ディレクティブで結果のファイルを参照できます:

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

dbm タイプによっては、共通のベース名で複数のファイルが生成される +ことがあることに注意してください。例えば、mapfile.map.dir +と mapfile.map.pag という 2 つのファイルが存在する +場合があります。これは正常であり、RewriteMap +ディレクティブではベース名 mapfile.map のみを使用 +してください。

+
+ +キャッシュされた検索 +

+検索されたキーは、マップファイルの mtime (変更時刻) が +変更されるか、httpd サーバが再起動されるまで httpd にキャッシュ +されます。これにより、多くのリクエストで呼び出されるマップの +パフォーマンスが向上します。 +

+
+ +
+ +
prg: 外部書き換えプログラム + +

MapType に prg を使用すると、MapSource はマッピング動作を + 提供する実行可能プログラムへのファイルシステムパスです。これは + コンパイル済みバイナリファイル、または Python や Perl などの + インタプリタ言語のプログラムです。

+ +

このプログラムは Apache HTTP Server の起動時に一度起動され、 + STDIN と STDOUT を通じて書き換えエンジンと + 通信します。各マップ関数の検索では、キーがプログラムの + STDIN に書き込まれ、その後に改行文字が続きます。 + プログラムは STDIN から 1 行 (改行を含む) を読み取り、 + 応答を改行で終わる 1 行として STDOUT に書き込む + 必要があります。キーに改行文字が含まれることはありません。 + 改行を含むキーが検出された場合、検索は失敗します。

+ +

対応する検索値がない場合、マッププログラムは 4 文字の + 文字列 "NULL" を返して、これを示す必要があります。 + この比較は大文字小文字を区別しないため、"null"、"Null" 等も + 検索失敗として扱われます。その結果、マッピングプログラムが + リテラル文字列 "NULL" をマップされた値として返すことは + できません。

+ +

プログラムの STDERR は httpd 親プロセスから + 継承されるため、プログラムが STDERR に書き込む内容は + httpd 自体のエラー出力 (通常は ErrorLog) と同じ場所に記録されます。

+ +

外部書き換えプログラムは、RewriteEngine が on に + 設定されていないコンテキストで定義されている場合は起動されません。

+ +

デフォルトでは、外部書き換えプログラムは httpd を起動した + ユーザ:グループとして実行されます。これは UNIX システムでは + RewriteMap の 3 番目の + 引数として username:groupname 形式でユーザ名と + グループ名を渡すことで変更できます。

+ +

この機能は rewrite-map ミューテックスを使用しており、 + プログラムとの信頼性のある通信に必要です。ミューテックスの + メカニズムとロックファイルは Mutex + ディレクティブで設定できます。

+ +

リクエスト URI 内のすべてのダッシュをアンダースコアに置き換える + シンプルな例を以下に示します。

+ +

書き換え設定

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

dash2under.py

+ +#!/usr/bin/env python3 +import sys + +for line in sys.stdin: + print(line.strip().replace('-', '_'), flush=True) + + +注意! +
    +
  • 書き換えマッププログラムはできるだけシンプルに保ってください。 +プログラムがハングすると、httpd はマップからのレスポンスを +無期限に待つことになり、その結果 httpd がリクエストへの応答を +停止します。
  • +
  • プログラムでバッファリングを必ずオフにしてください。上記の +Python の例では、print() に flush=True を +渡すことでこれを行っています。バッファされた I/O は httpd が +出力を待つ原因となり、ハングします。
  • +
  • プログラムは 1 コピーのみで、サーバ起動時に開始されることを +忘れないでください。すべてのリクエストはこの 1 つのボトルネックを +通過する必要があります。多くのリクエストがこのプロセスを通過する +必要がある場合や、スクリプト自体が非常に遅い場合、これは +著しい速度低下を引き起こす可能性があります。
  • +
  • マッピングプログラムが終了しても、自動的に再起動されません。 +以降の検索はサーバが再起動されるまで失敗します。
  • +
  • マッピングプログラムは、関連する設定ディレクティブが変更されたか +どうかに関係なく、サーバの再起動 (graceful またはそれ以外) 時に +常に kill され再起動されます。シャットダウン時にプログラムには +SIGTERM が送信されます。3 秒以内に終了しない場合は +SIGKILL が送信されます。
  • +
+
+ +
+ + +
+ dbd または fastdbd: SQL クエリ + +

MapType に dbd または fastdbd を使用すると、 + MapSource は単一の引数を取り、単一の値を返す SQL SELECT 文です。

+ +

この文を実行するために、mod_dbd を正しい + データベースを指すように設定する必要があります。

+ +

この MapType には 2 つの形式があります。 + MapType に dbd を使用すると、各マップリクエストで + クエリが実行されますが、fastdbd を使用すると + データベース検索が内部的にキャッシュされます。したがって、 + fastdbd はより効率的で高速ですが、サーバが + 再起動されるまでデータベースの変更を検出しません。

+ +

クエリが複数の行を返す場合、結果セットからランダムな行が + 使用されます。

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

クエリ名は SQL プリペアドステートメントのラベルとして + データベースドライバに渡されるため、データベースで必要な + ルール (大文字小文字の区別など) に従う必要があります。

+ +
+
+ まとめ + +

RewriteMap ディレクティブは + 複数回使用できます。各マッピング関数に対して 1 つの + RewriteMap ディレクティブを + 使用して書き換えマップファイルを宣言してください。

+ +

ディレクトリ単位のコンテキスト (.htaccess ファイルや + Directory ブロック) + ではマップを宣言できませんが、ディレクトリ単位の + コンテキストでこのマップを使用することは可能です。

+ +
+
diff --git a/docs/manual/rewrite/rewritemap.xml.ko b/docs/manual/rewrite/rewritemap.xml.ko new file mode 100644 index 0000000000..686edd71e7 --- /dev/null +++ b/docs/manual/rewrite/rewritemap.xml.ko @@ -0,0 +1,486 @@ + + + + + + + + Rewrite + RewriteMap 사용하기 + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +RewriteMap 지시어의 +사용법을 설명하고 다양한 RewriteMap 유형의 예제를 제공합니다.

+ + 이 예제들 중 많은 것이 특정 서버 설정에서 +그대로 작동하지 않을 수 있으므로, 단순히 예제를 복사하여 +설정에 붙여넣기보다는 이해하는 것이 중요합니다. + +
+ 모듈 문서 + mod_rewrite 소개 + 리다이렉션과 재매핑 + 접근 제어 + 가상 호스트 + 프록시 + 고급 기술 + mod_rewrite를 사용하지 말아야 할 경우 + +
+ 소개 + +

+ RewriteMap 지시어는 + RewriteRule 또는 + RewriteCond 지시어의 + 컨텍스트에서 호출할 수 있는 외부 함수를 정의하여 + 정규 표현식만으로는 너무 복잡하거나 너무 전문화된 + 재작성을 수행합니다. 이 조회의 소스는 아래 섹션에 + 나열되고 RewriteMap + 참조 문서에 열거된 유형 중 하나일 수 있습니다.

+ +

RewriteMap + 지시어의 구문은 다음과 같습니다:

+ + +RewriteMap MapName MapType:MapSource + + +

MapName은 + 맵에 할당하는 임의의 이름이며, 이후 지시어에서 + 사용합니다. 인수는 다음 구문을 통해 맵에 전달됩니다:

+ +

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

+ +

이러한 구조가 발생하면 맵 MapName이 + 조회되고 키 LookupKey가 검색됩니다. 키가 + 발견되면 맵 함수 구조는 SubstValue로 + 대체됩니다. 키를 찾지 못하면 DefaultValue로 + 대체되거나, DefaultValue가 지정되지 않은 + 경우 빈 문자열로 대체됩니다.

+ +

예를 들어 다음과 같이 + RewriteMap을 + 정의할 수 있습니다:

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

그러면 RewriteRule에서 + 다음과 같이 이 맵을 사용할 수 있습니다:

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

맵에서 아무것도 찾지 못한 경우를 대비하여 기본값을 +지정할 수 있습니다:

+ + +RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}" + + +디렉토리별 및 .htaccess 컨텍스트 +

+RewriteMap 지시어는 +Directory 섹션이나 +.htaccess 파일에서 사용할 수 없습니다. 서버 또는 +가상호스트 컨텍스트에서 맵을 선언해야 합니다. 일단 생성된 맵은 +해당 범위의 RewriteRule과 +RewriteCond 지시어에서 +사용할 수 있습니다. 해당 범위에서 선언할 수 +없을 뿐입니다.

+
+ +

다음 섹션에서는 사용할 수 있는 다양한 MapType을 +설명하고 각각의 예제를 제공합니다.

+
+ +
+ int: 내부 함수 + +

MapType이 int인 경우 MapSource는 사용 가능한 + 내부 RewriteMap + 함수 중 하나입니다. 모듈 작성자는 + ap_register_rewrite_mapfunc API를 등록하여 + 추가 내부 함수를 제공할 수 있습니다. + 기본적으로 제공되는 함수는 다음과 같습니다: +

+ +
    +
  • toupper:
    + 키를 모두 대문자로 변환합니다.
  • +
  • tolower:
    + 키를 모두 소문자로 변환합니다.
  • +
  • escape:
    + 키의 특수 문자를 16진수 인코딩으로 변환합니다.
  • +
  • unescape:
    + 키의 16진수 인코딩을 다시 특수 문자로 변환합니다.
  • +
+ +

+ 이러한 함수 중 하나를 사용하려면 int 함수를 참조하는 + RewriteMap을 + 생성한 다음 RewriteRule에서 사용합니다: +

+ +

URI를 모두 소문자 버전으로 리다이렉트

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

여기에 제공된 예제는 설명 목적으로만 제공되며 + 권장 사항이 아닙니다. URL을 대소문자 구분 없이 + 만들려면 대신 mod_speling 사용을 + 고려하십시오. +

+
+ +
+ +
+ txt: 일반 텍스트 맵 + +

MapType이 txt인 경우 MapSource는 + 한 줄에 하나의 공백으로 구분된 키/값 쌍을 포함하는 + 일반 텍스트 매핑 파일의 파일 시스템 경로입니다. + 선택적으로 '#' 문자로 시작하는 주석이 포함될 수 + 있습니다.

+ +

유효한 텍스트 재작성 맵 파일은 다음과 같은 구문을 + 가집니다:

+ + + # 주석 줄
+ MatchingKey SubstValue
+ MatchingKey SubstValue # 주석
+
+ +

RewriteMap이 + 호출되면 인수가 줄의 첫 번째 인수에서 검색되고, + 발견되면 치환 값이 반환됩니다.

+ +

예를 들어, 기억하기 쉬운 URL을 위해 제품 이름을 + 제품 ID로 변환하는 맵 파일을 사용할 수 있습니다:

+

제품에서 ID로의 설정

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

여기서 prods.php 스크립트는 조회 맵에서 + 제품을 찾지 못했을 때 id=NOTFOUND 인수를 + 받으면 어떻게 해야 하는지 알고 있다고 가정합니다.

+ +

/etc/apache2/productmap.txt 파일에는 + 다음이 포함됩니다:

+ + 제품에서 ID로의 맵 +##
+## productmap.txt - 제품에서 ID로의 맵 파일
+##
+
+television 993
+stereo 198
+fishingrod 043
+basketball 418
+telephone 328 +
+ +

따라서 http://example.com/product/television이 + 요청되면 RewriteRule이 + 적용되고 요청은 내부적으로 + /prods.php?id=993에 매핑됩니다.

+ + 참고: .htaccess 파일 + 주어진 예제는 서버 또는 가상호스트 범위에서 사용하도록 + 작성되었습니다. .htaccess 파일에서 사용할 + 계획이라면, 무엇이든 일치하도록 재작성 패턴에서 앞의 + 슬래시를 제거해야 합니다: + +RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT] + + + + 캐시된 조회 +

+ 조회된 키는 맵 파일의 mtime(수정 시간)이 + 변경되거나 httpd 서버가 재시작될 때까지 httpd에 의해 + 캐시됩니다. 이는 많은 요청에 의해 호출되는 맵의 + 성능을 향상시킵니다. +

+
+ +
+
+ rnd: 무작위 일반 텍스트 + +

MapType이 rnd인 경우 MapSource는 일반 + 텍스트 매핑 파일의 파일 시스템 경로이며, 각 줄에는 + 키와 |로 구분된 하나 이상의 값이 포함됩니다. + 키가 일치하면 이 값 중 하나가 무작위로 선택됩니다.

+ +

예를 들어, 리버스 프록시를 통한 무작위 부하 분산을 + 위해 다음 맵 파일과 지시어를 사용할 수 있습니다. + 이미지는 'static' 풀의 서버 중 하나로 전송되고, + 나머지는 'dynamic' 풀의 서버 중 하나로 전송됩니다.

+ + 재작성 맵 파일 +##
+## map.txt -- 재작성 맵
+##
+
+static www1|www2|www3|www4
+dynamic www5|www6 +
+

설정 지시어

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

따라서 이미지가 요청되고 이 규칙 중 첫 번째가 + 일치하면 RewriteMap은 + 맵 파일에서 문자열 static을 조회하고 + 지정된 호스트명 중 하나를 무작위로 반환하여 + RewriteRule + 대상에서 사용합니다.

+ +

서버 중 하나가 선택될 확률을 높이려면(예를 들어 + 서버 중 하나가 더 많은 메모리를 가지고 있어 더 많은 + 요청을 처리할 수 있는 경우) 맵 파일에 해당 서버를 + 더 많이 나열하면 됩니다.

+ + +static www1|www1|www2|www3|www4 + + +
+ +
+ dbm: DBM 해시 파일 + +

MapType이 dbm인 경우 MapSource는 + 매핑에 사용할 키/값 쌍을 포함하는 DBM 데이터베이스 + 파일의 파일 시스템 경로입니다. 이것은 txt + 맵과 정확히 같은 방식으로 작동하지만, DBM은 인덱싱되어 + 있는 반면 텍스트 파일은 그렇지 않으므로 훨씬 빠릅니다. + 이를 통해 원하는 키에 더 빠르게 접근할 수 있습니다.

+ +

선택적으로 특정 dbm 유형을 지정할 수 있습니다:

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

유형은 sdbm, gdbm, + ndbm 또는 db일 수 있습니다. + 그러나 httpd 자체가 빌드될 때 사용된 것과 일치하는 + 올바른 DBM 라이브러리를 사용하므로 Apache HTTP Server와 + 함께 제공되는 httxt2dbm + 유틸리티를 사용하는 것이 좋습니다.

+ +

dbm 파일을 생성하려면 먼저 txt + 섹션에 설명된 대로 텍스트 맵 파일을 생성합니다. 그런 다음 + httxt2dbm을 실행합니다:

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

그런 다음 RewriteMap +지시어에서 결과 파일을 참조할 수 있습니다:

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

일부 dbm 유형에서는 공통 기본 이름을 가진 둘 이상의 +파일이 생성됩니다. 예를 들어 mapfile.map.dir과 +mapfile.map.pag라는 두 파일이 있을 수 있습니다. +이것은 정상이며 RewriteMap +지시어에서 기본 이름인 mapfile.map만 사용하면 +됩니다.

+
+ +캐시된 조회 +

+조회된 키는 맵 파일의 mtime(수정 시간)이 +변경되거나 httpd 서버가 재시작될 때까지 httpd에 의해 +캐시됩니다. 이는 많은 요청에 의해 호출되는 맵의 +성능을 향상시킵니다. +

+
+ +
+ +
prg: 외부 재작성 프로그램 + +

MapType이 prg인 경우 MapSource는 + 매핑 동작을 제공할 실행 가능한 프로그램의 파일 시스템 + 경로입니다. 이것은 컴파일된 바이너리 파일이거나 + Python이나 Perl과 같은 인터프리터 언어의 프로그램일 수 + 있습니다.

+ +

이 프로그램은 Apache HTTP Server가 시작될 때 한 번 + 시작되며, STDIN과 STDOUT을 + 통해 재작성 엔진과 통신합니다. 각 맵 함수 조회에 대해 + 키가 프로그램의 STDIN에 기록되고 그 뒤에 + 줄바꿈 문자가 옵니다. 프로그램은 STDIN에서 + 한 줄을 읽고(줄바꿈 포함) 응답을 + STDOUT에 줄바꿈으로 끝나는 한 줄로 + 작성해야 합니다. 키에는 줄바꿈 문자가 포함되지 + 않으며, 줄바꿈이 포함된 키가 발견되면 조회가 + 실패합니다.

+ +

대응하는 조회 값이 없으면 맵 프로그램은 + 네 문자 문자열 "NULL"을 반환하여 이를 + 나타내야 합니다. 이 비교는 대소문자를 구분하지 + 않으므로 "null", "Null" 등도 실패한 조회로 + 처리됩니다. 결과적으로 매핑 프로그램이 매핑된 값으로 + 리터럴 문자열 "NULL"을 반환하는 것은 불가능합니다.

+ +

프로그램의 STDERR은 httpd 부모 + 프로세스에서 상속되므로 프로그램이 STDERR에 + 쓰는 모든 것은 httpd의 자체 오류 출력과 같은 곳(일반적으로 + ErrorLog)에 + 기록됩니다.

+ +

외부 재작성 프로그램은 RewriteEngine이 + on으로 설정되지 않은 컨텍스트에서 + 정의된 경우 시작되지 않습니다.

+ +

기본적으로 외부 재작성 프로그램은 httpd를 시작한 + user:group으로 실행됩니다. 이것은 UNIX 시스템에서 + RewriteMap의 + 세 번째 인수로 username:groupname 형식으로 + 사용자 이름과 그룹 이름을 전달하여 변경할 수 있습니다.

+ +

이 기능은 프로그램과의 안정적인 통신에 필요한 + rewrite-map 뮤텍스를 활용합니다. + 뮤텍스 메커니즘과 잠금 파일은 Mutex 지시어로 구성할 수 + 있습니다.

+ +

여기에 요청 URI에서 모든 대시를 밑줄로 대체하는 + 간단한 예제가 나와 있습니다.

+ +

재작성 설정

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

dash2under.py

+ +#!/usr/bin/env python3 +import sys + +for line in sys.stdin: + print(line.strip().replace('-', '_'), flush=True) + + +주의! +
    +
  • 재작성 ë§µ 프로그램을 가능한 한 간단하게 유지하십시오. +프로그램이 멈추면 httpd가 맵의 응답을 무한정 기다리게 되고, +이는 다시 httpd가 요청에 응답하지 못하게 합니다.
  • +
  • 프로그램에서 버퍼링을 끄십시오. 위의 Python 예제에서는 +print()에 flush=True를 전달하여 +이를 수행합니다. 버퍼링된 I/O는 httpd가 출력을 기다리게 +하므로 멈추게 됩니다.
  • +
  • 서버 시작 시 시작되는 프로그램의 복사본은 하나뿐입니다. +모든 요청이 이 하나의 병목을 통과해야 합니다. 많은 요청이 +이 프로세스를 통과해야 하거나 스크립트 자체가 매우 느린 +경우 상당한 속도 저하를 초래할 수 있습니다.
  • +
  • 매핑 프로그램이 종료되면 자동으로 다시 시작되지 않습니다. +서버가 재시작될 때까지 후속 조회가 실패합니다.
  • +
  • 매핑 프로그램은 관련 설정 지시어가 변경되었는지 여부에 +관계없이 서버 재시작(graceful 또는 기타) 시 항상 종료되고 +다시 시작됩니다. 종료 시 프로그램에 SIGTERM이 +전송되며, 3초 이내에 종료되지 않으면 +SIGKILL이 전송됩니다.
  • +
+
+ +
+ + +
+ dbd 또는 fastdbd: SQL 쿼리 + +

MapType이 dbd 또는 fastdbd인 + 경우 MapSource는 단일 인수를 받아 단일 값을 반환하는 + SQL SELECT 문입니다.

+ +

이 문이 실행되려면 올바른 데이터베이스를 가리키도록 + mod_dbd를 구성해야 합니다.

+ +

이 MapType에는 두 가지 형태가 있습니다. + dbd MapType을 사용하면 각 맵 요청마다 + 쿼리가 실행되고, fastdbd를 사용하면 + 데이터베이스 조회가 내부적으로 캐시됩니다. 따라서 + fastdbd가 더 효율적이고 빠르지만, + 서버가 재시작될 때까지 데이터베이스 변경 사항을 + 반영하지 않습니다.

+ +

쿼리가 둘 이상의 행을 반환하면 결과 세트에서 + 무작위 행이 사용됩니다.

+ + 예제 + +RewriteMap myquery "fastdbd:SELECT destination FROM rewrite WHERE source = %s" + + + + 참고 +

쿼리 이름은 SQL 준비된 문의 레이블로 데이터베이스 + 드라이버에 전달되므로 데이터베이스에 필요한 모든 + 규칙(대소문자 구분 등)을 따라야 합니다.

+ +
+
+ 요약 + +

RewriteMap 지시어는 + 여러 번 사용할 수 있습니다. 각 매핑 함수에 대해 하나의 + RewriteMap 지시어를 + 사용하여 재작성 맵 파일을 선언합니다.

+ +

디렉토리별 컨텍스트(.htaccess 파일이나 + Directory + 블록)에서는 맵을 선언할 수 없지만 + 디렉토리별 컨텍스트에서 이 맵을 사용하는 + 것은 가능합니다.

+ +
+
diff --git a/docs/manual/rewrite/rewritemap.xml.meta b/docs/manual/rewrite/rewritemap.xml.meta index b77e9e6168..e9a5bc67ef 100644 --- a/docs/manual/rewrite/rewritemap.xml.meta +++ b/docs/manual/rewrite/rewritemap.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/rewritemap.xml.tr b/docs/manual/rewrite/rewritemap.xml.tr new file mode 100644 index 0000000000..de9b19a3d6 --- /dev/null +++ b/docs/manual/rewrite/rewritemap.xml.tr @@ -0,0 +1,506 @@ + + + + + + + Rewrite + RewriteMap Kullanımı + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +RewriteMap yönergesinin +kullanımını açıklar ve çeşitli RewriteMap türlerinin her birine örnekler sunar.

+ + Bu örneklerin birçoğunun sizin sunucu +yapılandırmanızda değişiklik yapılmadan çalışmayacağını unutmayın; bu +nedenle örnekleri yapılandırmanıza kopyalayıp yapıştırmak yerine +anlamanız önemlidir. + +
+ Modül belgeleri + mod_rewrite'a giriş + Yeniden yönlendirme ve yeniden eşleme + Erişim denetimi + Sanal konaklar + Vekil kullanımı + İleri teknikler + mod_rewrite kullanılmaması gereken durumlar + +
+ Giriş + +

+ RewriteMap yönergesi, + düzenli ifadelerle gerçekleştirilmesi çok karmaşık veya çok özel + olan yeniden yazma işlemlerini yapmak üzere + RewriteRule veya + RewriteCond yönergeleri + bağlamında çağrılabilecek harici bir işlev tanımlar. Bu aramanın + kaynağı, aşağıdaki bölümlerde listelenen türlerden herhangi biri + olabilir ve RewriteMap + başvuru belgelerinde numaralandırılmıştır.

+ +

RewriteMap + yönergesinin sözdizimi şöyledir:

+ + +RewriteMap EşlemAdı EşlemTürü:EşlemKaynağı + + +

EşlemAdı, eşleme + için atadığınız keyfi bir addır ve daha sonra yönergelerde + kullanacaksınız. Argümanlar eşlemeye aşağıdaki sözdizimi ile + iletilir:

+ +

+ + ${ EşlemAdı : AramaAnahtarı + }
${ EşlemAdı : + AramaAnahtarı | ÖntanımlıDeğer } +
+

+ +

Böyle bir yapı oluştuğunda, EşlemAdı eşlemine + başvurulur ve AramaAnahtarı aranır. Anahtar bulunursa + eşlem-işlev yapısı DeğiştirmeDeğeri ile değiştirilir. + Anahtar bulunamazsa ÖntanımlıDeğer ile veya hiçbir + ÖntanımlıDeğer belirtilmemişse boş dizgeyle + değiştirilir.

+ +

Örneğin, bir + RewriteMap şöyle + tanımlayabilirsiniz:

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

Daha sonra bu eşlemi bir + RewriteRule + içinde şöyle kullanabilirsiniz:

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

Eşlemde hiçbir şey bulunamazsa öntanımlı bir değer +belirtilebilir:

+ + +RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}" + + +Dizin başına ve .htaccess bağlamı +

+RewriteMap yönergesi +Directory +bölümlerinde veya .htaccess dosyalarında kullanılamaz. +Eşlemi sunucu veya sanal konak bağlamında bildirmelisiniz. Eşlemi +oluşturduktan sonra, RewriteRule ve RewriteCond yönergelerinizde bu +kapsamlarda kullanabilirsiniz. Ancak bu kapsamlarda +bildirme yapamazsınız.

+
+ +

Aşağıdaki bölümler kullanılabilecek çeşitli EşlemTürü +değerlerini açıklar ve her birine örnekler verir.

+
+ +
+ int: Dahili İşlev + +

int EşlemTürü kullanıldığında, EşlemKaynağı + kullanılabilir dahili RewriteMap işlevlerinden biridir. + Modül yazarları, ap_register_rewrite_mapfunc API'sini + kullanarak ek dahili işlevler sağlayabilir. Öntanımlı olarak + sağlanan işlevler şunlardır: +

+ +
    +
  • toupper:
    + Anahtarı tamamen büyük harfe dönüştürür.
  • +
  • tolower:
    + Anahtarı tamamen küçük harfe dönüştürür.
  • +
  • escape:
    + Anahtardaki özel karakterleri onaltılık kodlamaya + çevirir.
  • +
  • unescape:
    + Anahtardaki onaltılık kodlamaları özel karakterlere geri + çevirir.
  • +
+ +

+ Bu işlevlerden birini kullanmak için, int işlevine başvuran bir + RewriteMap oluşturun + ve ardından bunu RewriteRule yönergenizde + kullanın: +

+ +

Bir URI'yi tamamen küçük harfli sürümüne + yönlendir

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

Burada sunulan örneğin yalnızca açıklama amaçlı olduğunu ve + bir öneri olmadığını lütfen unutmayın. URL'leri büyük/küçük harf + duyarsız yapmak istiyorsanız, bunun yerine + mod_speling kullanmayı düşünün. +

+
+ +
+ +
+ txt: Düz Metin Eşlemleri + +

txt EşlemTürü kullanıldığında, EşlemKaynağı satır + başına bir boşlukla ayrılmış anahtar/değer çifti içeren düz metin + eşlem dosyasının bir dosya sistemi yoludur. İsteğe bağlı olarak, + bir satır '#' karakteriyle başlayan bir açıklama içerebilir.

+ +

Geçerli bir metin yeniden yazma eşlem dosyası aşağıdaki + sözdizimine sahip olacaktır:

+ + + # Açıklama satırı
+ EşleşenAnahtar DeğiştirmeDeğeri
+ EşleşenAnahtar DeğiştirmeDeğeri # açıklama
+
+ +

RewriteMap + çağrıldığında, argüman bir satırın ilk argümanında aranır ve + bulunursa değiştirme değeri döndürülür.

+ +

Örneğin, daha kolay hatırlanan URL'ler için ürün adlarını + ürün kimliklerine çevirmek üzere aşağıdaki tarifi kullanarak bir + eşlem dosyası kullanabiliriz:

+

Ürün-kimlik yapılandırması

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

Burada prods.php betiğinin, bir ürün arama + eşleminde bulunmadığında id=NOTFOUND argümanını + aldığında ne yapacağını bildiğini varsayıyoruz.

+ +

/etc/apache2/productmap.txt dosyası daha sonra + şunları içerir:

+ + Ürün-kimlik eşlem dosyası +##
+## productmap.txt - Ürün-Kimlik eşlem dosyası
+##
+
+television 993
+stereo 198
+fishingrod 043
+basketball 418
+telephone 328 +
+ +

Böylece, http://example.com/product/television + istendiğinde, RewriteRule + uygulanır ve istek dahili olarak + /prods.php?id=993 ile eşlenir.

+ + Not: .htaccess dosyaları + Verilen örnek sunucu veya sanal konak kapsamında kullanılmak üzere + hazırlanmıştır. Bunu bir .htaccess dosyasında + kullanmayı planlıyorsanız, herhangi bir şeyle eşleşebilmesi için + yeniden yazma kalıbından baştaki eğik çizgiyi kaldırmanız + gerekecektir: + +RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT] + + + + Önbelleğe alınmış aramalar +

+ Aranan anahtarlar, eşlem dosyasının mtime + (değiştirme zamanı) değişene veya httpd sunucusu yeniden + başlatılana kadar httpd tarafından önbelleğe alınır. Bu, birçok + istek tarafından çağrılan eşlemler için daha iyi performans + sağlar. +

+
+ +
+
+ rnd: Rastgeleleştirilmiş Düz Metin + +

rnd EşlemTürü kullanıldığında, EşlemKaynağı her + satırı bir anahtar ve | ile ayrılmış bir veya daha + fazla değer içeren düz metin eşlem dosyasının bir dosya sistemi + yoludur. Anahtar eşleşirse bu değerlerden biri rastgele + seçilir.

+ +

Örneğin, ters vekil aracılığıyla birkaç arka uç sunucu + arasında rastgele yük dengeleme sağlamak için aşağıdaki eşlem + dosyasını ve yönergeleri kullanabilirsiniz. Resimler 'static' + havuzundaki sunuculardan birine gönderilirken, diğer her şey + 'dynamic' havuzuna gönderilir.

+ + Yeniden yazma eşlem dosyası +##
+## map.txt -- yeniden yazma eşlem dosyası
+##
+
+static www1|www2|www3|www4
+dynamic www5|www6 +
+

Yapılandırma yönergeleri

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

Böylece, bir resim istendiğinde ve bu kurallardan ilki + eşleştiğinde, RewriteMap + eşlem dosyasında static dizgesini arar ve belirtilen + konak adlarından birini rastgele döndürür; bu daha sonra + RewriteRule hedefinde + kullanılır.

+ +

Sunuculardan birinin daha sık seçilmesini istiyorsanız (örneğin, + sunuculardan birinin daha fazla belleği varsa ve daha fazla isteği + işleyebiliyorsa), onu eşlem dosyasında daha fazla kez listeleyin.

+ + +static www1|www1|www2|www3|www4 + + +
+ +
+ dbm: DBM Adresleme Dosyası + +

dbm EşlemTürü kullanıldığında, EşlemKaynağı + eşlemede kullanılacak anahtar/değer çiftleri içeren bir DBM + veritabanı dosyasının dosya sistemi yoludur. Bu, txt + eşlemiyle tamamen aynı şekilde çalışır, ancak DBM dizinlendiğinden + ve metin dosyası dizinlenmediğinden çok daha hızlıdır. Bu, istenen + anahtara daha hızlı erişim sağlar.

+ +

İsteğe bağlı olarak belirli bir dbm türü belirtebilirsiniz:

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

Tür sdbm, gdbm, ndbm + veya db olabilir. Ancak, Apache HTTP Sunucusu ile + sağlanan httxt2dbm + aracını kullanmanız önerilir; çünkü httpd'nin kendisi + oluşturulurken kullanılan doğru DBM kitaplığını kullanacaktır.

+ +

Bir dbm dosyası oluşturmak için önce txt + bölümünde açıklandığı gibi bir metin eşlem dosyası oluşturun. + Ardından httxt2dbm'yi çalıştırın:

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

Daha sonra ortaya çıkan dosyaya RewriteMap yönergenizde +başvurabilirsiniz:

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

Bazı dbm türleriyle, ortak bir temel adla birden fazla dosya +oluşturulduğunu unutmayın. Örneğin, mapfile.map.dir +ve mapfile.map.pag adlı iki dosyanız olabilir. Bu +normaldir ve RewriteMap +yönergenizde yalnızca mapfile.map temel adını +kullanmanız yeterlidir.

+
+ +Önbelleğe alınmış aramalar +

+Aranan anahtarlar, eşlem dosyasının mtime +(değiştirme zamanı) değişene veya httpd sunucusu yeniden +başlatılana kadar httpd tarafından önbelleğe alınır. Bu, birçok +istek tarafından çağrılan eşlemler için daha iyi performans +sağlar. +

+
+ +
+ +
prg: Harici Yeniden Yazma Programı + +

prg EşlemTürü kullanıldığında, EşlemKaynağı + eşleme davranışını sağlayacak çalıştırılabilir bir programın + dosya sistemi yoludur. Bu, derlenmiş bir ikili dosya veya Python + ya da Perl gibi yorumlanan bir dilde yazılmış bir program + olabilir.

+ +

Bu program, Apache HTTP Sunucusu başlatıldığında bir kez + başlatılır ve ardından yeniden yazma motoruyla + STDIN ve STDOUT aracılığıyla + iletişim kurar. Her eşlem işlevi aramasında, anahtar programın + STDIN'ine yazılır ve ardından bir satırsonu karakteri + gelir. Program, STDIN'den bir satır okumalı (satırsonu + dahil) ve yanıtını STDOUT'a tek bir satırsonu ile + sonlandırılmış satır olarak yazmalıdır. Anahtarlar hiçbir zaman + satırsonu karakteri içermez; satırsonu içeren bir anahtarla + karşılaşılırsa arama başarısız olur.

+ +

Karşılık gelen bir arama değeri yoksa, eşlem programı bunu + belirtmek için dört karakterlik "NULL" dizgesini + döndürmelidir. Bu karşılaştırmanın büyük/küçük harf duyarsız + olduğunu unutmayın; "null", "Null" vb. de başarısız arama olarak + değerlendirilir. Sonuç olarak, bir eşleme programının eşlenen + değer olarak "NULL" birebir dizgesini döndürmesi mümkün + değildir.

+ +

Programın STDERR'si httpd üst sürecinden + miras alınır; bu nedenle programın STDERR'ye + yazdığı her şey httpd'nin kendi hata çıktısıyla (genellikle + ErrorLog) aynı yere + gider.

+ +

Harici yeniden yazma programları, RewriteEngine on + olarak ayarlanmamış bir bağlamda tanımlanmışlarsa + başlatılmaz.

+ +

Öntanımlı olarak, harici yeniden yazma programları httpd'yi + başlatan kullanıcı:grup olarak çalıştırılır. Bu, UNIX + sistemlerinde RewriteMap + yönergesine üçüncü argüman olarak + kullanıcıadı:grupadı biçiminde kullanıcı adı ve + grup adı geçirilerek değiştirilebilir.

+ +

Bu özellik, programla güvenilir iletişim için gerekli olan + rewrite-map mutex'ini kullanır. Mutex mekanizması + ve kilit dosyası Mutex + yönergesiyle yapılandırılabilir.

+ +

Burada, bir istek URI'sindeki tüm tireleri alt çizgilerle + değiştirecek basit bir örnek gösterilmektedir.

+ +

Yeniden yazma yapılandırması

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

dash2under.py

+ +#!/usr/bin/env python3 +import sys + +for line in sys.stdin: + print(line.strip().replace('-', '_'), flush=True) + + +Dikkat! +
    +
  • Yeniden yazma eşlem programınızı olabildiğince basit tutun. +Program askıda kalırsa, httpd'nin eşlemden yanıt beklerken süresiz +olarak beklemesine neden olur ve bu da httpd'nin isteklere yanıt +vermesini durduracaktır.
  • +
  • Programınızda arabelleğe almayı kapattığınızdan emin olun. +Yukarıdaki Python örneğinde bu, print() işlevine +flush=True geçirilerek yapılır. Arabelleğe alınmış G/Ç, +httpd'nin çıktıyı beklemesine neden olur ve askıda kalmasına +yol açar.
  • +
  • Sunucu başlangıcında başlatılan programın yalnızca bir kopyası +olduğunu unutmayın. Tüm isteklerin bu tek darboğazdan geçmesi +gerekecektir. Birçok istek bu süreçten geçmek zorundaysa veya +betiğin kendisi çok yavaşsa bu önemli yavaşlamalara neden +olabilir.
  • +
  • Eşleme programı sonlanırsa otomatik olarak yeniden +başlatılmaz. Sonraki aramalar, sunucu yeniden başlatılana kadar +başarısız olur.
  • +
  • Eşleme programı, ilgili yapılandırma yönergelerinin değişip +değişmediğine bakılmaksızın herhangi bir sunucu yeniden +başlatmasında (zarif veya başka türlü) her zaman sonlandırılır +ve yeniden başlatılır. Kapatmada programa SIGTERM +gönderilir; 3 saniye içinde çıkmazsa SIGKILL +gönderilir.
  • +
+
+ +
+ + +
+ dbd veya fastdbd: SQL Sorgusu + +

dbd veya fastdbd EşlemTürü + kullanıldığında, EşlemKaynağı tek bir argüman alan ve tek bir + değer döndüren bir SQL SELECT deyimidir.

+ +

Bu deyimin yürütülmesi için mod_dbd modülünün + doğru veritabanına işaret edecek şekilde yapılandırılması + gerekir.

+ +

Bu EşlemTürünün iki biçimi vardır. dbd EşlemTürü + kullanmak, sorgunun her eşlem isteğinde yürütülmesine neden + olurken, fastdbd kullanmak veritabanı aramalarını + dahili olarak önbelleğe alır. Böylece fastdbd daha + verimli ve dolayısıyla daha hızlı olsa da, sunucu yeniden + başlatılana kadar veritabanındaki değişiklikleri almaz.

+ +

Bir sorgu birden fazla satır döndürürse, sonuç kümesinden + rastgele bir satır kullanılır.

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

Sorgu adı veritabanı sürücüsüne bir SQL hazır deyimi için + etiket olarak iletilir ve bu nedenle veritabanınız için gereken + tüm kuralları (büyük/küçük harf duyarlılığı gibi) izlemelidir.

+
+ +
+
+ Özet + +

RewriteMap yönergesi + birden fazla kez kullanılabilir. Her eşleme-işlevi için yeniden + yazma eşlem dosyasını bildirmek üzere bir + RewriteMap yönergesi + kullanın.

+ +

Dizin başına bağlamda (.htaccess dosyaları veya + Directory + blokları) bir eşlem bildirmeniz mümkün olmasa da, + bu eşlemi dizin başına bağlamda kullanmanız + mümkündür.

+ +
+
diff --git a/docs/manual/rewrite/rewritemap.xml.zh-cn b/docs/manual/rewrite/rewritemap.xml.zh-cn new file mode 100644 index 0000000000..c0547a79bb --- /dev/null +++ b/docs/manual/rewrite/rewritemap.xml.zh-cn @@ -0,0 +1,436 @@ + + + + + + + Rewrite + 使用 RewriteMap + + +

本文档是 mod_rewrite +参考文档的补充。它描述了 +RewriteMap 指令的使用方法, +并提供了各种 RewriteMap +类型的示例。

+ + 请注意,这些示例中的许多在你的特定服务器配置中 +不会原封不动地工作,因此理解它们非常重要, +而不是仅仅将示例复制粘贴到你的配置中。 + +
+ 模块文档 + mod_rewrite 简介 + 重定向和重映射 + 访问控制 + 虚拟主机 + 代理 + 高级技术 + 何时不使用 mod_rewrite + +
+ 介绍 + +

+ RewriteMap 指令定义了一个外部函数, + 可以在 RewriteRule 或 + RewriteCond + 指令的上下文中调用,以执行过于复杂或过于专业化而无法仅通过正则表达式完成的重写。 + 此查找的来源可以是下面各节中列出的任何类型, + 并在 RewriteMap + 参考文档中有详细说明。

+ +

RewriteMap + 指令的语法如下:

+ + +RewriteMap MapName MapType:MapSource + + +

MapName + 是你分配给映射的任意名称,稍后将在指令中使用。 + 通过以下语法将参数传递给映射:

+ +

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

+ +

当出现这样的结构时,将查询映射 MapName + 并查找键 LookupKey。如果找到该键, + 映射函数结构将被替换为 SubstValue。 + 如果未找到该键,则替换为 DefaultValue, + 如果未指定 DefaultValue 则替换为空字符串。

+ +

例如,你可以定义一个 + RewriteMap 如下:

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

然后你可以在 + RewriteRule 中如下使用此映射:

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

在映射中未找到任何内容时,可以指定默认值:

+ + +RewriteRule "^/ex/(.*)" "${examplemap:$1|/not_found.html}" + + +目录级和 .htaccess 上下文 +

+RewriteMap 指令不能在 +Directory 配置段或 +.htaccess 文件中使用。你必须在服务器或虚拟主机上下文中声明映射。 +创建映射后,你可以在这些范围内的 +RewriteRule 和 +RewriteCond +指令中使用它。只是不能在这些范围内声明它。

+
+ +

以下各节描述了可以使用的各种 MapType,并给出了每种类型的示例。

+
+ +
+ int:内部函数 + +

当 MapType 为 int 时,MapSource 是可用的 + RewriteMap + 内部函数之一。模块作者可以通过使用 + ap_register_rewrite_mapfunc API 注册来提供额外的内部函数。 + 默认提供的函数有: +

+ +
    +
  • toupper:
    + 将键转换为全大写。
  • +
  • tolower:
    + 将键转换为全小写。
  • +
  • escape:
    + 将键中的特殊字符转换为十六进制编码。
  • +
  • unescape:
    + 将键中的十六进制编码转换回特殊字符。
  • +
+ +

+ 要使用这些函数之一,创建一个引用 int 函数的 + RewriteMap, + 然后在你的 + RewriteRule 中使用它: +

+ +

将 URI 重定向到其全小写版本

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

请注意,此处提供的示例仅用于说明目的,并非建议。 + 如果你想使 URL 不区分大小写,请考虑使用 + mod_speling 代替。 +

+
+ +
+ +
+ txt:纯文本映射 + +

当 MapType 为 txt 时,MapSource 是一个纯文本映射文件的 + 文件系统路径,每行包含一个以空格分隔的键/值对。 + 可选地,一行可以包含以 '#' 字符开头的注释。

+ +

有效的文本重写映射文件将具有以下语法:

+ + + # 注释行
+ MatchingKey SubstValue
+ MatchingKey SubstValue # 注释
+
+ +

当调用 RewriteMap 时, + 在行的第一个参数中查找该参数,如果找到,则返回替换值。

+ +

例如,我们可以使用映射文件将产品名称转换为产品 ID, + 以获得更易记的 URL,使用以下配方:

+

产品到 ID 的配置

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

我们假设 prods.php 脚本知道在收到 + id=NOTFOUND 参数时如何处理——当在查找映射中找不到产品时。

+ +

文件 /etc/apache2/productmap.txt 包含以下内容:

+ + 产品到 ID 的映射 +##
+## productmap.txt - 产品到 ID 的映射文件
+##
+
+television 993
+stereo 198
+fishingrod 043
+basketball 418
+telephone 328 +
+ +

因此,当请求 http://example.com/product/television 时, + RewriteRule 被应用, + 请求在内部被映射到 /prods.php?id=993。

+ + 注意:.htaccess 文件 + 此处给出的示例是为在服务器或虚拟主机范围内使用而设计的。 + 如果你计划在 .htaccess 文件中使用, + 则需要从重写模式中删除前导斜杠才能匹配任何内容: + +RewriteRule "^product/(.*)" "/prods.php?id=${product2id:$1|NOTFOUND}" [PT] + + + + 缓存查找 +

+ 查找的键会被 httpd 缓存,直到映射文件的 mtime + (修改时间)发生变化或 httpd 服务器重启。 + 这确保了被许多请求调用的映射有更好的性能。 +

+
+ +
+
+ rnd:随机纯文本 + +

当 MapType 为 rnd 时,MapSource 是一个纯文本映射文件的 + 文件系统路径,每行包含一个键和一个或多个由 | + 分隔的值。如果键匹配,将随机选择其中一个值。

+ +

例如,你可以使用以下映射文件和指令通过反向代理在多个后端服务器之间 + 提供随机负载均衡。图像被发送到 'static' 池中的某个服务器, + 而其他所有内容被发送到 'dynamic' 池中的某个服务器。

+ + 重写映射文件 +##
+## map.txt -- 重写映射
+##
+
+static www1|www2|www3|www4
+dynamic www5|www6 +
+

配置指令

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

因此,当请求图像并且第一条规则匹配时, + RewriteMap + 在映射文件中查找字符串 static, + 随机返回指定主机名之一,然后将其用于 + RewriteRule 目标。

+ +

如果你想让某个服务器更有可能被选中(例如, + 如果某个服务器比其他服务器有更多内存,因此可以处理更多请求), + 只需在映射文件中多次列出它即可。

+ + +static www1|www1|www2|www3|www4 + + +
+ +
+ dbm:DBM 哈希文件 + +

当 MapType 为 dbm 时,MapSource 是一个 DBM + 数据库文件的文件系统路径,其中包含用于映射的键/值对。 + 其工作方式与 txt 映射完全相同,但速度更快, + 因为 DBM 是有索引的,而文本文件没有索引。 + 这允许更快地访问所需的键。

+ +

你可以选择指定特定的 dbm 类型:

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

类型可以是 sdbm、gdbm、ndbm + 或 db。但建议你使用 Apache HTTP Server 提供的 + httxt2dbm 工具, + 因为它会使用正确的 DBM 库,与构建 httpd 本身时使用的库相匹配。

+ +

要创建 dbm 文件,首先按照 txt + 节中的描述创建文本映射文件。然后运行 + httxt2dbm:

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

然后你可以在 +RewriteMap +指令中引用生成的文件:

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

请注意,对于某些 dbm 类型,会生成多个文件,它们具有共同的基本名称。 +例如,你可能有两个名为 mapfile.map.dir 和 +mapfile.map.pag 的文件。这是正常的,你只需在 +RewriteMap +指令中使用基本名称 mapfile.map 即可。

+
+ +缓存查找 +

+查找的键会被 httpd 缓存,直到映射文件的 mtime +(修改时间)发生变化或 httpd 服务器重启。 +这确保了被许多请求调用的映射有更好的性能。 +

+
+ +
+ +
prg:外部重写程序 + +

当 MapType 为 prg 时,MapSource 是一个可执行程序的 + 文件系统路径,该程序将提供映射行为。这可以是编译的二进制文件, + 也可以是 Python 或 Perl 等解释型语言的程序。

+ +

此程序在 Apache HTTP Server 启动时启动一次, + 然后通过 STDIN 和 STDOUT + 与重写引擎通信。对于每次映射函数查找, + 键被写入程序的 STDIN,后跟换行符。 + 程序应从 STDIN 读取一行(直到并包括换行符), + 并在 STDOUT 上写入其响应作为单个以换行符终止的行。 + 键永远不会包含换行符;如果遇到包含换行符的键,查找将失败。

+ +

如果没有对应的查找值,映射程序应返回四字符字符串 + "NULL" 来表示这一点。请注意,此比较不区分大小写, + 因此 "null"、"Null" 等也被视为查找失败。 + 因此,映射程序不可能返回字面量字符串 "NULL" 作为映射值。

+ +

程序的 STDERR 继承自 httpd 父进程, + 因此程序写入 STDERR 的任何内容都将与 httpd + 自身的错误输出出现在相同的位置(通常是 + ErrorLog)。

+ +

如果外部重写程序定义在未将 + RewriteEngine + 设置为 on 的上下文中,则不会启动。

+ +

默认情况下,外部重写程序以启动 httpd 的用户:组身份运行。 + 在 UNIX 系统上,可以通过将用户名和组名作为第三个参数传递给 + RewriteMap, + 以 username:groupname 格式进行更改。

+ +

此功能使用 rewrite-map 互斥锁, + 这是与程序可靠通信所必需的。互斥锁机制和锁文件可以通过 + Mutex 指令进行配置。

+ +

这里展示了一个简单的示例,它将请求 URI 中的所有破折号替换为下划线。

+ +

重写配置

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

dash2under.py

+ +#!/usr/bin/env python3 +import sys + +for line in sys.stdin: + print(line.strip().replace('-', '_'), flush=True) + + +注意! +
    +
  • 保持你的重写映射程序尽可能简单。如果程序挂起, +它将导致 httpd 无限期地等待映射的响应, +这反过来会导致 httpd 停止响应请求。
  • +
  • 确保在你的程序中关闭缓冲。在上面的 Python 示例中, +这是通过向 print() 传递 flush=True 来完成的。 +缓冲的 I/O 将导致 httpd 等待输出,从而挂起。
  • +
  • 请记住,程序只有一个副本,在服务器启动时启动。 +所有请求都需要通过这一个瓶颈。如果许多请求必须通过此进程, +或者脚本本身非常慢,这可能会导致显著的性能下降。
  • +
  • 如果映射程序终止,它不会自动重启。后续查找将失败, +直到服务器重启。
  • +
  • 无论相关配置指令是否发生更改,映射程序在任何服务器重启 +(优雅重启或其他方式)时都会被终止并重新启动。 +关闭时,程序会收到 SIGTERM 信号; +如果在 3 秒内未退出,则会收到 SIGKILL 信号。
  • +
+
+ +
+ + +
+ dbd 或 fastdbd:SQL 查询 + +

当 MapType 为 dbd 或 fastdbd 时, + MapSource 是一个接受单个参数并返回单个值的 SQL SELECT 语句。

+ +

需要配置 mod_dbd + 指向正确的数据库才能执行此语句。

+ +

此 MapType 有两种形式。使用 dbd 的 MapType + 会在每次映射请求时执行查询,而使用 fastdbd + 则在内部缓存数据库查找结果。因此,虽然 fastdbd + 更高效、更快,但它不会在服务器重启之前获取数据库的更改。

+ +

如果查询返回多行,将从结果集中随机使用一行。

+ + 示例 + +RewriteMap myquery "fastdbd:SELECT destination FROM rewrite WHERE source = %s" + + + + 注意 +

查询名称作为 SQL 预处理语句的标签传递给数据库驱动程序, + 因此需要遵循数据库要求的任何规则(例如大小写敏感性)。

+ +
+
+ 总结 + +

RewriteMap + 指令可以出现多次。对于每个映射函数,使用一个 + RewriteMap + 指令来声明其重写映射文件。

+ +

虽然你不能在目录级上下文(.htaccess 文件或 + Directory 块)中 + 声明映射,但可以在目录级上下文中使用此映射。

+ +
+
diff --git a/docs/manual/rewrite/tech.xml.de b/docs/manual/rewrite/tech.xml.de new file mode 100644 index 0000000000..7f4c7cd1a2 --- /dev/null +++ b/docs/manual/rewrite/tech.xml.de @@ -0,0 +1,197 @@ + + + + + + + + +Rewrite + + Technische Details zu Apache mod_rewrite + + +

Dieses Dokument behandelt einige der technischen Details von +mod_rewrite und der URL-Zuordnung.

+
+Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung +Zugriffskontrolle +Virtuelle Hosts +Proxying +Verwendung von RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
API-Phasen + +

Der Apache HTTP Server bearbeitet Anfragen in mehreren Phasen. + In jeder dieser Phasen können ein oder mehrere Module aufgerufen + werden, um diesen Teil des Anfrage-Lebenszyklus zu behandeln. Zu + den Phasen gehören Dinge wie URL-zu-Dateiname-Übersetzung, + Authentifizierung, Autorisierung, Inhalt und Protokollierung. (Dies + ist keine vollständige Liste.)

+ +

mod_rewrite wirkt in zwei dieser Phasen (oder "Hooks", wie + sie oft genannt werden), um zu beeinflussen, wie URLs umgeschrieben + werden können.

+ +

Erstens verwendet es den URL-zu-Dateiname-Übersetzungs-Hook, der + nach dem Lesen der HTTP-Anfrage stattfindet, aber bevor eine + Autorisierung beginnt. Zweitens verwendet es den Fixup-Hook, der + nach den Autorisierungsphasen und nach dem Lesen der + verzeichnisbezogenen Konfigurationsdateien + (.htaccess-Dateien) stattfindet, aber bevor der + Inhalts-Handler aufgerufen wird.

+ +

Nachdem eine Anfrage eingegangen ist und ein entsprechender Server + oder virtueller Host bestimmt wurde, beginnt die Umschreibungs-Engine + mit der Verarbeitung aller mod_rewrite-Direktiven in der + Server-Konfiguration. (d.h. in der Hauptserverkonfigurationsdatei und + in Virtualhost-Abschnitten.) + Dies geschieht in der URL-zu-Dateiname-Phase.

+ +

Einige Schritte später, nachdem die endgültigen Datenverzeichnisse + gefunden wurden, werden die verzeichnisbezogenen + Konfigurationsdirektiven (.htaccess-Dateien und + Directory-Blöcke) + angewendet. Dies geschieht in der Fixup-Phase.

+ +

In jedem dieser Fälle schreibt mod_rewrite die + REQUEST_URI entweder auf eine neue URL oder auf einen + Dateinamen um.

+ +

Im Verzeichniskontext (d.h. in .htaccess-Dateien und + Directory-Blöcken) werden diese Regeln angewendet, + nachdem eine URL bereits in einen Dateinamen übersetzt wurde. Aus + diesem Grund ist der URL-Pfad, gegen den mod_rewrite + zunächst die RewriteRule-Direktiven + abgleicht, der vollständige Dateisystempfad zum übersetzten + Dateinamen, wobei der Pfad des aktuellen Verzeichnisses (einschließlich + eines abschließenden Schrägstrichs) vom Anfang entfernt wurde.

+ +

Zur Veranschaulichung: Wenn Regeln in /var/www/foo/.htaccess stehen + und eine Anfrage für /foo/bar/baz verarbeitet wird, würde ein Ausdruck + wie ^bar/baz$ übereinstimmen.

+ +

Wenn eine Ersetzung im Verzeichniskontext vorgenommen wird, wird + eine neue interne Unteranfrage mit der neuen URL ausgelöst, die die + Verarbeitung der Anfragephasen neu startet. Wenn die Ersetzung ein + relativer Pfad ist, bestimmt die + RewriteBase-Direktive + das URL-Pfad-Präfix, das der Ersetzung vorangestellt wird. Im + Verzeichniskontext muss darauf geachtet werden, Regeln zu erstellen, + die letztendlich (in einer zukünftigen "Runde" der verzeichnisbezogenen + Umschreibungsverarbeitung) keine Ersetzung durchführen, um Schleifen + zu vermeiden. (Siehe RewriteLooping + für eine weitere Diskussion dieses Problems.)

+ +

Aufgrund dieser weiteren Manipulation der URL im Verzeichniskontext + müssen Sie Ihre Umschreibungsregeln in diesem Kontext anders + gestalten. Insbesondere denken Sie daran, dass der führende + Verzeichnispfad vom URL-Pfad abgeschnitten wird, den Ihre + Umschreibungsregeln sehen. Betrachten Sie die folgenden Beispiele + zur weiteren Verdeutlichung.

+ + + + + + + + + + + + + + + + + + + + + + + +
Ort der RegelRegel
VirtualHost-AbschnittRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
.htaccess-Datei im Document RootRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
.htaccess-Datei im images-VerzeichnisRewriteRule "^(.+)\.jpg" "$1.gif"
+ +

Für noch mehr Einblick, wie mod_rewrite URLs in + verschiedenen Kontexten manipuliert, sollten Sie die + Protokolleinträge + konsultieren, die während der Umschreibung erstellt werden.

+ +
+ +
Regelsatz-Verarbeitung + +

Wenn mod_rewrite in diesen beiden API-Phasen + ausgelöst wird, liest es die konfigurierten Regelsätze aus seiner + Konfigurationsstruktur (die entweder beim Start für den + Server-Kontext oder während des Verzeichnisdurchlaufs des + Apache-Kerns für den Verzeichniskontext erstellt wurde). Dann wird + die URL-Umschreibungs-Engine mit dem enthaltenen Regelsatz gestartet + (eine oder mehrere Regeln zusammen mit ihren Bedingungen). Die + Funktionsweise der URL-Umschreibungs-Engine ist für beide + Konfigurationskontexte genau gleich. Nur die endgültige + Ergebnisverarbeitung ist unterschiedlich.

+ +

Die Reihenfolge der Regeln im Regelsatz ist wichtig, da die + Umschreibungs-Engine sie in einer speziellen (und nicht sehr + offensichtlichen) Reihenfolge verarbeitet. Die Regel lautet: + Die Umschreibungs-Engine durchläuft den Regelsatz Regel für Regel + (RewriteRule-Direktiven) + und wenn eine bestimmte Regel übereinstimmt, durchläuft sie optional + die vorhandenen zugehörigen Bedingungen (RewriteCond-Direktiven). + Aus historischen Gründen werden die Bedingungen zuerst angegeben, + sodass der Kontrollfluss etwas umständlich ist. Siehe Abbildung 1 + für weitere Details.

+

+ Ablauf der RewriteRule- und RewriteCond-Zuordnung
+ Abbildung 1:Der Kontrollfluss durch den Umschreibungsregelsatz +

+

Zuerst wird die URL gegen das Pattern jeder Regel + abgeglichen. Wenn es fehlschlägt, stoppt mod_rewrite + sofort die Verarbeitung dieser Regel und fährt mit der nächsten Regel + fort. Wenn das Pattern übereinstimmt, sucht + mod_rewrite nach zugehörigen Regelbedingungen + (RewriteCond-Direktiven, die in der Konfiguration unmittelbar über + der RewriteRule stehen). Wenn keine vorhanden sind, ersetzt es die + URL durch einen neuen Wert, der aus dem String Substitution + konstruiert wird, und fährt mit seiner Regelschleife fort. Wenn + jedoch Bedingungen vorhanden sind, startet es eine innere Schleife + zur Verarbeitung dieser in der Reihenfolge, in der sie aufgeführt + sind. Für Bedingungen ist die Logik anders: Wir gleichen kein + Muster gegen die aktuelle URL ab. Stattdessen erstellen wir zuerst + einen String TestString durch Expansion von Variablen, + Rückreferenzen, Map-Nachschlagungen usw., und dann + versuchen wir, CondPattern dagegen abzugleichen. Wenn das + Muster nicht übereinstimmt, schlägt die gesamte Menge von + Bedingungen und die zugehörige Regel fehl. Wenn das Muster + übereinstimmt, wird die nächste Bedingung verarbeitet, bis keine + weiteren Bedingungen verfügbar sind. Wenn alle Bedingungen + übereinstimmen, wird die Verarbeitung mit der Ersetzung der URL + durch Substitution fortgesetzt.

+ +
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/tech.xml.es b/docs/manual/rewrite/tech.xml.es new file mode 100644 index 0000000000..436d018341 --- /dev/null +++ b/docs/manual/rewrite/tech.xml.es @@ -0,0 +1,189 @@ + + + + + + + + +Rewrite + + Detalles Técnicos de Apache mod_rewrite + + +

Este documento discute algunos de los detalles técnicos de mod_rewrite +y la coincidencia de URLs.

+
+Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo +Control de acceso +Hosts virtuales +Proxy +Uso de RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
Fases de la API + +

Apache HTTP Server maneja las solicitudes en varias fases. En + cada una de estas fases, uno o más módulos pueden ser llamados para + manejar esa porción del ciclo de vida de la solicitud. Las fases incluyen cosas + como traducción de URL a nombre de archivo, autenticación, autorización, + contenido, y registro. (Esta no es una lista exhaustiva.)

+ +

mod_rewrite actúa en dos de estas fases (o "hooks", como se les + suele llamar) para influir en cómo las URLs pueden ser reescritas.

+ +

Primero, usa el hook de traducción de URL a nombre de archivo, que ocurre + después de que la solicitud HTTP ha sido leída, pero antes de que cualquier autorización + comience. Segundo, usa el hook de Fixup, que es después de las + fases de autorización, y después de que los archivos de configuración per-directorio + (archivos .htaccess) han sido leídos, pero antes de que el + manejador de contenido sea llamado.

+ +

Después de que una solicitud llega y se ha determinado un servidor o + host virtual correspondiente, el motor de reescritura comienza a + procesar cualquier directiva de mod_rewrite que aparezca en la + configuración per-servidor. (es decir, en el archivo de configuración principal del servidor + y secciones Virtualhost.) + Esto sucede en la fase de traducción de URL a nombre de archivo.

+ +

Unos pasos más tarde, una vez que se han encontrado los directorios de datos finales, + se aplican las directivas de configuración per-directorio (archivos .htaccess + y bloques Directory). Esto + sucede en la fase de Fixup.

+ +

En cada uno de estos casos, mod_rewrite reescribe el + REQUEST_URI ya sea a una nueva URL, o a un nombre de archivo.

+ +

En contexto per-directorio (es decir, dentro de archivos .htaccess + y bloques Directory), estas reglas se están aplicando + después de que una URL ya ha sido traducida a un nombre de archivo. Debido a + esto, la ruta URL contra la que mod_rewrite inicialmente compara las directivas + RewriteRule + es la ruta completa del sistema de archivos al nombre de archivo traducido con la ruta del + directorio actual (incluyendo una barra final) eliminada del frente.

+ +

Para ilustrar: Si las reglas están en /var/www/foo/.htaccess y se está procesando una solicitud + para /foo/bar/baz, una expresión como ^bar/baz$ coincidiría.

+ +

Si se hace una sustitución en contexto per-directorio, se emite una nueva + sub-solicitud interna con la nueva URL, que reinicia el procesamiento de las + fases de la solicitud. Si la sustitución es una ruta relativa, la directiva RewriteBase + determina el prefijo de ruta URL que se antepone a la sustitución. + En contexto per-directorio, se debe tener cuidado de + crear reglas que eventualmente (en alguna "ronda" futura de procesamiento de reescritura + per-directorio) no realicen una sustitución para evitar bucles. + (Vea RewriteLooping + para más discusión de este problema.)

+ +

Debido a esta manipulación adicional de la URL en contexto per-directorio, + necesitará tener cuidado de crear sus reglas de reescritura + de manera diferente en ese contexto. En particular, recuerde que la + ruta de directorio principal se eliminará de la URL que sus + reglas de reescritura verán. Considere los ejemplos siguientes para más + clarificación.

+ + + + + + + + + + + + + + + + + + + + + + + +
Ubicación de la reglaRegla
Sección VirtualHostRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
Archivo .htaccess en la raíz del documentoRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
Archivo .htaccess en el directorio imagesRewriteRule "^(.+)\.jpg" "$1.gif"
+ +

Para aún más información sobre cómo mod_rewrite manipula URLs en + diferentes contextos, debería consultar las entradas del log realizadas durante + la reescritura.

+ +
+ +
Procesamiento del Conjunto de Reglas + +

Ahora cuando mod_rewrite se activa en estas dos fases de la API, lee + los conjuntos de reglas configurados desde su estructura de + configuración (que a su vez fue creada al inicio para + contexto per-servidor o durante el recorrido de directorios del + núcleo de Apache para contexto per-directorio). Entonces el motor de reescritura + de URLs se inicia con el conjunto de reglas contenido (una o más + reglas junto con sus condiciones). La operación del + motor de reescritura de URLs es exactamente la misma para ambos + contextos de configuración. Solo el procesamiento del resultado final es + diferente.

+ +

El orden de las reglas en el conjunto de reglas es importante porque el + motor de reescritura las procesa en un orden especial (y no muy + obvio). La regla es esta: El motor de reescritura recorre + el conjunto de reglas regla por regla (directivas + RewriteRule) y + cuando una regla particular coincide, opcionalmente recorre + las condiciones correspondientes existentes (directivas RewriteCond). + Por razones históricas las condiciones se dan + primero, y por lo tanto el flujo de control es un poco + enrevesado. Vea la Figura 1 para más detalles.

+

+ Flujo de coincidencia de RewriteRule y RewriteCond
+ Figura 1:El flujo de control a través del conjunto de reglas de reescritura +

+

Primero la URL se compara contra el + Pattern de cada regla. Si falla, mod_rewrite + inmediatamente deja de procesar esta regla, y continúa con la + siguiente regla. Si el Pattern coincide, mod_rewrite busca + las condiciones de regla correspondientes (directivas RewriteCond, + que aparecen inmediatamente encima de la RewriteRule en la configuración). + Si no hay ninguna, sustituye la URL con un nuevo valor, que se + construye a partir de la cadena Substitution, y continúa + con su bucle de reglas. Pero si existen condiciones, inicia un + bucle interno para procesarlas en el orden en que están + listadas. Para las condiciones, la lógica es diferente: no comparamos + un patrón contra la URL actual. En su lugar, primero creamos una + cadena TestString expandiendo variables, + referencias inversas, búsquedas en mapas, etc. y luego intentamos + comparar CondPattern contra ella. Si el patrón + no coincide, el conjunto completo de condiciones y la + regla correspondiente fallan. Si el patrón coincide, entonces se + procesa la siguiente condición hasta que no haya más condiciones + disponibles. Si todas las condiciones coinciden, el procesamiento continúa + con la sustitución de la URL con + Substitution.

+ +
+ + +
diff --git a/docs/manual/rewrite/tech.xml.fr b/docs/manual/rewrite/tech.xml.fr index 6c8750edfa..4ac7ce0249 100644 --- a/docs/manual/rewrite/tech.xml.fr +++ b/docs/manual/rewrite/tech.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -25,102 +25,102 @@ Rewrite - Détails techniques sur le module Apache mod_rewrite + Détails techniques sur le module Apache mod_rewrite -

Ce document passe en revue certains détails techniques à propos du +

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

Documentation du module mod_rewrite -Introduction à mod_rewrite +Introduction à mod_rewrite Redirection et remise en correspondance -Contrôle d'accès +Contrôle d'accès Serveurs virtuels Mise en cache Utilisation de RewriteMap -Techniques avancées +Techniques avancées Quand ne pas utiliser mod_rewrite
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 +

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.

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

-

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 +

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

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.

+ type="section">Directory) sont appliquées. Ce processus + s'exécute au cours de la phase Fixup.

-

Dans tous ces cas, mod_rewrite réécrit le +

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 +

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

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

+

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 +

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 + module="mod_rewrite">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 + 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 :

- - + + @@ -129,82 +129,81 @@ correspondance - + - +
Position de la règleRèglePosition de la règleRègle
Fichier .htaccess à la racine des documentsFichier .htaccess à la racine des documents RewriteRule "^images/(.+)\.jpg" "images/$1.gif"
Fichier .htaccess dans le répertoire imagesFichier .htaccess dans le répertoire images RewriteRule "^(.+)\.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.

+

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.

-
Traitement du jeu de règles +
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 + +

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

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

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

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

- diff --git a/docs/manual/rewrite/tech.xml.ja b/docs/manual/rewrite/tech.xml.ja new file mode 100644 index 0000000000..f82afcc634 --- /dev/null +++ b/docs/manual/rewrite/tech.xml.ja @@ -0,0 +1,184 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite 技術的詳細 + + +

このドキュメントでは、mod_rewrite と URL マッチングの +技術的な詳細について説明します。

+
+モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング +アクセス制御 +バーチャルホスト +プロキシ +RewriteMap の使用 +高度なテクニック +mod_rewrite を使わない場合 + +
API フェーズ + +

Apache HTTP Server は、いくつかのフェーズでリクエストを処理します。 + 各フェーズでは、リクエストライフサイクルのその部分を処理するために + 1 つ以上のモジュールが呼び出される可能性があります。フェーズには、 + URL からファイル名への変換、認証、認可、コンテンツ、ロギングなどが + 含まれます。(これは完全なリストではありません。)

+ +

mod_rewrite は、URL の書き換え方法に影響を与えるために、 + これらのフェーズ (しばしば「フック」と呼ばれます) のうち 2 つで + 動作します。

+ +

まず、URL からファイル名への変換フックを使用します。これは + HTTP リクエストが読み取られた後、認可が開始される前に発生します。 + 次に、Fixup フックを使用します。これは認可フェーズの後、 + ディレクトリ単位の設定ファイル (.htaccess ファイル) + が読み取られた後、コンテンツハンドラが呼び出される前です。

+ +

リクエストが到着し、対応するサーバまたはバーチャルホストが + 決定された後、書き換えエンジンはサーバ単位の設定に含まれる + mod_rewrite ディレクティブの処理を開始します。 + (つまり、メインサーバ設定ファイルと + Virtualhost + セクション内のディレクティブです。) これは URL からファイル名への + 変換フェーズで発生します。

+ +

数ステップ後、最終的なデータディレクトリが見つかると、 + ディレクトリ単位の設定ディレクティブ (.htaccess + ファイルと Directory ブロック) が適用されます。 + これは Fixup フェーズで発生します。

+ +

これらの各ケースで、mod_rewrite は + REQUEST_URI を新しい URL またはファイル名に + 書き換えます。

+ +

ディレクトリ単位のコンテキスト (つまり .htaccess + ファイルと Directory ブロック内) では、URL が既に + ファイル名に変換された後にこれらのルールが適用されます。このため、 + mod_rewrite が最初に RewriteRule ディレクティブと比較する + URL パスは、変換されたファイル名のフルファイルシステムパスから、 + 現在のディレクトリのパス (末尾のスラッシュを含む) を先頭から + 削除したものになります。

+ +

例として: ルールが /var/www/foo/.htaccess にあり、 + /foo/bar/baz へのリクエストが処理されている場合、^bar/baz$ のような + 式がマッチします。

+ +

ディレクトリ単位のコンテキストで置換が行われた場合、新しい URL で + 新しい内部サブリクエストが発行され、リクエストフェーズの処理が + 再開されます。置換が相対パスの場合、RewriteBase ディレクティブが + 置換の前に付加する URL パスプレフィックスを決定します。 + ディレクトリ単位のコンテキストでは、ループを避けるために、 + 最終的に (将来のディレクトリ単位の書き換え処理の「ラウンド」で) + 置換を行わないルールを作成するよう注意する必要があります。 + (この問題の詳細については + RewriteLooping + を参照してください。)

+ +

ディレクトリ単位のコンテキストでの URL のさらなる操作のため、 + そのコンテキストでは書き換えルールを異なるように作成するよう + 注意する必要があります。特に、先頭のディレクトリパスが書き換えルールが + 認識する URL から削除されることを忘れないでください。詳細については + 以下の例を参照してください。

+ + + + + + + + + + + + + + + + + + + + + + + +
ルールの場所ルール
VirtualHost セクションRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
ドキュメントルートの .htaccess ファイルRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
images ディレクトリの .htaccess ファイルRewriteRule "^(.+)\.jpg" "$1.gif"
+ +

mod_rewrite がさまざまなコンテキストで URL をどのように + 操作するかについてさらに詳しくは、書き換え中に作成される + ログエントリを + 参照してください。

+ +
+ +
ルールセットの処理 + +

これら 2 つの API フェーズで mod_rewrite がトリガー + されると、設定構造体 (サーバ単位のコンテキストではスタートアップ時に + 作成されたもの、ディレクトリ単位のコンテキストでは Apache カーネルの + ディレクトリウォーク中に作成されたもの) から設定済みのルールセットを + 読み取ります。次に、含まれるルールセット (1 つ以上のルールとその + 条件のセット) を使用して URL 書き換えエンジンが起動されます。 + URL 書き換えエンジン自体の動作は、両方の設定コンテキストで + まったく同じです。最終結果の処理のみが異なります。

+ +

ルールセット内のルールの順序は重要です。書き換えエンジンは + 特殊な (あまり直感的ではない) 順序でルールを処理するためです。 + ルールは次のとおりです: 書き換えエンジンはルールセットをルールごとに + (RewriteRule + ディレクティブ) ループし、特定のルールがマッチすると、対応する + 条件 (RewriteCond ディレクティブ) をオプションで + ループします。歴史的な理由により、条件が先に記述されるため、 + 制御フローは少し冗長になります。詳細は図 1 を参照してください。

+

+ RewriteRule と RewriteCond マッチングのフロー
+ 図 1: 書き換えルールセットを通る制御フロー +

+

まず、URL が各ルールの Pattern に対してマッチされます。 + マッチしない場合、mod_rewrite はそのルールの処理を + 直ちに停止し、次のルールに進みます。Pattern がマッチすると、 + mod_rewrite は対応するルール条件 (設定内の RewriteRule の + 直前に記述される RewriteCond ディレクティブ) を探します。 + 条件がない場合、URL を Substitution 文字列から構築された + 新しい値で置換し、ルールループを続行します。条件が存在する場合、 + 記述された順序で処理する内部ループを開始します。条件のロジックは + 異なります: 現在の URL に対してパターンをマッチさせるのではなく、 + まず変数の展開、バックリファレンス、マップ検索等を行って + TestString 文字列を作成し、それに対して + CondPattern をマッチさせようとします。パターンがマッチしない + 場合、条件のセット全体と対応するルールが失敗します。パターンが + マッチすると、次の条件が処理され、条件がなくなるまで続きます。 + すべての条件がマッチした場合、URL の Substitution による + 置換の処理が続行されます。

+ +
+ + +
diff --git a/docs/manual/rewrite/tech.xml.ko b/docs/manual/rewrite/tech.xml.ko new file mode 100644 index 0000000000..3547de19cc --- /dev/null +++ b/docs/manual/rewrite/tech.xml.ko @@ -0,0 +1,194 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite 기술적 세부 사항 + + +

이 문서는 mod_rewrite와 URL 매칭의 기술적 +세부 사항 일부를 논의합니다.

+
+모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 +접근 제어 +가상 호스트 +프록시 +RewriteMap 사용하기 +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
API 단계 + +

Apache HTTP Server는 여러 단계로 요청을 처리합니다. + 이러한 각 단계에서 요청 수명 주기의 해당 부분을 처리하기 + 위해 하나 이상의 모듈이 호출될 수 있습니다. 단계에는 + URL에서 파일명으로의 변환, 인증, 인가, 콘텐츠, 로깅 + 등이 포함됩니다. (이것은 전체 목록이 아닙니다.)

+ +

mod_rewrite는 URL이 재작성될 수 있는 + 방식에 영향을 미치기 위해 이러한 단계(또는 종종 + "훅"이라 불리는) 중 두 가지에서 작동합니다.

+ +

첫째, HTTP 요청이 읽혀진 후 인가가 시작되기 전에 + 발생하는 URL에서 파일명으로의 변환 훅을 사용합니다. + 둘째, 인가 단계 후 그리고 디렉토리별 설정 파일 + (.htaccess 파일)이 읽힌 후 콘텐츠 + 핸들러가 호출되기 전에 발생하는 Fixup 훅을 + 사용합니다.

+ +

요청이 들어오고 해당 서버 또는 가상 호스트가 + 결정된 후, 재작성 엔진은 서버별 설정에 나타나는 + 모든 mod_rewrite 지시어의 처리를 + 시작합니다. (즉, 주 서버 설정 파일과 + Virtualhost + 섹션에서.) 이것은 URL에서 파일명으로의 단계에서 + 발생합니다.

+ +

몇 단계 후, 최종 데이터 디렉토리가 발견되면 + 디렉토리별 설정 지시어(.htaccess 파일과 + Directory + 블록)가 적용됩니다. 이것은 Fixup 단계에서 + 발생합니다.

+ +

이러한 각 경우에 mod_rewrite는 + REQUEST_URI를 새 URL 또는 파일명으로 + 재작성합니다.

+ +

디렉토리별 컨텍스트(즉, .htaccess 파일과 + Directory 블록 내)에서 이러한 규칙은 + URL이 이미 파일명으로 변환된 후에 적용됩니다. + 이 때문에 mod_rewrite가 처음에 + RewriteRule + 지시어와 비교하는 URL 경로는 현재 디렉토리 경로(뒤에 + 슬래시 포함)가 앞에서 제거된 변환된 파일명의 전체 + 파일 시스템 경로입니다.

+ +

예를 들어: 규칙이 /var/www/foo/.htaccess에 있고 + /foo/bar/baz에 대한 요청이 처리되고 있다면 + ^bar/baz$와 같은 표현식이 일치합니다.

+ +

디렉토리별 컨텍스트에서 치환이 이루어지면 + 새 URL로 새로운 내부 서브요청이 발행되어 요청 + 단계의 처리가 다시 시작됩니다. 치환이 상대 경로인 + 경우 RewriteBase + 지시어가 치환 앞에 추가되는 URL 경로 접두사를 + 결정합니다. 디렉토리별 컨텍스트에서는 루핑을 피하기 + 위해 결국(미래의 디렉토리별 재작성 처리 "라운드"에서) + 치환을 수행하지 않는 규칙을 작성하도록 주의해야 + 합니다. (이 문제에 대한 자세한 논의는 + RewriteLooping을 + 참조하십시오.)

+ +

디렉토리별 컨텍스트에서의 이러한 추가 URL 조작 + 때문에 해당 컨텍스트에서 재작성 규칙을 다르게 + 작성하도록 주의해야 합니다. 특히 앞의 디렉토리 경로가 + 재작성 규칙이 보게 될 URL에서 제거된다는 것을 + 기억하십시오. 더 자세한 설명은 아래 예제를 + 참조하십시오.

+ + + + + + + + + + + + + + + + + + + + + + + +
규칙의 위치규칙
VirtualHost 섹션RewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
문서 루트의 .htaccess 파일RewriteRule "^images/(.+)\.jpg" "images/$1.gif"
images 디렉토리의 .htaccess 파일RewriteRule "^(.+)\.jpg" "$1.gif"
+ +

mod_rewrite가 다양한 컨텍스트에서 + URL을 조작하는 방식에 대한 더 많은 통찰력을 얻으려면 + 재작성 중에 생성되는 로그 항목을 + 참조해야 합니다.

+ +
+ +
규칙 세트 처리 + +

이제 mod_rewrite가 이 두 API 단계에서 + 트리거되면 설정 구조에서 구성된 규칙 세트를 읽습니다 + (이것은 서버별 컨텍스트의 경우 시작 시에 생성되거나 + 디렉토리별 컨텍스트의 경우 Apache 커널의 디렉토리 탐색 + 중에 생성됩니다). 그런 다음 포함된 규칙 세트(하나 + 이상의 규칙과 그 조건)로 URL 재작성 엔진이 + 시작됩니다. URL 재작성 엔진 자체의 동작은 두 + 설정 컨텍스트에서 정확히 동일합니다. 최종 결과 + 처리만 다릅니다.

+ +

규칙 세트에서 규칙의 순서는 재작성 엔진이 + 특별한(그리고 그다지 분명하지 않은) 순서로 처리하므로 + 중요합니다. 규칙은 다음과 같습니다: 재작성 엔진은 + 규칙 세트를 규칙별로(RewriteRule 지시어) + 순회하고 특정 규칙이 일치하면 선택적으로 해당하는 + 기존 조건(RewriteCond 지시어)을 + 순회합니다. 역사적 이유로 조건이 먼저 주어지므로 + 제어 흐름이 약간 장황합니다. 자세한 내용은 + 그림 1을 참조하십시오.

+

+ RewriteRule과 RewriteCond 매칭의 흐름
+ 그림 1: 재작성 규칙 세트를 통한 제어 흐름 +

+

먼저 URL이 각 규칙의 Pattern과 + 비교됩니다. 실패하면 mod_rewrite는 + 즉시 이 규칙의 처리를 중지하고 다음 규칙으로 + 계속합니다. Pattern이 일치하면 + mod_rewrite는 해당하는 규칙 조건 + (설정에서 RewriteRule 바로 위에 나타나는 + RewriteCond 지시어)을 찾습니다. 조건이 없으면 + Substitution 문자열에서 구성된 새 값으로 + URL을 치환하고 규칙 순회를 계속합니다. 그러나 + 조건이 있으면 나열된 순서대로 처리하기 위해 내부 + 루프를 시작합니다. 조건의 경우 로직이 다릅니다: + 현재 URL에 대해 패턴을 매칭하지 않습니다. 대신 + 먼저 변수, 역참조, 맵 조회 등을 확장하여 + 문자열 TestString을 생성한 다음 + CondPattern을 이에 대해 매칭하려고 + 합니다. 패턴이 일치하지 않으면 전체 조건 세트와 + 해당 규칙이 실패합니다. 패턴이 일치하면 더 이상 + 조건이 없을 때까지 다음 조건이 처리됩니다. 모든 + 조건이 일치하면 Substitution으로 URL을 + 치환하여 처리가 계속됩니다.

+ +
+ + +
diff --git a/docs/manual/rewrite/tech.xml.meta b/docs/manual/rewrite/tech.xml.meta index f8fb2f4fda..0e04fe7d6c 100644 --- a/docs/manual/rewrite/tech.xml.meta +++ b/docs/manual/rewrite/tech.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/tech.xml.tr b/docs/manual/rewrite/tech.xml.tr new file mode 100644 index 0000000000..f7aa426165 --- /dev/null +++ b/docs/manual/rewrite/tech.xml.tr @@ -0,0 +1,191 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite Teknik Ayrıntıları + + +

Bu belge, mod_rewrite ve URL eşleştirmesinin bazı +teknik ayrıntılarını tartışır.

+
+Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme +Erişim denetimi +Sanal konaklar +Vekil kullanımı +RewriteMap Kullanımı +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
API Aşamaları + +

Apache HTTP Sunucusu, istekleri birkaç aşamada işler. Bu + aşamaların her birinde, istek yaşam döngüsünün o bölümünü + işlemek üzere bir veya daha fazla modül çağrılabilir. Aşamalar + URL-dosyaadı çevirisi, kimlik doğrulama, yetkilendirme, içerik + ve günlükleme gibi şeyleri içerir. (Bu kapsamlı bir liste + değildir.)

+ +

mod_rewrite, URL'lerin nasıl yeniden + yazılabileceğini etkilemek için bu aşamalardan ikisinde (veya + sıklıkla çağrıldıkları şekliyle "kancalarda") çalışır.

+ +

İlk olarak, HTTP isteği okunduktan sonra ancak herhangi bir + yetkilendirme başlamadan önce gerçekleşen URL-dosyaadı çevirisi + kancasını kullanır. İkinci olarak, yetkilendirme aşamalarından + sonra ve dizin başına yapılandırma dosyaları + (.htaccess dosyaları) okunduktan sonra ancak içerik + işleyicisi çağrılmadan önce gerçekleşen Düzeltme (Fixup) + kancasını kullanır.

+ +

Bir istek geldikten ve karşılık gelen sunucu veya sanal konak + belirlendikten sonra, yeniden yazma motoru sunucu başına + yapılandırmada görünen mod_rewrite yönergelerini + işlemeye başlar. (Yani ana sunucu yapılandırma dosyası ve + Virtualhost + bölümleri.) Bu, URL-dosyaadı aşamasında gerçekleşir.

+ +

Birkaç adım sonra, son veri dizinleri bulunduktan sonra dizin + başına yapılandırma yönergeleri (.htaccess dosyaları + ve Directory + blokları) uygulanır. Bu, Düzeltme aşamasında gerçekleşir.

+ +

Bu durumların her birinde mod_rewrite, + REQUEST_URI'yi ya yeni bir URL'ye ya da bir dosya + adına yeniden yazar.

+ +

Dizin başına bağlamda (yani .htaccess dosyaları ve + Directory blokları içinde) bu kurallar, bir URL + zaten bir dosya adına çevrilmiş olduktan sonra uygulanır. Bu + nedenle, mod_rewrite modülünün RewriteRule yönergelerini + başlangıçta karşılaştırdığı URL yolu, çevrilen dosya adının tam + dosya sistemi yolu olup geçerli dizin yolu (sondaki eğik çizgi + dahil) öndeki kısımdan çıkarılmıştır.

+ +

Göstermek gerekirse: Kurallar /var/www/foo/.htaccess içindeyse + ve /foo/bar/baz isteği işleniyorsa, ^bar/baz$ gibi bir ifade + eşleşecektir.

+ +

Dizin başına bağlamda bir değiştirme yapılırsa, yeni URL ile + yeni bir dahili alt istek verilir ve bu da istek aşamalarının + işlenmesini yeniden başlatır. Değiştirme göreli bir yolsa, + RewriteBase yönergesi + değiştirmenin önüne eklenen URL yolu önekini belirler. Dizin + başına bağlamda, döngüyü önlemek için sonunda (gelecekteki bir + dizin başına yeniden yazma işleme "turunda") değiştirme yapmayan + kurallar oluşturmaya dikkat edilmelidir. (Bu sorunun daha ayrıntılı + tartışması için RewriteLooping + sayfasına bakın.)

+ +

Dizin başına bağlamda URL'nin bu ek işlenmesi nedeniyle, bu + bağlamda yeniden yazma kurallarınızı farklı şekilde oluşturmaya + dikkat etmeniz gerekecektir. Özellikle, baştaki dizin yolunun + yeniden yazma kurallarınızın göreceği URL'den çıkarılacağını + unutmayın. Daha fazla açıklama için aşağıdaki örneklere bakın.

+ + + + + + + + + + + + + + + + + + + + + + + +
Kuralın konumuKural
VirtualHost bölümüRewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
Belge kökündeki .htaccess dosyasıRewriteRule "^images/(.+)\.jpg" "images/$1.gif"
images dizinindeki .htaccess dosyasıRewriteRule "^(.+)\.jpg" "$1.gif"
+ +

mod_rewrite modülünün farklı bağlamlarda + URL'leri nasıl değiştirdiği hakkında daha fazla bilgi için, + yeniden yazma sırasında oluşturulan günlük kayıtlarına + başvurmalısınız.

+ +
+ +
Kural Kümesi İşleme + +

Şimdi mod_rewrite bu iki API aşamasında + tetiklendiğinde, yapılandırılmış kural kümelerini yapılandırma + yapısından okur (bu yapı sunucu başına bağlam için başlangıçta + veya dizin başına bağlam için Apache çekirdeğinin dizin + yürüyüşü sırasında oluşturulmuştur). Ardından URL yeniden + yazma motoru içerilen kural kümesiyle (bir veya daha fazla kural + ve bunların koşulları birlikte) başlatılır. URL yeniden yazma + motorunun çalışması her iki yapılandırma bağlamı için de + tamamen aynıdır. Yalnızca nihai sonuç işleme farklıdır.

+ +

Kural kümesindeki kuralların sırası önemlidir; çünkü yeniden + yazma motoru bunları özel (ve çok belirgin olmayan) bir sırada + işler. Kural şudur: Yeniden yazma motoru kural kümesini kural + kural (RewriteRule + yönergeleri) döner ve belirli bir kural eşleştiğinde isteğe + bağlı olarak karşılık gelen koşulları (RewriteCond + yönergeleri) döner. Tarihsel nedenlerle koşullar önce verilir + ve bu nedenle kontrol akışı biraz dolambaçlıdır. Daha fazla + ayrıntı için Şekil 1'e bakın.

+

+ RewriteRule ve RewriteCond eşleştirme akışı
+ Şekil 1:Yeniden yazma kural kümesindeki kontrol akışı +

+

İlk olarak URL, her kuralın Kalıp'ıyla eşleştirilir. + Başarısız olursa mod_rewrite bu kuralı hemen + işlemeyi durdurur ve sonraki kuralla devam eder. Kalıp + eşleşirse mod_rewrite karşılık gelen kural + koşullarını (yapılandırmada RewriteRule'un hemen üstünde görünen + RewriteCond yönergeleri) arar. Hiçbiri yoksa, URL'yi + Değiştirme dizgesinden oluşturulan yeni bir değerle + değiştirir ve kural döngüsüne devam eder. Ancak koşullar + varsa, listelenme sırasına göre bunları işlemek için bir iç + döngü başlatır. Koşullar için mantık farklıdır: geçerli URL'ye + karşı bir kalıp eşleştirmeyiz. Bunun yerine, önce değişkenleri, + geri başvuruları, eşlem aramalarını vb. genişleterek + bir SınamaDizgesi oluştururuz ve ardından + KoşulKalıbı'nı bununla eşleştirmeye çalışırız. Kalıp + eşleşmezse, koşulların tamamı ve karşılık gelen kural başarısız + olur. Kalıp eşleşirse, daha fazla koşul kalmayana kadar bir + sonraki koşul işlenir. Tüm koşullar eşleşirse, URL'nin + Değiştirme ile değiştirilmesiyle işleme devam + eder.

+ +
+ + +
diff --git a/docs/manual/rewrite/tech.xml.zh-cn b/docs/manual/rewrite/tech.xml.zh-cn new file mode 100644 index 0000000000..0bacf0fecc --- /dev/null +++ b/docs/manual/rewrite/tech.xml.zh-cn @@ -0,0 +1,162 @@ + + + + + + + + +Rewrite + + Apache mod_rewrite 技术细节 + + +

本文档讨论 mod_rewrite 和 URL 匹配的一些技术细节。

+
+模块文档 +mod_rewrite 简介 +重定向和重映射 +访问控制 +虚拟主机 +代理 +使用 RewriteMap +高级技术 +何时不使用 mod_rewrite + +
API 阶段 + +

Apache HTTP 服务器分多个阶段处理请求。在每个阶段, + 一个或多个模块可能被调用来处理请求生命周期的那个部分。 + 这些阶段包括 URL 到文件名转换、身份验证、授权、内容和日志记录等。 + (这不是一个详尽的列表。)

+ +

mod_rewrite 在其中两个阶段(或通常所说的"钩子") + 中起作用,以影响 URL 的重写方式。

+ +

首先,它使用 URL 到文件名转换钩子,该钩子在 HTTP + 请求被读取之后、但在任何授权开始之前触发。其次,它使用 Fixup 钩子, + 该钩子在授权阶段之后、在目录级配置文件(.htaccess 文件) + 被读取之后、但在内容处理程序被调用之前触发。

+ +

当请求进入并确定了对应的服务器或虚拟主机后, + 重写引擎开始处理出现在服务器级配置中的所有 mod_rewrite + 指令。(即在主服务器配置文件和 Virtualhost 配置段中。) + 这发生在 URL 到文件名转换阶段。

+ +

几个步骤之后,一旦找到最终的数据目录, + 就会应用目录级配置指令(.htaccess 文件和 Directory 块)。 + 这发生在 Fixup 阶段。

+ +

在每种情况下,mod_rewrite 都会将 + REQUEST_URI 重写为新的 URL 或文件名。

+ +

在目录级上下文中(即在 .htaccess 文件和 + Directory 块中),这些规则在 URL + 已经被转换为文件名之后才被应用。因此,mod_rewrite + 最初用来与 RewriteRule + 指令进行比较的 URL 路径是转换后的完整文件系统路径, + 其中当前目录路径(包括尾部斜杠)已从前面被移除。

+ +

举例来说:如果规则位于 /var/www/foo/.htaccess 中, + 正在处理对 /foo/bar/baz 的请求,则表达式 ^bar/baz$ 将会匹配。

+ +

如果在目录级上下文中进行了替换,将使用新的 URL + 发出新的内部子请求,重新开始请求阶段的处理。如果替换是相对路径, + RewriteBase + 指令决定在替换前面添加的 URL 路径前缀。在目录级上下文中, + 必须注意创建的规则最终(在未来某轮目录级重写处理中)不会执行替换, + 以避免循环。(参见 RewriteLooping + 以进一步讨论此问题。)

+ +

由于在目录级上下文中对 URL 进行了进一步操作, + 你需要注意在该上下文中以不同方式编写重写规则。特别要记住, + 前导目录路径将从你的重写规则所看到的 URL 中被去除。 + 请参考下面的示例以进一步说明。

+ + + + + + + + + + + + + + + + + + + + + + + +
规则位置规则
VirtualHost 配置段RewriteRule "^/images/(.+)\.jpg" "/images/$1.gif"
文档根目录下的 .htaccess 文件RewriteRule "^images/(.+)\.jpg" "images/$1.gif"
images 目录下的 .htaccess 文件RewriteRule "^(.+)\.jpg" "$1.gif"
+ +

要更深入地了解 mod_rewrite 如何在不同上下文中操作 URL, + 你应该查阅重写期间生成的日志条目。

+ +
+ +
规则集处理 + +

现在当 mod_rewrite 在这两个 API 阶段被触发时, + 它从其配置结构中读取已配置的规则集(该配置结构在服务器级上下文中于启动时创建, + 或在目录级上下文中于 Apache 内核的目录遍历过程中创建)。 + 然后使用包含的规则集(一条或多条规则及其条件)启动 URL 重写引擎。 + URL 重写引擎本身的操作在两种配置上下文中完全相同。 + 只有最终结果的处理方式不同。

+ +

规则集中规则的顺序很重要,因为重写引擎以一种特殊的(且不太直观的) + 顺序处理它们。规则如下:重写引擎逐条遍历规则集中的规则 + (RewriteRule 指令), + 当某条规则匹配时,它会可选地遍历对应的条件 + (RewriteCond 指令)。由于历史原因, + 条件写在前面,因此控制流程有点绕。参见图 1 了解更多细节。

+

+ RewriteRule 和 RewriteCond 匹配流程
+ 图 1:重写规则集的控制流程 +

+

首先,URL 与每条规则的模式进行匹配。如果匹配失败, + mod_rewrite 立即停止处理该规则,并继续处理下一条规则。 + 如果模式匹配成功,mod_rewrite + 会查找对应的规则条件(RewriteCond 指令, + 在配置中紧接在 RewriteRule 之前出现)。 + 如果没有条件,则用从字符串替换构造的新值替换 URL, + 并继续其规则循环。但如果存在条件,则启动一个内部循环, + 按照条件列出的顺序处理它们。对于条件,逻辑是不同的: + 我们不是将模式与当前 URL 匹配。而是首先通过展开变量、 + 反向引用、映射查找等来创建一个字符串 TestString, + 然后尝试将 CondPattern 与之匹配。如果模式不匹配, + 则整组条件和对应规则都失败。如果模式匹配,则处理下一个条件, + 直到没有更多条件为止。如果所有条件都匹配, + 则继续用替换替换 URL。

+ +
+ + +
diff --git a/docs/manual/rewrite/vhosts.xml.de b/docs/manual/rewrite/vhosts.xml.de new file mode 100644 index 0000000000..796f77b192 --- /dev/null +++ b/docs/manual/rewrite/vhosts.xml.de @@ -0,0 +1,219 @@ + + + + + + + + + Rewrite + +Dynamische Massen-Virtual-Hosts mit mod_rewrite + + + +

Dieses Dokument ergänzt die mod_rewrite +Referenzdokumentation. Es beschreibt, +wie Sie mod_rewrite verwenden können, um dynamisch +konfigurierte virtuelle Hosts zu erstellen.

+ +mod_rewrite ist normalerweise nicht der beste Weg, +um virtuelle Hosts zu konfigurieren. Sie sollten zuerst die +Alternativen in Betracht ziehen, bevor +Sie auf mod_rewrite zurückgreifen. Siehe auch das Dokument +"Wie man mod_rewrite vermeidet". + +
+Moduldokumentation +Einführung in mod_rewrite +Umleitung und Neuzuordnung +Zugriffskontrolle + +Proxying +RewriteMap +Fortgeschrittene Techniken +Wann man mod_rewrite nicht verwenden sollte + +
+ + Virtuelle Hosts für beliebige Hostnamen + +
+
Beschreibung:
+ +
+

Wir möchten automatisch einen virtuellen Host für jeden Hostnamen + erstellen, der in unserer Domain aufgelöst wird, ohne für jeden + eine neue VirtualHost-Sektion erstellen zu müssen.

+ +

In diesem Rezept nehmen wir an, dass wir den Hostnamen + SITE.example.com für jeden Benutzer + verwenden und deren Inhalte aus + /home/SITE/www ausliefern. Wir möchten + jedoch, dass www.example.com von dieser Zuordnung + ausgenommen wird.

+
+ +
Lösung:
+ +
+ + +RewriteEngine on + +RewriteMap lowercase int:tolower + +RewriteCond %{HTTP_HOST} !^www\. +RewriteCond ${lowercase:%{HTTP_HOST}} ^([^.]+)\.example\.com$ +RewriteRule ^(.*) /home/%1/www$1 +
+ +
Diskussion
+
+ + Sie müssen sich um die DNS-Auflösung kümmern - + Apache übernimmt keine Namensauflösung. Sie müssen entweder + CNAME-Einträge für jeden Hostnamen oder einen DNS-Wildcard-Eintrag + erstellen. Die Erstellung von DNS-Einträgen liegt außerhalb des + Umfangs dieses Dokuments. + +

Die interne tolower-RewriteMap-Direktive wird verwendet, +um sicherzustellen, dass alle verwendeten Hostnamen in Kleinbuchstaben +sind, sodass keine Mehrdeutigkeit in der Verzeichnisstruktur entsteht, +die erstellt werden muss.

+ +

Klammern in einer RewriteCond +werden in die Rückreferenzen %1, %2 usw. +erfasst, während Klammern in RewriteRule +in die Rückreferenzen $1, $2 usw. erfasst +werden.

+ +

Die erste RewriteCond prüft, ob der Hostname mit +www. beginnt, und wenn ja, wird die Umschreibung +übersprungen.

+ +

+Wie bei vielen in diesem Dokument besprochenen Techniken ist +mod_rewrite wirklich nicht der beste Weg, um diese Aufgabe +zu erledigen. Sie sollten stattdessen die Verwendung von +mod_vhost_alias in Betracht ziehen, da es alles jenseits +der Auslieferung statischer Dateien wesentlich eleganter handhabt, wie +dynamische Inhalte und Alias-Auflösung. +

+
+
+ +
+ +
Dynamische virtuelle Hosts mit + <module>mod_rewrite</module> + +

Dieser Auszug aus httpd.conf bewirkt dasselbe wie + das erste Beispiel. Die erste Hälfte + ist dem entsprechenden Teil oben sehr ähnlich, mit einigen + Änderungen, die für die Abwärtskompatibilität und die korrekte + Funktionsweise des mod_rewrite-Teils erforderlich + sind; die zweite Hälfte konfiguriert mod_rewrite + für die eigentliche Arbeit.

+ +

Da mod_rewrite vor anderen URI-Übersetzungsmodulen + (z.B. mod_alias) läuft, muss mod_rewrite + angewiesen werden, alle URLs, die von diesen Modulen verarbeitet + worden wären, explizit zu ignorieren. Und da diese Regeln ansonsten + alle ScriptAlias-Direktiven umgehen würden, müssen + wir mod_rewrite diese Zuordnungen explizit durchführen + lassen.

+ + +# Den Servernamen aus dem Host:-Header ermitteln +UseCanonicalName Off + +# Aufteilbare Protokolldateien +LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon +CustomLog "logs/access_log" vcommon + +<Directory "/www/hosts"> + # ExecCGI wird hier benötigt, da wir die CGI-Ausführung + # nicht so erzwingen können wie ScriptAlias es tut + Options FollowSymLinks ExecCGI +</Directory> + +RewriteEngine On + +# Ein vom Host:-Header abgeleiteter ServerName kann beliebige Groß-/Kleinschreibung haben +RewriteMap lowercase "int:tolower" + +## Zuerst normale Dokumente behandeln: +# Alias /icons/ zulassen - für andere Aliase wiederholen +RewriteCond "%{REQUEST_URI}" "!^/icons/" +# CGIs zulassen +RewriteCond "%{REQUEST_URI}" "!^/cgi-bin/" +# Die Magie ausführen +RewriteRule "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1" + +## Nun CGIs behandeln - wir müssen einen Handler erzwingen +RewriteCond "%{REQUEST_URI}" "^/cgi-bin/" +RewriteRule "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1" [H=cgi-script] + + +
+ +
Verwendung einer separaten Konfigurationsdatei für virtuelle Hosts + +

Diese Anordnung verwendet fortgeschrittenere + mod_rewrite-Funktionen, um die Übersetzung vom + virtuellen Host zum Document Root aus einer separaten + Konfigurationsdatei abzuleiten. Dies bietet mehr Flexibilität, + erfordert aber eine kompliziertere Konfiguration.

+ +

Die vhost.map-Datei sollte in etwa so aussehen:

+ + +customer-1.example.com /www/customers/1
+customer-2.example.com /www/customers/2
+# ...
+customer-N.example.com /www/customers/N
+
+ +

Die httpd.conf sollte Folgendes enthalten:

+ + +RewriteEngine on + +RewriteMap lowercase "int:tolower" + +# Die Map-Datei definieren +RewriteMap vhost "txt:/www/conf/vhost.map" + +# Aliase wie oben behandeln +RewriteCond "%{REQUEST_URI}" "!^/icons/" +RewriteCond "%{REQUEST_URI}" "!^/cgi-bin/" +RewriteCond "${lowercase:%{SERVER_NAME}}" "^(.+)$" +# Dies führt die dateibasierte Neuzuordnung durch +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] + + +
+ +
\ No newline at end of file diff --git a/docs/manual/rewrite/vhosts.xml.es b/docs/manual/rewrite/vhosts.xml.es new file mode 100644 index 0000000000..68ba8c298c --- /dev/null +++ b/docs/manual/rewrite/vhosts.xml.es @@ -0,0 +1,214 @@ + + + + + + + + + Rewrite + +Hosts virtuales masivos dinámicos con mod_rewrite + + + +

Este documento complementa la mod_rewrite +documentación de referencia. Describe +cómo puede usar mod_rewrite para crear hosts virtuales +configurados dinámicamente.

+ +mod_rewrite generalmente no es la mejor forma de configurar +hosts virtuales. Debería considerar primero las alternativas antes de recurrir a +mod_rewrite. Vea también el documento "cómo evitar +mod_rewrite". + +
+Documentación del módulo +Introducción a mod_rewrite +Redirección y remapeo +Control de acceso + +Proxy +RewriteMap +Técnicas avanzadas +Cuándo no usar mod_rewrite + +
+ + Hosts Virtuales para Nombres de Host Arbitrarios + +
+
Descripción:
+ +
+

Queremos crear automáticamente un host virtual para cada nombre de host + que resuelva en nuestro dominio, sin tener que crear + nuevas secciones VirtualHost.

+ +

En esta receta, asumimos que usaremos el nombre de host + SITIO.example.com para cada + usuario, y serviremos su contenido desde + /home/SITIO/www. Sin embargo, queremos + que www.example.com sea omitido de este mapeo.

+
+ +
Solución:
+ +
+ + +RewriteEngine on + +RewriteMap lowercase int:tolower + +RewriteCond %{HTTP_HOST} !^www\. +RewriteCond ${lowercase:%{HTTP_HOST}} ^([^.]+)\.example\.com$ +RewriteRule ^(.*) /home/%1/www$1 +
+ +
Discusión
+
+ + Necesitará encargarse de la resolución DNS + - Apache no maneja la resolución de nombres. Necesitará crear registros CNAME + para cada nombre de host, o un registro DNS comodín. La creación de registros DNS + está fuera del alcance de este documento. + +

La directiva interna tolower de RewriteMap se usa para +asegurar que los nombres de host que se usen estén todos en minúsculas, de modo que no haya +ambigüedad en la estructura de directorios que debe crearse.

+ +

Los paréntesis usados en una RewriteCond se capturan en las +referencias inversas %1, %2, etc, mientras que los paréntesis +usados en RewriteRule se +capturan en las referencias inversas $1, $2, +etc.

+ +

La primera RewriteCond verifica si el nombre de host +comienza con www., y si es así, la reescritura se +omite.

+ +

+Como con muchas técnicas discutidas en este documento, mod_rewrite realmente +no es la mejor forma de lograr esta tarea. Debería, en su lugar, +considerar usar mod_vhost_alias, ya que manejará +mucho más elegantemente cualquier cosa más allá de servir archivos estáticos, como cualquier +contenido dinámico, y resolución de Alias. +

+
+
+ +
+ +
Hosts Virtuales + Dinámicos Usando <module>mod_rewrite</module> + +

Este extracto de httpd.conf hace lo mismo + que el primer ejemplo. La primera + mitad es muy similar a la parte correspondiente anterior, excepto por + algunos cambios, necesarios para compatibilidad hacia atrás y para hacer que la + parte de mod_rewrite funcione correctamente; la segunda mitad + configura mod_rewrite para hacer el trabajo real.

+ +

Debido a que mod_rewrite se ejecuta antes que otros módulos de traducción + de URI (por ejemplo, mod_alias), se le debe decir a mod_rewrite + que ignore explícitamente cualquier URL que hubiera sido manejada + por esos módulos. Y, debido a que estas reglas de lo contrario evitarían + cualquier directiva ScriptAlias, debemos hacer que + mod_rewrite ejecute explícitamente esos mapeos.

+ + +# 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] + + +
+ +
Usando un Archivo de Configuración de Host Virtual Separado + +

Este arreglo usa características más avanzadas de mod_rewrite + para determinar la traducción de host virtual a raíz de documento, + desde un archivo de configuración separado. Esto proporciona más + flexibilidad, pero requiere una configuración más complicada.

+ +

El archivo vhost.map debería verse algo como + esto:

+ + +customer-1.example.com /www/customers/1
+customer-2.example.com /www/customers/2
+# ...
+customer-N.example.com /www/customers/N
+
+ +

El httpd.conf debería contener lo siguiente:

+ + +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] + + +
+ +
diff --git a/docs/manual/rewrite/vhosts.xml.ja b/docs/manual/rewrite/vhosts.xml.ja new file mode 100644 index 0000000000..94a3410b21 --- /dev/null +++ b/docs/manual/rewrite/vhosts.xml.ja @@ -0,0 +1,212 @@ + + + + + + + + + Rewrite + +mod_rewrite を使った動的な大量バーチャルホスト + + + +

このドキュメントは mod_rewrite +リファレンスドキュメントを補足するものです。 +mod_rewrite を使用して動的に設定されるバーチャルホストを +作成する方法を説明します。

+ +mod_rewrite は通常、バーチャルホストを +設定する最良の方法ではありません。mod_rewrite に頼る前に、まず +代替手段を検討してください。 +「mod_rewrite を避ける方法」ドキュメントも +参照してください。 + +
+モジュールドキュメント +mod_rewrite 入門 +リダイレクトとリマッピング +アクセス制御 + +プロキシ +RewriteMap +高度なテクニック +mod_rewrite を使わない場合 + +
+ + 任意のホスト名に対するバーチャルホスト + +
+
説明:
+ +
+

ドメイン内で解決されるすべてのホスト名に対して、新しい + VirtualHost セクションを作成することなく、自動的にバーチャルホストを + 作成したいとします。

+ +

このレシピでは、各ユーザに対してホスト名 + SITE.example.com を使用し、 + コンテンツを /home/SITE/www から + 提供すると仮定しています。ただし、www.example.com は + このマッピングから除外したいとします。

+
+ +
解決方法:
+ +
+ + +RewriteEngine on + +RewriteMap lowercase int:tolower + +RewriteCond %{HTTP_HOST} !^www\. +RewriteCond ${lowercase:%{HTTP_HOST}} ^([^.]+)\.example\.com$ +RewriteRule ^(.*) /home/%1/www$1 +
+ +
議論
+
+ + DNS 解決に注意する必要があります - Apache は + 名前解決を処理しません。各ホスト名の CNAME レコードか、DNS + ワイルドカードレコードを作成する必要があります。DNS レコードの + 作成はこのドキュメントの範囲外です。 + +

内部 tolower RewriteMap ディレクティブは、使用される +ホスト名がすべて小文字であることを保証し、作成すべきディレクトリ構造に +曖昧さがないようにします。

+ +

RewriteCond で使用される +括弧はバックリファレンス %1、%2 等に +キャプチャされ、RewriteRule +で使用される括弧はバックリファレンス $1、$2 +等にキャプチャされます。

+ +

最初の RewriteCond は、ホスト名が www. で +始まるかどうかを確認し、始まる場合は書き換えがスキップされます。

+ +

+このドキュメントで説明されている多くのテクニックと同様に、 +mod_rewrite はこのタスクを達成する最良の方法では +ありません。代わりに mod_vhost_alias の使用を検討して +ください。静的ファイルの提供以外のこと、例えば動的コンテンツや +Alias の解決をはるかに優雅に処理できます。 +

+
+
+ +
+ +
<module>mod_rewrite</module> + を使った動的バーチャルホスト + +

この httpd.conf からの抜粋は、 + 最初の例と同じことを行います。 + 前半は上記の対応する部分と非常に似ていますが、後方互換性のため、 + および mod_rewrite 部分が正しく動作するように + いくつかの変更が加えられています。後半は mod_rewrite + に実際の作業を設定します。

+ +

mod_rewrite は他の URI 変換モジュール + (例: mod_alias) よりも前に実行されるため、 + それらのモジュールで処理されるはずの URL を明示的に無視するように + mod_rewrite に指示する必要があります。また、これらの + ルールは ScriptAlias ディレクティブをバイパスするため、 + mod_rewrite にそれらのマッピングを明示的に実行させる + 必要があります。

+ + +# 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] + + +
+ +
個別のバーチャルホスト設定ファイルの使用 + +

この構成では、mod_rewrite のより高度な機能を使用して、 + 個別の設定ファイルからバーチャルホストのドキュメントルートへの + 変換を行います。これにより柔軟性が高まりますが、より複雑な設定が + 必要になります。

+ +

vhost.map ファイルは次のようになります:

+ + +customer-1.example.com /www/customers/1
+customer-2.example.com /www/customers/2
+# ...
+customer-N.example.com /www/customers/N
+
+ +

httpd.conf には以下を含める必要があります:

+ + +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] + + +
+ +
diff --git a/docs/manual/rewrite/vhosts.xml.ko b/docs/manual/rewrite/vhosts.xml.ko new file mode 100644 index 0000000000..8e66415cee --- /dev/null +++ b/docs/manual/rewrite/vhosts.xml.ko @@ -0,0 +1,219 @@ + + + + + + + + + Rewrite + +mod_rewrite를 사용한 동적 대량 가상 호스트 + + + +

이 문서는 mod_rewrite +참조 문서를 보충합니다. +mod_rewrite를 사용하여 동적으로 구성된 +가상 호스트를 만드는 방법을 설명합니다.

+ +mod_rewrite는 보통 가상 호스트를 +구성하는 최선의 방법이 아닙니다. mod_rewrite에 의존하기 전에 +먼저 대안을 고려해야 합니다. +"mod_rewrite를 피하는 방법" +문서도 참조하십시오. + +
+모듈 문서 +mod_rewrite 소개 +리다이렉션과 재매핑 +접근 제어 + +프록시 +RewriteMap +고급 기술 +mod_rewrite를 사용하지 말아야 할 경우 + +
+ + 임의 호스트명에 대한 가상 호스트 + +
+
설명:
+ +
+

새로운 VirtualHost 섹션을 만들지 않고 도메인에서 + 해석되는 모든 호스트명에 대해 자동으로 가상 호스트를 + 만들고자 합니다.

+ +

이 레시피에서는 각 사용자에 대해 호스트명 + SITE.example.com을 사용하고 + /home/SITE/www에서 콘텐츠를 + 제공한다고 가정합니다. 그러나 + www.example.com은 이 매핑에서 제외하고자 + 합니다.

+
+ +
해결책:
+ +
+ + +RewriteEngine on + +RewriteMap lowercase int:tolower + +RewriteCond %{HTTP_HOST} !^www\. +RewriteCond ${lowercase:%{HTTP_HOST}} ^([^.]+)\.example\.com$ +RewriteRule ^(.*) /home/%1/www$1 +
+ +
토론
+
+ + DNS 해석을 직접 관리해야 합니다 - + Apache는 이름 해석을 처리하지 않습니다. 각 호스트명에 + 대한 CNAME 레코드 또는 DNS 와일드카드 레코드를 + 만들어야 합니다. DNS 레코드 생성은 이 문서의 범위를 + 벗어납니다. + +

내부 tolower RewriteMap 지시어는 사용되는 +호스트명이 모두 소문자인지 확인하여 생성해야 하는 디렉토리 +구조에 모호함이 없도록 합니다.

+ +

RewriteCond에서 +사용된 괄호는 역참조 %1, %2 등으로 +캡처되며, RewriteRule에서 +사용된 괄호는 역참조 $1, $2 등으로 +캡처됩니다.

+ +

첫 번째 RewriteCond는 호스트명이 +www.로 시작하는지 확인하고, 그렇다면 재작성이 +건너뛰어집니다.

+ +

+이 문서에서 논의된 많은 기술과 마찬가지로, +mod_rewrite는 실제로 이 작업을 수행하는 +최선의 방법이 아닙니다. 대신 mod_vhost_alias +사용을 고려해야 합니다. 이 모듈은 동적 콘텐츠와 Alias +해석 등 정적 파일 제공 이상의 모든 것을 훨씬 더 우아하게 +처리합니다. +

+
+
+ +
+ +
<module>mod_rewrite</module>를 + 사용한 동적 가상 호스트 + +

httpd.conf에서의 이 발췌는 + 첫 번째 예제와 동일한 작업을 + 수행합니다. 전반부는 위의 해당 부분과 매우 유사하지만 + 하위 호환성을 위해 그리고 mod_rewrite + 부분이 올바르게 작동하도록 필요한 일부 변경이 있습니다. + 후반부는 실제 작업을 수행하도록 + mod_rewrite를 구성합니다.

+ +

mod_rewrite는 다른 URI 변환 모듈(예: + mod_alias) 전에 실행되므로, + mod_rewrite에게 그러한 모듈이 처리했을 + URL을 명시적으로 무시하도록 지시해야 합니다. 또한 이 + 규칙이 ScriptAlias 지시어를 우회하므로 + mod_rewrite가 이러한 매핑을 명시적으로 + 수행하도록 해야 합니다.

+ + +# 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] + + +
+ +
별도의 가상 호스트 설정 파일 사용 + +

이 배치는 더 고급 mod_rewrite 기능을 + 사용하여 별도의 설정 파일에서 가상 호스트에서 문서 + 루트로의 변환을 수행합니다. 이는 더 많은 유연성을 + 제공하지만 더 복잡한 설정이 필요합니다.

+ +

vhost.map 파일은 다음과 같은 형태여야 + 합니다:

+ + +customer-1.example.com /www/customers/1
+customer-2.example.com /www/customers/2
+# ...
+customer-N.example.com /www/customers/N
+
+ +

httpd.conf에는 다음이 포함되어야 + 합니다:

+ + +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] + + +
+ +
diff --git a/docs/manual/rewrite/vhosts.xml.meta b/docs/manual/rewrite/vhosts.xml.meta index 02e019991d..23efe3a60b 100644 --- a/docs/manual/rewrite/vhosts.xml.meta +++ b/docs/manual/rewrite/vhosts.xml.meta @@ -7,7 +7,13 @@ .. + de en + es fr + ja + ko + tr + zh-cn diff --git a/docs/manual/rewrite/vhosts.xml.tr b/docs/manual/rewrite/vhosts.xml.tr new file mode 100644 index 0000000000..149fe39db1 --- /dev/null +++ b/docs/manual/rewrite/vhosts.xml.tr @@ -0,0 +1,220 @@ + + + + + + + + + Rewrite + +mod_rewrite ile Devingen Kitlesel Sanal Konaklar + + + +

Bu belge, mod_rewrite +başvuru belgelerini tamamlar. +Devingen olarak yapılandırılmış sanal konaklar oluşturmak için +mod_rewrite modülünü nasıl kullanabileceğinizi +açıklar.

+ +mod_rewrite, sanal konakları +yapılandırmanın genellikle en iyi yolu değildir. mod_rewrite'a +başvurmadan önce alternatifleri +değerlendirmelisiniz. Ayrıca "mod_rewrite +kullanmaktan nasıl kaçınılır" belgesine de bakın. + +
+Modül belgeleri +mod_rewrite'a giriş +Yeniden yönlendirme ve yeniden eşleme +Erişim denetimi + +Vekil kullanımı +RewriteMap +İleri teknikler +mod_rewrite kullanılmaması gereken durumlar + +
+ + Keyfi Konak Adları için Sanal Konaklar + +
+
Açıklama:
+ +
+

Alan adımızda çözümlenen her konak adı için, yeni VirtualHost + bölümleri oluşturmak zorunda kalmadan otomatik olarak bir sanal + konak oluşturmak istiyoruz.

+ +

Bu tarifle, her kullanıcı için + SITE.example.com konak adını + kullanacağımızı ve içeriklerini + /home/SITE/www dizininden + sunacağımızı varsayıyoruz. Ancak + www.example.com'u bu eşlemeden hariç tutmak + istiyoruz.

+
+ +
Çözüm:
+ +
+ + +RewriteEngine on + +RewriteMap lowercase int:tolower + +RewriteCond %{HTTP_HOST} !^www\. +RewriteCond ${lowercase:%{HTTP_HOST}} ^([^.]+)\.example\.com$ +RewriteRule ^(.*) /home/%1/www$1 +
+ +
Tartışma
+
+ + DNS çözümlemesine dikkat etmeniz + gerekecektir - Apache ad çözümlemesini üstlenmez. Her konak adı + için CNAME kayıtları veya bir DNS joker kaydı oluşturmanız + gerekecektir. DNS kayıtları oluşturmak bu belgenin kapsamı + dışındadır. + +

Kullanılan konak adlarının tümünün küçük harf olmasını sağlamak +için dahili tolower RewriteMap yönergesi kullanılır; +böylece oluşturulması gereken dizin yapısında belirsizlik olmaz.

+ +

Bir RewriteCond +içinde kullanılan parantezler %1, %2 vb. +geri başvurulara yakalanırken, RewriteRule içinde kullanılan +parantezler $1, $2 vb. geri başvurulara +yakalanır.

+ +

İlk RewriteCond, konak adının www. ile +başlayıp başlamadığını kontrol eder ve başlıyorsa yeniden yazma +atlanır.

+ +

+Bu belgede tartışılan birçok teknikte olduğu gibi, bu görevi +gerçekleştirmek için mod_rewrite gerçekten en iyi +yol değildir. Bunun yerine, statik dosyaların sunulmasının ötesinde +devingen içerik ve Alias çözümlemesi gibi şeyleri çok daha zarif bir +şekilde ele alacak olan mod_vhost_alias kullanmayı +düşünmelisiniz. +

+
+
+ +
+ +
<module>mod_rewrite</module> + Kullanılarak Devingen Sanal Konaklar + +

Bu httpd.conf alıntısı, ilk örnekle aynı şeyi yapar. İlk yarısı + yukarıdaki karşılık gelen bölüme çok benzer; ancak geriye dönük + uyumluluk ve mod_rewrite bölümünün düzgün + çalışması için gereken bazı değişiklikler yapılmıştır; ikinci + yarısı ise mod_rewrite modülünü asıl işi yapacak + şekilde yapılandırır.

+ +

mod_rewrite, diğer URI çeviri modüllerinden + (örneğin mod_alias) önce çalıştığından, + mod_rewrite modülüne bu modüller tarafından + işlenecek URL'leri açıkça yok sayması söylenmelidir. Ve bu + kurallar aksi takdirde ScriptAlias yönergelerini + atlayacağından, mod_rewrite modülünün bu + eşlemeleri açıkça uygulaması gerekir.

+ + +# Konak adını Host: başlığından al +UseCanonicalName Off + +# bölünebilir günlükler +LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon +CustomLog "logs/access_log" vcommon + +<Directory "/www/hosts"> + # ScriptAlias'ın yaptığı gibi CGI yürütmesini + # zorlayamadığımız için burada ExecCGI gereklidir + Options FollowSymLinks ExecCGI +</Directory> + +RewriteEngine On + +# bir Host: başlığından türetilen ServerName herhangi bir durumda olabilir +RewriteMap lowercase "int:tolower" + +## önce normal belgeleri ele al: +# Alias /icons/ çalışmasına izin ver - diğer takma adlar için tekrarla +RewriteCond "%{REQUEST_URI}" "!^/icons/" +# CGI'lerin çalışmasına izin ver +RewriteCond "%{REQUEST_URI}" "!^/cgi-bin/" +# sihri yap +RewriteRule "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1" + +## şimdi CGI'lerle ilgilen - bir işleyici zorlamalıyız +RewriteCond "%{REQUEST_URI}" "^/cgi-bin/" +RewriteRule "^/(.*)$" "/www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1" [H=cgi-script] + + +
+ +
Ayrı Bir Sanal Konak Yapılandırma Dosyası Kullanımı + +

Bu düzenleme, sanal konaktan belge köküne çeviriyi ayrı bir + yapılandırma dosyasından çözmek için daha gelişmiş + mod_rewrite özelliklerini kullanır. Bu daha fazla + esneklik sağlar ancak daha karmaşık yapılandırma gerektirir.

+ +

vhost.map dosyası şöyle görünmelidir:

+ + +customer-1.example.com /www/customers/1
+customer-2.example.com /www/customers/2
+# ...
+customer-N.example.com /www/customers/N
+
+ +

httpd.conf dosyası şunları içermelidir:

+ + +RewriteEngine on + +RewriteMap lowercase "int:tolower" + +# eşlem dosyasını tanımla +RewriteMap vhost "txt:/www/conf/vhost.map" + +# takma adlarla yukarıdaki gibi ilgilen +RewriteCond "%{REQUEST_URI}" "!^/icons/" +RewriteCond "%{REQUEST_URI}" "!^/cgi-bin/" +RewriteCond "${lowercase:%{SERVER_NAME}}" "^(.+)$" +# dosya tabanlı yeniden eşlemeyi yap +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] + + +
+ +
diff --git a/docs/manual/rewrite/vhosts.xml.zh-cn b/docs/manual/rewrite/vhosts.xml.zh-cn new file mode 100644 index 0000000000..144bd2ed63 --- /dev/null +++ b/docs/manual/rewrite/vhosts.xml.zh-cn @@ -0,0 +1,199 @@ + + + + + + + + + Rewrite + +使用 mod_rewrite 实现动态批量虚拟主机 + + + +

本文档是 mod_rewrite +参考文档的补充。它描述了如何使用 +mod_rewrite 来创建动态配置的虚拟主机。

+ +mod_rewrite 通常不是配置虚拟主机的最佳方式。 +你应该首先考虑其他替代方案, +然后再求助于 mod_rewrite。另请参阅"如何避免使用 +mod_rewrite"文档。 + +
+模块文档 +mod_rewrite 简介 +重定向和重映射 +访问控制 + +代理 +RewriteMap +高级技术 +何时不使用 mod_rewrite + +
+ + 任意主机名的虚拟主机 + +
+
描述:
+ +
+

我们希望为域中解析的每个主机名自动创建虚拟主机, + 而无需创建新的 VirtualHost 配置段。

+ +

在本配置方案中,我们假设对每个用户使用主机名 + SITE.example.com, + 并从 /home/SITE/www 提供其内容。 + 但是,我们希望 www.example.com 不包含在此映射中。

+
+ +
解决方案:
+ +
+ + +RewriteEngine on + +RewriteMap lowercase int:tolower + +RewriteCond %{HTTP_HOST} !^www\. +RewriteCond ${lowercase:%{HTTP_HOST}} ^([^.]+)\.example\.com$ +RewriteRule ^(.*) /home/%1/www$1 +
+ +
讨论
+
+ + 你需要注意 DNS 解析 - Apache + 不处理名称解析。你需要为每个主机名创建 CNAME 记录, + 或者创建 DNS 通配符记录。创建 DNS 记录超出了本文档的范围。 + +

内部 tolower RewriteMap 指令用于确保所使用的主机名全部为小写, +以避免目录结构中的歧义。

+ +

在 RewriteCond +中使用的括号会被捕获到反向引用 %1、%2 等中, +而在 RewriteRule +中使用的括号会被捕获到反向引用 $1、$2 等中。

+ +

第一个 RewriteCond 检查主机名是否以 www. 开头, +如果是,则跳过重写。

+ +

+与本文档中讨论的许多技术一样,mod_rewrite +确实不是完成此任务的最佳方式。你应该考虑使用 +mod_vhost_alias,因为它能更优雅地处理静态文件之外的任何内容, +包括动态内容和 Alias 解析。 +

+
+
+ +
+ +
使用 + <module>mod_rewrite</module> 的动态虚拟主机 + +

此 httpd.conf 摘录与第一个示例 + 实现相同的功能。前半部分与上面对应的部分非常相似, + 只是为了向后兼容和使 mod_rewrite 部分正常工作而做了一些更改; + 后半部分配置 mod_rewrite 来完成实际工作。

+ +

因为 mod_rewrite 在其他 URI 转换模块 + (例如 mod_alias)之前运行, + 必须告知 mod_rewrite 显式忽略那些本应由这些模块处理的 URL。 + 而且,由于这些规则会绕过任何 ScriptAlias 指令, + 我们必须让 mod_rewrite 显式执行这些映射。

+ + +# 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] + + +
+ +
使用独立的虚拟主机配置文件 + +

此方案使用更高级的 mod_rewrite 功能, + 从独立的配置文件中计算从虚拟主机到文档根目录的转换。 + 这提供了更大的灵活性,但需要更复杂的配置。

+ +

vhost.map 文件应类似于:

+ + +customer-1.example.com /www/customers/1
+customer-2.example.com /www/customers/2
+# ...
+customer-N.example.com /www/customers/N
+
+ +

httpd.conf 应包含以下内容:

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