[webkit-dev] Implementing new WebSocket protocol

[Yuta Kitamura]

On Wed, Jun 15, 2011 at 6:57 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> Getting on the latest protocol in place would be great, so long as we
> minimize the risk of anyone shipping a halfway mix.
>

What do you mean by "a halfway mix"?

If you mean we should not ship until the complete feature set is ready, it
is not feasible to do it in one patch and a runtime flag would be desirable;
however, if you just mean we should not break existing features (sending or
receiving text frames, etc.), that's probably not too hard. I intend to keep
existing features on protocol migration.

Like many other features, I want to implement WebSocket features
incrementally; first I'd like to make WebKit understand the new protocol,
then add abilities to send or receive binary frames, and other new additions
and so forth. If we do not want to ship between these processes, I'd be
happy to work on the new protocol behind a flag.

FYI, I uploaded a WIP patch at https://bugs.webkit.org/show_bug.cgi?id=50099,
which changes the protocol implementation in-place (not using runtime or
compile-time flag, yet). This patch tries to keep existing functionalities.

Yuta


>  - Maciej
>
>
> On Jun 14, 2011, at 10:47 AM, Ian Fette (イアンフェッティ) wrote:
>
> I thought Kitamura-san had patches mostly ready to switch us over? Either
> way, I agree we don't want to ship something in the middle, but I would
> verymuch like to see us shipping -09 by July at the latest. We've got a
> protocol that's stable, we've got external partners waiting to use this
> (esp. with binary data), we need to get it out the door.
>
> -Ian
>
> 2011/6/14 Ojan Vafai <ojan at chromium.org>
>
>> Reading that bug, Alexey's concerns seem to have been addressed by Firefox
>> and IE shipping the new protocol. We don't want to ship something in between
>> the old and new protocols though, so if it will take multiple patches to
>> switch over, we should probably put it behind a runtime flag.
>>
>>
>> On Tue, Jun 14, 2011 at 10:00 AM, Ian Fette (イアンフェッティ) <ifette at google.com
>> > wrote:
>>
>>> We also said previously that we would remove the old protocol due to
>>> security concerns about poisoning caches/proxies. We justified not
>>> immediately disabling -00 like other browsers did by saying that a new
>>> version addressing the issue would come soon. We've had 9 new versions since
>>> and have yet to update, which is not good. Microsoft and Mozilla both are
>>> targeting newer drafts.
>>>
>>> Also, the protocol is in last call, and we're now at the point of just
>>> making editorial changes. It's stable, and it's time to update the
>>> implementation.
>>>
>>>
>>> On Tue, Jun 14, 2011 at 9:49 AM, Adam Barth <abarth at webkit.org> wrote:
>>>
>>>> I think it's important to move forward with the new protocol.  I'm not
>>>> sure it matter too much what the transition plan is, but we should
>>>> eventually remove the implementation of the old protocol from WebKit.
>>>> No one else is going to implement the old protocol.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura <yutak at chromium.org>
>>>> wrote:
>>>> > Hello,
>>>> > I would like to propose to start implementing the new WebSocket
>>>> protocol
>>>> > which is discussed in IETF HyBi working group.
>>>> > Protocol
>>>> > draft:
>>>> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09
>>>> > JavaScript API draft: http://dev.w3.org/html5/websockets/
>>>> > The new protocol is incompatible with the old one we are currently
>>>> > supporting. New additions include:
>>>> >   - Binary frame support (Blob / ArrayBuffer)
>>>> >   - Frame content masking (to solve security concern raised for the
>>>> old
>>>> > draft)
>>>> >   - Protocol extensions (such as frame compression)
>>>> > Because of the incompatibility, existing services using WebSockets are
>>>> going
>>>> > to break. However, I think this is a necessary cost we have to pay
>>>> > eventually, because:
>>>> >   - Other browsers are going to support the new protocol. (Firefox
>>>> Aurora
>>>> > already includes support for the new protocol.)
>>>> >   - The earlier we switch the protocols, the smaller shock there will
>>>> be.
>>>> > Safari and Chrome are the only browsers that support WebSocket (the
>>>> old
>>>> > protocol) by default.
>>>> >   - There is a security concern raised for the protocol we are
>>>> currently
>>>> > supporting.
>>>> > * How to proceed
>>>> > My original plan was to implement the new protocol directly (i.e.
>>>> replacing
>>>> > the old implementation in-place). However Alexey (ap) objected to
>>>> dropping
>>>> > support for the old protocol immediately.
>>>> > So, I'm currently planning to add a runtime flag to switch the
>>>> WebSocket
>>>> > protocols used by a WebCore's WebSocket implementation. Other
>>>> possibilities
>>>> > are to add a compile-time flag or to use (subversion's) branch, which
>>>> are
>>>> > discussed at:
>>>> > https://bugs.webkit.org/show_bug.cgi?id=60348
>>>> > The discussion in this bug has been stalled for a while, but I really
>>>> would
>>>> > like to move forward. Comments and suggestions are greatly
>>>> appreciated.
>>>> > Regards,
>>>> > Yuta
>>>> >
>>>> > _______________________________________________
>>>> > webkit-dev mailing list
>>>> > webkit-dev at lists.webkit.org
>>>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>> >
>>>> >
>>>> _______________________________________________
>>>> webkit-dev mailing list
>>>> webkit-dev at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>
>>>
>>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110615/ddbe94a0/attachment-0001.html>