[webkit-dev] Implementing new WebSocket protocol

[Yuta Kitamura]

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

Re: [webkit-dev] Implementing new WebSocket protocol

[Adam Barth]

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  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

Re: [webkit-dev] Implementing new WebSocket protocol

[Ryosuke Niwa]

On Tue, Jun 14, 2011 at 7:55 AM, Yuta Kitamura  wrote:
>
> 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
>

A runtime flag or compile-time flag sound good to me.  Ideally, we can
re-use the existing infrastructure for old WebSocket to implement new one.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[イアンフェッティ]

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  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  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

Re: [webkit-dev] Implementing new WebSocket protocol

[Ojan Vafai]

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 (イアンフェッティ) 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  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 
>> 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

Re: [webkit-dev] Implementing new WebSocket protocol

[イアンフェッティ]

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 

> 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 (イアンフェッティ) 
> 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  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 
>>> 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

Re: [webkit-dev] Implementing new WebSocket protocol

[Maciej Stachowiak]

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

 - 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 
> 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 (イアンフェッティ)  
> 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  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  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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[Yuta Kitamura]

On Wed, Jun 15, 2011 at 6:57 AM, Maciej Stachowiak  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 
>
>> 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 (イアンフェッティ) > > 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  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 
 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

Re: [webkit-dev] Implementing new WebSocket protocol

[Adam Crabtree]

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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[Yuta Kitamura]

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).

As a starting point, could somebody review a patch in bug 60348 (
http://webkit.org/b/60348), which only adds a flag?

Regards,
Yuta
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[Simon Fraser]

I'm surprised that the protocol has no facility for versioning. Is that really 
he case? Should it be considered for future versions of the spec?

Simon

On Jun 23, 2011, at 6:07 AM, Yuta Kitamura wrote:

> 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).
> 
> As a starting point, could somebody review a patch in bug 60348 
> (http://webkit.org/b/60348), which only adds a flag?
> 
> 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

Re: [webkit-dev] Implementing new WebSocket protocol

[Julian Reschke]

On 2011-06-23 17:15, Simon Fraser wrote:

I'm surprised that the protocol has no facility for versioning. Is that
really he case? Should it be considered for future versions of the spec?


It does.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[イアンフェッティ]

That said, I don't think the intent should be to support any old versions
for any protracted amount of time. -00 has security vulnerabilities brought
up by people on webkit-dev@ so from the Chrome side, we intend not to
support -00 at all once we have -09 support available. All the makers of
server-side code have already published versions compatibile with the latest
draft, and IETF drafts are intended to expire after a fixed amount of time
(-00 is already well past its expiration date).

-Ian

On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke wrote:

> On 2011-06-23 17:15, Simon Fraser wrote:
>
>> I'm surprised that the protocol has no facility for versioning. Is that
>> really he case? Should it be considered for future versions of the spec?
>>
>
> It does.
>
>  section-11.11
> >
>
> __**_
> 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

Re: [webkit-dev] Implementing new WebSocket protocol

[Charles Pritchard]

That said, you're all lucky that the rest of us developers
have no idea when the current round of specification flux
will settle down.

Security vulnerabilities will always trump the specs. Thanks for keeping 
on top of things.


-Charles

On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote:
That said, I don't think the intent should be to support any old 
versions for any protracted amount of time. -00 has security 
vulnerabilities brought up by people on webkit-dev@ so from the Chrome 
side, we intend not to support -00 at all once we have -09 support 
available. All the makers of server-side code have already published 
versions compatibile with the latest draft, and IETF drafts are 
intended to expire after a fixed amount of time (-00 is already well 
past its expiration date).


-Ian

On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke 
mailto:julian.resc...@gmx.de>> wrote:


On 2011-06-23 17:15, Simon Fraser wrote:

I'm surprised that the protocol has no facility for
versioning. Is that
really he case? Should it be considered for future versions of
the spec?


It does.





___
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

Re: [webkit-dev] Implementing new WebSocket protocol

[イアンフェッティ]

FWIW it has settled down. The spec is in last call and isn't changing,
rather we're just arguing over wording, references in the spec, clarifying
text based on implementation experiences and ambiguities implementers have
found, etc.



On Thu, Jun 23, 2011 at 6:29 PM, Charles Pritchard  wrote:

> **
> That said, you're all lucky that the rest of us developers
> have no idea when the current round of specification flux
> will settle down.
>
> Security vulnerabilities will always trump the specs. Thanks for keeping on
> top of things.
>
> -Charles
>
>
> On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote:
>
> That said, I don't think the intent should be to support any old versions
> for any protracted amount of time. -00 has security vulnerabilities brought
> up by people on webkit-dev@ so from the Chrome side, we intend not to
> support -00 at all once we have -09 support available. All the makers of
> server-side code have already published versions compatibile with the latest
> draft, and IETF drafts are intended to expire after a fixed amount of time
> (-00 is already well past its expiration date).
>
>  -Ian
>
> On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke wrote:
>
>> On 2011-06-23 17:15, Simon Fraser wrote:
>>
>>> I'm surprised that the protocol has no facility for versioning. Is that
>>> really he case? Should it be considered for future versions of the spec?
>>>
>>
>>  It does.
>>
>> <
>> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.11>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing 
> listwebkit-dev@lists.webkit.orghttp://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