Hi All,
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
On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking jo...@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
* Anne van Kesteren wrote:
On Tue, 23 Nov 2010 22:41:00 +0100, Jonas Sicking jo...@sicking.cc wrote:
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
* Jonas Sicking 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
On 11/23/10 9:31 PM, Bjoern Hoehrmann wrote:
That is what the draft already requires, if by compressed Jonas means
you remove all transfer encodings but retain the content encodings
This is actually ambiguous, since the near-total lack of server and UA
support for Transfer-Encoding: gzip
