On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking <[email protected]> wrote:
How should ProgressEvents deal with compressed transfer encodings? The
problem is that the Content-Length header (if I understand things
correctly) contains the encoded number of bytes, so we don't have
access to the total number of bytes which will be exposed to the user
until it's all downloaded. I can see several solutions:
A) Set "total" to 0, and "loaded" to the number of decompressed bytes
downloaded so far
B) Set "total" to the contents of the Content-Length header and
"loaded" the number of compressed bytes downloaded so far
C) Like A, but also expose a percentage downloaded which is based on
the compressed data
B seems spec-wise the simplest, but at least gecko doesn't expose the
compressed number of bytes downloaded, not sure about other HTTP
libraries. It also has the downside that .loaded doesn't match
.responseText.length
When compression does not come into play they will only match for certain
encoding / byte streams anyway. E.g. for a UTF-8 encoded character stream
with characters that take up more than one byte they will not match. I
think it should be B.
C seems the most confusing for authors and the one I like the least.
--
Anne van Kesteren
http://annevankesteren.nl/
