I need a bit of .htaccess help. I know this isn't MT specific, but Its used to redirect MT pages.

I have my .htaccess in my public HTML directory set with a bunch of spambot and browser redirects. The only other .htaccess I have is in the Gallery Directory and that redirects Gallery pointers to their specific albums. Works fine.

Problem is that when I access the redirects the browsers get sent into a loop. I can see the redirect flashing on the bottom and it seems to be going

Site --> redirect -- Redirected to site --> redirected to redirect-- > etc

Same thing happens for hotlink protection, et al.

Do I need to put .htaccess files somewhere else to stop this? (ie /user )
Create copies for the sub directories? what do I need to do?

Here is an example or the code:




I only have one RewriteEngine on as documentation suggests.

Basically the same thing happens regardless of section.

Help?

Is there a link to try with a specific browser to see this?

Doc,
I shouldn't touch the keyboard before my morning coffee(s).

Well, .htaccess is inherited by all subdirectories, so you would get an infinite loop.

Your .htaccess needs to be saying something like "when AvantBrowser arrives AND is not requesting avantgo/index.php, then send it there." That way when you redirect it there, it IS requesting it, and does not get redirected.

My POSIX syntax is way too rusty, but it might be something like this:
Replace:

with

I'll see if I can figure out the correct syntax if that doesn't work.

What exactly are you trying to accomplish?  

Right now the rule says that ANY url will be redirected to http://www.seadoc.net/sd/avantgo/index.php.  Assuming the .htaccess is on the seadoc.net server in the roo, sd, or sd/avango directory, the this includes the http://www.seadoc.net/sd/avantgo/index.php URL, too.

You probably want a rule that redirects URLs except for those that already point into sd/avantgo, right?

In that case, you'll need a rule like so:

I.e. redirect the URL unless it points into sd/avango.

I was using AvantBrowser as a test browser for the condition, but basically I am trying to get any Browser with the UA of POCKETPC or AvantGo to redirect to /sd/avantgo/index.php

I was only using the one redirect to test.

I am really unfamiliar with htaccess syntax and the documentation is not very helpful..

I thought that !^ meant that any URL BEGINNING with sd/ would be redirected.  At least thats what I gathered from Webmaster World.

what exactly does ^ do?

Thanks for the help.

Look up POSIX Regular Expressions really understand the syntax.

But ! is the negation character, and ^ means "starts with"

So, !^ means "not starting with" and serves to only redirect those hits that are not already going where you want. You can rewrite the rule for each user_agent.

If that makes sense, or else, post your .htaccess as completely as security allows, and maybe we can help with it ...

Thanks, I got the browser redirect working fabulously.  Thanks for the help on that.

For anyone with PDA pages, this code will redirect Pocket Internet Explorer and AvantGo to your PDA page automatically.  I am sure it can be made useful for all types of browsers.



Now can you htaccess gurus explain why the same looping occurs with my hotlink file?  I have scanned many a website and my code looks exactly like other hotlink code.  I think I have the same problem in that I don't have .htaccess in the /siteimages directory.  If I used the same !^ code could that correct it?

Hmmm ... well, I'm hemorrhaging intelligence as my workday wears on (you can tell I'm working, right?) ... but, does this work any better:


And, I was wondering about that thief.jpg I was sometimes seeing ... it was beginning to impact my self-esteem in a most negative fashion  ;)

LOL, the thief.jpg is only supposed to be for hotlinkers.  When I first moved to Blogomania, I discovered there were a lot of people on systems like Blogger that were hotlinking files and stealing my bandwidth.
I even had to turn off direct URLs to cut down on the stealing of images!

I think I tried that exact code before and it doesn't block the first image!

If I remove RewriteCond %{HTTP_REFERER} !^$
it blocks the images, but starts the loops again.
So frustrating.  Why can't .htaccess be structured simpler?

Okay, Doc, I am now rapidly lowering my IQ even further with a special Mexican nectar designed almost solely for that purpose, s'far as I can tell ... so, I am now utterly incapable of imagining why:

which means "the referrer cannot be blank" should have any influence on your links or that looping. I realize that you too are nonplussed by this. Maybe the user_agent redirects need another looking over ...

But, I do have one more idea, how's about changing the last line from:

to:


Also, you really shouldn't need the whole URL, (losing it just makes the .htaccess file more portable), but maybe it's best not to mess with what's working, pretty much, kinda.

Also:


A Unix guru (which I am not) would say:


The rest of us just need a reference book close at hand, and we rest secure in the knowledge that someone else has probably already written the code we need and posted it somewhere!

Okay, I feel myself rambling ...  

I don't know what it is, but its definitely the RewriteCond %{HTTP_REFERER} !^$ line causing the problem.

Its like if I put that line in there it turns off hotlink prtection and I don't understand why.  I did a lot of research and almost all the hotlink protection schemes use it, so it has to be something else causing the error.

Maybe I need to set a Rewrite Base or something.

I have Options +FollowSymlinks turned on, and RewriteBase /public_html/  turned off.  Its currently blocking images without the bolded line, but it refuses to serve my custom image regardless.  I am just so lost on this.

Could it be a config erroe with httpd.conf on my host?

Is there a way to do it without mod_rewrite, ie with Redirect, Allow, Deny lines in my htaccess??

I'm going bald with this.  All my other redirects work just fine!

Alright Doc, it's a new day, time to get this thing ironed out, though I'm guessing certain members of my household will see it differently on this beautiful New England Spring-like day.

If you like, you can email me as much of your actual .htaccess file as you can comfortably disclose, and I will look at it in its entirety. I think you know as much about it as I do, but maybe two heads are better than one.

Otherwise (or also), maybe we should walk through it. That suspect line says basically "if the referrer is not blank" meaning if it IS blank (like you typed in the URL), then images will be served normally.

So, if it IS NOT blank, if it does NOT come from seadoc.net NOR from www.seadoc.net, why THEN, it is evil-doers requesting my images and they must be served the thief.jpg. Yeah, so we already know this.

So, what exactly happens when you enable this line, and how exactly do you test the effects of your .htaccess file?

I don't see amy reason why we can't get this working properly (heh).

There is nothing super secret in my htacess file.  Basically a bunch of redirects.  My host handles security pretty well through httpd.conf and I haven't had a need to lock up directories with Auth yet.

I am testing the hotlink protection with a HTML file.
I created a simple HTML document pulling one hotlinked file and saved it to my HDD.  I open it in my browser of the moment (I run 3 concurrently, lol) and see if it loads.

Maybe I ought to go to my old blogger acount and attempt hotlinking, but at either rate I would think it would serve up the Hotlink Image instead of just the Red X.  I wonder if its not blocking the hotlink image as well as a regular images and thats why thats not being served up.

Anyway, here is all pertinent htaccess stuff related to that portion.  Like I said nothing secret.  All the deep paths are removed, thats all.  Besides I am planning on posting "cleaned" portions on my blog in the "hacks" category.  Hopefully someone else will find all this useful.

Thans for the help.

At least I am starting to be able to decipher regexps..

Here's a little test page on my server, that tries to take your upper left image, and one from your gallery ...

Oscar Seadoc Thief Test

One thought I have is, what about flow control?

Like, are the redirects to thief.jpg the LAST thing in the .htaccess file. In other words, the flow isn't falling through the redirects to the user_agent redirects, is it?

the hotlink prtection segment is the first thing in the stream of redirect segments, even before the spambot blocking.  The rowser redirect is last.

If you try to view said photo through a direct URL you can watch it loop around just like the browser redirects did.

I am wondering if its not going -->display thief.jpg --> thats a jpg -- block jpgs -- display Thief.jpg --> etc etc etc  

Maybe if I could exclude thief.jpg?

Ahhhhhhhhhhhhh ... good THINKING Doc!!!

Duh! I'm sure you're right.

Try this right before the redirect to thief.jpg line. What's wrong with us, since we did this same thing for the other re-directs!



So, we're saying, the referrer isn't requesting thief.jpg, so send it through the rules to where the DO get it, then since it is a .jpg, it will come around again, and this time they ARE requesting it (or you are FOR them) and so it DOESN'T block it.

I'm even going to say in advance "problem solved" (optimistic ain't I?)  ;)

didn't work, still having the same issue.  I thought it was solved too.

Well, it was fun while it lasted.

What happens if you transfer the block of code for the hotlink disabling to the end of your .htaccess file?

I realize this shouldn't have any effect, but if it works then it might mean it had been falling through to some error in the user_agent redirects, so at least you could localize the trouble.

Right this minute, accessing the photo by a direct URL gives me the thief.jpg, so that must mean you have the "blank referrer" line disabled. But, as you say, the upper left image on your page is thief.jpg too, even when I go to your site legitimately.

Well, I DO have a REAL KLUDGE of an idea ... I should be ashamed for thinking of it instead of solving the problem, but it miiiiiight work to tide you over.

First, we say the "blank referrer" line causes a loop for some (as yet) incomprehensible reason ... so we take it out of there ...

Well, then ... um ... er ... well, I guess that very first image on your page still doesn't think it's being called from seadoc.net so it thiefs out ... but then by the time the next ones load, they've figured out that seadoc.net is calling them ... so they work (I'm making this up as I go along ... anthropomorphic computer debugging ...).

So, what if JUST FOR NOW, you threw in a dummy 1 pixel jpg as the very first image, and set it not to display (since it would be redirected to thief.jpg). Would that at least take care of legit referrers?

Hmm, I even hate that, and it's my idea ...

Just a little more thinking aloud ... on second thought, that hasn't helped ...

How about this, you just cut out all of your user_agent redirects and paste them somewhere for safekeeping, so that ONLY the hotlink disabling is in .htaccess (WITH the blank referrer line in there). That's just gotta work on its own, and if not, then we know something ...

Then, if it works, you start adding in the user_agent stuff a little at a time, before, after, wherever it works, and it should help tease out the problem ...

I see this as pressing on from sophisticated thought experiments to blind brute force trial and error, on the model of all those proverbial chimps and typewriters  :(

I will see what happens.  

Do you always see the thief.jpg when you load my regular site legitimatly, because I do not.  All my images load just fine on my browsers.  AvantBrowser, Mozilla, and IE 6.1.  This happens on a mac?  That may lead to some failing in of itself.. hmm..

None of the code I am using should cause that effect.

Seems fine on all my browsers, Mac and Windows, this morning?

I was getting the thief.jpg in the upper left last night, and I thought I'd cleared the caches and stuff. Who knows?

Guess the looping problem is the focus now.

I guess I'd rename my file .htaccess_old, and make a new one with just the hotlinking stuff, just to narrow the focus.

None of those suggestions worked.  I think its time I elevated the issue at my host.  I am blocking files alright, just not sending the hotlink image now.

Thanks for all the help.

Sounds good Doc - after all, you pay them to know what they're doing  ???

Do let us (or it's probably only me at this point in the thread) know what you learn - as you know, I don't sleep nights on account of things like this  ;)

Ok, I will.  Kep your eyes posted to the blog though.  I plan on posting whatever solves the issue there for all to see.  Might take a while though.