zlacker

Could you explain what the intended/expected outcome is for this? What is accomplished by doing that?

>>Shamel+(OP)
Cookies?

>>Shamel+(OP)
Crawlers and tools will get the right location http header but browsers and users will get the delay.

>>Shamel+(OP)
The purpose is so that Twitter is seen as the source of the traffic. A lot of Twitter-sourced traffic comes from native apps, so when people click links from tweets, they usually don’t send referrer information.

If the redirects were server side (setting the Location header), a blank referrer remains blank. Client side redirects will set the referral value.

From Twitter’s POV, there’s value in more fully conveying how much traffic they send to sites, even if it minorly inconveniences users.

>>yahelc+sf
How does this inconvenience users? It sounds like you’re saying site owners will be able to distinguish between users with a blank referer and users whose “referer” was the desktop app. Ignoring the privacy angle, isn’t that a good thing?

>>gcr+cO2
Other than the privacy angle a meta redirect is always a bit slower than a location header. You need to send an html page (more bytes) that the browser needs to render and then act on (more work).

A location header is nearly unnoticeable, a meta refresh page gives you a flash of a blank interstitial screen.

(Not that I had the same annoyance, just explaining the difference to the end user of the two approaches)

>>jauco+xY2
With the amount of bloat we have on the modern web, I think sending an HTML meta tag rather than a Location header should be the least of our concerns, when it comes to performance.

If the whole purpose of it is to have browsers send a Referer header, I don't think it's that bad. Even from a privacy perspective, you can configure browsers to not send that header anyway.