# RULE#2
RewriteCond %{HTTP_HOST} ^sub\.site1\.org$
RewriteCond %{REQUEST_URI} !/192.168.0.6/
RewriteRule ^(.*)$ /192.168.0.6/$1 [L]
When I go to http://sub.site1.org/files/
it works, but when I go to http://sub.site1.org/files
(without slash), it redirects me to http://sub.site1.org/192.168.0.6/files
You would seem to have a conflict with mod_dir. If /files
exists as a physical directory at /192.168.0.6/files
then mod_dir will append the trailing slash with a 301 redirect (in order to "fix" the URL) after the URL has been rewritten, thus exposing the rewritten URL. (You should be seeing a trailing slash on the redirected URL.)
You need to manually append the trailing slash before the request is rewritten, by checking whether the URL would map to a directory at the new location.
If /files
is the only directory that is likely to receive these types of requests then you could simply hardcode this. For example:
# Append slash to "/files"
RewriteCond %{HTTP_HOST} ^sub\.site1\.org$
RewriteRule ^files$ /$0/ [R=301,L]
# RULE#2 (Updated) - Rewrite request to subdirectory
RewriteCond %{HTTP_HOST} ^sub\.site1\.org$
RewriteCond %{REQUEST_URI} !^/192.168.0.6/
RewriteRule (.*) /192.168.0.6/$1 [L]
NB: You were missing the start-of-string anchor (^
) on the second condition that matches the subdirectory.
You need to clear your browser cache before testing since the erroneous 301 (permanent) redirect by mod_dir will have been cached by the browser.
For this reason it is recommended to test first with a 302 (temporary) redirect.
Otherwise, for a more general, any directory solution then something like the following would be required:
# Append slash to subdirectory BEFORE rewrite
RewriteCond %{HTTP_HOST} ^sub\.site1\.org$
RewriteCond %{REQUEST_URI} !^/192.168.0.6/
RewriteCond %{REQUEST_URI} !\.\w{2,4}$
RewriteCond %{DOCUMENT_ROOT}/192.168.0.6/$1 -d
RewriteRule (.+[^/])$ /$1/ [R=301,L]
# RULE#2 (Updated) - Rewrite request to subdirectory
# (as above)
The same issue potentially applies to RULE#1 and RULE#3 as well. Note that RULE#1 and RULE#2 are essentially the same and could (should) be combined.
Currently, in the rules as posted, there's nothing stopping a user from accessing the "hidden" subdirectory directly (if this should be known). You might consider redirecting the user if they should stumble upon this "hidden" subdirectory.
See also my answer to a similar question that goes into more detail (although that question is dealing with just one "site").