- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 22 Jun 2009 08:24:06 +0200
- To: "Charles McCathieNevile" <chaals@opera.com>, "Jonas Sicking" <jonas@sicking.cc>
- Cc: "Ian Hickson" <ian@hixie.ch>, public-webapps@w3.org
On Sun, 21 Jun 2009 00:54:22 +0200, Charles McCathieNevile <chaals@opera.com> wrote: > On Thu, 18 Jun 2009 19:28:48 +0200, Jonas Sicking <jonas@sicking.cc> > wrote: >> 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. Agreed. It's not clear to me you'd always want to use the same object though. E.g. for the simple case of Web Sockets no length is known and therefore it might be more interesting to get information about how many characters have been received so far rather than bytes. Though maybe this is too much complexity for little benefit. > 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. Maybe just define a concept e.g. "message length" and for HTTP you define it to be the entity body of the request/response and for other protocols you leave it until when we get there. -- Anne van Kesteren http://annevankesteren.nl/
Received on Monday, 22 June 2009 06:24:54 UTC