Re: [whatwg] WebSocket bufferedAmount includes overhead or not.
On Thu, Mar 4, 2010 at 18:52, Olli Pettay olli.pet...@helsinki.fi wrote: On 3/4/10 4:42 AM, Fumitoshi Ukai (鵜飼文敏) wrote: Hi, I noticed that WebSocket spec updated to not inlcude framing overhead in bufferedAmount. I asked that since from API point of view it doesn't make much sense to have the frame bytes to be magically included in the bufferedAmount. What if we change the protocol and require different amount framing bytes? Also why to have framing bytes and not the bytes related to http handling? I think bufferedAmount is a number of bytes are buffered to be sent on wire, so including frame byte is reasonable. Also, XHR+progress events don't include http headers etc in the .loaded or .total. http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html I tried to implement it in WebKit, but found it make hard to implement correctly. Not hard at all in gecko's implementation (the patch is still waiting for a review and will be possibly updated to include the latest changes to the protocol before pushing to hg repo). I just look over https://bugzilla.mozilla.org/show_bug.cgi?id=472529 It looks just updating bufferedAmount once a whole message has been sent, isn't it? But I think user of the API might want to know progress while partial transfer of large messsage, so this implementation isn't so happy, IMO. Anyway, if this level of feedback is ok, it would be better to have onsent event listener to fire after each message has been sent. Then, we don't need to poll bufferedAmount as do in example in WebSocket API draft. What do you think? -- ukai https://bugs.webkit.org/show_bug.cgi?id=35571 It's easy after WebSocket is closed (just add length of message), right but while it's open, we'll manage buffer including frame bytes In the patch for gecko there is a different buffer for each message, so it is easy to count how many frame bytes are in the buffers. and underlying socket will write arbitrary length of the buffer (may not be on frame boundary) To get bufferdAmount correctly without framing overhead, we need to parse the buffer again. It's not light operation and it's challenge to make it effective. I think including frame overhead is much easier. Could you revert it? That would make the API worse, especially for web developers, IMO. They shouldn't need to know about the protocol, they should just be able to use the API and understand easily what bufferedAmount means. br, -Olli -- Fumitoshi Ukai
[whatwg] WebSocket bufferedAmount includes overhead or not.
Hi, I noticed that WebSocket spec updated to not inlcude framing overhead in bufferedAmount. http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html I tried to implement it in WebKit, but found it make hard to implement correctly. https://bugs.webkit.org/show_bug.cgi?id=35571 It's easy after WebSocket is closed (just add length of message), but while it's open, we'll manage buffer including frame bytes and underlying socket will write arbitrary length of the buffer (may not be on frame boundary) To get bufferdAmount correctly without framing overhead, we need to parse the buffer again. It's not light operation and it's challenge to make it effective. I think including frame overhead is much easier. Could you revert it? -- Fumitoshi Ukai
[whatwg] HttpOnly cookie for WebSocket?
May/Should WebSocket use HttpOnly cookie while Handshaking? I think it would be useful to use HttpOnly cookie on WebSocket so that we could authenticate the WebSocket connection by the auth token cookie which might be HttpOnly for security reason. http://www.ietf.org/id/draft-ietf-httpstate-cookie-02.txt -- ukai
Re: [whatwg] WebSocket sub protocol name.
On Tue, Dec 8, 2009 at 4:59 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 8 Dec 2009, Fumitoshi Ukai (榈~\椋兼~V~G鎫U~O) wrote: protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ? (e.g. new WebSocket(ws://example.com/, ); ) It seems space is optional after colon in field of handshake message, how can we distinguish U+0020 and U+0020 U+0020 ? The space isn't optional (both the client and the server are required to send it before the subprotocol name), it's just that the client will handle a missing space gracefully. Maybe we should remove that feature, and require that the space be present, closing the connection otherwise? I don't feel strongly either way. Anyway, the point is that WebSocket-Protocol: is the empty string, and WebSocket-Protocol: is a one-space protocol name. Thanks for clarifying this. -- ukai -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebSocket sub protocol name.
On Mon, Dec 7, 2009 at 5:05 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Dec 2009, Fumitoshi Ukai (榈~\椋兼~V~G鎫U~O) wrote: Control characters are allowed (though using them would be silly). Why are control characters (except LF and CR) allowed? There doesn't seem to be a good reason to exclude them, and excluding them would lead to a more complicated processing model. In HTTP, field-content is TEXT or combinations of token, separators, and quoted-string. TEXT, or token, separators excludes CTLs. So, we must use quoted-string in WebSocket-Protocol: if protocol contains CTLs? Oh, I forgot that HTTP had the no-CTL restriction. Good point. I've updated the spec to be consistent with this. In The Web Sockets API, could you fix the following statement? The second, protocol, if present, specifies a sub-protocol that the server must support for the connection to be successful. The sub-protocol name must be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters in it. IIRC, in old spec draft, protocol should not be an empty string, but current spec draft accepts it? And, why is it limited to ASCII instead of UTF-8? Because the HTTP working group refuse to allow UTF-8 in HTTP headers for reasons that I don't really understand, and the handshake is supposed to be valid HTTP. Hmm, then it should be mentioned in The Web Socket protocol 1.2 Protocol overview? It looks websocket message accept UTF-8 in handshake message. -- ukai On Mon, 7 Dec 2009, Julian Reschke wrote: There isn't a good reason to disallow control characters in a *name* Not as far as I can tell, no... what would a good reason be? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] WebSocket sub protocol name.
On Mon, Dec 7, 2009 at 7:25 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Dec 2009, Fumitoshi Ukai (�µ~\飼æ~V~Gæ~U~O) wrote: On Mon, Dec 7, 2009 at 5:05 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Dec 2009, Fumitoshi Ukai (榈~\椋兼~V~G鎫U~O) wrote: Control characters are allowed (though using them would be silly). Why are control characters (except LF and CR) allowed? There doesn't seem to be a good reason to exclude them, and excluding them would lead to a more complicated processing model. In HTTP, field-content is TEXT or combinations of token, separators, and quoted-string. TEXT, or token, separators excludes CTLs. So, we must use quoted-string in WebSocket-Protocol: if protocol contains CTLs? Oh, I forgot that HTTP had the no-CTL restriction. Good point. I've updated the spec to be consistent with this. In The Web Sockets API, could you fix the following statement? The second, protocol, if present, specifies a sub-protocol that the server must support for the connection to be successful. The sub-protocol name must be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters in it. Fixed, thanks. IIRC, in old spec draft, protocol should not be an empty string, but current spec draft accepts it? Man, I'm just incompetent today. Sorry about that. Fixed. Thanks! protocol now accepts U+0020. Is it ok to use U+0020 only in /protocol/ ? (e.g. new WebSocket(ws://example.com/, ); ) It seems space is optional after colon in field of handshake message, how can we distinguish U+0020 and U+0020 U+0020 ? And, why is it limited to ASCII instead of UTF-8? Because the HTTP working group refuse to allow UTF-8 in HTTP headers for reasons that I don't really understand, and the handshake is supposed to be valid HTTP. Hmm, then it should be mentioned in The Web Socket protocol 1.2 Protocol overview? It looks websocket message accept UTF-8 in handshake message. There should be no way to _send_ UTF-8 in the handshake at this point, given the requirements in the spec, but once you _receive_ the handshake, it's no longer HTTP, it's just WebSocket, so you can use UTF-8 fine. (In practice it doesn't mean much, since there's nothing in the server-to-client handshake other than the client-to-server handshake, so if there ever was UTF-8 in the server-to-client handshake, it would either be ignored, or the connection would be dropped, depending on where exactly the UTF-8 was found.) Ok. I see. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Sockets URL
On Fri, Dec 4, 2009 at 8:38 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Dec 2009, Fumitoshi Ukai (榈~\椋兼~V~G鎫U~O) wrote: On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 2 Dec 2009, Alexey Proskuryakov wrote: Currently, the Web Sockets API spec says that the WebSocket.URL attribute must just return a value that was passed to the WebSocket constructor. This doesn't match how many other url accessors work, and consequentially, it doesn't match what currently happens in WebKit. I think it makes more sense to return a resolved URL - e.g. (new WebSocket(ws://host/path/../)).URL would return ws://host/. I've changed the spec to say that the .URL attribute must return the same string as is actually used by the protocol spec (i.e. post-resolve). Whether this does ../ resolution will depend on what the IRI specs end up saying when we switch to relying on those. Should (new WebSocket(ws://host/path#frag)).URL be ws://host/path rather than ws://host/path#frag ? It seems Resolving Web addresses will drop fragment component according to http://www.w3.org/html/wg/href/draft.html, but I'd like to confirm it. I hadn't considered #fragment components. I've changed the spec to say that the constructor will throw an exception if one is present. ws: and wss: URLs can't have fragment identifiers in this version of the protocol. Ok. I'll fix WebKit to follow the spec. Thanks! -- ukai -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] WebSocket sub protocol name.
Hi, At 1.130 of The Web Socket API, it adds the sub-protocol name must be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters in it. But The Web Socket protocol 3.1 Parsing Web Socket URLs, says 1. If /protocol/ is specified but is either the empty string or contains characters that are not in the range U+0021 to U+007E, then fail this algorithm. Alghough I think it should not be a part of Parsing Web Socket URLs, but the /protocol/ here is talking about sub-protocol name in Web Socket constructor, right? I'm wondering why The Web Socket API has loose definition about sub-protocol name. If sub-protocol name contains a character less than U+0021, it fails and throw a SYNTAX_ERR exception ? -- ukai
Re: [whatwg] [hybi] WebSocket sub protocol name.
On Mon, Dec 7, 2009 at 3:21 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Dec 2009, Fumitoshi Ukai (榈~\椋兼~V~G鎫U~O) wrote: At 1.130 of The Web Socket API, it adds the sub-protocol name must be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters in it. But The Web Socket protocol 3.1 Parsing Web Socket URLs, says 1. If /protocol/ is specified but is either the empty string or contains characters that are not in the range U+0021 to U+007E, then fail this algorithm. Woops, that step is a copy-and-paste mistake from a past version. My apologies. I've removed that sentence; it should not have been present. Thanks for fixing. Control characters are allowed (though using them would be silly). Why are control characters (except LF and CR) allowed? -- ukai -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [hybi] WebSocket sub protocol name.
On Mon, Dec 7, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Dec 2009, Fumitoshi Ukai (�µ~\飼æ~V~Gæ~U~O) wrote: On Mon, Dec 7, 2009 at 3:21 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 7 Dec 2009, Fumitoshi Ukai (榈~\椋兼~V~G鎫U~O) wrote: At 1.130 of The Web Socket API, it adds the sub-protocol name must be an ASCII string with no U+000A LINE FEED (LF) or U+000D CARRIAGE RETURN (CR) characters in it. But The Web Socket protocol 3.1 Parsing Web Socket URLs, says 1. If /protocol/ is specified but is either the empty string or contains characters that are not in the range U+0021 to U+007E, then fail this algorithm. Woops, that step is a copy-and-paste mistake from a past version. My apologies. I've removed that sentence; it should not have been present. Thanks for fixing. Control characters are allowed (though using them would be silly). Why are control characters (except LF and CR) allowed? There doesn't seem to be a good reason to exclude them, and excluding them would lead to a more complicated processing model. In HTTP, field-content is TEXT or combinations of token, separators, and quoted-string. TEXT, or token, separators excludes CTLs. So, we must use quoted-string in WebSocket-Protocol: if protocol contains CTLs? And, why is it limited to ASCII instead of UTF-8? -- ukai -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Sockets URL
On Fri, Dec 4, 2009 at 10:55 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 2 Dec 2009, Alexey Proskuryakov wrote: Currently, the Web Sockets API spec says that the WebSocket.URL attribute must just return a value that was passed to the WebSocket constructor. This doesn't match how many other url accessors work, and consequentially, it doesn't match what currently happens in WebKit. I think it makes more sense to return a resolved URL - e.g. (new WebSocket(ws://host/path/../)).URL would return ws://host/. I've changed the spec to say that the .URL attribute must return the same string as is actually used by the protocol spec (i.e. post-resolve). Whether this does ../ resolution will depend on what the IRI specs end up saying when we switch to relying on those. Should (new WebSocket(ws://host/path#frag)).URL be ws://host/path rather than ws://host/path#frag ? It seems Resolving Web addresses will drop fragment component according to http://www.w3.org/html/wg/href/draft.html, but I'd like to confirm it. -- ukai -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Thread to run Web Socket feedback from the protocol ?
I've question about thread to run Web Socket feedback from the protocol. If server sends back handshake response and a data frame, and close immediately, fast enough to run JavaScript on browser, how readyState should be? 1) When client recognizes handshake response header, it changes readyState to OPEN and queue a task to fire a simple event named open. 2) Then client reads a data frame, and queue a task to fire a MessageEvent. 3) Then client recognizes the socket is closed, it changes readyState to CLOSED and queue a task to fire a simple event named close. I'm wondering this process should be done on the same thread of the JavaScript, or may be on the different thread. If it should run on the same thread, 1) would be processed after JavaScript code is processed. Thus, readyState is OPEN when it receives open event. However, if it may run on the different thread, 1)-3) might be processed before JavaScript code is processed. So, readyState might be CLOSED when it receives open event. Which is correct behavior? It seems WebKit/Mac does former, and Chromium does latter, so LayoutTests/websocket/tests/simple.html would fail with Chromium. -- ukai
Re: [whatwg] [hybi] Races in websocket API?
On Thu, Nov 19, 2009 at 1:00 PM, Greg Wilkins gr...@webtide.com wrote: Is there a race in the websocket API. When you do: var ws = new WebSocket(ws://mysite.com,myprotocol); then the spec says: Return a new WebSocket object, and continue these steps in the background (without blocking scripts). Establish a Web Socket connection to a host host, on port port (if one was specified), from origin, with the flag secure, with resource name as the resource name, and with protocol as the protocol (if it is present). So if the next line in the script is ws.onopen=myopenfunc; there is a race between if the onopen function will be assigned and if the background connection has been established? I believe open event is just queued at the moment, and it will be fired later when javascript becomes idle. When the Web Socket connection is established, the user agent must run the following steps: Change the readyState attribute's value to OPEN (1). Queue a task to fire a simple event named open at the WebSocket object. -- ukai OK it is currently unlikely that the connect will happen that quick - however if I'm running in a rhino test environment or a on a browser that is multiplexing the websocket onto an already existing connection, then the onopen may indeed be fast. Similar races exist for onmessage and onclose. Setting onmessage might miss a message that is delivered quickly after the websocket is opened. regards ___ hybi mailing list h...@ietf.org https://www.ietf.org/mailman/listinfo/hybi
