How does tinypic.com referrer/redirect work?

Question

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?

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).