Re: [hybi] Client offers invalid WS protocols, what must the server do? 101???

[Bruce Atherton <[e-mail]>]

On 31/08/2011 9:18 AM, Philipp Serafin wrote:
> I agree with Inaki that an error code for unsupported subprotocols would
> be useful. But I think it would be cleaner if the server would send it
> right as part of the handshake instead of the client.
>
> So far it looks to me as if WS connections that make use of sub
> protocols serve completely different use cases than those that don't.
>
> On the one hand, we have proprietary, "internal" endpoints that will
> solely be implementation details of a web application. The actual
> protocol used on top of WS will be tailor-made to that specific
> web-application and may change any time without notice. In fact, the
> application might even switch to a completely different technology than
> WS any time. Both WS client and server will be controlled by the same
> developers.
> As defining a formal subprotocol in such a case doesn't make much sense,
> the protocol header will likely not be used.

I think your analysis is mixing a few concerns. To me, there are two 
questions to answer when considering this issue: Is the subprotocol 
custom or standard? Is it running on an application-specific endpoint or 
a standard browser/server?

When both the subprotocol and the endpoints are custom, there are still 
benefits to using the subprotocol field. It allows versioning, for 
example. It also allows you to limit the subprotocols used at the 
endpoints so you can support things like pricing based on subprotocols 
deployed to a particular customer.

When the subprotocol is custom and the endpoints are standard, then a 
subprotocol layers on top of the default subprotocol. This may be useful 
if, for example, you want to deploy a vendor's widget that uses 
Websockets to your page. It allows your server to implement the specific 
protocol for talking to the widget. And consider if you had multiple 
widgets each from a different vendor on the same page. I would think 
that browsers will deal with an attempt to open multiple connections to 
the same URL with different subprotocols by MUXing them. I could be 
wrong about that, but it would provide a nice mechanism for dealing with 
the multiple vendor problem.

When the subprotocol is standard and one of the endpoints is custom, 
there is still a benefit to specifying a subprotocol as it enhances the 
chances of interoperability with other implementations.

When both the subprotocol and the endpoints are standard, right now it 
is the same as when the subprotocol is custom. But in the future, 
browsers and servers may provide architectures for extending the 
subprotocols they support. Imagine tunneling SIP and RTP over Websockets 
so that everyone visiting a particular web page was given the option of 
joining a conference call. That may be a useful enough feature that 
eventually browsers actually include support for the SIP and RTP 
subprotocols natively.

Regarding the server sending the error code, that would eliminate the 
ability for a client to fall back to the raw binary/text subprotocol if 
the server doesn't support any of the specific subprotocols. I don't 
think that is a good idea.