Comments on: Introducing bit.ly — the incredible professional’s URL-shortener

By: Charles

Charles — Mon, 14 Jul 2008 22:16:05 +0000

More suggestions.
1) URL resilience: 0 and O are treated the same by tinyurl, but not by bit.ly. Think you should – it’s an easy transcrition error, and doesn’t cost much in terms of the space.

2) case-sensitivity? is that really a good idea? OK, so you halve the number of potential links, but you’ve got as many links as you like if you want by adding more digits. If you’re reading out a bit.ly url to someone, do you want to have to specify caps or not caps?

By: jayridge

jayridge — Mon, 14 Jul 2008 18:54:16 +0000

Ianf: Understood. This is works as you described in development and will be in the next release.

Jay

By: Ianf

Ianf — Mon, 14 Jul 2008 18:19:08 +0000

jayridge, yes errors are gone, but the output of that feed.php op is still served sans explicit http content-type. See midway in my [#comment-74] above.

By: jayridge

jayridge — Mon, 14 Jul 2008 15:10:40 +0000

Manny. Tks for the bug report. This has been fixed.

By: Manny

Manny — Sun, 13 Jul 2008 18:46:57 +0000

Your API is throwing PHP errors:

http://bit.ly/feed.php?url=http://bit.ly/2lkCCn

By: Ianf

Ianf — Sun, 13 Jul 2008 16:24:29 +0000

This is a repost of an earlier “couple of points” comment trashed needlessly by your WP.

You NEED TO ENSURE that no tinyurl, or some such of other known similar services, get processed by bit.ly. A case in point is in [#comment-57 : chris // July 10, 2008 at 12:05 am] above, “bit.ly/guW58″ which returns

http://www.tinyurl.com/dh3jhg2d

which in turn goes to

bit.ly/guW58

…WHICH OF COURSE NEVER RESOLVES, but goes round a bit until returning

UNKNOWN ERROR tinyurl.com/redirect.php?num=dh3jhg2d

but which could be a viral nastie for all I know.

To combat such potentially lethal “double-cloaking,” I suggest that you implement better than your current, CONVOLUTED resolve-url mechanism.

bit.ly/resolve?url=target-url

(not to mention deliver the resolved url, and all /feed.php output, with proper, explicit HTTPD content-type “text/plain” or “text/html” headers – currently it’s untyped, causing my mobile browser to declare it unknown/ unsupported data type and saving it to file. Ie. do the same as with your /api?url=url stream, WHICH RENDERS CORRECTLY.).

Tinyurl allows prepending of any url with “preview.” for such purpose, ie.

preview.tinyurl.com/dh3jhg2d

but you could do it one better in multiply-redundant/ minimally-intrusive/ least-typo-prone fashion. E.g. all, or a subset of these:

check.bit.ly/api?url=target-url

bit.ly/check/target-url

bit.ly/preview/target-url

bit.ly/view/target-url

bit.ly/which/target-url

bit.ly/what/target-url

bit.ly/where/target-url

… to MAXIMALLY ease the task of remembering correct syntax when needing to manually check any publicly-posted bit.ly-ed url prior to clicking it.

And then you’d really need to preempt the use of selected/ high-profile phish-bait custom labels such as as

http://bit.ly/paypal

etc. This one’s a no brainer innit rhetorical question.

By: Jason

Jason — Sun, 13 Jul 2008 14:37:28 +0000

Ianf, I’ve responded over here to your point about whether Bit.ly should be caching content that authors state shouldn’t be cached:

http://q.queso.com/archives/002296#29342

By: Ianf

Ianf — Sun, 13 Jul 2008 14:16:46 +0000

What happened to my just-posted “A couple of points” item with important suggestions? Did your back-end maul it because I put in a correctly-formed internal-HREF link? I expected at least “awaiting moderation”.

By: Ianf

Ianf — Sun, 13 Jul 2008 12:43:03 +0000

Jason Levine [#comment-54] may have a formal point, but there’s no escaping that, once *anything* has appeared on the web, PRAGMA NO-CACHE OR NOT, there’s no way to ensure its non-offline’y static survivability.

Further on, Jason worries about the quality of cached items: “[...] Given how much of todays web is based on images, CSS, Javascript, Flash, and other added content, [which can be disputed --Ianf] this means that quite a bit of the content on cached versions of most pages will be missing, so its unclear how much utility these cached pages will hold to anyone. [...]”

…to which I can but respond by apeing[sic!]-by-analogy the immortal words of one Charles Darwin: “any intermediate eye form is better than no-eye at all.” Ie. survival of the cachiest!

By: Charles

Charles — Fri, 11 Jul 2008 08:45:55 +0000

Feature request: API key.
Reason: so I (or my org that creates bit.ly URLs) can keep track of which ones we’ve created.
How it would work: we request via the API a bit.ly URL. The request contains the API key (eg http://bit.ly/api?key=XXXX&url=http://twitabit.com)
Need to have the key first so you don’t get confused with being sent URLs containing GET parsing.
Difficulty: I dunno, you tell me.
User benefit: it would benefit orgs that want to track a lot (say, a newspaper that prints them to save space).
Benefit to you: you might even be able to ask a small fee to create one.