[cd34]

you are correct, your method is faster.

with 20 concurrent threads, 100k requests, no keepalives, .46 seconds faster and 3.4 tps faster.
oddly, at 20/10k/no keepalives, the margin tilts the opposite direction and is just as slim.

Although, I tested Apache2/mpm-prefork, not Apache1. When I benchmarked Apache1.3 last spring, there was a considerable difference edging towards having separate lines. However, with the config file in the virtual host rather than being read from .htaccess, and turning Override's off, it narrows down to .16 seconds faster and less than 1.1 tps faster. Granted this was just a seat-of-the-pants quick benchmark using ab, with all 5 tests run 5 times and the lowest score taken. Each used a referrer that required every rule to be evaluated.

So, current wisdom would suggest this:

Slightly corrected to remove two typos:

RewriteCond %{HTTP_REFERER} !^http://([a-z0-9]+\.)?yourdomain.com(/.*)?$ [NC]

this disallows RFC compliant hostnames that have a - in them, fixing the regexp to allow that makes it a bit more complex since the leading character cannot be a -, but, lets skip that for now and allow - anywhere in the hostname and allow for the port designation which some edge proxy servers like to insert. We might also consider allowing _ which was not in the original specs, but, Microsoft supported it, and it was later adopted. This rule also doesn't allow for the new International characters, but, if someone is using those, they can change the regexp.

RewriteCond %{HTTP_REFERER} !^http://([a-z0-9-]+\.)?yourdomain.com(:[0-9]+)?(/.*)?$ [NC]

This disallows subdomain.subdomain.yourdomain.com, which might be part of the + typo in the earlier post.

RewriteCond %{HTTP_REFERER} !^http://(([a-z0-9-]+\.)+)?yourdomain.com(:[0-9]+)?(/.*)?$ [NC]

So, Raymor, does the above rule seem sufficient for as many cases as possible?

Offhand, I can think of one really simple way to circumvent this -- Firefox pops a warning, but IE seems to have no problem with it.

I've run that rule against a regression test to make sure that it appears to behave exactly the way I would expect and intend it to work and short of the one possible regexp match which could be very easily implemented on fuskers side, it seems fairly complete.

Now, of course we're back to the age old problem of Google/Yahoo's hotlinking image search. By doing the rules this way, we are only allowing the listed domains to be able to hotlink. If the rule is sufficiently loose to allow google/yahoo, a slight url change on fusker's side will make all of this for naught.