rajasuba.suba@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.12.6 using the latest Stable 63.0.3239.108 and Canary 65.0.3305.0 by following the below steps.

1. launched Chrome and started to download a large file eg. Youtube video. (Couldn't download file from box.com site as credentials not available and not able to sign up in the site as well).
2. Unplugged the ethernet cable and can see the download is stopped and cannot observe any status as Complete on the download tray.
3. On plugging in the Ethernet cable, can see the Download is resumed without any issues.
Attached is the screen cast for reference.

Request you to please check and update if anything is missed from our end in reproducing the issue.
Also request you to please retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks...

Deleted: 795736.webm 6.7 MB

	795736.webm 6.7 MB View Download

Hi,

Thanks for reaching me out. Please follow the above steps and try downloading this file... I could still able to reproduce this issue

https://docs.zoho.com/download/183myde5894f30c2147c5bba9c01920b559e9

This is my Chrome version 

Version 63.0.3239.108 (Official Build) (64-bit)

And this is the screen recording of the reproduced issue.

https://drive.google.com/open?id=10T0t4im3NgHZ4mckH318MkvHB9lilG3u

And i could reproduce this by simply hosting the following code on a tomcat server.

https://docs.zoho.com/file/4xwcw4495eda4907145ec86ad163982e86a68

Please feel free to reach me out (@rajasuba.suba@gmail.com) if you need any help on reproducing this issue. Would be really happy to help you.

Thanks in advance.

Hi sc00335...@techmahindra.com,

I tried downloading the same file multiple times in incognito window (by disabling all my chrome extension in incognito mode - just removed the check from "Allow in incognito" checkbox) - and the issue could be reproduced. One of the file which is partially downloaded is marked as completed(similar to one i have shown in the above screen recording video).

Looking forward to hear from you !

Thanks....

And i just tried to reproduce the same with my friends machine - few could reproduce this only with their second attempt - and not all could reproduce with their first attempt...

other than ethernet cable, does the machine also have wifi connection when the download is ongoing?

No it doesn't ! 

I cannot reproduce the issue on my Mac pro but i think I know why this is happening.

after you disconnect the ethernet cable for some time, the socket will get closed. Chrome doesn't know whether all the data has been received or not, but a mismatch error between received file size and content-length is reported. 

Because content-length header are not always correct, so the mismatch error is often ignored. And there is no strong validators present in the respose(ETag or Last-modified). So Chrome is not be able to resume the download. As a result, it treats the download as completed.

If you add strong validators to your tomcat server, i believe this won't happen.

I think this is intended behavior, we could probably loosen the download resumption requirement to allow download to resume even without strong validators, as long as content-length doesn't change.

I think you're right about what's happening. I've seen this behavior when using a download tester I wrote to do UI work on downloads: if I ctrl+c while a download is in progress, it gets marked as completed. I just tried adding a Last-Modified header and it gets marked as failed.

For what it's worth, I just tried Safari and Firefox and they both consider the download to have failed in this case.

Deleted: download_tester.go 1.6 KB

download_tester.go 1.6 KB View Download

(Just thinking this through — an alternative would be for retry to just start the download over if there's no strong validator. That seems the least likely to result in an incomplete file or mashup of two versions, at the expense of potential wasted time/bandwidth.)

Great to hear from you sdy@chromium.org! 

What about trying to "restart the download" - when there is mismatch in content length and 

i) there is no strong validator (or) 
ii) the connection couldn't be resumed?

Does that make sense?

I think that’s what I was getting at too, in c#17. Other browsers seem to restart the download from the beginning when you retry without a strong validator, and that seems like the correct behavior.

qinmin@, thoughts? I'm going to reopen this so that it's in your queue, but if you still feel the same way then feel free to WontFix again.

The issue of restarting a download is that it could fall into an infinite cycle of redownloading.

For example, if a server does present a wrong content-length header, then Chrome will download the content over and over without able to finish it. Sometimes there is no good way of determining whether the server stops sending the data is due to a closed connection, a broken proxy, or a wifi issue or a local connection issue. 

Firefox just mark the download as failed in this case.
Chrome could also do the same, and that's probably better than redownloading it from the beginning.

Agreed, I meant marking the download as failed with an option to retry from the beginning, not auto-retry.

we could, a potential issue of that approach is then the download will never complete if the content-length header is wrong.

"marking the download as failed with an option to retry from the beginning, not auto-retry"

Sounds reasonable !