What is the difference between HTTP_HOST and HTTPS_HOST in apache .htaccess files?
I'm editing an .htaccess file..
In RewriteCondition for RewriteRules, HTTPS_HOST seems to only match urls that are accessed via https:// protocol (ssl). I saw in docs somewhere that it's a T/F variable that indicates if the url was accessed using the secure protocol.
However, I'm having trouble finding on the docs whether HTTP_HOST only matches http:// protocols, or if it effectively matches // relative protocols, meaning it matches both http:// and https://.
Can someone confirm one way or the other, or point me to a definitive source for this info?
Also, if HTTP_HOST matches both protocol variants, what is the best way to filter for matches of only http:// protocols ?
Example:
<IfModule mod_rewrite.c>
RewriteEngine on
Rewritecond %{HTTP_HOST} ^\/\.(?!some-url).*$
RewriteRule (.*) https://www.example.com/$1 [R=301,L,NC]
</IfModule>
In contrast:
...
Rewritecond %{HTTPS_HOST} ^\/\.(?!some-url).*$
...
Edit: Experimentation shows that HTTP_HOST does seem to match both protocols, whereas HTTPS_HOST only matches when the protocol, or url starts with https://.
.
(Note re: apache2 tag
TBH, I am not certain what version of apache I am running. To try finding out, so I could attach the proper tag..
I tried httpd -v, apache -v, apache2ctl -S, apachectl -S, httpd -S, etc. (It's not a virtualhost question, and I have nginx, which is think is for that (virtual server) anyway, but I tried those last 3 (virtualhost) commands anyway to see if they would enlighten me on my apache version).
Responses to those commands say either that I must first install apache2, or it is an unknown command.
I have an /etc/apache2 folder, but not an /usr/local/apache (hence no /usr/local/apache/bin/httpd folder).
)
Solution 1:
There is no such Apache server variable HTTPS_HOST, only HTTP_HOST. If HTTPS_HOST is set on your server then it's specific to your server.
The HTTP_HOST server variable contains the value of the Host HTTP request header (ie. the hostname), this is irrespective of the protocol used (HTTP or HTTPS). As with all variables that start HTTP_, they contain the value of the respective HTTP request header.
Maybe you're thinking of the HTTPS Apache server variable? This contains the value on or off depending on whether the request is over HTTPS or not. So, providing you don't have a front-end proxy that manages SSL then it is the HTTPS server variable you use to determine whether the request is over HTTP or HTTPS protocol.
Reference:
- Apache 2.4 - RewriteCond Directive
and I have nginx
So, what are you using Nginx for? Is it your application server? Or are you using it as a front end proxy? In which case, HTTPS might not be the variable to use after all.
UPDATE:
Rewritecond %{HTTP_HOST} ^\/\.(?!some-url).*$ RewriteRule (.*) https://www.example.com/$1 [R=301,L,NC]
This doesn't really make sense. The condition (RewriteCond directive) will never be successful (because the Host header never contains a slash), so the redirect will never occur.
As mentioned above, the HTTP_HOST server variable contains the hostname only, eg. example.com or www.example.com. It does not contain the URL-path, as you appear to be assuming here. Your condition is trying to match a literal /. not followed by some-url (using a negative lookahead). The hostname will never start with (or even contain) a slash, so it fails at the first character.
I'm trying to modify an htaccess rule that was blocking letsencrypt renewals, .... So there is the primary issue (.well-known was getting a 403)
To make an exception on a specific rule for a specific URL-path, you would do something like the following:
Rewritecond %{REQUEST_URI} !^/\.well-known
RewriteRule (.*) https://www.example.com/$1 [R=301,L,NC]
This excludes (note the ! prefix) any URL that starts /.well-known. The ! prefix on the CondPattern negates the regex. The REQUEST_URI server variable contains the full URL-path from the request (which naturally excludes the protocol, hostname and query string).
However, you state that ".well-known was getting a 403" - you may need to find out what was triggering the 403 and apply an exception to that rule.
OR, include a single exception at the very top of your .htaccess file:
# Any requests that start "/.well-known" are ignored
RewriteRule ^\.well-known - [L]
(Note the absence of the slash prefix on the RewriteRule pattern that matches the URL-path.)
Initially (and maybe secondarily now also) I thought requiring https on an expired certificate might be a problem.
Yes, that will certainly be a problem. The user will get a browser warning that the certificate is invalid and the request will never reach your server.