Frage

Upon inspecting Twitter's URL shortening service http://t.co, I noticed that, instead of redirecting to the goal URL using a Location HTTP header and a 3xx HTTP status code, it redirects using the following HTML (formatted for better readability):

<head>
  <meta name="referrer" content="always">
  <noscript>
    <META http-equiv="refresh" content="0;URL=[URL]">
  </noscript>
  <title>[URL]</title>
</head>
<script>window.opener = null; location.replace("[URL]")</script>

where [URL] would contain the actual goal URL. To be clear: this is the complete HTML content, not just an HTML fragment.

A large/popular service like http://t.co will surely have good reasons to choose this strategy over HTTP header redirection, but I can't think of any.

What are the benefits of choosing this redirection strategy over HTTP header redirection?


I just realized that it might be the <meta name="referrer" content="always"> tag. Will this keep a possibly existing Referer request header intact, perhaps?

War es hilfreich?

Lösung

As your edit suggests, the client-side redirect in conjunction with the referrer meta tag better ensures that the Referrer header is sent. Though it's not exactly the same problem, a quick search on the referrer meta tag offers suggests the purpose is SEO-ish in nature.

SEOs have long used referrer data for a number of beneficial purposes. Oftentimes, people will link back or check out the site sending traffic when they see the referrer in their analytics data. (moz.com)

Twitter doesn't care as much that you link back. But, they do want to ensure they get credit with site owners as a major traffic source / marketing tool.

The client-side redirect helps keeps Twitter in business.


If clarification is needed: A referrer meta tag on the initial page isn't sufficient. Because of the URL shortening and redirection, as well as the possibility of tweets being copied or posted in other places, the intermediate page is essential to ensure Twitter receives every ounce of credit it can possibly slurp up.

Andere Tipps

Actual benefits:

JavaScript redirects can be useful for redirecting mobile devices from a desktop version of a page to its mobile version, or vice versa for desktops. The server will only know the User-Agent, not the actual width of the screen. You could for instance swap between two version when the screen gets tilted from portrait to landscape and vice versa.

JavaScript would allow very temporary redirects. It doesn't matter if the response gets cached in the browser, the script can still execute differently. The destination can change more often than the page/response from the server does. You could for instance redirect to a randomly chosen page each time the page is accessed, or perhaps add a timestamp in a query string when redirecting.

Developer laziness:

Both JavaScript redirects and meta refreshes can be implemented without having access to the HTTP headers. This can be useful for poorly implemented server side scripts: you can redirect a page after the headers have already been sent, and you don't need to change large parts of code.

Totally pointless:

Both JavaScript redirects and meta refreshes will allow a delay before the redirect. If you want to show a message that the user will barely have time to read, this is a good solution.

The main benefit I can think is it would allow browser caching to be used, which on the scale of twitter, would be substantial. Other thought is maybe twitter logging/stats application they use needs it.

Normally server side redirects are preferred.

One scenario of client side redirect is localstorage/sessionstorage. If you need to copy some data from server to localstorage client side redirect is the way to go.

The disadvantage of using client side redirect is browser history can contain the useless redirect step. This can be mitigated by using window.location.replace(newurl) instead of window.location = newurl or meta tags.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top