Welcome to WebmasterWorld Guest from 54.145.173.147

Forum Moderators: Ocean10000 & incrediBILL & phranque

Message Too Old, No Replies

www / non.www re-write problem

   
10:34 pm on Aug 18, 2013 (gmt 0)

10+ Year Member



For a while now, I have been using the following to re-direct non-www to www:

RewriteCond %{HTTP_HOST} ^example\.net [NC]
RewriteRule (.*) http://www.example.net/$1 [R=301,L]

This seemed to be working fine....however:

By chance this evening, I typed in example.net/blog/ (without www). Rather than redirecting to www.example.net/blog, it went to www.example.net (back to the home page)

this only happens on the blog's index page (any blog posts seem to work fine.

Could any shed any light onto what I did wrong?
11:30 pm on Aug 18, 2013 (gmt 0)

WebmasterWorld Administrator phranque is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



one possibility is you have another mod_rewrite or mod_alias directive that is causing this redirect in this .htaccess file or in the server config file.
another possibility is that you have a .htaccess file in the /blog/ subdirectory causing this redirect.


RewriteCond %{HTTP_HOST} ^example\.net [NC]


in most cases, it is better to use something like this:
RewriteCond %{HTTP_HOST} !^(www\.example\.net)?$ [NC]


this properly handles requests from HTTP 1.0 compatible user agents which don't send a Host: header.
11:38 pm on Aug 18, 2013 (gmt 0)

10+ Year Member



Ah, yes! Turns out, in my .blog directory, I have:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
</IfModule>

# END WordPress

I just deleted this htaccess file but it stopped the blog working so put it back. What should I do next?

Appreciate all your help!
11:55 pm on Aug 18, 2013 (gmt 0)

10+ Year Member



Should I just change the above to:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
</IfModule>

# END WordPress

?
12:39 am on Aug 19, 2013 (gmt 0)

WebmasterWorld Senior Member lucy24 is a WebmasterWorld Top Contributor of All Time Top Contributors Of The Month



Here's the quirk to mod_rewrite. Unlike most things in Apache, it is not inherited by default. Instead, the product of any RewriteRule is put on hold by the server while it continues checking the rest of the path to the originally requested file. If it ever meets another htaccess file containing mod_rewrite, the results of any earlier rewriting are simply discarded, as if they had never existed.

You can enable inheriting within a specific htaccess file by adding the line

RewriteOptions inherit

... but you may not want to.

RewriteBase /blog/

The RewriteBase may be the biggest red herring in all of mod_rewrite. It is only applied when the target of a RewriteRule begins with something other than protocol-plus-domain or a directory slash-- in other words never, if you're constructing your rules carefully.

Should I just change the above to:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
</IfModule>

:: shudder ::

I hope that was a typo. You can't have a RewriteCond unless there's a following RewriteRule.

The simplest and safest approach is to take the rules for your blog and shift them to the appropriate part of the main htaccess, replacing
RewriteRule (.*)
with
RewriteRule ^(blog/.*)
so the rules only kick in if the request was for something in the /blog/ directory. (That's assuming /blog/ remains part of the WordPress URL, even if everything else changes.)

And get rid of the <IfModule> envelope. Not its contents, just the envelope itself. This is part of the boilerplate for prepackaged htaccess files-- but if you haven't got mod_rewrite, you wouldn't be here in the first place.
4:37 am on Aug 19, 2013 (gmt 0)

WebmasterWorld Administrator phranque is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



i would first verify the response status chain and see if your results came from a single redirect or multiple hops.
the Live HTTP Headers add-on for Firefox is helpful for this if you don't have another suitable tool handy.
5:20 am on Aug 19, 2013 (gmt 0)

WebmasterWorld Administrator 5+ Year Member Top Contributors Of The Month



If you have a second Rewrite in your top level htaccess that starts something like:
RewriteCond %{THE_REQUEST} to hand canonical index.htm|html|php requests and it comes after the one posted above in the OP it can cause that problem too. IF that is the case, change the order and it should resolve correctly.
9:38 am on Aug 19, 2013 (gmt 0)

WebmasterWorld Senior Member g1smd is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



Modify the code found in the /blog/.htaccess file and move that code into the root .htaccess file.

The new code woill look something like this (I have deleted the bits that are no longer required)

RewriteRule ^blog/index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule blog/ /blog/index.php [L]


This code will likely go near the end of the root htaccess file.

Make sure you also convert any rules using Redirect or RedirectMatch to instead use RewriteRule with the [R=301,L] flags.
10:35 am on Aug 19, 2013 (gmt 0)

10+ Year Member



@g1smd, thanks that - works perfectly! I transfered that to the main htaccess in the site's root directly and deleted the /blog/ htaccess file completely.

Thanks, too to everyone else who helped me with this!

I don't know how long my htaccess file has been wrong but I wonder if this error would have caused any issues with Google SERPS?
11:08 pm on Aug 19, 2013 (gmt 0)

WebmasterWorld Senior Member g1smd is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month



If an internally rewritten path is exposed back out on to the web as a new URL by an errant redirect, that usually causes an absolute disaster with the SERPs. That's unlikely to be the case here.