Re: [hybi] Extensibility mechanisms?

[Jamie Lokier <[e-mail]>]

Roberto Peon wrote:
> 
>    I have some experience with dealing with broken HTTP client
>    implementations in nearly-impossible-to-update devices such as
>    televisions, phones, etc.
> 
>    We're starting from scratch, so hopefully we won't have the confusion
>    of poor implementations that HTTP does, but I'd end up really sad if I
>    had to make my server not use advanced features of a *new* protocol
>    because some clients identify their capabilities wrongly

Unfortunately that kind of breakage is inevitable at some point, if
the protocol is widely adopted with many implementations.

Which is why we should approach any identification and negotiation in
such a way that there's a way out of that trap when it happens.

There are several approaches, and we can learn from what happened with
HTTP what methods actually work.

One way is to encourage widespread use of "user-agent" style strings
which are not meant for negotiation and mostly not used for it (and
therefore there is little incentive to lie in them), but can be used
as an emergency "I don't trust this implementation" get out clause.

When those are used and not abused, they work quite well to deal with
occasionally buggy implementations.  It is important that version
numbers are included.

That said, we see from HTTP that only works if there are other ways to
recognise what people actually want to recognise at the other end so
there is no incentive to parse the user-agent all the time, and no
incentive therefore to lie in it.  HTTP user-agent is now weaker at
this because it seems to have become the de facto way of recognising
characteristics of the device, such as whether it's a mobile and what
type, so there's an incentive to lie.

If a severe WebSocket fault occurs with a widespread, non-updatable
television with a client _or_ server (yes[*]), and it does not display
any identifiable characteristic (not least because the standard
discourages it :-/), the remaining solution to that is to invent a new
capability whose sole purpose is to mean the same as the old one, but
is not used in that widespread, faulty equipment.

Then at least your server can use the advanced feature with newer and
upgradable client implementations, and vice versa.

-- Jamie

[*] Coincidentally as we speak I am developing a server which runs in
a TV and uses comet-style streamed HTTP to both local and remote
(tunnelled) browsers, and may use WebSocket if it proves usable.
Since it's an embedded implementation in C you can bet it probably
will suffer from the issues discussed. :-)