STOP DOING THAT!!! </b>
-
Well, you won't get checksum in HTTP headers, so it would have to do with URL and timestamp like with any other web resource. Well, it does for any other web resource, it should do for downloads too. But I would still prefer the download to be to temporary location unless explicitly requested as download (Save Link? As?).
Nah. There's a fairly good chance that the file will have some kind of content identifier (
ETagheader?) though the algorithm will be uncertain, so some sort of association between URL, filename(s), content token and local content hash will have to be kept. Trivial; browsers keep all sorts of shit already. Then the browser will see whether it's got an existing file for the URL and anETagto go with it; if it has, it can issue a conditional fetch and fall back to the old file if the condition isn't satisfied.
-
Trivial; browsers keep all sorts of shit already.
Not trivial: even if the browser downloaded the file to a location that still exists in the past, it doesn't know without reading said file whether it has changed (or perhaps even removed and replaced). Unless it can reproduce the hash algorithm on the on-disk file independently and establish it's the same, it'll have to download. Otherwise, you would have less frequent but much more severe "failures."
-
Here's one that made me feel "Stop doing that!" but not because it wasted time, because it freaked me out:
I used to work occasionally with someone that would always hold the mouse rotated 90 degrees to the left: so left-click with thumb, move mouse left to move pointer up, move it up to move pointer right, etc. Given a mouse, she would always turn it and use it that way. It made me a little bit sick watching her do that.
-
Not trivial: even if the browser downloaded the file to a location that still exists in the past, it doesn't know without reading said file whether it has changed (or perhaps even removed and replaced). Unless it can reproduce the hash algorithm on the on-disk file independently and establish it's the same, it'll have to download. Otherwise, you would have less frequent but much more severe "failures."
That's why I was keeping the ETag (content token) separate from the locally-computed content hash (md5 might be good enough; it's not particularly security-sensitive and we're revalidating).
-
That's how people end up with prices.xls, prices (1).xls, prices (2).xls, prices (3).xls, prices (4).xls and so on in their Dowloads folder.
I have this problem, but that's because without a PDF plugin, you wind up with a Downloads folder that's a total donkey's rear end to search through, especially with some of the counterintuitive filenames that "web designers" give to the PDFs on their site.
-
hold the mouse rotated 90 degrees to the lef
I bet 75% of TDWTF turned their mouse 90° to try this
Admit it ... I did it too ...
-
That's how people end up with prices.xls, prices (1).xls, prices (2).xls, prices (3).xls, prices (4).xls and so on in their Dowloads folder.
I keep doing it too - usually half an hour later, when I come back to the tab, want to check the file out, and can't remember if I've already downloaded it or not. Besides, the link and the Chrome button are two clicks away; opening via Downloads is 4 + however long it takes to browse through the Downloads folder.
-
-
I'm not much of a JavaScript expert, but couldn't one easily add a "script" DOM node and set the src to some external webpage? I'd guess it's feasible in as many characters. If simply "<script src=... >" isn't possible, of course, otherwise it'd be trivial. Or am I missing something here?
I remember doing this over a decade ago using the WWWThreads forum systems and, as a proof of concept, would steal a user's cookie data too. Pretty sure browsers don't allow external JS to read cookies these days, though.
-
I didn't think of that, and misunderstood your suggestion. I like the idea.
-
-
