Here's a daft thing: a lot of browsers, typically on phones and Macs, won't re-download a file if it's been downloaded before. I can understand caching pages, images and CSS, that's good, but caching downloaded files? Meaning that when a user clicks to download a Word doc or a PDF, the browser will decide that they don't need to! Even though they think they do! I'm now having to add ?v=time() to PDFs, Excel files and similar, which feels really hacky. Some browsers will ask if the user wants to re-download, which is fine, but taking people to old and obsolete versions of documents when they want the current version is just stoooooopid.

Sauce?

well, i've never encountered such a phenomen.

but the phrase "and macs" lets me guess that it's just shit-tier browsers doing this - browsers that nobody in their right mind uses anyway.

on the other hand: if it _is_ a new version of a document, it _should_ have a new address. or at least headers telling the browser that there is a newer version available.

Never seen anything else than the redownload prompt

Never have I encountered such behavior

There is a way to tell the browser that the file have changed even without changing the url. One i using ETag.

Another is to set caching headers BUT safari sometimes ignore cache headers.

Seems like a dumb implementation, if it doesn't check hash of the file.

Can you change version number of metadata to make it download?

@tosensei The thing is, we still want people who aren't using the best possible browsers to get the latest versions of files. You'll often see various answers on Stack Overflow along the lines of 'just tell everyone to...', but in the real world we need our site to deliver the current version of the document, regardless of what's in the cache, straightforwardly. It's a classic case of failed KISS - just download, FFS.

@nitwhiz Source is user feedback. Clearing browser cache or history allowed re-download of the file, meaning they got the currently online version we want them to have. The only true fix is to version. No-cache headers (must-revalidate etc) are frequently ignored.

@WildOrangutan how would it check the hash without downloading it without additional headers or anything?

@spongegeoff "Clearing browser cache or history allowed re-download of the file" - seems like the version info isn't correctly said. as mentioned before: if it's a new version of a file, it should _in some way_ indicate it's new.

"no-cache headers are frequently ignored" - file a bug report with the browsers in question. yeah, sure, "Stuff Should Work", but it's not your job to work around others mistakes - but rather to tell others to fix their mistakes. (blown-out-of-proportion-analogy: if you sell steaks and the customers complain they can't cut it because their knifes are dull - would you pre-cut the steak, or tell the customer to use a sharper knife? or the knife manufacturer not to sell dull knifes?)

@ScriptCoded perhaps they send a HEAD request to get some metadata type headers like eTag or Cache-Control

@tosensei Have to be honest, I don't know exactly, in detail, how browsers determine the ages of static files or how the info is exposed. I just want the file(s) downloaded, in all circumstances, regardless of whether the file has changed. Not much point me telling browser mfrs about a 'bug', as it's really a case of the intended behaviour being problematic. There's a general tendency for browsers to shortcut excessively, as if sourcing outdated files quickly is better than delivering the current versions very slightly later.

Wait what now?

@tosensei Apple have made the continuous decision with Safari to sometimes ignore cache headers for the mobile version since they believe they are better at judging when something needs reloading than the builders of the site.

And unfortunately they mostly are correct :/ which is the root of the problem. Yes they break the standard, but in their eyes they do it because to many sites do not follow it anyway.

Forcing us who needs it to be followed to do workarounds.

Like adding a timestamp, or using Etags, etags should work even with safari and other browsers, at least any one from the last 10-15 years.

@Voxera "Apple have made the continuous decision with Safari to sometimes ignore cache headers" - apple making the decision to just screw the standards and do their own bullshit is nothing new.

and part of the problem - why should developers care to do it right, if apple (and others) purposefully does it wrong all the time?

@Voxera The reason I say Apple are wrong is because being 'mostly correct' won't do. The negative consequences of silently providing outdated versions of files far, far outweigh the benefits of saving a small number of unnecessary repeat downloads. I wasn't versioning the files we offer for download because it truly didn't occur to me that a browser design team would do something so dumb as to cache files that aren't page components. 99% of the world has video-capable bandwidth, so the great majority of pdf, xlsx and docx files will download in a couple of seconds, free of charge. Working from an old version of a document can have career implications. It almost feels as if users who haven't learned to be wary are being suckered.
Thanks re Etags, I hadn't heard of those, but could they too simply be ignored? Overall, I simply think that all browsers should download on request (and also properly refresh on refresh FFS, but that's another sh1tshow in itself).

@spongegeoff I never claimed they did anything right.

The only reason I know about Etags for example is because we had to learn about them to serve the right things.

Since IE was discontinued safari is my favorite hate object together with itunes :P

@Voxera Yeah, last time I looked desktop Safari wasn't even generating a datepicker for type='date' on input fields. Sounds obscure, but any sort of event needs a date.