Re: [hybi] Adding clarification regarding future revisions (Was: Proposed way forward for WebSockets)

[Willy Tarreau <[e-mail]>]

Hi Ian,

On Tue, Jul 27, 2010 at 07:13:58AM +0000, Ian Hickson wrote:
> On Tue, 27 Jul 2010, Willy Tarreau wrote:
> > On Tue, Jul 27, 2010 at 02:40:40AM -0400, John Tamplin wrote:
> > > On Tue, Jul 27, 2010 at 2:13 AM, Anne van Kesteren <[e-mail]> 
> > > wrote:
> > > >
> > > > Feature negotiation is there, by means of new headers.
> > > 
> > > If that is the intention, it would be good to state that in the 
> > > protocol [...]
> > 
> > Yes indeed, that should be clarified.
> 
> I've added another sentence to the end of the "Design philosophy" section 
> to try to explain this in slightly more detail. I don't really know how 
> better to clarify it, though. Could you elaborate on exactly what is 
> unclear?

I can't find there the requirement to reject handshakes featuring
unknown headers, nor can I find it in -76, though I'm sure I've read
it not long ago, so probably that it was in a slightly earlier version.

Your wording in the Design Philosophy section looks fine an unambiguous
to me.

> > And BTW, saying "Upgrade: WebSocket/1.0" would be *a lot* better than 
> > "Upgrade: WebSocket".
> 
> Not having a version field is intentional. Versioning is an anti-pattern 
> on the Web.

I don't understand what you mean by "anti-pattern". Right now for
instance it's fortunate that we have the distinction between HTTP/1.0
and 1.1 since their semantics have changed (connection: close vs
keep-alive, support for transfer-encoding, etc...).

Without a version advertised in the request, the server won't know
whether the client is supposed to support feature XXX or YYY that
is only part of an evolution.

Regards,
Willy