An HTTP server is a web site.
So something that connects to a web site is an HTTP client.
When a client connects to a server, it sends an HTTP request.
The server should respond with an HTTP response.
Web browsers are clients, so are search engine robots, comment spammers, copyright infringement spybots, RSS aggregators, CDDB-enabled applications, the 'wget' program, and of course programming languages allow programmers to develop clients of their own.
The 'wget' program is a client that can be run from a shell user or CGI script. The LWP::UserAgent is a Perl library that can be used to make clients in Perl.
http://web-sniffer.net/ is a web site that acts like a client: You specify a URI to request, and it will show you the response.
When a client sends its request, it has the option of letting the server know the URI from which the URI that generated the request was obtained. In otherwords, "Hi Bob, Larry told me I could get this page from you." or "Hi Bob you gave me this page but I need the image that goes along with it."
So what happens if a person types in a URI into their browser, or has it set as a bookmark? There is no referrer. Also, a client can obviously be developed with the intent not to send referrers, or allow the user to configure it to not send a referrer, or to even fake the referrer.
So the hotlink prevention code depends on this referrer, which might not be there, or might be faked.
Anyways, when troubleshooting hotlink prevention, you will have trouble if you use a browser. Browsers have two types of cache: memory and disk. So what happens if you go to a web page that is allowed to link to images? The images load, and they are stored in memory or disk cache if possible. If you then go to a page that is not allowed, or perhaps the first page is no longer allowed to link to the images, you got a problem. The browser might pull the images from its cache and never bother actually asking for them a second time. This means even if the hotlink prevention code is correct, and the browser is sending the referrer, it is still possible for a "blocked" page to show the images. The reverse may also happen: An "allowed" page might not show the images if previously a "blocked" page was viewed.
So the proper way to troubleshoot whether or not the hotlink prevention code is working is to use a different client, where you can be sure the responses aren't being cached and you can specify any referrer you want. Think of it as being thorough.
For example, if the DreamHost web panel spits out .htaccess file like so:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www.)?example.com/?.*$ [NC]
RewriteRule .(gif|jpg|jpeg|png|mp3|mpg|avi|mov|swf)$ - [F]
Edit: This means "forbid access to urls that end in these extensions if the referer is not blank and the referrer is not example.com or www.example.com"
and you have a GIF file in the same directory as the .htaccess,
Then log into shell, and run the following commands:
1. wget --header='Referer: http://example.com/' http://example.com/filename.gif
2. wget --header='Referer: http://www.example.com/' http://example.com/filename.gif
3. wget --header='Referer: http://not.example.com/' http://example.com/filename.gif
4. wget --header='Referer: http://www.dreamhost.com/' http://example.com/filename.gif
5. wget http://example.com/filename.gif ((no referer is sent))
1. This should show '200 OK', since example.com does not match last regexp
2. This should show '200 OK', since www.example.com does not match last regexp
3. This should show '403 Forbidden', since not.example.com matches both regexp
4. This should show '403 Forbidden', since www.dreamhost.com matches both regexp
5. This should show '200 OK', since ((no referer)) does not match first regexp
And for those who post to the forum asking for help. We're not psychic. Please post the URI to an image in addition to the contents of the .htaccess file so that the gurus can help.
Perl / MySQL / HTML CSSEdited by Atropos7 on 03/06/05 10:41 PM (server time).