Hotlinking Problem

[SynHolliday]

My Myspace profile: [myspace.com...]

Under "About Me," you will see a picture (my wife and I). Underneath that picture, there is an image placeholder box where the same image should show, since it is linked to the same picture file but through path forwarding via another domain I own (through a different domain registrar company).

The first image file is linked directly to my hosting provider account (my domain subspecies.com hosted through Web.com).
The second picture (which does not display) is linked via path fowarding (my domain lxavision.com through Domainstrar).
Both point to the same jpg file.

The weird thing is if you right-click on the image placeholder for the second picture, go to "Properties," and copy/paste the image url directly into the browser address bar, the image shows. Just on the MySpace page it doesn't show.

Domainstrar support says the problem is hotlinking protection by my hosting provider (Web.com using RedHat Linux Apache 2).

Web.com says hotlinking protection is not enabled by default. Unless I'm missing something, this seems to make sense since the image does show up when directly linking to the image file on my hosting provider (Web.com) server. If Web.com had hotlinking protection enabled, the first picture would not show up, right?

I brought this up to Domainstrar, the domain registrar providing my second domain registration (lxavision.com) and path fowarding service. They said the problem could not be related to Domainstrar since hotlinking is strictly a hosting provider issue, and Domainstrar is only providing me domain registration and path forwarding which have nothing to do with hotlinking.

Which one is the cause of the problem? Or could this be a MySpace issue?

Additional information:
1st picture url: [subspecies.com...]
2nd picture url: [lxavision.com...]

Lxavision.com is registered with Domainstrar and it is set to point to subspecies.com/lxavision on my Web.com hosting server. Path forwarding is enabled, and so the two urls are both pointing to the same file.

Thanks!
~Syn~

[jdMorgan]

This looks like a "forwarding" failure.

The first request/response transaction, as shown by the Live HTTP Headers add-on for Firefox looks like this (some irrelevant headers edited out) :

http://subspecies.com/lxavision/gallery/myspace/syn&shay01.jpg

GET /lxavision/gallery/myspace/syn&shay01.jpg HTTP/1.1
Host: subspecies.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Referer: http://www.myspace.com/549912728

HTTP/1.1 200 OK
Date: Sat, 11 Sep 2010 13:57:16 GMT
Server: Apache/2.2.3 (Red Hat)
Last-Modified: Thu, 26 Aug 2010 06:04:24 GMT
Etag: "4ea6da0-8262-c51aca00"
Accept-Ranges: bytes
Content-Length: 33378
Keep-Alive: timeout=30
Connection: Keep-Alive
Content-Type: image/jpeg

But the second request looks like this:

http://lxavision.com/gallery/myspace/syn&shay01.jpg

GET /gallery/myspace/syn&shay01.jpg HTTP/1.1
Host: lxavision.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Referer: http://www.myspace.com/549912728

HTTP/1.1 200 OK
Server: nginx/0.7.61
Date: Sat, 11 Sep 2010 13:57:17 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
X-Powered-By: PHP/5.3.0
Content-Length: 2030

Note that the second response is from an nginx server, that the Content-Length is 2030 bytes instead of 33378 bytes, and that the Content-Type is text/html. This latter implies, but does not specifically indicate, that this may be some kind of HTML error page.

That's all I can tell you from here, but the request is not being "forwarded" (an extremely ill-defined term) to your Apache server, and instead is being handled by an nginx server, which I presume to belong to your registrar.

If you don't have Live HTTP Headers or a similar server headers checker installed, I suggest that you get one. This is an important part of the basic Webmaster's toolkit.

In this case, it provides irrefutable evidence that the "forwarding" is failing, although it cannot indicate why.

However, since the DNS system does not have any knowledge of anything but the requested domain, there is no reason it should "care" about the requested object type (image/jpeg) or the referrer. That info is not used at the DNS level, so I rule out DNS problems here.

It could be a refusal of the "forwarder" to accept the request due to something as simple as the "illegal" ampersand in the URL (which is required to be encoded as %26 if used in the URL-path part of a linked URL), or it could be something more complicated.

You could modify the second image link to use that encoded character (i.e. syn%26shay01.jpg), or you could change the URL and image filename to an "HTTP-legal" name like "syn-and-shay01.jpg". If neither of these helps, then a call back to your "forwarding service" with the Live HTTP Headers report in hand would seem to be in order. The possible failure mechanisms depend on the method used for forwarding, whether by request-redirection, content-framing, or reverse-proxy. But the "forwarding" is demonstrably not working properly.

You should also check your own server access log and server error log files to verify this. If the *request* phase of the "forwarding" is not working, then you won't see the request for the second image in your server access log, and no entry will be present in your server error log either.

If the request is being successfully forwarded using a proxy method but is being rejected, then you may see entries indicating this in both your server access log and your server error log. This would imply that something about how their proxy implementation handles error responses coming back from a "forwarded-to" server is broken, since the response from the ngix server is quite-visibly a 200-OK in the LHTTPH report above.

Jim

[SynHolliday]

Thank you for the reply Jim! Out of five support forum sites I've posted on this issue, you're the only one who has responded.

Well, I ruled out the ampersand issue. On my MySpace page, right underneath the previous example, I put two more image links, this time using a file without any special character in the name.

I will investigate the other possibilities you mentioned and return.

Thanks!
~Syn~

[SynHolliday]

I checked the transfer logs and the error logs. As expected, the image requests direct to the server show up in the transfer logs. However, I see no indication that there were any other requests for the jpg file in either the transfer or error logs. Would the entry in the log from the path fowarding request actually mention the jpg filename? I searched the log text by the image filename (the log files are quite large).

I will email Domainstrar with the information you provided. I'll let you know what they say.

[SynHolliday]

Here is their reply:

"Domainstrar is a domain registrar, not a hosting provider (unless you order hosting from it). It ONLY points your domain to a hosting server or a URL to a hosting server. In another words, a domain registrar doesn't host any file, let alone a web server such as nginx."

[SynHolliday]

Domainstrar is insisting it is a hotlinking issue, even though I can hotlink image files directly to my server:

Response from Domainstrar:
"URL forwarding is a type of hotlinking. Your example actually proved that hotlinking is enabled. Every time you don't use the word "directly" the image doesn't work, then it is a hot linking issue. Also, you have just as much control over your domain as we do."

On Mon, Sep 13, 2010 at 4:42 PM, Syn Holliday wrote:
Thanks Wei. Are we sure that hotlinking is the issue? My hosting provider said they do not have hotlinking protection enabled, plus I gave two examples that showed hotlinking does work when pointed directly to an image file on my hosting provider server. It just doesn't work when using the path forwarding URL through Domainstrar.

[SynHolliday]

I was able to get it to work via a different method. I just couldn't get it to work through Domainstrar's domain and path forwarding service so I turned them off. I ended up just creating an A record with Domainstrar that pointed the domain to my Web.com server and used Web.com's control panel to direct the domain to the subdirectory. Seems to be working fine.

Thanks for your help!

[jdMorgan]

The key question here was, where was this nginx server, and who did it belong to?

Since the response came from that server, it was definitely part of the problem.

Whether blocked by anti-hotlinking code or not, all requests that actually arrive at your server will be logged in the server access log file. If blocked by anti-hotlinking code, you'll see a 403-Forbidden response code in the log. And if not blocked, then a 200-OK, a 206-Partial-Content, or a 304-Not Modified response code.

While testing anti-hotlinking,you do have to be acreful to delete your browser cache between different test cases. Otherwise, the image will be served from your own browser's cache, and no request will be sent to any server. However, that was quite evidently not the problem here.

I doubt that your registrar was "lying" to you, but I do suspect that they did not understand your problem or their own implementation of domain forwarding, since "removing them from the HTTP request path" fixed the problem.

Perhaps that "forwarding function" was hacked, or was intentionally "piped" through some server that collects statistics for some purpose... likely for on-line marketing purposes.

Jim

[SynHolliday]

Yes, that was my guess, that maybe they did not understand my problem.