Re: [hybi] WebSocket subprotocol parameters

Tobias Oberstein <tobias.oberstein@tavendo.de> Mon, 20 January 2014 16:13 UTC

Return-Path: <tobias.oberstein@tavendo.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6501A01BD for <hybi@ietfa.amsl.com>; Mon, 20 Jan 2014 08:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZJCkQGqldTN for <hybi@ietfa.amsl.com>; Mon, 20 Jan 2014 08:13:05 -0800 (PST)
Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id BEFBE1A0162 for <hybi@ietf.org>; Mon, 20 Jan 2014 08:13:04 -0800 (PST)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.11]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 20 Jan 2014 08:13:04 -0800
From: Tobias Oberstein <tobias.oberstein@tavendo.de>
To: Peter Thorson <webmaster@zaphoyd.com>
Date: Mon, 20 Jan 2014 08:13:02 -0800
Thread-Topic: [hybi] WebSocket subprotocol parameters
Thread-Index: Ac8V+AgPnCXQDYtNRqaOl8GOCCVVCAAAe1sg
Message-ID: <634914A010D0B943A035D226786325D4446BF99ACB@EXVMBX020-12.exch020.serverdata.net>
References: <634914A010D0B943A035D226786325D4446BF9948F@EXVMBX020-12.exch020.serverdata.net> <52D90F99.6080205@gmx.de> <634914A010D0B943A035D226786325D4446BF9949D@EXVMBX020-12.exch020.serverdata.net> <CAH9hSJZQ3NxVW36PnZ0TpMF4tPPaJLr12M8NtbPb6pUejf1wcQ@mail.gmail.com> <634914A010D0B943A035D226786325D4446BF99977@EXVMBX020-12.exch020.serverdata.net> <B8ED6F18-B710-44AE-829B-EDE5859B2C5B@zaphoyd.com>
In-Reply-To: <B8ED6F18-B710-44AE-829B-EDE5859B2C5B@zaphoyd.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE, en-US
Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D4446BF99ACBEXVMBX02012ex_"
MIME-Version: 1.0
Cc: Julian Reschke <julian.reschke@gmx.de>, "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] WebSocket subprotocol parameters
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2014 16:13:09 -0000

Take an example:

Client sends:
Sec-WebSocket-Protocol: foo; max_param1=10

Server answers:
Sec-WebSocket-Protocol: foo; max_param1=8

There are 2 problems:

1) ";" is not allowed as a character in subprotocols
2) the client would reject the WS connection anyway since " foo; max_param1=8" does not match _exactly_ (one of the) subprotocols announced: "foo; max_param1=10"

"""
   6.  If the response includes a |Sec-WebSocket-Protocol| header field
       and this header field indicates the use of a subprotocol that was
       not present in the client's handshake (the server has indicated a
       subprotocol not requested by the client), the client MUST _Fail
       the WebSocket Connection_.
"""


Von: Peter Thorson [mailto:webmaster@zaphoyd.com]
Gesendet: Montag, 20. Januar 2014 16:59
An: Tobias Oberstein
Cc: Takeshi Yoshino; Julian Reschke; hybi@ietf.org
Betreff: Re: [hybi] WebSocket subprotocol parameters

My impression was that subprotocol primarily changed the interpretation of messages payloads by the end applications themselves. WebSocket messages allow essentially arbitrary data so you can define whatever parameter setting mechanism you like with whatever grammar makes sense for your subprotocol and send the parameters in the opening "hello" message. Defining a grammar in the socket spec to allow application protocols to configure themselves seems limiting and out of scope.

Extensions on the other hand needed a way to communicate with themselves as defined and thus needed an explicitly provided grammar.

On Jan 20, 2014, at 5:26, Tobias Oberstein <tobias.oberstein@tavendo.de<mailto:tobias.oberstein@tavendo.de>> wrote:


Hi Takeshi,

thanks alot for digging out these posts!

In retrospect, I think it's a pity that we did not specify "qvalue-like" grammer for Sec-WebSocket-Protocol as we did for Sec-WebSocket-Extension.

The latter provides a lot of useful flexibility ... eg as used in "permessage-deflate".

Hacks like having subprotocols like this

wamp.2.json
wamp.2.msgpack
wamp.2.json.batched
wamp.2.msgpack.batched
..

negotiated only works for "discrete value parameters" (json/msgpack, batched/unbatched), but breaks down quite quickly.

As Julian pointed out, making Sec-WebSocket-Protocol using the same "qvalue-grammer" as Sec-WebSocket-Extension
would be a significant change to the RFC6455, and break existing code.

It would also possibly require changes to the WS API in JavaScript to be useful.

Mmh. Too bad;(

/Tobias




Von: Takeshi Yoshino [mailto:tyoshino@google.com]
Gesendet: Montag, 20. Januar 2014 09:36
An: Tobias Oberstein
Cc: Julian Reschke; hybi@ietf.org<mailto:hybi@ietf.org>
Betreff: Re: [hybi] WebSocket subprotocol parameters

On Fri, Jan 17, 2014 at 10:01 PM, Tobias Oberstein <tobias.oberstein@tavendo.de<mailto:tobias.oberstein@tavendo.de>> wrote:
> > Was there any good reason disallowing parameters for "Sec-WebSocket-
> Protocol"?
>
> I think that was discussed and the decision was made on purpose. For details
> you'll have to visit the mailing list archives though.
I can't find it .. searching the Hybi archives is a pain ..

I can't recall such discussion.

In this thread, Brodie used an example similar to that, but the main topic of the post was to update the spec to include multiple subprotocol offer mechanism.
http://www.ietf.org/mail-archive/web/hybi/current/msg04467.html

In this long thread, what character should be used for subprotocol is discussed. Some people preferred more liberal rule, but no one discussed qvalue-like grammar.
http://www.ietf.org/mail-archive/web/hybi/current/msg00913.html

Subprotocol History FYI:

We added the constraint "U+0021 ..  U+007E" from
http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-31 -> 32

Single value -> multiple value (SP-separated)
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-02 -> 03

We made it follow 1#(token | quoted-string) ABNF from
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-03 -> 04

Changed from (token | quoted-string) to token
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07
_______________________________________________
hybi mailing list
hybi@ietf.org<mailto:hybi@ietf.org>
https://www.ietf.org/mailman/listinfo/hybi