| 7:14 am on Oct 2, 2013 (gmt 0)|
|However, example.com/investors/index.php?page=22 is different from example.com/investors/index.php |
Yes it is. However, example.com/investors/index.php?page=22 should be the same as example.com/investors/?page=22 with both including ?page=22
^investors/(index\.php)?$ (2 places)
!^www\.example\.com\.au [NC] =>
| 3:23 am on Oct 21, 2013 (gmt 0)|
Apologies for resurrecting this thread.
These Redirect rules work well when I run them on my local development server.
However, when I run them on the production server they give a 404 error instead of triggering the redirects.
It took me a while to figure out that it could be due to the "proxy" server (web server sitting between the client and the actual CMS app server).
Seems like the proxy module gets hold of the URL first pushes it off the server which promptly sends back the wrong response i.e. 404.
I need the rewrite to occur first, then the new URL submitted and passed through to the proxy.
Then again I may be wrong.
In this scenario, should the rewrite rules still work irrespective of the "proxy"?
| 5:32 am on Oct 21, 2013 (gmt 0)|
I forgot to add,
Does it matter if the target url is absolute or relative?
e.g. /aboutus/companyprofile/press? vs http://www.example.com.au/aboutus/companyprofile/press? [R=301,L]
Someone I spoke to suggested that if redirecting to the same domain, the target should be relative
If redirecting to a different domain, the target url should be absolute.
I gave this a go, however, this did not work either.
| 8:02 am on Oct 21, 2013 (gmt 0)|
If you're redirecting rather than simply rewriting, always use a full URL including protocol.
The form with leading slash isn't strictly speaking a relative URL either-- those are the ones with leading directoryname or, in html, leading ../../ and worse. But a leading slash means "reattach whatever you used before" so it doesn't do anything about domain-name canonicalization (and potentially even http vs https if your site goes both ways).
However this should have no effect on whether your redirects work or not. And since you're redirecting rather than rewriting, you can easily see in the address bar where the browser "thinks" it is. Does it say what you expected it to say? If no, there's a problem with the rule. If yes, the problem is elsewhere.
| 11:16 pm on Oct 21, 2013 (gmt 0)|
Seems like there is a problem with the rule.
The address bar displays the original url and not the target url.
I am flummoxed.
The rules are exactly what I shared above.
These work on my local machine running XAMPP
Add them to the test server (tomcat) and it doesn't work.
Another issue that I see is the the address bar displays subdomain.domain.com.au//
An extra trailing slash at the end.
| 5:53 am on Oct 22, 2013 (gmt 0)|
I added a leading slash in my rewrite rule e.g. a slash before policies
RewriteRule ^/policies/$ http://www.example.com/news? [R=301,L]
All the redirect rules work now.
Thank you very much :-)
| 5:20 pm on Oct 22, 2013 (gmt 0)|
Leading slash? In htaccess? In conjunction with the preceding post about a double slash, this sounds ominous-- as if something, somewhere is adding a slash after the domain-name slash.
| 10:37 pm on Oct 22, 2013 (gmt 0)|
Well I don't know what was going on.
However, once I added the slash after the caret symbol all the redirects worked. It also resolved the issue where an extra slash was being added after subdomain.domain.com.au/
Surprisingly the rules worked on my local XAMPP setup without the slash after the caret symbol.
My guess is that the forward proxy on our test server is set up in a way that it required this slash to match the pattern.
| This 38 message thread spans 2 pages: < < 38 ( 1  ) |