code review 5303096: websocket: manage subprotocol negotiation in the websoc...

websocket: manage subprotocol negotiation in the websocket hybi specification

The Hybi-17 websocket specification allows subprotocol negotiation between
client and server (e.g. the "chat" or "superchat" subprotocols).
This change adds a mechanism for server-side choice of a
subprotocol from a set offered by a client. A "simple chooser" can
select from a list of subprotocols or a custom chooser can be used.

[jan.newmarch, 2011-11-03 08:18:58]

Hello golang-dev@googlegroups.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[adg, 2011-11-03 23:15:05]

Why would a user of websocket want to do this?

[adg, 2011-11-03 23:16:10]

Also looping in Ukai who knows this stuff.

[jan.newmarch, 2011-11-04 03:56:58]

It's part of the current websocket spec that isn't implemented. The
idea is that there may be several possible subprotocols that could be
used between a websocket client and server, and this allows a
negotiation mechanism beween them. The examples in the spec are a
"chat" and a "superchat" protocol. I have made an example where the
data format may be negotiated between JSON and XML.

It's been discussed on golang-nuts under "How can a server negotiate a
subprotocol in the new websocket package?". Kyle Lemons was the only
commentator there.

On Fri, Nov 4, 2011 at 10:15 AM,  <adg@golang.org> wrote:
> Why would a user of websocket want to do this?
>
> http://codereview.appspot.com/5303096/
>

[ukai, 2011-11-04 04:04:49]

http://codereview.appspot.com/5303096/diff/5001/src/pkg/websocket/server.go
File src/pkg/websocket/server.go (right):

http://codereview.appspot.com/5303096/diff/5001/src/pkg/websocket/server.go#n...
src/pkg/websocket/server.go:42: 
call protocolChooser here, and get rid of protocolChooser from ReadHandshake?

config.Protocol, err := protocolChooser(c.Protocol)
if err != nil {
      ...
}

Or, it might be better to check websocket.Config is acceptable, so that server
implementation could check origin, extensions or others.

[adg, 2011-11-04 04:08:03]

On 4 November 2011 14:56, Jan Newmarch <jan.newmarch@gmail.com> wrote:
> It's part of the current websocket spec that isn't implemented. The
> idea is that there may be several possible subprotocols that could be
> used between a websocket client and server, and this allows a
> negotiation mechanism beween them. The examples in the spec are a
> "chat" and a "superchat" protocol. I have made an example where the
> data format may be negotiated between JSON and XML.
>
> It's been discussed on golang-nuts under "How can a server negotiate a
> subprotocol in the new websocket package?". Kyle Lemons was the only
> commentator there.

Thanks for the background.

It's too early to say how important subprotocols will be and what their
best practices are, so I'm hesitant to include this. It complicates
what is already a fairly complicated interface.

I'd rather wait until someone has a concrete use for subprotocol
selection before implementing this. It's a challenging but fruitless
game to play catch-up with a spec that changes so frequently.

Does that sound okay to you?

Andrew

[jan.newmarch, 2011-11-04 04:15:31]

That's okay. I'll keep the code lying around and it can go in if a
strong enough use case comes up.

On Fri, Nov 4, 2011 at 3:07 PM, Andrew Gerrand <adg@golang.org> wrote:
> On 4 November 2011 14:56, Jan Newmarch <jan.newmarch@gmail.com> wrote:
>> It's part of the current websocket spec that isn't implemented. The
>> idea is that there may be several possible subprotocols that could be
>> used between a websocket client and server, and this allows a
>> negotiation mechanism beween them. The examples in the spec are a
>> "chat" and a "superchat" protocol. I have made an example where the
>> data format may be negotiated between JSON and XML.
>>
>> It's been discussed on golang-nuts under "How can a server negotiate a
>> subprotocol in the new websocket package?". Kyle Lemons was the only
>> commentator there.
>
> Thanks for the background.
>
> It's too early to say how important subprotocols will be and what their
> best practices are, so I'm hesitant to include this. It complicates
> what is already a fairly complicated interface.
>
> I'd rather wait until someone has a concrete use for subprotocol
> selection before implementing this. It's a challenging but fruitless
> game to play catch-up with a spec that changes so frequently.
>
> Does that sound okay to you?
>
> Andrew
>