Subject: [hybi] WebSocket browser support status

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 8 Aug 2011 22:47:26 +0200

Hi all,

I've not had the chance to follow closely what happened around WebSocket
lately and thus, I've been wondering what was the browser support status of
the protocol. Could anyone shed a light on this for me?

Thanks,
-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 8 Aug 2011 13:54:10 -0700

Protocol 8 (draft spec 10) is - as far as I know - currently only supported by Chrome 14 and Firefox 7/8

You can have a look at the test results from a little test suite covering conformance to detailed specifics
of the spec:

http://www.tavendo.de/autobahn/testsuite/report/

Description is here:

http://www.tavendo.de/autobahn/testsuite.html

Rest of the site is pretty much a work in progress ..

On 08.08.11 22:47, "Sylvain Hellegouarch" <[email-masked]> wrote:

Hi all,

I've not had the chance to follow closely what happened around WebSocket lately and thus, I've been wondering what was the browser support status of the protocol. Could anyone shed a light on this for me?

Thanks,

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Mon, 8 Aug 2011 23:00:20 +0200

> Rest of the site is pretty much a work in progress ..

Brilliant. Cheers.

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 9 Aug 2011 13:03:51 +0300

Hi Tobias,

thanks a lot for sharing the test results, they are really interesting.

It would be a great for all the community
if you can team up with Greg, Justin and the other people that have 
showed interest in the test suite
to produce and submit an Internet draft describing the test suite

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

On 8/8/11 11:54 PM, Tobias Oberstein wrote:
> You can have a look at the test results from a little test suite 
> covering conformance to detailed specifics
> of the spec:
>
>     I've not had the chance to follow closely what happened around
>     WebSocket lately and thus, I've been wondering what was the
>     browser support status of the protocol. Could anyone shed a light
>     on this for me?
>
>     Thanks,
>

---

From: Tobias Oberstein <[email-masked]>
Date: Tue, 9 Aug 2011 04:13:52 -0700

Hello Sal,

thanks for noticing.

If Greg, Justin and others would see benefit in producing a formal document,

I'd be on the boat. Only when collaborating though, since I never produced such a

document and also my time is quite limited.

In any case, I certainly will extend the test coverage further - both with regard to cases

and implementations. Waiting for IE/Opera;)

When others see test cases missing, drop me a line .. or even better, submit a test case

class, which is quite easy .. it's all open-source and on GitHub.

cheers,

Tobias

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Salvatore Loreto

Gesendet: Dienstag, 9. August 2011 12:04

An: [email-masked]

Betreff: Re: [hybi] WebSocket browser support status

Hi Tobias,

if you can team up with Greg, Justin and the other people that have showed interest in the test suite

cheers

/Sal

--

Salvatore Loreto

www.sloreto.com

of the spec:

Description is here:

Hi all,

Thanks,

---

From: Tobias Oberstein <[email-masked]>
Date: Wed, 10 Aug 2011 07:29:43 -0700

For those interested, I've updated the reports:

* the fixes for Firefox have landed on FF8 ("Nightly") .. it now passed _all_ test cases
* Chrome fixes are still moving
* the performance/limits detail reports now contain octet/frame statistics

PS:

The one red case for FF 8 shows the point where it bails out on message/frame size .. somewhere above 8MB.
Also, all clients currently send unfragmented messages in all cases.

The yellow cases for FF 8 are formally passes. Those test cases do this:

First, something valid, then something breaking the protocol.

The spec only requires to "fail the connection immediately".
The spec does not say what to do with the stuff up to the protocol violation.

Chrome/Autobahn process everything up to the point of violation.
FF discards everything buffered, but not yet processed, when it encounters a violation in buffered.
The latter means, the result is somehow indeterministic, since it depends on the buffered amount
at the point of violation.

==

Unrelated to test suite: I've gotten the performance of the Autobahn Python client approaching
that of FF and often exceeding that of Chrome;) Btw: the performance limiting factor (in my 
setup .. fast machine, loopback) is the masking ..

Cheers