- From: Charles McCathieNevile <chaals@opera.com>
- Date: Sun, 21 Jun 2009 00:54:22 +0200
- To: "Jonas Sicking" <jonas@sicking.cc>, "Anne van Kesteren" <annevk@opera.com>
- Cc: "Ian Hickson" <ian@hixie.ch>, public-webapps@w3.org
On Thu, 18 Jun 2009 19:28:48 +0200, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Jun 17, 2009 at 5:49 AM, Anne van Kesteren<annevk@opera.com> > wrote: >> On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile >> <chaals@opera.com> wrote: >>> On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren >>> <annevk@opera.com> >>> wrote: >>>> That definitely makes sense, though please take into consideration >>>> that >>>> for cross-origin loads exposing the file size cannot be done until all >>>> HTTP headers have been received and the requested resource has opted >>>> in >>>> with CORS. >>> >>> OK. One of the things I intended to keep leaving to the "host" spec was >>> definining what the size actually refers to. >> >> I'd think we would like this to consistently refer to the entity body >> for all usage of progress events as to not >> confuse people using the API. It seems odd to take great care in order >> and naming but not in consistent >> implementation of the event objects. > > At the very least we can define that for HTTP request, headers are not > used. For things like WebSocket and FutureAwesomeMegaAlienProtocol it > might make sense to do something different, perhaps. Right. This is ISSUE-4 which was resolved to do it the way the spec does it now (after having it defined in the spec when it was Web API issue 108). While it makes sense to describe what most things do, this seems a case where it might be reasonable to leave it to the spec. Although I am open to defining it (like other stuff) with a default of not counting transaction metadata/overhead, saying that specs can choose to override that specifically if they need to. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Saturday, 20 June 2009 22:55:11 UTC