Other documents go into greater detail, but this doc should help the beginner get their feet wet. With it, you can do nearly all types of URL rewriting that you may need. It is, however, somewhat complex, and may be intimidating to the beginner. There is also a tendency to treat rewrite rules as magic incantation, using them without actually understanding what they do. This document attempts to give sufficient background so that what follows is understood, rather than just copied blindly.
|Published (Last):||7 August 2019|
|PDF File Size:||11.88 Mb|
|ePub File Size:||14.55 Mb|
|Price:||Free* [*Free Regsitration Required]|
Each rule can have an unlimited number of attached rule conditions, to allow you to rewrite URL based on server variables, environment variables, HTTP headers, or time stamps. A rewrite rule can be invoked in httpd. The path generated by a rewrite rule can include a query string, or can lead to internal sub-processing, external request redirection, or internal proxy throughput.
This functionality has been completely replaced by the new per-module logging configuration mentioned above. The RewriteBase directive specifies the URL prefix to be used for per-directory htaccess RewriteRule directives that substitute a relative path.
This directive is required when you use a relative path in a substitution in per-directory htaccess context unless any of the following conditions are true:. This misconfiguration would normally cause the server to look for an "opt" directory under the document root. The RewriteCond directive defines a rule condition.
One or more RewriteCond can precede a RewriteRule directive. The following rule is then only used if both the current state of the URI matches its pattern, and if these conditions are met. TestString is a string which can contain the following expanded constructs in addition to plain text:.
Most are documented here or elsewhere in the Manual or in the CGI specification. HTTP headers referenced in the expression will be added to the Vary header if the novary flag is not given.
If a substitution occurred and the rewriting continues, the value of both variables will be updated accordingly. If used in per-server context i. If a HTTP header is used in a condition this header is added to the Vary header of the response in case the condition evaluates to true for the request. It is not added if the condition evaluates to false for the request. It has to be kept in mind that conditions follow a short circuit logic in the case of the ' ornext OR ' flag so that certain conditions might not be evaluated at all.
CondPattern is the condition pattern, a regular expression which is applied to the current instance of the TestString. TestString is first evaluated, before being matched against CondPattern. CondPattern is usually a perl compatible regular expression , but there is additional syntax available to perform other useful tests against the Teststring :.
Is existing URL, via subrequest. Checks whether or not TestString is a valid URL, accessible via all the server's currently-configured access controls for that path. This uses an internal subrequest to do the check, so use it with care - it can impact your server's performance! This flag only returns information about things like access control, authentication, and authorization. This flag does not return information about the status code the configured handler static file, CGI, proxy, etc.
You can also set special flags for CondPattern by appending [ flags ] as the third argument to the RewriteCond directive, where flags is a comma-separated list of any of the following flags:.
Explanation: If you use a browser which identifies itself as a mobile browser note that the example is incomplete, as there are many other mobile platforms , the mobile version of the homepage is served. Otherwise, the standard page is served. The RewriteEngine directive enables or disables the runtime rewriting engine.
If it is set to off this module does no runtime processing at all. Use this directive to disable rules in a particular context, rather than commenting out all the RewriteRule directives. Note that rewrite configurations are not inherited by virtual hosts. This means that you need to have a RewriteEngine on directive for each virtual host in which you wish to use rewrite rules. RewriteMap directives of the type prg are not started during server initialization if they're defined in a context that does not have RewriteEngine set to on.
The source of this lookup can be of various types. The MapName is the name of the map and will be used to specify a mapping-function for the substitution strings of a rewriting rule via one of the following constructs:.
When such a construct occurs, the map MapName is consulted and the key LookupKey is looked-up. If the key is found, the map-function construct is substituted by SubstValue. If the key is not found then it is substituted by DefaultValue or by the empty string if no DefaultValue was specified. Empty values behave as if the key was absent, therefore it is not possible to distinguish between empty-valued keys and absent keys.
You would then be able to use this map in a RewriteRule as follows:. See the Using RewriteMap for more information. Further details, and numerous examples, may be found in the RewriteMap HowTo. The RewriteOptions directive sets some special options for the current per-server or per-directory configuration. The Option string can currently only be one of the following:.
This forces the current configuration to inherit the configuration of the parent. In per-virtual-server context, this means that the maps, conditions and rules of the main server are inherited.
In per-directory context this means that conditions and rules of the parent directory's. The inherited rules are virtually copied to the section where this directive is being used. If used in combination with local rules, the inherited rules are copied behind the local rules.
The position of this directive - below or above of local rules - has no influence on this behavior. If local rules forced the rewriting to stop, the inherited rules won't be processed. Like Inherit above, but the rules from the parent scope are applied before rules specified in the child scope.
If this option is enabled, all child configurations will inherit the configuration of the current configuration. It is equivalent to specifying RewriteOptions Inherit in all child configurations. See the Inherit option for more details on how the parent-child relationships are handled.
Like InheritDown above, but the rules from the current scope are applied before rules specified in any child's scope. This option forces the current and child configurations to ignore all rules that would be inherited from a parent specifying InheritDown or InheritDownBefore. When the DirectorySlash directive is set to off, the AllowNoSlash option can be enabled to ensure that rewrite rules are no longer ignored.
This option makes it possible to apply rewrite rules within. When RewriteRule is used in VirtualHost or server context with version 2. This avoids some security issues where particular rules could allow "surprising" pattern expansions see CVE and CVE Enabling this option will make the server vulnerable to security issues if used with rewrite rules which are not carefully authored.
It is strongly recommended that this option is not used. In particular, beware of input strings containing the ' ' character which could change the interpretation of the transformed URI, as per the above CVE names. With this option, the value of RewriteBase is copied from where it's explicitly defined into any sub-directory or sub-location that doesn't define its own RewriteBase. This was the default behavior in 2. When a relative substitution is made in directory htaccess context and RewriteBase has not been set, this module uses some extended URL and filesystem context information to change the relative substitution back into a URL.
Available in 2. Prior to 2. Since the URL can be reduced to a local path, the path should be prefixed with the document root. This option allows the old behavior to be used where the document root is not prefixed to a local path that was reduced from a URL. The RewriteRule directive is the real rewriting workhorse. The directive can occur more than once, with each instance defining a single rewrite rule.
The order in which these rules are defined is important - this is the order in which they will be applied at run-time. Pattern is a perl compatible regular expression. What this pattern is compared against varies depending on where the RewriteRule directive is defined.
In VirtualHost context, The Pattern will initially be matched against the part of the URL after the hostname and port, and before the query string e. In per-directory context Directory and. The directory path where the rule is defined is stripped from the currently mapped filesystem path before comparison up to and including a trailing slash.
The net result of this per-directory prefix stripping is that rules in this context only match against the portion of the currently mapped filesystem path "below" where the rule is defined.
Directives such as DocumentRoot and Alias , or even the result of previous RewriteRule substitutions, determine the currently mapped filesystem path. This can be used for exceptional cases, where it is easier to match the negative pattern, or as a last default rule. The Substitution of a rewrite rule is the string that replaces the original URL-path that was matched by Pattern. The Substitution may be a:. The server-variables are the same as for the TestString of a RewriteCond directive.
The mapping-functions come from the RewriteMap directive and are explained there. These three types of variables are expanded in the order above. Rewrite rules are applied to the results of previous rewrite rules, in the order in which they are defined in the config file.
The URL-path or file-system path see "What is matched? By default, the query string is passed through unchanged. You can, however, create URLs in the substitution string containing a query string part. Simply use a question mark inside the substitution string to indicate that the following text should be re-injected into the query string. When you want to erase an existing query string, end the substitution string with just a question mark.
To combine new and old query strings, use the [QSA] flag. Additionally you can set special actions to be performed by appending [ flags ] as the third argument to the RewriteRule directive. Flags is a comma-separated list, surround by square brackets, of any of the flags in the following table. More details, and examples, for each flag, are available in the Rewrite Flags document.
Apache Module mod_rewrite
Each rule can have an unlimited number of attached rule conditions, to allow you to rewrite URL based on server variables, environment variables, HTTP headers, or time stamps. A rewrite rule can be invoked in httpd. The path generated by a rewrite rule can include a query string, or can lead to internal sub-processing, external request redirection, or internal proxy throughput. This functionality has been completely replaced by the new per-module logging configuration mentioned above. The RewriteBase directive specifies the URL prefix to be used for per-directory htaccess RewriteRule directives that substitute a relative path. This directive is required when you use a relative path in a substitution in per-directory htaccess context unless any of the following conditions are true:.
The Definitive Guide to Apache mod_rewrite
Apache mod_rewrite Introduction