Deferring downloads

[mfalken]

https://jeremyroman.github.io/alternate-loading-modes/#patch-downloading

I'm writing this in haste before I forget, and didn't look closely, but is it really feasible to defer a download? In Chromium we sometimes only know if it's a download once we get the HTTP response header with content-disposition. Is the algorithm deferring only specific download triggers, or all of them including content-disposition?

In Chromium we are planning to cancel prerender in this case, because I think we can't reliably queue up the download and have it resume on activation.

[jeremyroman]

There are presently two separate patches related to downloads. One is the download the hyperlink algorithm you linked, executed when an <a download> is clicked, and the other is the patch to the process a navigate response patch which currently just discards if the navigation is to a resource with attachment disposition.

This seems consistent with what you described as Chromium's plan. I think we could queue it even in the latter case if we wanted to (e.g., by re-requesting it and either forcing it to download or dropping it if the disposition mismatches), but the presently described behavior seems likely to be fine and is much simpler from a spec and impl POV.

[mfalken]

OK thanks, that makes sense.

I missed the bad-navs section. I'll see if we can do the same in Chromium.

[domenic]

Note that there's a known issue that the HTML spec's "downloading a hyperlink" section goes down a separate path than navigations, but in browsers downloads are much more like navigations than not. I think that's whatwg/html#5548 . So if this division makes less sense in the implementation than it does in the spec, that'd be good to know.