Re: [whatwg] [hybi] 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. Hi, Ian, let me confirm one thing: Empty string is not allowed for subprotocol, is it? Yuzo -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ hybi mailing list h...@ietf.org https://www.ietf.org/mailman/listinfo/hybi
[whatwg] Web Socket Protocol: How Lenient Server Should Be in Handshake?
Hi, As far as I can read from http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54#section-5.2 the server should (or must?) accept requests starting with, say: POSTSPACE/some/resourceSPACEHTTP/1.0 or, even SPACE/some/resourceSPACE Is a server expected to be this lenient? Yuzo
[whatwg] US-ASCII vs. ASCII in Web Socket Protocol
I see both US-ASCII and ASCII are used in: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54 If they mean the same thing, one should be used consistently. In the document, US-ASCII seems to mean encoding while ASCII mean charset. Is this common? (I guess US-ASCII is commonly considered as an alias for ASCII. http://en.wikipedia.org/wiki/ASCII#Aliases ) Yuzo
[whatwg] Web Socket Protocol: Handling of erroneous UTF-8 on the server side?
Hi, Section 4.4 of http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54 specifies how erroneous UTF-8 must be handled on the client side. Does the same apply for the server side? Yuzo
[whatwg] Web Socket Default Ports Confusing?
Hi, as per http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-35 , in web socket handshake, a client omits the port number if it is 80/443 while a server omits it if it is 81/815. Isn't this confusing? I guess the client side behavior mimics HTTP and hence hard to be changed. How about changing the server side behavior such that port number is always explicitly stated regardless of the value? (Behavior is still inconsistent but less confusing, IMHO.) 4. Client-side requirements 4.1. Handshake 6. Send the following bytes: 48 6f 73 74 3a 20 Send the /host/ value, converted to ASCII lowercase, and encoded as US-ASCII. If /secure/ is false, and /port/ is not 80, or if /secure/ is true, and /port/ is not 443, then send an 0x3a byte (:) followed by the value of /port/, expressed as a base-ten integer, encoded as US-ASCII. ... 5. Server-side requirements 5.1. Minimal handshake NOTE: Do not include the port if it is the default port for Web Socket protocol connections of the type in question (81 for unencrypted connections and 815 for encrypted connections). Yuzo
