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

[Philipp Serafin <[e-mail]>]

I may be wrong, but this looks like a feature that would be really cheap
to specify and implement now (even if we don't know if it'll actually be
of much use) but very hard later when we'd have to take lots and lots of
back-compat issues into consideration.

I'd just hate to see subprotocols go the way of the HTTP Accept header,
which is practically unuseable in the browser world today, even though
it would solve some real-world problems. (As shown by the &type=... URL
params in many APIs)

Am 31.08.2011 21:26, schrieb John Tamplin:
> On Wed, Aug 31, 2011 at 3:21 PM, Iñaki Baz Castillo <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     2011/8/31 Philipp Serafin <[e-mail]
>     <mailto:[e-mail]>>:
>     > If a client sends a protocol header, I don't see why it can't
>     indicate ALL
>     > protocols it supports for this connection. If the server
>     supports none of
>     > those protocols, and if neither client nor server are part of a
>     single web
>     > application (so there is no implicit custom protocol they could both
>     > understand), I don't see how a sucessful connection could be
>     established.
>
>     Of course. Say the opposite means allowing ugly/annoying pseudo
>     negotiations.
>
>
> Personally, I see little value at this point for subprotocols.  They
> basically represent an agreement between the application end points
> for a protocol to run on top of WS.  Since the app developer owns both
> endpoints, they can already use whatever protocol they like.  It is a
> convenient place to send selection between multiple protocols
> out-of-band, but no more.
>
> Maybe in the future there are standard subprotocols, and you could
> have some off-the-shelf product to offload those subprotocols, but
> initially there seems to be little value so I don' t think we need to
> go overboard imagining things that would be useful with only limited
> experience with WS itself. 
>
> -- 
> John A. Tamplin
> Software Engineer (GWT), Google