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 <o...@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 (イアンフェッティ) > <ife...@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 <aba...@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 <yu...@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@lists.webkit.org >>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> > >>> > >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
