Rewritebase Url-path
Rewritebase is used to set the base URL for the override. In the following section, you can see that rewriterule can be used in directory-level configuration files (. htaccess) and in a local scope, that is, the rules actually handle only part of the local path prefix being stripped. After the process is finished, the path is automatically attached back. The default value is "Rewritebase physical-directory-path".
When a new URL is replaced, the module must inject the URL back into the server process. To do this, it must know its corresponding URL prefix or URL reference. Typically, the prefix is the corresponding file path. However, most web site URLs do not directly correspond to their physical file path, and therefore generally do not make such an assumption! So in this case, you must use the Rewritebase directive to specify the correct URL prefix.
If your site server URL does not correspond directly to the physical file path, and you need to use the Rewritebase directive, you must specify the Rewriterule in each of the corresponding. htaccess files.
The rewritebase directive explicitly sets the base URL for a directory-level override. In the following, you will see that rewriterule can be used in directory-level configuration files (. htaccess) and in a local scope, that is, the rule actually handles only part of the local path prefix being stripped. After the process is finished, the path is automatically attached back. The default value is "Rewritebasephysical-directory-path".
When a new URL is replaced, the module must inject the URL back into the server process. To do this, it must know its corresponding URL prefix or URL reference. Typically, the prefix is the corresponding file path. However, most web site URLs do not directly correspond to their physical file path, and therefore generally do not make such an assumption! So in this case, you must use the Rewritebase directive to specify the correct URL prefix.
If your site server URL does not correspond directly to the physical file path, you must use the Rewritebase directive in each. htaccess file that uses Rewriterule.
For example, the contents of a directory-level configuration file are as follows:
#/abc/def/.htaccess--/abc/def directory configuration file
# Note:/abc/def is the physical path of the/xyz (for example, there is a ' alias/xyz/abc/def ' instruction).
Rewriteengine on# Let the server know that we are using/xyz rather than physical paths/abc/defrewritebase/xyz
# rewrite rules Rewriterule ^oldstuff\.html$ newstuff.html
In the above example, the request for/xyz/oldstuff.html is correctly rewritten as a request to the physical file/abc/def/newstuff.html.
For the Apache hacker only reference
The detailed steps for internal processing are listed below:
Request:/xyz/oldstuff.html internal process:/xyz/oldstuff.html->/abc/def/oldstuff.html (per-server Alias)/abc/def/oldstuff . html->/abc/def/newstuff.html (per-dir rewriterule)/abc/def/newstuff.html->/xyz/newstuff.html (per-di R rewritebase)/xyz/newstuff.html->/abc/def/newstuff.html (per-server Alias)
Result:/abc/def/newstuff.html
Although this process appears to be cumbersome, it has to inject this (rewrite) request back into the Apache core because the arrival of the directory-level rewrite is too late, so this is exactly how it is handled within Apache. But: it's not as big as it seems, because the injection is done entirely within the Apache server, and the process is also used by many other operations within Apache. So you can fully trust that its design and implementation are correct.