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
Received on Tuesday, 23 November 2010 21:57:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC