Cannot get .htaccess redirect working

I need to redirect many RSS feeds in .htaccess

[Meancode]

Hi,

Read these forums for a long time, but this is my first post. I am trying to get some redirects to work and they either do not work or just cause an error 500 because they are incorrectly formed.

I have a dedicated server which is running: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8b mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 PHP/5.2.6

Neither of these work:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule /dev/atom.xml http://feeds2.feedburner.com/myblog [R,L]

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteRule /dev/atom.xml http://feeds2.feedburner.com/myblog [R=301,L]

I find it odd that there are a ton of references online to redirecting any rss feed to FeedBurner, but none I can find that would work for redirecting specific files to specific Feedburner addresses.

What am I doing wrong? Thanks,

Ken

[edited by: jdMorgan at 6:26 pm (utc) on Feb. 2, 2009]
[edit reason] de-linked, obscured. [/edit]

[Meancode]

OK I might have just answered my own question:

RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
Redirect 301 /dev/atom.xml http://feeds2.feedburner.com/mylog

But will that allow the RewriteCond do its thing and allow FeedBurner?

[edited by: jdMorgan at 6:25 pm (utc) on Feb. 2, 2009]
[edit reason] de-linked, obscured. [/edit]

[Meancode]

That would be a no.

[g1smd]

Don't use Redirect. Use RewriteRule with [R=301,L].

RewriteRule, when used in .htacess cannot 'see' the leading slash on a URL path.

[jdMorgan]

RewriteCond is a mod_rewrite [httpd.apache.org] directive, while Redirect is a mod_alias [httpd.apache.org] directive. Therefore, RewriteCond has no effect on Redirect -- They are processed separately by the two Apache modules, and don't "talk to each other."

Strongly suggest you review the Apache documentation for any module you want to use; Code in .htaccess affects your server configuration, and even tiny errors can have far-reaching and potentially-disastrous effects.

Jim

[Meancode]

g1smd, so far nothing I have tried work. Even when I use the full URL of http://example.com/dev/atom.xml.

Can you suggest something that will work? Because I obviously don't know what I am doing.

Ken

[edited by: jdMorgan at 6:24 pm (utc) on Feb. 2, 2009]
[edit reason] example.com [/edit]

[g1smd]

RewriteRule, when used in .htacess cannot 'see' the leading slash on a URL path.

[jdMorgan]

Well, I hope you read the docs cited above. As stated several times in this thread, you must use RewriteRule not Redirect. You also need to exclude blank user-agents from being redirected:

RewriteEngine on
#
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteCond %{HTTP_USER_AGENT} .
[b]RewriteRule ^dev/atom\.xml$ http:[i][/i]//feeds2.feedburner.com/[i]myblog[/i] [R=301,L][/b]

Good luck,
Jim

[edited by: jdMorgan at 6:23 pm (utc) on Feb. 2, 2009]

[Meancode]

Yes that did it Jim. Thanks. Never seen the blank user agents line before. To be honest I looked at the documentation and understand only parts of it.

Ken

[jdMorgan]

Read each "word" or even character of each line of code above. As soon as you get to any word or character you don't completely understand, look it up in the docs. You now have a huge advantage: A working code example that solves a problem that you fully understand. That's a good way to work through the documentation, because you will have at least one foot on the ground at all times. :)

Jim

[Meancode]

Hi Jim,

I now have five redirects in my file and the last one does not work:

#
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteCond %{HTTP_USER_AGENT} .
RewriteRule ^sports/atom\.xml$ [feeds2.feedburner.com...] [R=301,L]

Others work, such as:

#
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteCond %{HTTP_USER_AGENT} .
RewriteRule ^food/atom\.xml$ [feeds2.feedburner.com...] [R=301,L]

I am going to need many redirects like this. Why are they not working now?

Thanks,

Ken

[g1smd]

Define "does not work".

What was the test URL? What was the referrer? What was the expected outcome? What actually happened? What do you see using Live HTTP Headers for Firefox?

[Meancode]

This is currently working:

<snip>

Those all redirect just fine, as I would expect.

If I add this:

#
RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteCond %{HTTP_USER_AGENT} .
RewriteRule ^sports/atom\.xml$ [feeds2.feedburner.com...] [R=301,L]

It does not redirect, it just goes to the feed at: http://example.com/sports/atom.xml. I expected it to go to [feeds2.feedburner.com...]

I have tried this in Safari and Firefox. I have never used this live headers plugin, have to restart.

When I click on my Dev Atom file I get: HTTP/1.x 301 Moved Permanently

When I click on my Sports Atom file, I actually get no new output in Live Headers. Not unless I click Refresh in the browser. At which point I am not given a 301 Moved Permanently.

Further, if I take out the Dev Atom redirect and instead put in the Sports Atom redirect, it does not redirect me to [feeds2.feedburner.com...] as I have indicated in the .htaccess file.

[edited by: jdMorgan at 7:59 pm (utc) on Feb. 9, 2009]
[edit reason] example.com [/edit]

[jdMorgan]

Did you completely flush your browser(s) caches before testing?

If the only differences in the URLs being tested and the RewriteRules being used to redirect them are the words "food" and "sports", etc. then there is no reason why one rule should work and another would not. So I'd suspect your browser is showing you stale cached responses.

Also, you may only need a single rule to do all of these redirects. Something like:

RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteCond %{HTTP_USER_AGENT} .
RewriteRule ^([a-z]+)/atom\.xml$ http://feeds2.feedburner.com/bgv/$1 [R=301,L] 

would take a request for a URL-path starting with <one-or-more-lowercase-letters> followed by "/atom.xml" and redirect to http://example.com/<the-one-or-more-lowercase-letters>/atom.xml

You can make the RewriteRule pattern more or less specific, for example, by using the pattern "([a-z0-9]+)" if you also want to accept numbers, or by using an explicit list of feed names such as "(food¦sports¦whatever)" if you want to be very specific.

Note that you must change any and all broken pipe "¦" characters to solid pipe characters before use; Posting on this forum modifies the pipe characters.

Jim

[edited by: jdMorgan at 8:02 pm (utc) on Feb. 9, 2009]

[Meancode]

I have cleared the cache and I have tried different computers. I also just tried it on a computer who has never accessed the site before, and still the feed did not redirect.

<snip>

If you click Subscribe to RSS Feed, it should take you to the Feedburner URL, as that is in the htaccess file.

I don't want to put everything at the root, and not everything there has a name match, but I can at least change that, and then have that one rule work for everything at the root.

I wondered about the broken pipes on the board.

Once I rename all the feeds I will give that rewrite a go.

Thanks,

Ken

[edited by: eelixduppy at 2:13 am (utc) on Feb. 11, 2009]
[edit reason] no URLs, please [/edit]

[Meancode]

I must be losing my marbles. the sports feed is not working, it is not redirecting, and it is not redirecting with the new rule that you just gave me to use.

RewriteEngine on

RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteCond %{HTTP_USER_AGENT} .
RewriteRule ^([a-z]+)/atom\.xml$ [feeds2.feedburner.com...] [R=301,L]

RewriteCond %{HTTP_USER_AGENT} !FeedBurner
RewriteCond %{HTTP_USER_AGENT} .
RewriteRule ^housing/forum/atom\.xml$ [feeds2.feedburner.com...] [R=301,L]

RewriteCond %{HTTP_HOST} ^example.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.example.com$
RewriteRule ^mt/?$ "http\:\/\/example\.com\/mt\/mt\.cgi" [R=301,L]

These work fine:
http://example.com/food/
http://example.com/dev/
http://example.com/housing/

This one does not:
http://example.com/sports/

I have deleted and republished the sports atom feed.

I changed the feedburner name for the housing feed, as it used to be ocss-community on feedburner, now it is housing, and it is working with the new redirect.

So, I do not know what is going on here. Does it redirect for you? Because on every single computer I have tried it on, it does not redirect.

Ken

[edited by: eelixduppy at 2:14 am (utc) on Feb. 11, 2009]
[edit reason] use example.com, please [/edit]

[Meancode]

I just created another blog at /pulse and the [a-z]+ redirect took care of it just fine.

/sports still does not work at all. I am now testing it on an entire different network of computers.

[g1smd]

In the final redirect you do not need to escape the slashes in the target URL:

That is \/\/ needs to be only // etc, but I am guessing that you actually need a rewrite here not a redirect (and you'll need a separate non-www to www redirect before that rewrite).

[jdMorgan]

Some other code somewhere in your server might be rewriting "sports", redirecting it, or aliasing it. There's also the possibility that it may have tripped a filter in your host's firewall, or in mod_security on your server.

Rather than driving yourself crazy, I'd suggest trying a few typo-feed-names (with temporary supporting rewriterules) like "sprots", "sport", and "sportz" just to discover if an exact match on the word "sports" is triggering something somewhere that is interfering, and then contact your host and inquire about the firewall settings, mod_security config, and "alias" directives in the server configuration.

By the way, just so I can feel useful, your "/mt" redirect can be better (more correctly and efficiently) coded as:

RewriteCond %{HTTP_HOST} ^(www\.)?example\.com
RewriteRule ^mt/?$ http://example.com/mt/mt.cgi [R=301,L] 

and if only example.com and www.example.com resolve to this server, then the RewriteCond won't be needed at all.

I'm also not sure why you'd want to expose that /cgi filepath as a URL, so I suspect an internal rewrite would be better. But that's a subject for later...

Jim

[Meancode]

Many thanks for the input. I will report back when I have time to fiddle with this.

As for the /mt rewrite, this is just convienence, I do not want to have to sell someone to go /mt/mt.cgi, as they would not remember that. /mt is much easier to remember. I have no idea of rewriting the .cgi would mess up MT itself.

Thanks,

Ken

[jdMorgan]

> I have no idea of rewriting the .cgi would mess up MT itself.

You should certainly try it. Using an internal rewrite would mean that the URL would be "/mt" and the filepath would be "/mt/mt.cgi", and the user would never see anything but "/mt" in the browser address bar.

Exposing the .cgi path looks ugly. It also tells the world what server-side technology you use, which is a small but non-negligible security risk, because it invites targeted attacks.

Jim