W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: XMLHttpRequest progress events

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Mon, 24 Apr 2006 11:35:01 -0500
Message-ID: <444CFE35.8000102@mit.edu>
To: Gorm Haug Eriksen <gormer@opera.com>
CC: "Web APIs WG (public)" <public-webapi@w3.org>

Gorm Haug Eriksen wrote:
> Btw, I found two strange behaviours while looking at it now. It seems 
> like the onprogress event is one cycle before responseText.length.

The interaction between the two in Gecko is undefined and subject to change.

> Also, strange things seems to happen if the Content-Length header is missing.

In this case, the entity size is not known, so progress events report the total 
downloaded so far, but use the maximum number they can for the total size.  At 
least that's how it should work.

> Opera will probably wait until this group has made an recommendation 
> because the same behaviour is possible to implement without the 
> onprogress event (by checking the Content-Length header and watching the 
> length of responseText as it progress).

Only if you're doing HTTP.  There are other protocols supported by 
XMLHttpRequest (in spite of the name), where getting the content size happens in 
some other way.

Furthermore, even for HTTP your proposal doesn't work for "Content-Encoding: gzip".

> I would wait until all vendors get a chance to review a proposal in 
> public. The people that need this behaviour are capable of implementing 
> it today using server side scripting.

Actually, we have consumers that need this behavior that cannot implement it via 
server-side scripting (e.g. the browser UI and various extensions).  I've put 
this on hold for now while we're discussing it, but we do need to do something 
along these lines in the next few months at most.

Received on Monday, 24 April 2006 16:35:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:21 UTC