make chromium use CONNECT for websockets

Question

At work, IT introduced a new proxy solution based on squid. It should support websockets if the client uses connect:

Squid does not support WebSockets natively. However if the client software is correctly using CONNECT it should be possible with Squid-3.4.5.

Using chomiums DevTools (on SO), I can see the handshake to upgrade from a HTTPS connection to a wss one. This doesn't work (see image below). The issue seems to be that chromium uses GET instead of CONNECT.

I also see that the server response has Connection: keep-alive instead of Upgrade, what I would have expected. Hence the error at the bottom of the page.

Question: How can I configure chromium to use CONNECT instead of GET?

Sidenote: This is related to this post on meta.se. FF pops up a boatload of proxy authentication requests and still fails.

Answer 1

As you can see in the RFC6455 documentation, the request is expected to be a GET request:

The opening handshake is intended to be compatible with HTTP-based server-side software and intermediaries, so that a single port can be used by both HTTP clients talking to that server and WebSocket clients talking to that server. To this end, the WebSocket client's handshake is an HTTP Upgrade request:

    GET /chat HTTP/1.1

    Host: server.example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    Origin: http://example.com
    Sec-WebSocket-Protocol: chat, superchat
    Sec-WebSocket-Version: 13

... The "Request-URI" of the GET method [RFC2616] is used to identify the endpoint of the WebSocket connection, both to allow multiple domains to be served from one IP address and to allow multiple WebSocket endpoints to be served by a single server.

In a different section it is stated that:

The client's opening handshake consists of the following parts. If the server, while reading the handshake, finds that the client did not send a handshake that matches the description below (note that as per [RFC2616], the order of the header fields is not important), including but not limited to any violations of the ABNF grammar specified for the components of the handshake, the server MUST stop processing the client's handshake and return an HTTP response with an appropriate error code (such as 400 Bad Request).

1. An HTTP/1.1 or higher GET request, including a "Request-URI" [RFC2616] that should be interpreted as a /resource name/ defined in Section 3 (or an absolute HTTP/HTTPS URI containing the /resource name/).

So... Hmmm.... using a CONNECT request is actually the issue, not the solution...

I would work on pushing squid to correctly evaluate a Websocket request or monkey-patching a workaround for squid rather than try and force chomiums to use a non-standard request that might be rejected by other Websocket servers.