Re: [hybi] WebSocket subprotocol parameters

Takeshi Yoshino <tyoshino@google.com> Thu, 23 January 2014 04:50 UTC

MIME-Version: 1.0
In-Reply-To: <634914A010D0B943A035D226786325D4446C082A0D@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> <52DE3B1B.1010804@it.aoyama.ac.jp> <634914A010D0B943A035D226786325D4446C082A0D@EXVMBX020-12.exch020.serverdata.net>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 23 Jan 2014 13:49:51 +0900
Message-ID: <CAH9hSJZwf4ZuOnOwt7k+YjqCd5zxYYWXdp=krPjZKE+Tq=9LXw@mail.gmail.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary="047d7bfcfc82fefe7304f09bf94e"
Cc: Julian Reschke <julian.reschke@gmx.de>, "hybi@ietf.org" <hybi@ietf.org>, Peter Thorson <webmaster@zaphoyd.com>
Subject: Re: [hybi] WebSocket subprotocol parameters
Precedence: list

On Tue, Jan 21, 2014 at 7:12 PM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> > > 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.
> >
> > Yes indeed. It has always been my impression that even subprotocols
> > themselves are rather unnecessary. On the server side, just use a
> different
> > URI/IRI as endpoint. On the client side, it's all JS anyway.
>
> No quite, since using a different URL does not allow the server to
> communicate back
> it's subprotocol selection, e.g.
>
>
The server can immediately send back a frame following the opening
handshake response. So, there's not much difference between subprotocol
selection reply in form of opening handshake and in form of the first
message. No additional RTT.


> Sec-WebSocket-Protocol: foo.msgpack, foo.json
>
> allows the client to announce the "foo" protocol in 2 variants (MsgPack
> and JSON serialization)
> and the server to _select_ one of those, and communicate back it's
> selection to the client.
>
> An URL
>
> ws://server.com?serializers=msgpack;json
>
> does not allow the server to communicate back it's selection.
>

So, you'll define a thin extension layer to your application level protocol
which uses the URI and the first message from the server to negotiate
subprotocol parameter.


>
> Further, as an example, imagine a subprotocol that allows message batching
> with length prefixes, that wants to negotiate the number of bytes used for
> the length prefix.
>
> Sec-WebSocket-Protocol: foo; max_len_prefix=4
>
> A server that wants to use "len_prefix=3" cannot communicate that -
> neither with URL (since there is no "URL response"), and not with
> Sec-WebSocket-Protocol,
> since the server _must_ choose one subprotocol announced by the client
> _exactly_.
>
> It cannot answer
>
> Sec-WebSocket-Protocol: foo; len_prefix=3
>
> Since the number of bytes per length prefix in batched messages is needed
> to _parse_ already the first WebSocket message at application level,
> negotiating at the WS application message level does not work either (or
> gets complicated).
>

I understand it'll be simpler if we could complete that with in subprotocol
negotiation framework. But does it really get so complicated if we do that
using URI and bootstrap message? The client just need to pass one phase
where it parses len_prefix from the server and then transit to real app
mode where len_prefix will be used.

I don't object to raising a request to relax subprotocol constraint from
the next version. But I think it doesn't make much difference technically.

[hybi] WebSocket subprotocol parameters Tobias Oberstein
Re: [hybi] WebSocket subprotocol parameters Julian Reschke
Re: [hybi] WebSocket subprotocol parameters Tobias Oberstein
Re: [hybi] WebSocket subprotocol parameters Bjoern Hoehrmann
Re: [hybi] WebSocket subprotocol parameters Takeshi Yoshino
Re: [hybi] WebSocket subprotocol parameters Tobias Oberstein
Re: [hybi] WebSocket subprotocol parameters Peter Thorson
Re: [hybi] WebSocket subprotocol parameters Tobias Oberstein
Re: [hybi] WebSocket subprotocol parameters Peter Thorson
Re: [hybi] WebSocket subprotocol parameters Tobias Oberstein
Re: [hybi] WebSocket subprotocol parameters Takeshi Yoshino
Re: [hybi] WebSocket subprotocol parameters Martin J. Dürst
Re: [hybi] WebSocket subprotocol parameters Tobias Oberstein
Re: [hybi] WebSocket subprotocol parameters Takeshi Yoshino