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.
... 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.
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.