Forum Moderators: phranque
RewriteEngine on
RewriteCond %{HTTP_HOST} example\.com [NC]
RewriteCond %{REQUEST_URI} !^/(foo/bar|images|cgi-bin)
RewriteRule ^(.*)$ foo/bar/$1 [QSA,L]RewriteEngine on
RewriteCond %{HTTP_HOST} example\.com [NC]
RewriteCond %{REQUEST_URI} !foo/bar
RewriteCond %{REQUEST_URI} !^/(images|cgi-bin)
RewriteRule ^(.*)$ ../ww2.example.com/foo/bar/$1 [QSA,L]
[edited by: phranque at 11:23 pm (utc) on Sep 12, 2019]
[edit reason] see charter [/edit]
# Via SSH
cd /home/example/public_html
ln -s /home/example/ww2.example.com ww2
# .htaccess
RewriteEngine on
RewriteCond %{HTTP_HOST} example\.com [NC]
RewriteCond %{REQUEST_URI} !^/(foo/bar|images|cgi-bin)
RewriteRule ^(.*)$ ww2/foo/bar/$1 [QSA,L]
As a marketer who often uses appended parameters to track Source / Medium, I'd say always include QSA.
When the replacement URI contains a query string, the default behavior of RewriteRule is to discard the existing query string, and replace it with the newly generated one. Using the [QSA] flag causes the query strings to be combined.
Consider the following rule:
RewriteRule "/pages/(.+)" "/page.php?page=$1" [QSA]
With the [QSA] flag, a request for /pages/123?one=two will be mapped to /page.php?page=123&one=two. Without the [QSA] flag, that same request will be mapped to /page.php?page=123 - that is, the existing query string will be discarded.
A symlink isn't a bad idea at all!
Options -FollowSymLinks
Options +SymLinksIfOwnerMatch
This option should not be considered a security restriction, since symlink testing is subject to race conditions that make it circumventable.
a secure apache server would prevent apache from following symlinks using this configuration directive:Options -FollowSymLinks
A symlink isn't a bad idea at all!
i would recommend against that solution!
But now I would like to change it to show them what's at:
ww2.example.com/foo/bar
Note that the PT flag is implied in per-directory contexts such as <Directory> sections or in .htaccess files.(And I'm pretty sure you can't do anything involving mod_proxy [P] in htaccess, so scratch that.)
you got the QSA thing all twisted up
(And I'm pretty sure you can't do anything involving mod_proxy [P] in htaccess, so scratch that.)
[Sat Sep 14 09:55:45.816499 2019] [ssl:error] [pid 18133] [remote 2607:f298:5:105b::blahblah] AH01961: SSL Proxy requested for example.com:443 but not enabled [Hint: SSLProxyEngine]
[Sat Sep 14 09:55:45.816580 2019] [proxy:error] [pid 18133] AH00961: HTTPS: failed to enable ssl support for [2607:f298:5:105b::blahblah]:443 (example.com)
please explain.
With the [QSA] flag, a request for /pages/123?one=two will be mapped to /page.php?page=123&one=two. Without the [QSA] flag, that same request will be mapped to /page.php?page=123 - that is, the existing query string will be discarded.
If the incoming one=two is tracking info, without QSA, it will be discarded.It will only be discarded if the target URL contains a query of its own, which by default replaces the former query. That includes targets with the null query, a final ? with nothing after it (equivalent to QSD flag, at a savings of three bytes, but really more about personal coding style). In the proposed RewriteRule that started this thread
RewriteRule ^(.*)$ foo/bar/$1 [QSA,L]
RewriteRule ^(.*)$ foo/bar/$1?one=two [QSA,L]
are you guys saying that [QSA] is only needed if I have hard-coded a query string in to the RewriteRule?
Please re-read your answer:With the [QSA] flag, a request for /pages/123?one=two will be mapped to /page.php?page=123&one=two. Without the [QSA] flag, that same request will be mapped to /page.php?page=123 - that is, the existing query string will be discarded.
If the incoming one=two is tracking info, without QSA, it will be discarded.
...RewriteRule ^(.*)$ foo/bar/$1 [QSA,L]RewriteRule ^(.*)$ ../ww2.example.com/foo/bar/$1 [QSA,L]
[edited by: not2easy at 10:04 pm (utc) on Sep 15, 2019]
