1828151 - [DNR] Add test coverage for WebSocket requests

Status: NEW

(WebExtensions :: Request Handling, task, P3)

Description

[Rob Wu [:robwu]]

Internally, WebSocket requests are just regular http(s) requests.

In the webRequest API, we intentionally transform the scheme to ws(s) since bug 1367478, because an extension in the wild uses the pattern.

And that is because Chrome internally uses ws(s) scheme for WebSocket URLs.

Given how Firefox works internally, WebSocket requests are likely handled as expected in DNR (i.e. DNR can block or redirect/modify WebSocket requests). We don't have any test coverage however.

In the light of Chrome's implementation, it's also worth investigating whether the API needs any special treatment for ws(s) schemes. For example:

• the "ws" and "wss" schemes are currently not part of the DNR API (e.g. not in URLTransform.scheme).
• But when I use chrome.declarativeNetRequest.onRuleMatchedDebug.addListener(console.log) in Chrome and trigger a WebSocket request (e.g. new WebSocket("wss://example.com/"), the reported URL is wss://example.com.
• WebSocket requests in Chrome can be matched with urlFilter: "|ws".
• WebSocket requests can be blocked, but not redirected to another URL in Chrome. onRuleMatchedDebug is fired for action: {type:"block"} but not when action: {type:"redirect",redirect:{url: "wss or even https url here"}}. WebSocket requests cannot be redirected with webRequest in Chrome either.

We should decide whether to continue maintaining translating http(s) to ws(s), or whether we want to treat them as http(s) so that DNR extensions can more easily match and modify WebSocket requests without the need to special-case the urlFilter or regexFilter.
And then we should add unit tests in Firefox to verify that DNR can at least block requests in Firefox.

Comment 1

[Rob Wu [:robwu]]

FYI: Chrome acknowledges that it doesn't support redirects for ws(s) in general, and that the upgradeSchema action does not work at https://bugs.chromium.org/p/chromium/issues/detail?id=1231254

Comment 2

[Rob Wu [:robwu]]

FYI: The WebSocket constructor on the web platform now accepts http(s) URLs instead of ws(s), and translates that to ws(s) internally: bug 1797449 + https://github.com/whatwg/websockets/pull/45

Since they are interchangeable, we could consider using http(s) through the DNR API, so that extension developers don't have to be concerned with the special ws(s) scheme in their DNR rules.