Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.
Sign up to join this community
I am attempting to redirect
<VirtualHost *:5555>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{SERVER_PORT} =5555
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
However when I attempt to connect to via a web browser it is adding an extra / inbetween the %{HTTP_HOST}//%{REQUEST_URI}
How do I remove the extra / between the values?
If the
Redirectdirective is used within a<Location>or<LocationMatch>section with theURL-pathomitted, then the URL parameter will be interpreted using expression syntax.This syntax is available in Apache 2.4.19 and later
This makes this, once again, a case of When not to use mod_rewrite.
<VirtualHost *:5555>
<Location />
Redirect permanent https://%{HTTP_HOST}/
</Location>
</VirtualHost>
HTTP_HOST server variable (the value of the Host HTTP request header) also includes the port number (if present on the request), so this would redirect to the same port, not port 80 as would seem to be the intention? (Although the same issue would affect the OPs code as well, but neither would the OPs code result in a double slash, so I suspect there is something else going on here?)
Alias directive, where the source URL-path is dropped (mapping to a single URL, as defined using the expression syntax). (There is a new directive AliasPreservePath in later version 2.5.1 that preserves the URL-path with regards to the Alias directive, default Off. Nothing similar for the Redirect directive though AFAICS.)
https (port 443 by default, not port 80 as I mentioned) then that may resolve the issue? (Although I'm not convinced it would?)
<Location> is required for using the expression syntax". This is neither good or "bad", it's simply the required syntax. @DanielFerradal
No need to check the port or if it is SSL, if a requests that is SSL lands here you will get an error since virtualhost won't be able to answer, and virtualhost is already specifying it is port 5555 the port this virtualhost is answering too, so you those redundand directives are not necessary.
If you insist on using mod rewrite and using variables this would be the most simple/correct way.
<VirtualHost *:5555>
ServerName normallyouwantahostnamehere.example.com
RewriteEngine On
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [R=301,L]
</VirtualHost>
If you know the hostname I would be inclined to define it correctly and use a simple redirect (which redirects everything without the need to capture):
<VirtualHost *:5555>
ServerName hostname.example.com
Redirect / https://hostname.example.com/
</VirtualHost
HTTP_HOST server variable also includes the port number (if present on the request)", so your RewriteRule would redirect back to port 5555, not port 443, which is presumably the intention.
It looks like you're trying to redirect HTTP requests on port 5555 to HTTPS without an extra slash between the %{HTTP_HOST} and %{REQUEST_URI}. You can achieve this by modifying your RewriteRule slightly.
Here's the updated configuration:
<VirtualHost *:5555>
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{SERVER_PORT} =5555
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>
The key change here is in the RewriteRule. By using ^ before https://%{HTTP_HOST}, it anchors the rule to the beginning of the URL, ensuring that there won't be an extra slash inserted.
With this modification, the redirect should work without the extra slash between %{HTTP_HOST} and %{REQUEST_URI}.
Let us know if this works, or if you're still having problems!
RewriteRule pattern (that matches against the requested URL-path) from (.*) to ^, which will make no difference at all in this context. "By using ^ before https://%{HTTP_HOST}, it anchors the rule to the beginning of the URL" - no it doesn't. The ^ simply asserts the start-of-string, which will be successful for everything (every URL-path). Whereas (.*) matches everything (and unnecessarily captures everything - the backreference is not used), so the result of ^ and (.*) is the same in this context.