13777 2011-08-15 08:27:06 +0000 The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined 2011-09-19 22:34:13 +0000 1 1 1 Unclassified WebAppsWG WebSocket API (editor: Ian Hickson) unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#top P3 critical --- 1 contributor ian art.barstow brian.raymor ian jonas julian.reschke mike public-webapps public-webapps-bugzilla oldest_to_newest 55056 0 contributor 2011-08-15 08:27:06 +0000 Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as follows: The elements that comprise this value MUST be non- empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616], and MUST all be unique strings." Current WebSocket API does not fully enforce the above limitations. I think API should be in line with the protocol spec on limitation of subprotocols. This affects the following snippets of text from WS API: "The subprotocol names must all be non-empty ASCII strings with no control characters and no spaces in them (i.e. only characters in the range U+0021 to U+007E)." This statement should mention: - Subprotocol names must not contain separator characters. - Each subprotocol name must be unique. "If any of the values in protocols occur more than once or contain characters with Unicode code points less than U+0021 or greater than U+007E (i.e. the space character or any characters that are not printable ASCII characters), then throw a SYNTAX_ERR exception and abort these steps." This statement should mention: - Any of subprotocol names must not be empty. - Subprotocol names must not contain separator characters. - SYNTAX_ERR must be thrown in these cases. Posted from: 2401:fa00:4:1000:baac:6fff:fe99:adfb User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/15.0.849.0 Safari/535.1 56022 1 brian.raymor 2011-08-30 03:46:05 +0000 I agree with this approach. It aligns subprotocol validation in the W3C API with the IETF draft which is fine. 56574 2 ian 2011-09-09 22:13:14 +0000 What are the limitations in the protocol for? 56577 3 jonas 2011-09-10 01:20:03 +0000 I agree with comment 0. First off the protocol is what it is and unless changed we simply can't honor a protocol request outside the character range. So we'll provide better debugging information by throwing. Second, allowing non-ascii characters here increases the risk of security problems if for example servers drop the high-byte in a decoded protocol. This is something that is happening in URLs today for example. 56585 4 ian 2011-09-10 04:23:46 +0000 There's no question the API has to only pass valid values to the API, I'm just curious what the reasoning was in disallowing more than just non-ASCII. 56774 5 ian 2011-09-14 18:17:03 +0000 BTW, what are the "separator characters as defined in [RFC2616]"? Does it mean this <separators> terminal in the ABNF? separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT 56775 6 ian 2011-09-14 18:17:38 +0000 (if so, that makes it illegal to use a URL as an extension token; is that really intentional?) 57006 7 ian 2011-09-19 22:33:53 +0000 I just referenced the WebSocket protocol. 57007 8 contributor 2011-09-19 22:34:13 +0000 Checked in as WHATWG revision r6555. Check-in comment: Align with WSP on the subprotocol syntax. http://html5.org/tools/web-apps-tracker?from=6554&to=6555