W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 23 Nov 2010 22:56:44 +0100
To: "Webapps WG" <public-webapps@w3.org>, "Jonas Sicking" <jonas@sicking.cc>
Message-ID: <op.vmm8ktzn64w2qv@anne-van-kesterens-macbook-pro.local>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT