[Webkit-unassigned] [Bug 259282] New: WebSocket connections via HTTP proxy with scheme ws:// do not use CONNECT method

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=259282

            Bug ID: 259282
           Summary: WebSocket connections via HTTP proxy with scheme ws://
                    do not use CONNECT method
           Product: WebKit
           Version: WebKit Local Build
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: james at mabl.com

RFC-6455 Section 4.1 (https://datatracker.ietf.org/doc/html/rfc6455#section-4.1) specifies that when the client is configured to use a proxy, the CONNECT method should be used to establish the WebSocket connection.  This section does not differentiate between ws and wss schemes, so the implication is that CONNECT should be used for _all_ WebSocket connections when the client is configured to use a proxy.  WebKit uses CONNECT for wss:// URLs, but for ws:// URLs it issues a normal GET request to the proxy using the absolute URI of the server in the request line.  By contrast, Firefox and Chrome use CONNECT regardless of whether the WebSocket URL scheme is ws or wss.  I've tested this with a local build with version WebKitGTK 2.41.6 (265776 at main).  The problem with using GET rather than CONNECT is that some proxies that strictly conform to RFC-6455 will reject these GET requests.  One such example is mitmproxy (https://github.com/mitmproxy/mitmproxy), which returns an error code and complains about an invalid request scheme.

For reference, below is an example request/response log showing what happens when WebKit is configured to connect to a ws:// URL via mitmproxy:

> GET ws://192.168.122.1:8888/ HTTP/1.1
> Host: 192.168.122.1:8888
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.4 Safari/605.1.15
> Origin: http://192.168.122.1:8888
> Pragma: no-cache
> Cache-Control: no-cache
> Upgrade: websocket
> Connection: Upgrade
> Sec-WebSocket-Key: Jed6Wvk9oJQvBqlfYCKTiw==
> Sec-WebSocket-Version: 13
> Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
> Accept-Encoding: gzip, deflate
> Accept-Language: en-US
> 
> HTTP/1.1 502 Bad Gateway
> content-length: 26
> 
> Invalid request scheme: ws

For comparison, here is the same request/response using Firefox (note that it uses CONNECT and then a subsequent GET request with a relative URI):

> CONNECT 192.168.122.1:8888 HTTP/1.1
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0
> Proxy-Connection: keep-alive
> Connection: keep-alive
> Host: 192.168.122.1:8888
> 
> HTTP/1.1 200 Connection established
> 
> GET / HTTP/1.1
> Host: 192.168.122.1:8888
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0
> Accept: */*
> Accept-Language: en-US,en;q=0.5
> Accept-Encoding: gzip, deflate
> Sec-WebSocket-Version: 13
> Origin: http://192.168.122.1:8888
> Sec-WebSocket-Extensions: permessage-deflate
> Sec-WebSocket-Key: /Uzba02mhelEhLMsoObx9Q==
> Connection: keep-alive, Upgrade
> Pragma: no-cache
> Cache-Control: no-cache
> Upgrade: websocket
> 
> HTTP/1.1 101 Switching Protocols
> Upgrade: websocket
> Connection: Upgrade
> Sec-WebSocket-Accept: Cr3XgX2NzWNx/mvS1CDZeuknHhU=

It should be easy to reproduce this issue by installing mitmproxy and starting it up locally.  The way I prefer to do this is:
> mitmdump -k -p 8080
Next, start WebKit and configure it to connect via mitmproxy:
> Tools/Scripts/run-minibrowser --gtk --proxy='http://localhost:8080'
The last piece that is needed is a server that accepts WebSocket connections over HTTP.  I've created a very simple node-based HTTP/WebSocket server for testing scenarios like this.  It includes a basic UI that can be used to initiate the WebSocket connection.  You can access that code here: https://github.com/jbaldassari/websocket-echo
> npm ci
> npm run build
> HTTP_PORT=8888 node build/index.js

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230717/96c62e3d/attachment.htm>