Improving download estimations |
||
Issue descriptionhttps://gzipped-download-test.glitch.me/ The above is a slow download (1k per second), but the resource is heavily gzipped (from 100mb to ~100k). We currently report the size as written to disk, but we don't show a percent, or estimated time to completion. The time to completion could be calculated using the bytes down the wire / Content-Length vs time. This could also be used for percentage, but 50% downloaded may not mean 50% written to disk, as the compression ratio may not be constant. We could even try to get the total size by making an additional range request (eg Range: 0-10), as the responding Content-Range header often includes the total unencoded byte size.
,
May 17 2018
I think Chrome's network layer currently does not support range requests if there is any on-the-wire encoding. IIUC the download layer does not see the encoded data coming in / the unzipped offset.
,
May 17 2018
The network layer might be able to provide something here to help us determine actual % complete. We'd have to talk about whether or not this makes sense for the API. I don't know if the network layer wants to be responsible for exposing that type of information.
,
May 17 2018
The network stack does already provide the content-length header (if present) and the raw bytes received (See URLLoaderClient::OnTransferSizeUpdated) |
||
►
Sign in to add a comment |
||
Comment 1 by na...@chromium.org
, May 17 2018