[Bug 23576] New: Clarify what to do when received null value subprotocol in reply to non-empty subprotocol

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23576

            Bug ID: 23576
           Summary: Clarify what to do when received null value
                    subprotocol in reply to non-empty subprotocol
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebSocket API (editor: Ian Hickson)
          Assignee: ian@hixie.ch
          Reporter: tyoshino@google.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, public-webapps@w3.org

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 21 October 2013 07:19:09 UTC