Take the 2-minute tour ×
Webmasters Stack Exchange is a question and answer site for pro webmasters. It's 100% free, no registration required.

For example, if I embed this random image in a forum, it will show up normally:

[IMG]http://i48.tinypic.com/350m3ut.jpg[/IMG]

If I try to view the image in a new tab, it will redirect me to the main page:

http://tinypic.com/view.php?pic=350m3ut&s=6

If I copy the image location there, it is:

http://oi48.tinypic.com/350m3ut.jpg

The difference is in the sub-domain, the "direct" embed link is "i48", the actual direct link is "oi48" - this is true for all tinypic uploads (though, the server numbers might be different: i38 vs. oi37 for example).

If I embed the "oi48" image, trying to view it in a new tab will work without redirecting to the main page.

So how do they do that?

And if I try to access the direct "oi48" link by typing/pasting it in the address bar, without first loading it in a forum post (for example), thus not having it in my cache, it will still redirect to the main tinypic.com page just like the "i48" link.

How? Why?

I also think funnyjunk.com used to add hotlink protection to the mix: a hotlink image ("Please go to funnyjunk to view this image") would show, and when you opened the image in a new tab, it'd redirect you to the image's page (for example, funnyjunk.com/funny_pictures/589823/Place/), but I'm not so sure if that's really what it did (they allow hotlinking now). Though, I guess if that would be possible, everyone would be using that method...

Would it be possible to implement a hotlink protection and a redirect to the image's main page? If so, how?

share|improve this question

1 Answer 1

This is done using the Accept HTTP header.

If you enter the URL http://oi48.tinypic.com/350m3ut.jpg in your address-bar the browser doesn't know yet what Content-type that URL returns (except that URL is already in the browser cache, I go into that a bit later). The browser then sends the "default" Accept header, which looks like this if you're using Firefox:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

The tinypic.com-Server then evaluates the Accept header and notices that your browser is preferring a text/html type. So it knows which image you like and that you want a HTML document, in that case it redirects you to the "main page".

Now if you use that same URL in an <img>-tag (again assuming the URL is not cached yet), the browser assumes that the URL resolves to a image-resource. Firefox sends the following headers:

Accept: image/png,image/*;q=0.8,*/*;q=0.5

You can see that image/* are preferred to any other content-types (and Firefox obviously likes PNG files). Obviously in that case the image-file is returned instead of the redirect.

The point here is that the browser does not look at the URL to "guess" what content-type to expect. It just uses some default preferences depending on which use case (entering the URL in the address-bar, referencing the URL in an <img>-tag) is, well, used.

Of course some browsers may behave differently, and I'm sure tinypic.com also uses the User-Agent-header to decide whether or not to use the Accept-header - probably to not break the <img>-tag for any old or weird browser (I've noticed in my test with cURL, that tinypic.com does not use the Accept-header with the default cURL User-Agent-header).

Now about the cache: if the URL is in the cache, the browser does not need to hit the server to know what the response is going to look like (in the case of tinypic.com it's a JPEG-file), so in this case the server can't do a redirect, and the browser just display the image as usual.

I guess the important thing here is to prevent that, instead of the actual image, the redirect to the "main-page" is cached - because otherwise the browser would be doing a redirect even if the resource is referenced inside an <img>-tag (I'm not sure tough, so this could be wrong).

The hotlink protection of funnyjunk.com is probably implemented using the Referer-header (I could not reproduce it, but I can't imagine how to solve "hotlink protection" without the referer-header).

share|improve this answer
    
Thank you for the answer! "so in this case the server can't do a redirect, and the browser just display the image as usual." But this is not true, for tinypic.com, the i## subdomains will always redirect, even if the image is cached. oi## won't, though. Why? –  f3tus Sep 22 '13 at 13:22
    
@f3tus: Because the i*-Domain redirects to the main-page whose <img>-tag references the oi*-domain. As a result, the i*-image-URL is not stored in the cache. You can solve this by creating a local HTML file with the content <img src="http://i48.tinypic.com/350m3ut.jpg" />. Open that HTML-file with your browser and then open the i*-URL. This should work, because the HTML-file references the i*-URL as image, which is then stored in the cache. –  vstm Sep 22 '13 at 14:40
    
This is exactly what I tried before and it redirected... I just tried again, and now it didn't. I guess it didn't save in the cache before for some reason. Thanks. Anyway, here's something similar to the hotlinking protection, except it's not really, it's just for redirecting direct links: alistapart.com/article/hotlinking –  f3tus Sep 22 '13 at 15:18

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.