Why doesn't $1 store the complete URL when the pattern is ^(.*)$? - apache

Question

There are several topics already about this. But I haven't found an answer or I still don't understand it correctly.I know that $1 represents the match from the first set of parentheses in the RewriteRule regex. $1 also stores this value.But if there is only ^(.*)$, then it seems to work differently?
Example:URL: http://www.example.com/
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC,OR]
RewriteCond %{HTTPS_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
What I understand:1. http://www.example.com/ matches with RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] and stores the match in %1 (=example.com/).2. go to RewriteRule because the URL matched in step 13. RewriteRule gets the string http://www.example.com/. Because of ^(.*)$, http://www.example.com/ matches completely and is stored in $1.4. I think this URL should appear : https://example.com/http://www.example.com/
What actually appears: https://example.com/
Why does $1 have an empty string? It's all matched, isn't it?

Answer 1

There's quite a few misconceptions here that I'll try to address...
RewriteBase /
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC,OR]
RewriteCond %{HTTPS_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
I'll ignore the RewriteBase directive and the second RewriteCond directive...
The RewriteBase directive does not apply here, since there are no relative path substitution strings (the 2nd argument to the RewriteRule directive).
There is no HTTPS_HOST server variable, only HTTP_HOST. See the following question on ServerFault: https://serverfault.com/questions/953020/what-is-the-difference-between-http-host-and-https-host-in-apache-htaccess-file
I think HTTPS_HOST has perpetuated around the internet due to a few typos/misconceptions that have been blindly copy/pasted.
HTTP_HOST contains the value of the Host HTTP request header (the hostname) eg. www.example.com or example.com, depending on what was requested. Hence the name HTTP_ + HOST. This is the same naming convention used for all HTTP request headers. A corresponding server variable is created for each.
So, this becomes (removing the OR flag from the first condition):
RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC]
RewriteRule ^(.*)$ https://%1/$1 [R=301,L]
The RewriteRule pattern (eg. ^(.*)$)
But if there is only ^(.*)$, then it seems to work differently?
No, it works the same. The confusion would seem to be what the RewriteRule pattern actually matches against.
The RewriteRule pattern matches against the URL-path only.
The URL-path is the part of the URL after the scheme + hostname and before the query string. eg. Given a request for http://example.com/ then the URL-path is simply /. Or request http://example.com/foo/bar?param=1 - the URL-path is /foo/bar.
HOWEVER, in a per-directory context like .htaccess (as opposed to a server or virtualhost context) the directory-prefix is first removed from the URL-path before the match occurs. (Because .htaccess is processed after the request is mapped to the filesystem and strictly speaking matches against a file-path.) The directory-prefix is the absolute file path of the .htaccess file itself and notably ends with a slash. eg. When the .htaccess file is located in the document root, then the directory-prefix will be something like /var/www/user/public_html/ (the filesystem path to the document root).
So, given a request for http://example.com/ then the URL-path that is matched by the RewriteRule pattern in .htaccess is simply "" (empty string). Or request http://example.com/foo/bar?param=1 - the URL-path that is matched is foo/bar - no slash prefix.
This is more significant when the .htaccess file is located in a subdirectory off the document root. For example, if the .htaccess file is located in the /subdir subdirectory and there is a request of the form http://example.com/subdir/foo/bar, the RewriteRule pattern will again match against just foo/bar (not subdir/foo/bar or /subdir/foo/bar). This is a significant difference to when RewriteRule directives are used in a server (or virtualhost) context. In a server context, the RewriteRule pattern always matches against the full URL-path, starting with a slash - there is no concept of a directory-prefix when used in a server context, since the directives are processed before the request is mapped to the filesystem.
What I understand:
http://www.example.com/ matches with RewriteCond %{HTTP_HOST} ^www\.(.*)$ [NC] and stores the match in %1 (=example.com/).
go to RewriteRule because the URL matched in step 1
RewriteRule gets the string http://www.example.com/. Because of ^(.*)$, http://www.example.com/ matches completely and is stored
in $1.
I think this URL should appear : https://example.com/http://www.example.com/
You've got the order of processing wrong. It's actually the RewriteRule pattern that is processed first. Only if the RewriteRule pattern matches are the preceding RewriteCond (conditions) processed. If all the conditions are successful then the RewriteRule substituion (2nd argument) occurs.
So, in order, given a request for http://www.example.com/:
RewriteRule ^(.*)$ - The resulting URL-path "" (empty string) matches the RewriteRule pattern ^(.*)$. The $1 backreference then holds an empty string (as does the $0 backreference - which stores the match of the entire pattern - the same in this case)
RewriteCond %{HTTP_HOST} ^www\.(.*)$ - If the RewriteRule pattern matched in step #1 (it does in this case) then the preceding RewriteCond directive is processed. This matches the Host header eg. www.example.com (no http://) against the regex ^www\.(.*)$. If this is successful then the %1 backreference holds the value of the first captured group, ie. example.com in this example.
RewriteRule ^(.*)$ https://%1/$1 [R=301,L] - If the preceding condition(s) is successful then the substitution (ie. https://%1/$1) in the RewriteRule directive occurs. ie. https://example.com/ - %1 is example.om from the captured group in the last matched CondPattern and $1 is an empty string, from the captured group in the RewriteRule pattern.
Other notes:
Due to the order of processing, it is naturally more efficient to do as much pattern matching in the RewriteRule pattern as possible, instead of relying on preceding RewriteCond directives. (A common misconception that RewriteCond directives are processed first - that is not the case.)
Due to the order of processing, you can use $n backreferences in the TestString (first) argument of the preceding RewriteCond directives. (This wouldn't be possible if the directives were literally processed top-down.)
The %n back references are only from the last matched CondPattern. This is important to consider if you have multiple conditions.