4 ms·

I can see how Twitters length-limit led to external link shorteners, but once they took it in-house, why expose it? Why not just say that a link (of any length)

I can see how Twitters length-limit led to external link shorteners, but once they took it in-house, why expose it? Why not just say that a link (of any length) "costs" n characters, and handle the shortening/expansion on the backend? What is the benefit of exposing the mechanism?

brian_cloutier 14y ago
If you're a regular user it's not exposed. Links are shown with their full url on the site and the user is usually redirected before tthey have a chance to notice they're being sent through t.co
- mseebach 14y ago
  It is very much exposed: The regular user can't click on links on Twitter because it's down.
- justincormack 14y ago
  I am a regular user but mostly on mobile. Often I give up on links as it gets stuck loading t.co and I notice constantly.
TazeTSchnitzel 14y ago
Backwards compatibility.
- mseebach 14y ago
  It could be as simple as a flag on the API: Do you want shortened links and a guarantee that the message is less than 140 characters, or full link, with a risk that it will "spill over". As most (all?) clients expand links anyway, they'd be choosing the latter.
kcl 14y ago
Twitter wants to route links through their servers for at least two reasons: 1. Analytics and monitoring. (Google's results page uses the same technique.) 2. Disabling malicious and unwanted links.
- guelo 14y ago
  Google search does not use the same technique.
  - damncabbage 14y ago
    What's the difference? * User browses on Twitter, clicks link in tweet pointing to t.co, is redirected off to the page where they wanted to go. * User searches on Google, clicks link in search result pointing to google.com, is redirected off to the page where they wanted to go. Admittedly it only happens with half of the search results of the first page (I think; it seems to vary), but it's very much the same technique.
    - kcl 14y ago
      If he was not misled by the false "on hover" representation of the link in his address bar, then its possible he means: 1. That Twitter uses a "short link" where Google uses some kind of (I trust) token-secured "open redirect" or 2. That Google uses a {Javascript, 301, ...} redirect where Twitter uses a {Javascript, 301, ...} redirect. Depending on what User-agent I sent, I got Twitter to variously return a Javascript or 301 Moved Permanently response. I could only get Google to return a Javascript response to cURL, but I did not try hard, and I would not rule out Google employing different redirect methods, particularly on their search results page. Google is notorious for falling back to different methods depending on the particulars of the client. See: http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/ http://www.stevesouders.com/blog/2010/07/12/velocity-forcing... So they at least both use the Javascript method. In any event, if you mod out the content of the hyperlink after the domain, and mod out the content of the text based HTTP response (!), which is fair here, then the methods are all equivalent, and all generate the same server diagrams. In this case, there is not much difference between the browser parsing plaintext in HTTP headers that tells it to go to a different site and the browser parsing plaintext in an HTTP body that tells it to go to a different site once executed in a Javascript engine.
      - guelo 14y ago

brian_cloutier 14y ago

If you're a regular user it's not exposed. Links are shown with their full url on the site and the user is usually redirected before tthey have a chance to notice they're being sent through t.co

mseebach 14y ago
It is very much exposed: The regular user can't click on links on Twitter because it's down.
justincormack 14y ago
I am a regular user but mostly on mobile. Often I give up on links as it gets stuck loading t.co and I notice constantly.

TazeTSchnitzel 14y ago

Backwards compatibility.

mseebach 14y ago
It could be as simple as a flag on the API: Do you want shortened links and a guarantee that the message is less than 140 characters, or full link, with a risk that it will "spill over". As most (all?) clients expand links anyway, they'd be choosing the latter.

kcl 14y ago

Twitter wants to route links through their servers for at least two reasons: 1. Analytics and monitoring. (Google's results page uses the same technique.) 2. Disabling malicious and unwanted links.

guelo 14y ago
Google search does not use the same technique.
- damncabbage 14y ago
  What's the difference? * User browses on Twitter, clicks link in tweet pointing to t.co, is redirected off to the page where they wanted to go. * User searches on Google, clicks link in search result pointing to google.com, is redirected off to the page where they wanted to go. Admittedly it only happens with half of the search results of the first page (I think; it seems to vary), but it's very much the same technique.
  - kcl 14y ago
    If he was not misled by the false "on hover" representation of the link in his address bar, then its possible he means: 1. That Twitter uses a "short link" where Google uses some kind of (I trust) token-secured "open redirect" or 2. That Google uses a {Javascript, 301, ...} redirect where Twitter uses a {Javascript, 301, ...} redirect. Depending on what User-agent I sent, I got Twitter to variously return a Javascript or 301 Moved Permanently response. I could only get Google to return a Javascript response to cURL, but I did not try hard, and I would not rule out Google employing different redirect methods, particularly on their search results page. Google is notorious for falling back to different methods depending on the particulars of the client. See: http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/ http://www.stevesouders.com/blog/2010/07/12/velocity-forcing... So they at least both use the Javascript method. In any event, if you mod out the content of the hyperlink after the domain, and mod out the content of the text based HTTP response (!), which is fair here, then the methods are all equivalent, and all generate the same server diagrams. In this case, there is not much difference between the browser parsing plaintext in HTTP headers that tells it to go to a different site and the browser parsing plaintext in an HTTP body that tells it to go to a different site once executed in a Javascript engine.
    - guelo 14y ago