This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec has this text at the beginning of the text defining constructor's behavior. > The connection will only be established if the server reports that it has selected one of these subprotocols. Though this may be intended to explain the role of the protocols argument briefly and non-normatively, we interpreted that this text adds a requirement that a WebSocket client MUST abort connection establishment if the peer server doesn't select any subprotocol offered by the client. It should correspond to null response to Sec-WebSocket-Protocol which is indicated by not including Sec-WebSocket-Protocol header as defined in RFC 6455. RFC 6455 itself doesn't require a client to abort connection establishment. Let's use explicit language here to make it clear how to deal with this case. I suggest that we remove this sentence and instead add this text to the end of step 8. "When <i>protocols</i> is non-empty and the <i>subprotocol in use</i> returned by the server is null value, the user agent must <i>fail the WebSocket connection</i>." ---- RFC 6455 is incomplete about subprotocol validation. It specifies the WebSocket protocol layer to fail on the following cases: 1) no subprotocol in req && subprotocol in res 2) subprotocol(s) in req && subprotocol in res but doesn't match any of ones in req but not for 3) subprotocol(s) in req && not subprotocol in res Thinking of the purpose of subprotocol, 3) should also be considered to be a response that should result in giving up establishment of a WebSocket connection. So, I think the clarification I proposed above should make sense.
(In reply to Takeshi Yoshino from comment #0) > > > The connection will only be established if the server reports that it has > > selected one of these subprotocols. > > Though this may be intended to explain the role of the protocols argument > briefly and non-normatively, we interpreted that this text adds a > requirement that a WebSocket client MUST abort connection establishment if > the peer server doesn't select any subprotocol offered by the client. You interpreted this text incorrectly; it's non-normative. You can tell because it doesn't contain any normative statements — in particular, the word "must" isn't there. > RFC 6455 itself doesn't require a client to abort connection establishment. Wow, yeah. Huh. Looks like they broke that. I've added normative text to the HTML spec to fix it. > RFC 6455 is incomplete about subprotocol validation. It specifies the > WebSocket protocol layer to fail on the following cases: [...] Yeah, looks like they broke it between when I edited the spec and when it became an RFC. Going to the IETF was such a mistake. Thanks for catching this.
Checked in as WHATWG revision r8232. Check-in comment: Make sure WebSocket connections that can't honour the subprotocol don't get established (looks like this got broken in the protocol spec at some point) http://html5.org/tools/web-apps-tracker?from=8231&to=8232