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

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.

On the other hand, we may have standardized, "external", WS-based APIs,
the same way e.g. SOAP and OAUTH can be layered on top of HTTP today.
Here, clients and servers from different parties will have to speak with
each other, some of which might not even run in a browser or might
otherwise be hard to update. Here, standardized subprotocols and the
negotiation mechanism will be of much use.

However, I don't see much overlap in those two use-cases right now. I
don't see many cases where a server that doesn't support a certain
standardized protocols could reasonably fall back to a proprietary
default protocol. This also makes the subprotocol header less useful
IMO, since it implies that the client doesn't actually lists all
protocols it supports in the header - it might or might not also support
an unnamed, proprietary protocol.

Why can't we take the presence of a subprotocol header in the client
request as a hint that the client wants to speak a "standard" protocol?
Then it would be reasoneable for the server to reject the connection if
none of those standard protocols are supported.
However, if the client sends no protocol header, then the server can
still accept the connection and speak an unnamed, proprietary protocol.

Am 30.08.2011 17:42, schrieb Alexey Melnikov:
> John Tamplin wrote:
>
>> On Tue, Aug 30, 2011 at 7:29 AM, Iñaki Baz Castillo <ibc@aliax.net
>> <mailto:ibc@aliax.net>> wrote:
>>
>>     2011/8/30 Alexey Melnikov <alexey.melnikov@isode.com
>>     <mailto:alexey.melnikov@isode.com>>:
>>     > If the client really expected the extensions to be mandatory, it
>>     has to send
>>     > Close.
>>
>>     A new close status code just to say "the WS protocol negotiation has
>>     obviously failed so I close the connection"?
>>
>>
>> We don't need a separate close code for every possible reason --
>> there will be too many, and we will certainly miss many ones that
>> would actually be used.  Instead, we need more generic error codes
>> describing categories of failures.
>
> I think we need both. More specific error codes are better, if
> introduced early.
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi