Implementing new WebSocket protocol
2011-06-14 14:55:53 GMT
Hello,
_______________________________________________ webkit-dev mailing list webkit-dev <at> lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hello,
_______________________________________________ webkit-dev mailing list webkit-dev <at> lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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 > >
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.
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
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.
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
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.
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
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
Getting on the latest protocol in place would be great, so long as we minimize the risk of anyone shipping a halfway mix.
- MaciejOn 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
_______________________________________________ webkit-dev mailing list webkit-dev <at> lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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:
_______________________________________________ webkit-dev mailing list webkit-dev <at> lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
If possible, I would encourage any breaking update to WebSockets (protocol or JS API) to be feature detectable. Additionally, I would encourage WebKit to postpone updating to -09 to coincide with expected changes to the JS API, which may provide the necessary feature detection mechanisms (e.g., WebSocket.open a la XHR): http://www.w3.org/Bugs/Public/show_bug.cgi?id=12102.
More specifically, I work at HP Palm and our devices currently support the -00 implementation of WebSockets, and while we are able to auto-update, users must approvebut may not have been updated, and while as far as I understand being just a protocol -00 could be detected and supported server-side along-side -09, -00 implementations connecting to a -09 server will have to fail (full RTT) in order to feature detect support for -09.
Allowing this feature detection along-side the protocol-break would enable libraries and implementations to know what protocol versions are supported and adjust behavior accordingly.
Alternatively, being that the protocol updates are in draft while API updates are not with no anticipation of when they will be, some other means of feature detection could be exposed instead.
Cheers,
Adam Crabtree
_______________________________________________ webkit-dev mailing list webkit-dev <at> lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
There seems to be no strong objection to adding a runtime flag, and I think it will take some time and need multiple patches to get the implementation in good shape. Therefore, I'd like to start to implement behind a runtime flag. It allows each port to control the time to switch protocols, too (of course all ports should be migrated eventually).
_______________________________________________ webkit-dev mailing list webkit-dev <at> lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
RSS Feed