3 ms·

Yes, it’s probably the same behavior: https://html.spec.whatwg.org/multipage/links.html#downloading-hyperlinks https://html.spec.whatwg.org/multipage/links.html

Yes, it’s probably the same behavior: https://html.spec.whatwg.org/multipage/links.html#downloading-hyperlinks https://html.spec.whatwg.org/multipage/links.html#downloadin.... Step 7 is mostly where any improvements would go, I imagine. I’m OK with “Save as” (“Download linked file”, etc.) behaving as it does: it is more or less intuitively clear that with it we sort of “cheat” and use browser’s semi-hidden feature to interact with a website in ways not necessarily intended by its engineers. With the download attribute, however, any confusing outcome falls squarely on me, the developer, so I’d rather stick with plain links and response headers as a mechanism I have more control over. There may be some workarounds to make download behave adequately in case of an error, such as having your server behave in some way that causes browser’s fetch sequence to fail with a low-level error. Unless I’m missing something, it seems like proper network error is the only condition under which download can actually fail, and I don’t think a typical web framework setup is equipped to intentionally cause that to happen. I doubt it’s worth the bother—if you have control over the server then why not drop the attribute and just return the appropriate headers.

alduin32 5y ago
I've had to do something like that for an awful application where the frontend did chunked downloads, but didn't check properly for the status code, embedding error pages directly in the downloaded file. As I had no control over the frontend itself, I configured the reverse proxy so that for requests to download endpoints, all error responses would instantly close the connection to the client. Your post makes me think that I could generalize this so that any error to an explicit download would close the connection at the network level. It would be quite tricky to be able to distinguish between implicit and explicit downloads, but I think that if the frontend, backend and reverse proxy coordinate well together, it can be done without introducing other problems. Of course, it's a big hack that's not worth the bother.

alduin32 5y ago

I've had to do something like that for an awful application where the frontend did chunked downloads, but didn't check properly for the status code, embedding error pages directly in the downloaded file. As I had no control over the frontend itself, I configured the reverse proxy so that for requests to download endpoints, all error responses would instantly close the connection to the client. Your post makes me think that I could generalize this so that any error to an explicit download would close the connection at the network level. It would be quite tricky to be able to distinguish between implicit and explicit downloads, but I think that if the frontend, backend and reverse proxy coordinate well together, it can be done without introducing other problems. Of course, it's a big hack that's not worth the bother.