WebSocket support

[hangim]

1. What version of Caddy are you using (caddy -version)?

Caddy 0.11.0

2. What are you trying to do?

Make a http2 proxy use caddy, I hope it can support WebSocket.

I use Chrome + SwitchyOmega for client.

PAC file:

function FindProxyForURL(url, host) {
  return "HTTPS example.com:443";
}

3. What is your entire Caddyfile?

example.com:443 {
    tls /***/cert.pem /***/privkey.pem
    forwardproxy {
        basicauth user pass
        hide_ip
        hide_via
        response_timeout 10
        dial_timeout 10
    }
}

4. How did you run Caddy (give the full command and describe the execution environment)?

caddy --conf Caddyfile

5. Please paste any relevant HTTP request(s) here.

Please open this js code example:

http://jsbin.com/muqamiqimu/2/edit?js,console

Click run, modify the first line from wss://echo.websocket.org to ws://echo.websocket.org, and run again.

6. What did you expect to see?

Both protocols should be supported (ws and wss).

7. What did you see instead (give full error messages and/or log)?

Only wss supported, ws cant work, which works normally without proxy.

8. How can someone who is starting from scratch reproduce the bug as minimally as possible?

• Install caddy with forwardproxy.
• CopyCaddyfile.
• Run caddy as a http2 proxy server.
• Configure Chrome to use the http2 proxy.
• Open the URL I support in above and test.

[sergeyfrolov]

Interesting. HTTP/2 proxy is supposed to be indifferent to target protocol, be it ws, wss, as the client is expected to just send standard CONNECT in both cases and then proceed with actual protocol. Do you have any logs from the forwardproxy indicating what your client sends?

[hangim]

How can I get these logs? I try to start caddy with -log=stdout, but the log is too less to solve this problem.

[sergeyfrolov]

I believe adding log {request} {response} to Caddyfile should do the trick

[hangim]

For ws, cant work

***.***.***.*** - - [27/Jun/2018:03:35:18 +0000] "CONNECT / HTTP/2.0" 200 181

CONNECT echo.websocket.org:80 HTTP/2.0\r\nHost: echo.websocket.org:80\r\nProxy-Authorization: Basic ***password for basicauth***\r\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36\r\n\r\n -

For wss, work normal

***.***.***.*** - - [27/Jun/2018:03:35:55 +0000] "CONNECT / HTTP/2.0" 200 7903

CONNECT echo.websocket.org:443 HTTP/2.0\r\nHost: echo.websocket.org:443\r\nProxy-Authorization: Basic ***password for basicauth***\r\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Safari/537.36\r\n\r\n -

View in Chrome Network

Seems like some unexpected truncated, make the Chrome still wait for the response.

[sergeyfrolov]

Thanks, that's a very good report! So, client with both ws and wss just sends CONNECT and receives 200 (success) response, indicating successful establishment of connection between client and ws/wss port. What happens next and why it gets truncated afterwards is unclear. Seemingly, it follows with HTTP ws handshake (-> Connection: Upgrade) (<- Ok, sure, let's upgrade) and some side closes. Unfortunately, I don't have time to dig into this right now, perhaps later in the summer.

[hangim]

Thanks for your attention. BTW, I found this problem when I visit http://www.speedtest.net/, which use ws for latency test. Maybe this information can help you debug.

[angristan]

👋 hey @sergeyfrolov is this is your roadmap?

[sergeyfrolov]

@angristan I'd like to eventually get to this, but haven't been able to find the time yet.

I tried to reproduce it again, and it seems that speedtest.net no longer uses ws for latency test, and does not fail for me over forwardproxy. Furthermore, I found another ws test: http://demos.kaazing.com/echo/index.html and it seems to work fine for me. So, I am unable to reproduce this issue anymore. Are you able to reproduce the issue @angristan @hangim ?

[hangim]

@sergeyfrolov Time flies, my second summer vacation almost end, LOL. I haven't used this since last comment, maybe I will test it this weekend? If I don't forget it, procrastination is terrible.

[angristan]

So this is a bit weird, http://demos.kaazing.com/echo/index.html seems to work:

However I get this error:

On Mastodon, which uses websockets for the streaming API (the timelines), I get many of these:

But it's not 100% broken. it seems there is a sever delay, sometimes the timelines will scroll sometimes they won't... :thinking:

[sergeyfrolov]

ERR_NOT_IMPLEMENTED seems to be chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=684681

[angristan]

In Firefox, websockets are fully working indeed...

[sergeyfrolov]

it seems there is a sever delay, sometimes the timelines will scroll sometimes they won't

Do you still see delays when you visit mastodon via forwardproxy using Firefox? I have a suspicion that the delay might be a separate issue, not caused by the Chromium bug.

[angristan]

No, I don't see any delay.

[hangim]

I just now do some little test.

In Chrome, without this plugin, ws and wss both works fine.

In Chrome, use this plugin, ws meet ERR_NOT_IMPLEMENTED problem, can't work. And wss works fine, as before mentioned.

In Firefox, use this plugin, everything works fine.

---

So the conclusion is maybe there some bug in Chrome? I am not sure about this, I don't spend time to investigate ERR_NOT_IMPLEMENTED.