image hotlink redirect to page uri - one domain referer

[aeronautic]

Oh friends, I have Gg'd this issue mightily and tested many formulas without success before I come to you seeking help. Sigh.

I've had global image hotlink working on this Apache server before - both the simple 403 result and redirect to a "please don't hotlink" substitute image... I've studied that code and as I mentioned, tested and researched this but I can't get it to work.

There is a domain that has hotlinked to a specific image. I want those referred by that domain to be taken to a page uri instead of the full size image.

Here is what I've been trying in various tweaks, etc.

RewriteCond %{HTTP_REFERER} ^http://(.+\.)?THATPESKYDOMAIN\.com/ [NC,OR]
RewriteRule ^path/path/path/imagefilename\.jpg$ http://mydomain.com/?attachment_id=12345 [NC]

From what I can tell to start with I'm not even getting the referrer domain "catch."

Also tried this for the first line:

RewriteCond %{HTTP_REFERER} THATPESKYDOMAIN\.com [NC]

The source of the link is deep on THATPESKYDOMAIN. In other words, it is THATPESKYDOMAIN.com/path/path/path/ (in case that is part of my problem).

Any help would be appreciated!

Thanks!

[phranque]

I can't get it to work.

is this a technical description of the response?
=8)

I want those referred by that domain to be taken to a page uri instead of the full size image.

does the resource returned by the page uri match any of the acceptable content types specified in the Accept: header?

RewriteRule ^path/path/path/imagefilename\.jpg$ http://mydomain.com/?attachment_id=12345 [NC]

did you intend an internal rewrite here or a 302 status code?

[lucy24]

does the resource returned by the page uri match any of the acceptable content types specified in the Accept: header?

Ah-ha! That's why the anti-hotlinking file of my dreams wouldn't work. I once found this great wav of a police siren, and wanted to rewrite all hotlinkers to that, but it wouldn't work. (Where "wouldn't work" means I tried it and the file didn't come through.) I guess the "Accept:" header is the grownup way of saying "I asked for an image, so don't try to fob me off with a sound."

Or, in this case, a page.

[NC,OR]

I really hope that was just an artifact of posting, because an [OR] in this position would lead only to a
:: quick detour to test site to refresh memory ::
Oh. Just a silent failure. I'd have expected something more 500-ish.

Incidentally, you really don't need an [NC] unless you know for a fact that this specific domain doesn't have a domain-name-canonicalization redirect. It's worth checking ("www.ThAtPesKYdomain.com" etcetera), because an [NC] is more work for your server.

Edit: But wait! Isn't there some kind of loophole? I once knew someone who ran her own little server out of her garage, and dealt with hotlinkers by showing the content of a random group of horrible extreme-lunatic-fringe sites. (The kind that will never protest because they're happy to get any kind of traffic, invited or not.) It got rid of hotlinks even faster than a garish NO HOTLINKS image.

[aeronautic]

Thanks for the responses.

The goal is to have requests for the direct http://example.com/path/file.jpg move the visitor to http://example.com/?attachment_id=12345 [This is a Wordpress media attachment Page URI]

did you intend an internal rewrite here or a 302 status code?

All of this on my own, same, domain. If it is an internal rewrite or a 302 status redirect depends mostly on what I can get to work reasonably. And candidly, I'd welcome your guidance and education.

By not working I mean literally I can't even seem to get it to catch the requests based on the referrer, let alone take the next step to move the request to the desired resource.

does the resource returned by the page uri match any of the acceptable content types specified in the Accept: header?

I don't know for certain but as mentioned above it is a Wordpress media attachment standard uri which ought to present an HTML header I suspect.

Lucy: The [NC,OR] code was taken from sample code tried after my efforts to tweak my blanket anti-hotlink code failed.

I'm not a complete idiot when it comes to this stuff but please take note of the term "complete." ;)

Again, your help is very much appreciated.

[aeronautic]

Did I say something impolite?

[lucy24]

On the contrary, you said "thank you", implying that you were now ready to handle it yourself ;)

The underlying question is: does your anti-hotlink routine involve serving up a page instead of an image, and if so, do you have reason to believe it is possible to do this?

[aeronautic]

Oh Lucy, I'm getting the sense that "we're going to need a bigger boat." Yes, my goal is to swap an image request out for a page. A redirect (or some cousin thereof) can not be file-type agnostic? Are ya saying image for image, page for page?

I've no reason to believe it possible. Just hope! ;)

[phranque]

A redirect (or some cousin thereof) can not be file-type agnostic? Are ya saying image for image, page for page?

there is reason the User Agent (browser) specifies the acceptable content type(s) in the Accept: header.
the browser is designed to render an image tag using an image-type resource.

[aeronautic]

there is reason the User Agent (browser) specifies the acceptable content type(s) in the Accept: header.
the browser is designed to render an image tag using an image-type resource.

Well that explains why I never got close. Or perhaps in part at least.

Any suggestions about some method that will accomplish my goals?

Take a click to an image that is hotlinked, and based on where the click came from (referrer), send the visitor to an actual page?

Adding to the complexity is I don't want to take any and all visitors from that site, just those trying to go directly to this specific image file.

Again, I do appreciate your help and suggestions.

[lucy24]

Well, that was educational.

Before answering, I took some time to pore over my own header logs in conjunction with access logs. Since I don't normally log headers for non-page requests-- in fact I have no idea how to do it-- headers are only logged for blocked requests, where they are provided by the 403 page that the server always sends out. But since I was looking particularly for hotlinked images, this is not a problem.

Before investigating, I had assumed that when a browser requests an image (that is, something found within "img" tags) it includes an Accept: header along the lines of

Accept: image/gif, image/jpeg, image/*

This turned out not to be the case. Although the various image types are listed first in the "Accept:" header, there's always a */* fallback. (Weird corollary discovery: "image/gif" and "image/jpg" are standard; "image/png" is much less common. They don't seem to have anything to do with the actual extension of the requested file. I'm pretty sure I have way more pngs than gifs.)

:: detour to find out what "image/webp" is, resulting in Dog Bites Man discovery that it's something Google is pushing, currently recognized only by Chrome and Opera (including, interestingly, the pre-webkit Opera 12) ::

Otherwise I guess the browser would get confused by things like piwik's noscript option, which involves

img src = "http://www.example.com/piwik/piwik.php?idsite=3&rec=1"

(I've never figured out what the "rec=1" part means, since the parameter is always present and never has any other value.) But requesting the file is one thing; acting on it is another. The browser will accept anything you send, but it will only display the file if it comes through in some kind of image format. The response can't override the whole containing page-- no competent browser would allow this-- so at most the hotlinking page might show the content of the new URL in a box the size of the image. Or some default size, if the hotlinker didn't say. (I have actually seen this, as noted elsewhere, but I do not know how it's done. Maybe it involves a command that can only be used in the config file.)

Did you ever explain what your underlying purpose is? It would be trivial to make up a customized NO HOTLINKS image and send it out only to hotlinkers with a particular referer. That's done as a rewrite, not as a redirect, because generally you don't want the browser to know that the file they've received isn't the droid they're looking for. If, on the other hand, you're looking for a response that would redirect the entire page to some new location, that's impossible.

[aeronautic]

Lucy thanks so much for your diligent and kind help. I believe I mentioned I do have a working version of the rewrite from the hotlinked image (any hotlinked image) to a nohotlinkingmyimages.jpg (ya get my point) image. In this thread I sought a more subtle, custom solution that would take the visitor to a page on my site - from where they might spend more time enjoying other content, instead of just looking at the hotlinked pic.

Re: webp - I too have seen this - and without research - my guess is it is intended to be a format that offers some level of improved efficiency over PNG, JPG and GIF.

The rewrite from jpg to page URI is also impossible? (Vs redirect?)