Subject: [hybi] WebSocket -76 implementation in Opera

From: Adam Barth <[email-masked]>
Date: Mon, 11 Oct 2010 17:11:46 -0700

I thought the members of this working group might be interested in
reading this blog post:

http://annevankesteren.nl/2010/10/websocket-protocol

Adam

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 12 Oct 2010 07:22:43 +0200

> http://annevankesteren.nl/2010/10/websocket-protocol

Interesting. That's why I thought it would be useful (but dangerous)
to at least fix the server-side description in the spec. It will then
suddenly make those implementations interoperable without changing
the client side. The downside is that it may also put an end to the
efforts in improving the handshake.

Willy

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 12 Oct 2010 17:30:13 +1100

> http://annevankesteren.nl/2010/10/websocket-protocol
IETF draft 01 has been out for over a month now with the new framing, so
have any of the browser vendors implemented it  - at least in development
versions?

The recent release candidate of Jetty 7.2.0.RC0 should be able to handle
clients using -75,-76,-00, -01 & -02    but hard to be sure without any
client to try against.

regards

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Oct 2010 11:44:55 +0200

> http://annevankesteren.nl/2010/10/websocket-protocol

And the followup 
<http://www.0xdeadbeef.com/weblog/2010/10/websockets-shipping-before-its-ready/>...

I think it would be great if those who already ship experimental support 
(Safari, Chrome) and those who plan to (Opera, Firefox) collaborated on 
a plan to do this properly.

Best regards, Julian

---

From: James Graham <[email-masked]>
Date: Tue, 12 Oct 2010 11:52:01 +0200

On 10/12/2010 08:30 AM, Greg Wilkins wrote:
>
> On 12 October 2010 11:11, Adam Barth <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> have any of the browser vendors implemented it  - at least in
> development versions?

Not to my knowledge. It is not hard to see why, however; when all ones 
competitors are shipping supposedly unstable version A of the protocol 
there is no incentive to ship supposedly unstable version B so that one 
is neither compatible with content written against A nor compatible with 
some supposed future final version C. There is also the concern that 
"those who ship win". So far this group has failed to make progress at a 
rate that suggests we will finish soon — we have for example utterly 
failed to follow the four week timetable set out in July — suggesting 
there will be plenty of time for -76 to establish itself as a de-facto 
standard before there is an official one.

---

From: gustav <[email-masked]>
Date: Tue, 12 Oct 2010 12:17:30 +0200

On 12 October 2010 11:52, James Graham <[email-masked]> wrote:

> competitors are shipping supposedly unstable version A of the protocol there
> is no incentive to ship supposedly unstable version B so that one is neither
> compatible with content written against A nor compatible with some supposed
> future final version C. There is also the concern that "those who ship win".
> So far this group has failed to make progress at a rate that suggests we
> will finish soon — we have for example utterly failed to follow the four
> week timetable set out in July — suggesting there will be plenty of time for
> -76 to establish itself as a de-facto standard before there is an official
> one.
> ____________________________

How responsible and professional is it that the by some
people perceived market value benefits is allowed to risk the websockets
future like this ?.

Its tragic to notice that the open development process is hence something
people cant handle the fact that something is "available", ready or not is
just too tempting ?.
They cant wait ... but must have now.. like kids who wants candy NOW,
regardless of the potential long term consequences.
That similar disasters happened before is of course nothing people, as usual
can learn from.

regards
 gustav trede

---

From: Vivek Khurana <[email-masked]>
Date: Tue, 12 Oct 2010 16:35:43 +0530

> That similar disasters happened before is of course nothing people, as usual

  Opera shipped the websocket in development snapshot and not final
version. Infact development snapshot is not even alpha release it is
experimental. So what wrong with this ? Experimentation can un-earth
things that even a group cannot think of. Also, there are server side
developers like me who will like to have a sample implementation
client to try out few things on server side, specially security
aspect.
 I o not think there is anything wrong in browser shipping websockets
in experimental branch, as long as the code is upto date with latest
draft version.

regards
Vivek

-- 
The hidden harmony is better than the obvious!!

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Oct 2010 13:11:08 +0200

On 12.10.2010 13:05, Vivek Khurana wrote:
> ...
 > ...

It's certainly not more "wrong" then FF doing the same, or Chrome and 
Safari doing it in release versions.

> in experimental branch, as long as the code is upto date with latest

And that's one of the problems. They are shipping something not only not 
up-to-date, but also something that wasn't an IETF draft in the first 
place (as far as I can tell).

All of this is fixable, but it requires that the right decisions will be 
made.

We know that Apple won't comment; the other browser *currently* shipping 
this is Chrome. From that point of view it would be good if the Chromium 
people would give us some clue what they're intending to do.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 12 Oct 2010 13:58:15 +0200

> place (as far as I can tell).

An IETF draft being something published by an IETF WG and not an  
individual?

What we ship reflects -00 as far as I know -- the first draft of this WG,  
but that is commonly referred to as -76.

http://my.opera.com/core/blog/websockets has details.

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Oct 2010 14:11:27 +0200

On 12.10.2010 13:58, Anne van Kesteren wrote:
> On Tue, 12 Oct 2010 13:11:08 +0200, Julian Reschke
> <[email-masked]> wrote:
>> And that's one of the problems. They are shipping something not only
>> not up-to-date, but also something that wasn't an IETF draft in the
>> first place (as far as I can tell).
>

Yes, that's what I meant. Sorry for the lack of precision.

> What we ship reflects -00 as far as I know -- the first draft of this
> WG, but that is commonly referred to as -76.
>

I think it would be helpful then to refer to the draft by the "proper" 
name (as published by the WG), citing the draft-hixie-*-* drafts at this 
point only adds to the confusion when in fact everybody implements the 
first WG draft.

Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 12 Oct 2010 14:16:13 +0200

> point only adds to the confusion when in fact everybody implements the  

I just picked the name that seemed to be used most widely by developers.  
Trying to educate everyone on naming is boring. Especially as the  
difference between -76 and -00 is negligible.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Oct 2010 14:26:30 +0200

On 12.10.2010 14:16, Anne van Kesteren wrote:
> On Tue, 12 Oct 2010 14:11:27 +0200, Julian Reschke
>> name (as published by the WG), citing the draft-hixie-*-* drafts at
>> this point only adds to the confusion when in fact everybody
>> implements the first WG draft.
>

Actually, I just checked and it's zero except for boilerplate; which is 
good.

(What I *thought* was that when people say they were implementing "-76" 
they were referring Ian's "-latest" version, which indeed differs from 
the two drafts mentioned above).

Best regards, Julian

---

From: James Graham <[email-masked]>
Date: Tue, 12 Oct 2010 16:19:19 +0200

On 10/12/2010 12:17 PM, gustav wrote:
>
>
> On 12 October 2010 11:52, James Graham <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>     Not to my knowledge. It is not hard to see why, however; when all
>     ones competitors are shipping supposedly unstable version A of the
>     protocol there is no incentive to ship supposedly unstable version B
>     so that one is neither compatible with content written against A nor
>     compatible with some supposed future final version C. There is also
>     the concern that "those who ship win". So far this group has failed
>     to make progress at a rate that suggests we will finish soon — we
>     have for example utterly failed to follow the four week timetable
>     set out in July — suggesting there will be plenty of time for -76 to
>     establish itself as a de-facto standard before there is an official one.

Unfortunately the dynamics of the situation work against you here. There 
are lots of incentives for browser makers to be the first implement new 
features; being perceived as technological leaders, attracting web 
developers to use their browser, or just a desire to add new, useful, 
capabilities to the platform. Once one manufacturer implements a 
feature, there is a even more incentive for others to follow in order to 
interoperate with content developed for the first implementation, to not 
be perceived as technological laggards, etc. For compelling 
technologies, simply saying "you shouldn't implement yet" doesn't work 
in the face of these drivers.

I also question the "risk to the websockets future". What possible 
future scenarios exist assuming -00 is widely deployed by clients now?

1) -00 isn't sufficiently compatible with existing infrastructure to be 
widely deployed on the server side. In this case it will not be a big 
success so there is a limited risk. We upgrade to a later version at 
some future time and solve the problem.

2) -00 is good enough for many applications and takes off fast enough 
that UAs cannot drop support for it. However it lacks features that some 
deployments need or is hard to deploy in some scenarios. In this case it 
is likely that, possibly ugly, hacks get developed to add those features 
in in a way that is compatible with -00. Not ideal but not a great 
disaster. Alternatively UAs agree to implement both -00 and some later 
version.

3) -00 is successful and becomes a common vector for security breaches. 
Possibly the worst situation, although common in existing technologies. 
Either the implementations have to be patched in some compatible way to 
mitigate the risk, or a cottage industry grows up around reducing the risk.

> Its tragic to notice that the open development process is hence
> something people cant handle the fact that something is "available",
> ready or not is just too tempting ?.
> That similar disasters happened before is of course nothing people, as
> usual can learn from.

Indeed, although I suspect the lesson that I think you should take from 
history is different from the one that you have in mind. The lesson I 
see is that once people are starting to implement, you have a short 
window of opportunity left to make major, breaking changes before you 
are locked into a fundamental design. If you miss this window your 
better design is likely to lose to the one that shipped. Therefore, 
during this time, it is important to work together with the people 
implementing to converge on the final design as fast as possible. Having 
a "it's done when it's done" attitude doesn't work.

---

From: Ian Fette (イアンフェッティ) <[email-masked]>
Date: Tue, 12 Oct 2010 07:44:57 -0700

FWIW we (chrome) are in the midst of switching over to -02

On Mon, Oct 11, 2010 at 10:22 PM, Willy Tarreau <[email-masked]> wrote:

> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>