Bug 160159 – Content Blocker cannot block WebSocket connections

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Andrey Meshkov]

Steps to reproduce:
1. Register a simple content blocker:
[{trigger: {url-filter: "echo.websocket.org" }, action: {type: "block"}}]
2. Go to https://websocket.org/echo.html
3. Click "Connect", then "Send"

Expected result:
WebSocket connection should be blocked by the content blocker.

Actual result:
WebSocket connection is working.

[Radar WebKit Bug Importer]

<rdar://problem/27557334>

[Alex Christensen]

Created attachment 284844 [details]
Patch

[Andrey Meshkov]

Thank you Alex!

Offtop: I see you've added a new feature for forcing HTTPS? Is it in the stable Safari version already?

[Alex Christensen]

Created attachment 285054 [details]
Patch

[Build Bot]

Comment on attachment 285054 [details]
Patch

Attachment 285054 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1795547

New failing tests:
http/tests/websocket/tests/hybi/contentextensions/upgrade.html
http/tests/websocket/tests/hybi/contentextensions/upgrade-worker.html
http/tests/websocket/tests/hybi/contentextensions/display-none-worker.html
http/tests/websocket/tests/hybi/contentextensions/block.html
http/tests/websocket/tests/hybi/contentextensions/block-cookies-worker.php
http/tests/websocket/tests/hybi/contentextensions/block-cookies.php
http/tests/websocket/tests/hybi/contentextensions/block-worker.html
http/tests/websocket/tests/hybi/contentextensions/display-none.html

[Build Bot]

Created attachment 285059 [details]
Archive of layout-test-results from ews103 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 285054 [details]
Patch

Attachment 285054 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/1795517

New failing tests:
http/tests/websocket/tests/hybi/contentextensions/upgrade.html
http/tests/websocket/tests/hybi/contentextensions/upgrade-worker.html
http/tests/websocket/tests/hybi/contentextensions/display-none-worker.html
http/tests/websocket/tests/hybi/contentextensions/block.html
http/tests/websocket/tests/hybi/contentextensions/block-cookies-worker.php
http/tests/websocket/tests/hybi/contentextensions/block-cookies.php
http/tests/websocket/tests/hybi/contentextensions/block-worker.html
http/tests/websocket/tests/hybi/contentextensions/display-none.html

[Build Bot]

Created attachment 285060 [details]
Archive of layout-test-results from ews125 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews125  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.5

[Build Bot]

Comment on attachment 285054 [details]
Patch

Attachment 285054 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1795554

New failing tests:
http/tests/contentextensions/make-https.html

[Build Bot]

Created attachment 285061 [details]
Archive of layout-test-results from ews104 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 285054 [details]
Patch

Attachment 285054 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/1795559

New failing tests:
http/tests/websocket/tests/hybi/contentextensions/upgrade.html
http/tests/websocket/tests/hybi/contentextensions/upgrade-worker.html
http/tests/websocket/tests/hybi/contentextensions/display-none-worker.html
http/tests/websocket/tests/hybi/contentextensions/block.html
http/tests/websocket/tests/hybi/contentextensions/block-cookies-worker.php
http/tests/websocket/tests/hybi/contentextensions/block-cookies.php
http/tests/websocket/tests/hybi/contentextensions/block-worker.html
http/tests/websocket/tests/hybi/contentextensions/display-none.html

[Build Bot]

Created attachment 285064 [details]
Archive of layout-test-results from ews112 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Alex Christensen]

Created attachment 285071 [details]
Patch

[Brady Eidson]

Comment on attachment 285071 [details]
Patch

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

> Source/WebCore/Modules/websockets/ThreadableWebSocketChannelClientWrapper.cpp:237
> +    m_pendingTasks.append(std::make_unique<ScriptExecutionContext::Task>([this, protectedThis = makeRef(*this)] (ScriptExecutionContext&) {
> +        if (m_client)
> +            m_client->didUpgradeURL();
> +    }));

This makes me super, super sad; That ThreadableWebSocketChannelClientWrapper has its own m_pendingTasks queue, to execute tasks in the ScriptExecutionContext's thread, when ScriptExecutionContext already has that functionality.

I know this is established style in the class, so you shouldn't change it now, but please file a bug to follow up and get rid of that.

> Source/WebCore/Modules/websockets/WebSocketHandshake.cpp:257
> -        // Set "Cookie2: <cookie>" if cookies 2 exists for url?
> -    }
> +    String cookie = cookieRequestHeaderFieldValue(m_document, url);
> +    if (!cookie.isEmpty())
> +        request.setHTTPHeaderField(HTTPHeaderName::Cookie, cookie);
> +    // Set "Cookie2: <cookie>" if cookies 2 exists for url?

Do we have a bugzilla for Cookie2?
Should this be a formal FIXME referencing that bugzilla?

If not, then I don't see the value in keeping the comment.

[Alex Christensen]

(In reply to comment #14)
> Comment on attachment 285071 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=285071&action=review
> 
> > Source/WebCore/Modules/websockets/ThreadableWebSocketChannelClientWrapper.cpp:237
> > +    m_pendingTasks.append(std::make_unique<ScriptExecutionContext::Task>([this, protectedThis = makeRef(*this)] (ScriptExecutionContext&) {
> > +        if (m_client)
> > +            m_client->didUpgradeURL();
> > +    }));
> 
> This makes me super, super sad; That ThreadableWebSocketChannelClientWrapper
> has its own m_pendingTasks queue, to execute tasks in the
> ScriptExecutionContext's thread, when ScriptExecutionContext already has
> that functionality.
> 
> I know this is established style in the class, so you shouldn't change it
> now, but please file a bug to follow up and get rid of that.
https://bugs.webkit.org/show_bug.cgi?id=160557
> 
> > Source/WebCore/Modules/websockets/WebSocketHandshake.cpp:257
> > -        // Set "Cookie2: <cookie>" if cookies 2 exists for url?
> > -    }
> > +    String cookie = cookieRequestHeaderFieldValue(m_document, url);
> > +    if (!cookie.isEmpty())
> > +        request.setHTTPHeaderField(HTTPHeaderName::Cookie, cookie);
> > +    // Set "Cookie2: <cookie>" if cookies 2 exists for url?
> 
> Do we have a bugzilla for Cookie2?
> Should this be a formal FIXME referencing that bugzilla?
> 
> If not, then I don't see the value in keeping the comment.
Removed comment.  We have not yet supported cookie2 in websockets, and it's deprecated.  https://tools.ietf.org/html/rfc6265#section-9.3

[Alex Christensen]

Created attachment 285337 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 285337 [details]
Patch

Clearing flags on attachment: 285337

Committed r204127: <http://trac.webkit.org/changeset/204127>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.