Bug 73852 - Expose reusable WebSocket code for WebSocketServer.
Summary: Expose reusable WebSocket code for WebSocketServer.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Jocelyn Turcotte
URL:
Keywords:
Depends on:
Blocks: 73094
  Show dependency treegraph
 
Reported: 2011-12-05 12:22 PST by Jocelyn Turcotte
Modified: 2012-04-03 06:34 PDT (History)
7 users (show)

See Also:


Attachments
Patch (10.73 KB, patch)
2011-12-05 12:24 PST, Jocelyn Turcotte
no flags Details | Formatted Diff | Diff
Patch (15.17 KB, patch)
2011-12-12 14:07 PST, Jocelyn Turcotte
no flags Details | Formatted Diff | Diff
Patch (15.49 KB, patch)
2011-12-13 12:15 PST, Jocelyn Turcotte
no flags Details | Formatted Diff | Diff
Patch (29.17 KB, patch)
2012-03-29 10:38 PDT, Jocelyn Turcotte
no flags Details | Formatted Diff | Diff
Patch (29.30 KB, patch)
2012-03-30 02:05 PDT, Jocelyn Turcotte
no flags Details | Formatted Diff | Diff
Patch (29.33 KB, patch)
2012-04-01 12:22 PDT, Jocelyn Turcotte
tkent: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jocelyn Turcotte 2011-12-05 12:22:30 PST
Expose reusable WebSocket code for WebSocketServer.
Comment 1 Jocelyn Turcotte 2011-12-05 12:24:09 PST
Created attachment 117914 [details]
Patch
Comment 2 Hajime Morrita 2011-12-11 20:44:03 PST
Comment on attachment 117914 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=117914&action=review

> Source/WebCore/websockets/WebSocketChannel.cpp:959
> +void WebSocketChannel::buildFrame(OpCode opCode, bool maskPayload, const char* data, size_t dataLength, Vector<char>& frame)

Could you elaborate this change?
I couldn't see any reason to have an option to allow non-masked frames.
Comment 3 Hajime Morrita 2011-12-11 20:44:59 PST
Hi yutak@, toyoshim@, do you have any opinion about this?
Because this change is superficial and I'm OK to rubber-stamping this
Once you guys agree this.
Comment 4 Takashi Toyoshima 2011-12-11 21:29:27 PST
Comment on attachment 117914 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=117914&action=review

>> Source/WebCore/websockets/WebSocketChannel.cpp:959
>> +void WebSocketChannel::buildFrame(OpCode opCode, bool maskPayload, const char* data, size_t dataLength, Vector<char>& frame)
> 
> Could you elaborate this change?
> I couldn't see any reason to have an option to allow non-masked frames.

WebSocket's spec say only upstream frames must be masked.
I guess that's why he added this option and agree with it.
Comment 5 Takashi Toyoshima 2011-12-11 21:30:17 PST
I have no objection to this change.
Comment 6 Kent Tamura 2011-12-11 21:45:27 PST
Comment on attachment 117914 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=117914&action=review

>>> Source/WebCore/websockets/WebSocketChannel.cpp:959
>>> -bool WebSocketChannel::sendFrame(OpCode opCode, const char* data, size_t dataLength)
>>> +void WebSocketChannel::buildFrame(OpCode opCode, bool maskPayload, const char* data, size_t dataLength, Vector<char>& frame)

Adding a bool argument is not good.
We had better update the following functions:

* Adding buildFrameHeader()
* Adding buildUnmaskedFrame()
  calling buildFrameHeader() and frame.append(data, dataLength)
* Updating sendFrame()
  calling buildFrameHeader(), masking the payload, and sending it.
Comment 7 Jocelyn Turcotte 2011-12-12 14:07:08 PST
Created attachment 118841 [details]
Patch

Thanks for having a look. I checked and I would still need a boolean flag in buildFrameHeader to set the mask bit and append the making key. Here is a patch that replaces the boolean flag by an option enum that contains all the flag bit for the frame and use it in FrameData as well instead of individual booleans.

Another option would be to keep it that way and add an enum flag just for the masking, or tell me if you have another idea.
Comment 8 Jocelyn Turcotte 2011-12-12 14:15:06 PST
By the way, there is a patch in bug #73092 that goes along the same line as this one. If one of you guys could have a look that would probably be the best.
Comment 9 WebKit Review Bot 2011-12-12 14:57:44 PST
Comment on attachment 118841 [details]
Patch

Attachment 118841 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/10848074

New failing tests:
http/tests/websocket/tests/hybi/reserved-bits.html
Comment 10 Yuta Kitamura 2011-12-12 19:41:27 PST
Comment on attachment 118841 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=118841&action=review

The patch generally looks fine to me. If the failure from EWS is real, you need to investigate and fix it. [Note: I'm not a WebKit reviewer.]

> Source/WebCore/websockets/WebSocketChannel.h:145
> +    static ParseFrameResult parseFrame(const char* data, size_t dataLength, FrameData&, String& errorString); // May modify part of "data" to unmask the frame.

The type of |data| should be char* (non-const) to indicate the content of |data| may be modified.
Comment 11 Yuta Kitamura 2011-12-12 20:30:01 PST
Comment on attachment 118841 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=118841&action=review

> Source/WebCore/websockets/WebSocketChannel.cpp:634
> +    if (isControlOpCode(frame.opCode) && !frame.options & FrameOptionFinal) {

Do you mean !(frame.options & FrameOptionFinal) ?
Comment 12 Kent Tamura 2011-12-12 21:46:19 PST
(In reply to comment #7)
> Thanks for having a look. I checked and I would still need a boolean flag in buildFrameHeader to set the mask bit and append the making key. Here is a patch that replaces the boolean flag by an option enum that contains all the flag bit for the frame and use it in FrameData as well instead of individual booleans.
> 
> Another option would be to keep it that way and add an enum flag just for the masking, or tell me if you have another idea.

ok, I see.  The FrameOptions idea looks nice.
Comment 13 Jocelyn Turcotte 2011-12-13 12:14:15 PST
(In reply to comment #10)
> The patch generally looks fine to me. If the failure from EWS is real, you need to investigate and fix it. [Note: I'm not a WebKit reviewer.]

This test was passing on other platform since WTF String would convert the bit-ANDed value automatically to bool for some reason. On chromium the error message was something like "One or more reserved bits are on: reserved1 = 2, reserved2 = 4, reserved3 = 8" instead of "...= 1, ...= 1, ...= 1". It should work now.

> The type of |data| should be char* (non-const) to indicate the content of |data| may be modified.

Good idea.

(In reply to comment #11)
> Do you mean !(frame.options & FrameOptionFinal) ?

This is embarrassing, nice catch.
A new patch is following.
Comment 14 Jocelyn Turcotte 2011-12-13 12:15:44 PST
Created attachment 119061 [details]
Patch
Comment 15 Kent Tamura 2011-12-13 18:12:43 PST
Comment on attachment 119061 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=119061&action=review

> Source/WebCore/websockets/WebSocketChannel.cpp:629
> -        fail("One or more reserved bits are on: reserved1 = " + String::number(frame.reserved1) + ", reserved2 = " + String::number(frame.reserved2) + ", reserved3 = " + String::number(frame.reserved3));
> +    if (frame.options & (FrameOptionReserved1 | FrameOptionReserved2 | FrameOptionReserved3)) {
> +        fail("One or more reserved bits are on: reserved1 = " + String::number(!!(frame.options & FrameOptionReserved1)) + ", reserved2 = " + String::number(!!(frame.options & FrameOptionReserved2)) + ", reserved3 = " + String::number(!!(frame.options & FrameOptionReserved3)));

nit: We have String::format().
Comment 16 Jocelyn Turcotte 2011-12-14 04:14:25 PST
(In reply to comment #15)
> nit: We have String::format().

Thanks! Will do.
Comment 17 Jocelyn Turcotte 2012-03-29 10:38:47 PDT
Created attachment 134613 [details]
Patch

Taking some time to iterate over the inspector server patches again.
I had to rebase this patch. The code has now been moved to the new WebSocketFrame instead of exposing straight static methods.
Comment 18 Kent Tamura 2012-03-29 18:09:54 PDT
Comment on attachment 134613 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=134613&action=review

> Source/WebCore/Modules/websockets/WebSocketFrame.cpp:2
> + * Copyright (C) 2012 Nokia Corporation and/or its subsidiary(-ies)

Please respect the copyright of the original code.
Comment 19 Jocelyn Turcotte 2012-03-30 02:05:45 PDT
Created attachment 134749 [details]
Patch

Preserve the copyrights for WebSocketFrame.cpp
Comment 20 Kent Tamura 2012-03-30 03:34:29 PDT
Comment on attachment 134749 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=134749&action=review

> Source/WebCore/Modules/websockets/WebSocketChannel.cpp:589
> -    if (WebSocketFrame::isControlOpCode(frame.opCode) && frame.payloadLength > maxPayloadLengthWithoutExtendedLengthField) {
> +    if (WebSocketFrame::isControlOpCode(frame.opCode) && frame.payloadLength > WebSocketFrame::maxPayloadLengthWithoutExtendedLengthField) {

I recommend adding WebSocketFrame::isControlFrameWithTooLongPayload(), and hide maxPayloadLengthWithoutExtendedLengthField.
Comment 21 Jocelyn Turcotte 2012-04-01 12:22:57 PDT
Created attachment 135010 [details]
Patch

Expose maxPayloadLengthWithoutExtendedLengthField as WebSocketFrame::needsExtendedLengthField to make it consistent with the other struct helpers. Tell me if that's alright.
WebSocketFrame might also look better as a proper class instead of those helpers.
Comment 22 Kent Tamura 2012-04-01 20:31:25 PDT
Comment on attachment 135010 [details]
Patch

ok
Comment 23 Jocelyn Turcotte 2012-04-03 06:34:35 PDT
Committed r113025: <http://trac.webkit.org/changeset/113025>