Rewrite rewrite rules

The Apache module Mod_rewrite provides a rewrite engine based on the regular expression parser to rewrite URL requests in real time. It supports a flexible and powerful URL manipulation mechanism in which each full rule can have an unlimited number of sub-rules and additional conditional rules. This URL operation can depend on a variety of tests, such as server variables, environment variables, HTTP headers, time stamps, and even lookup databases that match the URL component in various formats.


This module can manipulate all parts of the URL, including the path Information section, both at the server level (httpd.conf) and at the directory-level (. htaccess) configuration, and can also generate a final request string. The result of this override operation can be internal sub-processing, or it can be a steering of an external request, or even an internal agent processing.
Here is an introduction to the rules of Rewritecond and parameter descriptions. The Rewritecond directive defines the conditions under which a rule is valid, that is, one or more rewritecond directives can be preceded by a rewriterule instruction. The rewrite rule after the condition will only work if the current URI matches the pattern and satisfies the conditions here (TestString can match the Condpattern).
"description" defines the condition that overrides occur
"Grammar" Rewritecond teststring Condpattern [flags]
Scope Server config, virtual host, directory,. htaccess
"Overlay" FileInfo
"State" extension (E)
"Module" mod_rewrite
TestString is a plain-text string, but it can also contain the following extensible components:
Rewriterule The Reference method is: $N (0 <= N <= 9) refers to the grouping component (parentheses!) that matches the pattern in Rewritecond of the current (with several rewriterule directives).
Rewritecond A reverse reference, the reference method is:%N (1 <= N <= 9) refers to the grouping component (parentheses!) in the last qualifying condition in several current rewritecond conditions.
Rewritemap extension, the reference method is: ${mapname:key|default} for details, see the REWRITEMAP directive.
Server variables, the reference method is:%{name_of_variable} name_of_variable can be one of the strings listed in the following table:
HTTP Header connection and request
Http_user_agent
Http_referer
Http_cookie
http_forwarded
Http_host
Http_proxy_connection
Http_accept REMOTE_ADDR
Remote_host
Remote_port
Remote_user
Remote_ident
Request_method
Script_filename
Path_info
Query_string
Auth_type
Server itself date and time other
Document_root
Server_admin
server_name
Server_addr
Server_port
Server_protocol
Server_software time_year
Time_mon
Time_day
Time_hour
Time_min
Time_sec
Time_wday
Time Api_version
The_request
Request_uri
Request_filename
Is_subreq
HTTPS

These variables correspond to similar named HTTP MIME headers, c variables on Apache servers, and struct TM fields in Unix systems, most of which are described in other manuals or CGI specifications. The variables that are unique to mod_rewrite are as follows:
Is_subreq
If the request being processed is a child request, it will contain the string "true", otherwise it is "false". The module may produce a child request in order to parse the attached file in the URI.
Api_version
This is the version of the Apache module API that is in use (internal interface between the server and the module), which is defined in Include/ap_mmn.h. This module API version corresponds to the version of Apache that is in use (for example, this value is 19,990,320:10 in the release version of Apache 1.3.14). In general, it is the developer of the module that is interested in it.
The_request
This is the full HTTP request line sent by the browser (for example: "Get/index.html Http/1.1″"). It does not contain any other header information sent by the browser.
Request_uri
This is the resource requested in the HTTP request line (for example, "/index.html" in the above example).
Request_filename
This is the file path name of the complete local file system that matches the request.
HTTPS
If the connection uses SSL/TLS, it will contain the string "on" or "Off" (the variable can be used safely regardless of whether the mod_ssl has been loaded).

Other precautions:
Script_filename and request_filename contain the same values-that is, the filename field in the REQUEST_REC structure inside the Apache server. The first is the CGI variable name that everyone knows, and the second is a copy of Request_uri (the URI field in the REQUEST_REC structure).
Special form:%{env:variable}, where the variable can be any environment variable. It is obtained by searching the Apache internal structure or (if not found) by the Apache server process through getenv ().
Special form:%{ssl:variable}, where the variable can be the name of an SSL environment variable, regardless of whether the Mod_ssl module is already loaded (empty string when not loaded). For example:%{ssl:ssl_cipher_usekeysize} will be replaced with 128.
Special form:%{http:header}, where the header can be the name of any HTTP MIME header. It can always be obtained by looking up HTTP requests. For example:%{http:proxy-connection} will be replaced with the value of the proxy-connection:http header.
Default form:%{la-u:variable}, the final value of the variable is determined after an internal (URL-based) child request is executed. Use this method when you need to use a variable that is currently unknown but will be set in the subsequent procedure. For example, you need to use%{la-u:remote_user} in order to override the Remote_user variable in a server-level configuration (httpd.conf file). Because this variable is overridden by a URL (mod??). _rewrite) Step after the authentication step is set. On the other hand, because Mod_rewrite is configured with the API remediation steps for the directory-level (. htaccess file), the authentication step is preceded by the API remediation step, so you can use%{remote_user}.
Default form:%{la-f:variable}, the final value of the variable is determined after an internal (file-based) child request is executed. In most cases, the la-u is the same as above.

Condpattern is a conditional pattern, which is a regular expression applied to the current teststring instance. TestString will be calculated first and then matched with Condpattern.
Note: Condpattern is a Perl-compatible regular expression, but there are several additions:
1, can be used at the beginning of the Condpattern string '! ' (exclamation point) to specify a mismatch.
2, Condpatterns has a number of special variants. In addition to the standard usage of regular expressions, there are the following uses:
' <condpattern ' (less than the dictionary order)
Treats Condpattern as a pure string, compared to teststring by dictionary order. True if TestString is less than Condpattern.
' >condpattern ' (dictionary order greater than)
Treats Condpattern as a pure string, compared to teststring by dictionary order. True if TestString is greater than condpattern.
' =condpattern ' (dictionary order equals)
Treats Condpattern as a pure string, compared to teststring by dictionary order. True if TestString equals Condpattern (two strings are exactly equal by character). If Condpattern is "" (two double quotes), then teststring will be compared to an empty string.
'-d ' (directory)
Treat TestString as a pathname and test whether it is a directory that exists.
'-f ' (regular file)
Treat teststring as a path name and test whether it is a regular file that exists.
'-S ' (non-empty regular file)
Treat TestString as a pathname and test whether it is an existing regular file with a size greater than 0.
'-l ' (symbolic Connection)
Treat TestString as a pathname and test whether it is an existing symbolic connection.
'-X ' (executable)
Treat TestString as a pathname and test whether it is an existing file with executable permissions. This permission is detected by the operating system.
'-f ' (Files that exist on a child request)
Check if teststring is a valid file and can be accessed under the current access control configuration of the server. It uses an internal sub-request to do the check, because it will reduce the performance of the server, so please use it carefully!
'-u ' (the URL that exists for a child request)
Check if teststring is a valid URL and can be accessed under the current access control configuration of the server. It uses an internal sub-request to do the check, because it will reduce the performance of the server, so please use it carefully!
Note: All of these tests can be prefixed with an exclamation point ('! ') To achieve the reversal of test conditions.
3. You can also append a special tag [flags] after condpattern as the third parameter of the Rewritecond directive. Flags is a comma-delimited list of the following tokens:
' Nocase| NC ' (ignoring case)
It makes the test ignore case, and the expanded teststring and Condpattern ' AZ ' and ' A-Z ' are indistinguishable. This tag is used only for comparisons between TestString and Condpattern, and checks on file systems and child requests do not work.
' Ornext|or ' (or Next condition)
It combines the conditions of several rules in or, not the implied and. A typical example is as follows:
Rewritecond%{remote_host} ^host1.* [OR]
Rewritecond%{remote_host} ^host2.* [OR]
Rewritecond%{remote_host} ^host3.*
Rewriterule ... Rule set for these 3 hosts ... If you don't use this tag, you'll have to write three conditions/rules.
Example
If you want to rewrite the home page of a site by "User-agent:" in the request header, you can write:
Rewritecond% {http_user_agent} ^mozilla.* rewriterule ^/$/homepage. Max. html [L]

Rewritecond% {http_user_agent} ^lynx.* rewriterule ^/$/homepage. Min. html [L]

Rewriterule ^/$/homepage. std.html [L]
Explain:
If you use the browser recognition logo as ' Mozilla ', then you will get the homepage with the maximum content (including frames, etc.).
If you're using Lynx (terminal-based), you get a home page with minimal content (no table, etc.).
If none of the above conditions are met (using a different browser), then you get a standard home page.

Rewrite rewrite rules