- From: <bugzilla@jessica.w3.org>
- Date: Thu, 26 Sep 2013 14:22:16 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23348 --- Comment #17 from Marcelo Volmaro <mvolmaro@hotmail.com> --- So, to sum up: If the content is compressed, there is no way to get a progress (in terms of a percentage from a total). The only thing I can get is the number of bytes downloaded AFTER the decompression. I refuse to believe that there is no way, in the system, to get the number of downloaded bytes (and I don't think that a specification needs to be tied to what a system can/can't do - doing so means that we are tied to what the lowest implementation of a system can do). I really don't know how the HTTP system libraries work so I can't comment on that, but doing a small test with .net, I can get Glenn's file, compressed, and get the number of downloaded bytes from the stream. I don't think .net is downloading the file through the HTTP libraries in uncompressed form and compressing it back only to give me a compressed stream. Also, if I try to download the file, this is what I get: - With Opera, I get a progress bar over the downloaded bytes. Just what I expect. - With Chrome, I get an undetermined download progress. - With Firefox, I get a progress bar that shows the compressed size, but the file continues downloading even after the number of downloaded bytes were way bigger than the total. So, .net and Opera work as I expected, Chrome/Firefox don't. Since there are at least two implementations (on Windows) that can read/determine the correct number of downloaded bytes, I don't think the problem is with the underlining HTTP libraries. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 26 September 2013 14:22:18 UTC