We are not able to access this url - http://www.thinkbroadband.com/download.html


Can you provide the URLs of some sites on which you experience this issue? other than this url -http://www.thinkbroadband.com/download.html? This will help us reproduce what you are seeing.

I believe the download failure will happen with any download. Just find a file large enough so you have time to pause the download before it completes. 

Thank you for providing more feedback. Adding requester "kravula@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I am able to repro with large files.

this also reproduces on  linux desktop

I think waiting for 30 seconds probably closes the connection. And that causes reading from the socket to end prematurely.

The url request log indicates that the download failed with ERR_CONTENT_LENGTH_MISMATCH, somehow we still rename the file and treat it as if it completes. 

Will look into this.

ok, in HttpStreamParser::DoReadBodyComplete(), we have this comment:

  //  - If a Content-Length header is present and the body contains fewer bytes
  //    than promised by the header at connection close, it may indicate that
  //    the connection was closed prematurely, or it may indicate that the
  //    server sent an invalid Content-Length header. Unfortunately, the invalid
  //    Content-Length header case does occur in practice and other browsers are
  //    tolerant of it. We choose to treat it as an error for now, but the
  //    download system treats it as a non-error, and URLRequestHttpJob also
  //    treats it as OK if the Content-Length is the post-decoded body content
  //    length.

This is curretly expected as pause() always leave the connection open. If server closes the connection before resume() is called, then we end up with this situation. 

Chrome cannot differentiate whether the connection was closed or whether the content-length header is incorrect.

One possible solution is to always cancel the request when pause() is called, and then resend a new request on resumption. That will create a new connection, but it will also introduce re-download issues if content-length is not present.

correct myself: the last sentence should be "re-download issues if strong validators are not present"

Asanka@, any thoughts on this?

pausing a download for more than 30 seconds seems common. But if the connection is closed, then the download will end in a wrong size.

This is the same as  issue 453357 .

The underlying cause and possible remediations are discussed briefly there.

Interesting, we have some code to handle ERR_CONTENT_LENGTH_MISMATCH in download_request_core, does it make sense to add more logic to let the download system know, that we're in this situation and we may create a new connection when Resume() is called after a Pause().

But if there is no strong validators, I guess we shouldn't resume with a new connection.

Also, even if the download system knows it, we still have the edge case(very rare) that the connection is actually being closed and the user pause, at this point it's hard to tell if a new connection is needed.

+asanka into cc list. 

I think we can send a new range request if we found that the downloaded content size mismatches with the content-length, before completing the download

I'd suggest duping this into  issue 453357  and continuing there. The suggested approach is to treat ERR_CONTENT_LENGTH_MISMATCH as an error, map it to a corresponding interrupt reason, and allow that interrupt to resume automatically.

We'd end up with an interrupted download if the there were no strong validators. In that case, users may lose data they would've previously been able to access. This is a case which we'll need to look into further. One option is to condition the behavior based on whether the response is byte addressible, and only consider it an error in that case.

Either way there's no need to keep two bugs open for this.