This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13777 - 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
Summary: The WebSocket protocol draft (hybi-10) restricts the value of subprotocols as...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebSocket API (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 critical
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-15 08:27 UTC by contributor
Modified: 2011-09-19 22:34 UTC (History)
7 users (show)

See Also:


Attachments

Description contributor 2011-08-15 08:27:06 UTC
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
Comment 1 Brian Raymor [MSFT] 2011-08-30 03:46:05 UTC
I agree with this approach. It aligns subprotocol validation in the W3C API with the IETF draft which is fine.
Comment 2 Ian 'Hixie' Hickson 2011-09-09 22:13:14 UTC
What are the limitations in the protocol for?
Comment 3 Jonas Sicking (Not reading bugmail) 2011-09-10 01:20:03 UTC
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.
Comment 4 Ian 'Hixie' Hickson 2011-09-10 04:23:46 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2011-09-14 18:17:03 UTC
BTW, what are the "separator characters as defined in [RFC2616]"? Does it mean this <separators> terminal in the ABNF?

       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT
Comment 6 Ian 'Hixie' Hickson 2011-09-14 18:17:38 UTC
(if so, that makes it illegal to use a URL as an extension token; is that really intentional?)
Comment 7 Ian 'Hixie' Hickson 2011-09-19 22:33:53 UTC
I just referenced the WebSocket protocol.
Comment 8 contributor 2011-09-19 22:34:13 UTC
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