Bugzilla

Afaict, the downloads code is currently unable to repeat the network request exactly as it was, when retrying a download.
Downloads from the Web are handled by DownloadLegacy.sys.mjs that implements nsITransfer. When the download is retried we create a DownloadCopySaver that will just use a new http channel. Many of the characteristics of the original download are lost at this point, we retain the url, the referrer, the auth header, the userContextId... not much more. To pass downloads around (and across sessions) we use a serializable object, that cannot really contain a complex request object.

There is a helper that Valentin found yesterday called `adjustChannel`, that was introduced in Bug 915036 for WebExt API, that allows to adjust the download channel with specific request method, post data and headers. Though that is currently only used by the WebExt API.
It is possible to set download.source.adjustChannel when the download object is created, to a function setting certain characteristics (the requestMethod, postData and headers) and it will be used when retrying the download. I have a local patch doing that and it fixes the case in Bug 1892115.
BUT, setting adjustChannel makes the download not serializable, and not portable across sessions. Whether that's acceptable for POST blocked pages is debatable.

To got a bit further, one could add requestMethod and postData to the serializable data, instead of using adjustChannel. That would make POST downloads act properly across sessions.
I must note that once the download is considered "done" and moved to history, that serialized data is lost again. So if a download fails today, and one would retry it from history in a few days, it won't be the same. To also support that case, we should store additional metadata (method and postData) in history too.

Headers are even more complicate, as there may be many that are necessary and many that are not, or maybe some should also be removed to retry the download succesfully, like in the case outlined here.
It's unlikely we can detect allo those cases, so maybe we should just address the POST/postData problem and leave headers to the future?

These issues would normally affect failed downloads, failed POST downloads are probably rare enough that we didn't notice. Blocked downloads make the problem more frequent.

Afaict, the downloads code is currently unable to repeat the network request exactly as it was, when retrying a download.
Downloads from the Web are handled by DownloadLegacy.sys.mjs that implements nsITransfer. When the download is retried we create a DownloadCopySaver that will just use a new http channel. Many of the characteristics of the original download are lost at this point, we retain the url, the referrer, the auth header, the userContextId... not much more. To pass downloads around (and across sessions) we use a serializable object, that cannot really contain a complex request object.

There is a helper that Valentin found yesterday called `adjustChannel`, that was introduced in Bug 915036 for WebExt API, that allows to adjust the download channel with specific request method, post data and headers. Though that is currently only used by the WebExt API.
It is possible to set download.source.adjustChannel when the download object is created, to a function setting certain characteristics (the requestMethod, postData and headers) and it will be used when retrying the download. I have a local patch doing that and it fixes the case in Bug 1892115.
BUT, setting adjustChannel makes the download not serializable, and not portable across sessions. Whether that's acceptable for POST blocked pages is debatable.

To got a bit further, one could add requestMethod and postData to the serializable data, instead of using adjustChannel. That would make POST downloads act properly across sessions.
I must note that once the download is considered "done" and moved to history, that serialized data is lost again. So if a download fails today, and one would retry it from history in a few days, it won't be the same. To also support that case, we should store additional metadata (method and postData) in history too.

Headers are even more complicate, as there may be many that are necessary and many that are not, or maybe some should also be removed to retry the download succesfully, like in the case outlined here.
It's unlikely we can detect all those cases, so maybe we should just address the POST/postData problem and leave headers to the future?

These issues would normally affect failed downloads, failed POST downloads are probably rare enough that we didn't notice. Blocked downloads make the problem more frequent.

Afaict, the downloads code is currently unable to repeat the network request exactly as it was, when retrying a download.
Downloads from the Web are handled by DownloadLegacy.sys.mjs that implements nsITransfer. When the download is retried we create a DownloadCopySaver that will just use a new http channel. Many of the characteristics of the original download are lost at this point, we retain the url, the referrer, the auth header, the userContextId... not much more. To pass downloads around (and across sessions) we use a serializable object, that cannot really contain a complex request object.

There is a helper that Valentin found yesterday called `adjustChannel`, that was introduced in Bug 915036 for WebExt API, that allows to adjust the download channel with specific request method, post data and headers. Though that is currently only used by the WebExt API.
It is possible to set download.source.adjustChannel when the download object is created, to a function setting certain characteristics (the requestMethod, postData and headers) and it will be used when retrying the download. I have a [local patch]
(https://pastebin.mozilla.org/HG8HQzes) doing that and it fixes the case in Bug 1892115.
BUT, setting adjustChannel makes the download not serializable, and not portable across sessions. Whether that's acceptable for POST blocked pages is debatable.

To got a bit further, one could add requestMethod and postData to the serializable data, instead of using adjustChannel. That would make POST downloads act properly across sessions.
I must note that once the download is considered "done" and moved to history, that serialized data is lost again. So if a download fails today, and one would retry it from history in a few days, it won't be the same. To also support that case, we should store additional metadata (method and postData) in history too.

Headers are even more complicate, as there may be many that are necessary and many that are not, or maybe some should also be removed to retry the download succesfully, like in the case outlined here.
It's unlikely we can detect all those cases, so maybe we should just address the POST/postData problem and leave headers to the future?

These issues would normally affect failed downloads, failed POST downloads are probably rare enough that we didn't notice. Blocked downloads make the problem more frequent.

Afaict, the downloads code is currently unable to repeat the network request exactly as it was, when retrying a download.
Downloads from the Web are handled by DownloadLegacy.sys.mjs that implements nsITransfer. When the download is retried we create a DownloadCopySaver that will just use a new http channel. Many of the characteristics of the original download are lost at this point, we retain the url, the referrer, the auth header, the userContextId... not much more. To pass downloads around (and across sessions) we use a serializable object, that cannot really contain a complex request object.

There is a helper that Valentin found yesterday called `adjustChannel`, that was introduced in Bug 915036 for WebExt API, that allows to adjust the download channel with specific request method, post data and headers. Though that is currently only used by the WebExt API.
It is possible to set download.source.adjustChannel when the download object is created, to a function setting certain characteristics (the requestMethod, postData and headers) and it will be used when retrying the download. I have a [local patch](https://pastebin.mozilla.org/HG8HQzes) doing that and it fixes the case in Bug 1892115.
BUT, setting adjustChannel makes the download not serializable, and not portable across sessions. Whether that's acceptable for POST blocked pages is debatable.

To got a bit further, one could add requestMethod and postData to the serializable data, instead of using adjustChannel. That would make POST downloads act properly across sessions.
I must note that once the download is considered "done" and moved to history, that serialized data is lost again. So if a download fails today, and one would retry it from history in a few days, it won't be the same. To also support that case, we should store additional metadata (method and postData) in history too.

Headers are even more complicate, as there may be many that are necessary and many that are not, or maybe some should also be removed to retry the download succesfully, like in the case outlined here.
It's unlikely we can detect all those cases, so maybe we should just address the POST/postData problem and leave headers to the future?

These issues would normally affect failed downloads, failed POST downloads are probably rare enough that we didn't notice. Blocked downloads make the problem more frequent.