Re: [ProgressEvents] How to deal with compressed transfer encodings

On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking <jonas@sicking.cc> 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/

Received on Tuesday, 23 November 2010 21:57:20 UTC