- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 24 Apr 2006 11:35:01 -0500
- 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. -Boris
Received on Monday, 24 April 2006 16:35:28 UTC