cags

It's simple logic from here, you have all the tools required, you just need to make them make sense. In simple English terms, your rules say Rule 1 : if a request is made to mysite.com, forward the request to the same location on www.mysite.com, regardless of the page requested. Rule 2 : If a request is made from any subdomain of mysite.com forward the request to the same location on mysite.com. It's important to understand that the L flag only stops parsing of the rules on this request to the server. Both rewrite rules cause a redirect, which in essence tells the clients browser to request a different page (thus making it a different request). Your objective seems to be to make any request that's not for the www subdomain, point at the www subdomain. This being the case I'm not sure why you are playing around with two different rules, in English this is a simple singular statement. Redirect all requests that are not for www.mysite.com to the same URI on the www.mysite.com domain. The information should be clear from what you already have. If you have a go, I may provide the solution (or somebody less interested in helping people actually learn something may provide it in the mean time).

Your first rule redirects mysite.com to www.mysite.com, your second rule redirect www.mysite.com to mysite.com, your first rule redirects mysite.com to www.mysite.com etc.

Is the object to redirect requests for Sitename-home to Sitename-homepage before proceeding with the other rewrite rules? If so make sure you place the rule I suggested first and give it the L flag.

In honesty it's been quite awhile since I've used a .htaccess folder in any directory other than the document root, so I couldn't say for sure, it's almost certainly a redirect loop that's occuring, you justt need to play around with the values and see what happens. You can turn on RewriteLog, this should give you an indication of what's occurring.

RewriteRule ^/?Sitename-home/?$ /Sitename-homepage [R=301]

You could try using mod_rewrite (RewriteRule) rather than mod_alias (Redirect).

When our server load got silly high (and took the servers offline due to so much traffic basically ddos'ing the servers) it was down to Apache. We were under a lot of load in terms of hits and it was memory bound spawning Apache processes. This was down to the fact that an instance was being spawned for every resource on the page i.e. images, css, js (it was a Magento install so there were plenty). I would imagine you could drop the load significantly by either using something like Varnish to cache the assets, or by proxying the assets with lighttpd, or other lightweight server (both solutions essentially do the same thing and stop Apache processes being spawned so often).

What are you expecting the &query part to contain? The simple answer is that with the trailing slash of your URI the second capture group has something to capture (the /), without it it doesn't match anything, meaning your pattern doesn't match so the RewriteRule won't get applied. Something like this would probably be more approriate, as the second capture group doesn't have a required width and will not contain the trailing slash. Alternatively you could write one RewriteRule for 1 'directory' deep and another for 2. RewriteRule ^([A-Za-z0-9-]+-test-page)/?([A-Za-z0-9-]*)$ file.php?city=$1&query=$2 [L]

Trying adding a question mark to the end of the target location.

Juist to offer some alternatives (assuming your are using mod_php)... The mod_rewrite modules is not enabled. You can test if that's the problem by removing the Rewrite stuff and leaving in the php settings (obviously you can do vice versa to test PFMaBiSmAd's theory). Perhaps index.php isn't matching a file which is causing an infinite loop. Depending on your folder structure this could be down to your RewriteBase. You could easily test that by changing index.php to http://www.google.com/ and seeing if you end up on google or still get the error.

Sounds like you no longer have Options +MultiViews, with this option enabled a request for /foo will search for /foo.* and returns the one it believes to be the best fit. If you haven't changed this in your .htaccess file, then it's perhaps been changed at the VirtualHost level by your host.

Stopping stream.php from redirecting on http should be as simple as... RewriteRule ^/stream.php$ - [L] I don't see a reason to check the port, because if they are on port 443 they will end up in the other vhost, but I guess you could keep that in if you really wanted to. Not entirely sure what you mean by DOES take parameters, but I assume you mean only redirect if there's a query string? RewriteCond %{QUERY_STRING} ! ^$ RewriteRule ^/stream.php$ https://%{SERVER_NAME}%{REQUEST_URI} [L,QSA,R=302]

The way I understand it they don't want to have to log-in on every file access, merely that if a user attempts to access a file without being logged in, upon achieving that log-in they should be redirected to the page they originally requested, not the default 'logged in' page you might arrive at by going directly to a login page.

Having .htaccess files disabled on the server can improve performance, however the chances are you don't have control of that. Will there be a performance hit by using one? Possibly. Will you notice it? No.

RewriteEngine on RewriteCond %{HTTP_REFERER} !^http://(www\.)?mysite\.com [NC] RewriteRule ^(.*)$ http://mysite.com/login.php?original_request=$1 [R,L]

If you are validating the 'title' part of the URL, then you might as well simply switch to using the slug to select from the database rather than the ID and drop the ID from the address altogether. The only reason to leave the id in there would be to allow multiple articles to have the same title, but this wouldn't be the best idea as it will be confusing/misleading for the end user. This is all academic of course, as thorpe says, it's down to the script logic, not mod_rewrite. If you really need to do it then you would (in your script) simply load the blog post, compare the title to that of the blog, and issue a 404 redirect with php.

You could also use a RewriteMap, and add the routes to the map when you create new categories. As a rule though, I'd agree with thorpe and say just change the db query to search by slug rather than id.

It sounds like you are expecting the links on your site to change, mod_rewrite won't do this for you. All it allows is for requests for one URI, to be mapped to a different URI based on a pattern / set of rules.

No real difference to joe92's pattern, just a slightly different take of... preg_replace('/£\d+(?:\.\d{2})/', "<tag>\0</tag>", $title); I think it should work, though I did just get up, so it's not tested

worthless post by WebStyles. Coolness! worthless post by AyKay47, about a worthless post by WebStyles. Coolness!

infinite redirect

Define doesn't work... 404 error, blank page, 500 error, wrong page, computer explodes....?

What URL are you requesting, your rewrite looks correct assuming you type yourdomain.com/details/10 (or enquiries if your second post was supposed to indicate that was a typo in your first) in your browsers address bar you should get served yourdomain.com/details?id=10

To start with you have url and mid the wrong way round (which 2 seconds with the manual would have told you).

RewriteRule cond rewrite [flags] The cond part is regular expression which is matched against REQUEST_URI (well to be accurate the part of REQUEST_URI that is relative to the current directory). If it matches and the preceeding RewriteConds match then the request is rewritten to the rewrite part. So in your case you are finding requests that match anything (.*) then matching it against a pattern, you could just move that pattern to the cond part (minus the beginning forward slash if it's going in .htaccess file).