undefined | Better HN

0 pointskijin7y ago0 comments

Do you ever run into a problem when an overzealous email service or virus scanner pre-fetches the link and invalidates it before an actual person clicks on it? This used to happen with all sorts of links in emails, though I haven't heard about it in a while.

0 comments

AdmiralAsshat7y ago

To my knowledge, the link is only invalidated if the person actually downloads the file. Simply viewing the link does not invalidate it. I can recall a couple of times emailing a Send link to my brother, then checking it in the morning to see if he had grabbed him or not. It was still viewable, so I deduced that he hadn't grabbed it yet, sent him a follow-up e-mail ("Hey you lazy bastard, grab the damn file before it automatically expires!"), and checked again a few hours later to find it gone.

JoshTriplett7y ago

> To my knowledge, the link is only invalidated if the person actually downloads the file.

I've used one-time-link services sometimes, and posting the link to Slack causes Slack to make an HTTP fetch looking for metadata, which then invalidates the link.

bradknowles7y ago

Which is why you put a trivial password on the file, which isn't included as part of the link.

Then, any automated system which sees the link cannot accidentally cause the file to be "downloaded" which would cause the link to be invalidated. They can see the link itself, but they don't have the password, therefore they can't download the content to scan it.

I have used onetimesecret.com a number of times in this way.

regecks7y ago

The easy solution is for the link to lead to an interstitial that shows "do you want to view the content? It will be the only time you can do so.", and make the underlying HTTP resource unpredictable (e.g. different ID to the link) so that it cannot be directly addressed.

It's a very common and easy to anticipate issue, I'm surprised that there are any one-time-link services left that suffer from it.

kccqzy7y ago

What if the download was interrupted because, e.g. the other person had a temporary issue in their internet connection? Does the server at least detect that the entire file has been sent over the socket? Does the server at least check that, on a TCP level, receive all the ACK packets it is meant to receive? Of course this still isn't foolproof but it's a good way towards detecting interrupted downloads.

j / k navigate · click thread line to collapse