Hacker News new | past | comments | ask | show | jobs | submit login

hacker news is not cool with link shorteners. most link shorteners (bit.ly, et al) are banned here. chances are good that the only reason this particular shortener isn't banned yet is because dang is not aware of it. should be replaced with this article's true url:


Is it really a link-shortener or just atavist providing a short perma-link? 'atav.st' == atavist.com?

it doesn't make any difference, if you think about why hacker news bans link shorteners: there should be one, and ONLY one, canonical URL for every article. if you allow two or more, then there is essentially no way to detect duplicate submissions. so i can pretty much guarantee that it is just a matter of time until atav.st is banned here.

> essentially no way to detect duplicate submissions

No, the shortened URL can be followed.

... and once it is followed, it is the true URL that should be displayed, because it contains more useful information for the end user, like the true domain where the article resides, instead of the alphabet soup you get with link shorteners. which, again, is why link shorteners are banned here.

i probably shouldn't engage in arguing pointless minutiae like this. i will refrain after this one.

I think it's good to discuss HN social norms when it's appropriate. Your comment added to the discussion.

I agree.

True, if anything that should be a feature of HN. To try and follow a 403 and use that instead. The only examples I can think of in which this wouldn't be desired are articles you have to login to access, but that could be a short blacklist or whitelist. Of course once we're inspecting URLs for 403s, I can see a slippery slope to indexing and comparing content of submissions...

304, not 403. And actually, only a 301 Permanent Redirect should be followed and used instead. bit.ly and URL shorteners it powers, which includes atav.st, use 301 Permanent Redirect.

Fetching the headers would also be a good way to check the MIME type (for automatic warnings like [pdf] or [video]), as well as checking the title.

Of course 304, ungh. The reason 304 gets used more often than 301 even for essentially permanent redirects is because of browser caching... If you allow editing a redirect, then you might want to change future requests. Of course, many URL shorteners don't allow edits. As far as I know, some browsers don't cache-invalidate 301s. Haven't investigated recently, maybe there's an HTTP2 solution for this, or proper use of headers, or something.

I'm pretty sure bitly dedupes.

They also have partnerships to do branded shortening. Bitly will happily generate shortened URLs for other domains, eg http://amzn.to/

As part of their content scrubbing, I suggest HN re-shortens URLs. Another +1 use case that bitly or other service could provide.

Agree about dups, but there's no reason why HN could not use bitly and open source some access to the analytics data.

Here's a direct link to the bitly report for the link:


^^ which redirects to:


(In case some don't know, just add "+" to the end of a bitly link to see the report.)

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact