[Bug 23348] The loaded property doesn't make sense when the body is compressed

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23348

--- Comment #20 from Marcelo Volmaro <mvolmaro@hotmail.com> ---
(In reply to Boris Zbarsky from comment #18)

> > but doing a small test
> > with .net, I can get Glenn's file, compressed, and get the number of
> > downloaded bytes from the stream. 
> 
> Yes, but the point is a browser wants to get the file _uncompressed_ in this
> case.  And in fact pretty much always (there is only one exception I can
> think of, and that's when the file is being saved and has a .gz or .gzip
> extension).

The browser uses (by what you said) its own HTTP library to fetch data. What
then it does with that data will depend on who asked for that data, but the
data is transferred as a bunch of bytes. From my point of view, the JS engine
asks for some data. The engine asks the HTTP library for it. It is ok (and
makes total sense) that what the JS engine receives the data uncompressed since
the compression is part of the underlining transmission protocol. It is even ok
that the underlining HTTP library feeds that data to the JS engine
uncompressed. But the progress event can't be handled by the JS engine. Is has
to be handled by the HTTP library. Then, the library can report back to the JS
engine the correct progress.

I don't know how that's being handled right now on each browser. If the
specification states what I said above (basically, that you can always get a
proper progress indicator if the content-length is specified), and right now
all browsers are doing it wrong, that's ok. It is their fault and they may/may
not fix that. But it is clear that they are the ones doing things wrong.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 26 September 2013 15:55:27 UTC