Caddy: websocket does not work through http proxy

[giner]

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

Caddy 0.9.5

2. What are you trying to do?

Configure caddy to use upstream though http proxy

3. What is your entire Caddyfile?

localhost:8080
proxy / https://echo.websocket.org {
    websocket
}

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

http_proxy=http://myproxy:3128 https_proxy=http://myproxy:3128 ./caddy

5. What did you expect to see?

I was expecting websockets to work.

HTTP/1.1 101 Web Socket Protocol Handshake
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: authorization
Access-Control-Allow-Headers: x-websocket-extensions
Access-Control-Allow-Headers: x-websocket-version
Access-Control-Allow-Headers: x-websocket-protocol
Access-Control-Allow-Origin: https://www.websocket.org
Connection: Upgrade
Date: Tue, 14 Feb 2017 14:45:41 GMT
Server: Kaazing Gateway
Upgrade: WebSocket
WebSocket-Location: wss://echo.websocket.org/
WebSocket-Origin: https://www.websocket.org

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

Websockets didn't work.

... output is just binary garbage ...

7. How can someone who is starting from scratch reproduce this behavior as minimally as possible?

tinyproxy -d -c <(echo -e "Port 3128\nMaxClients 100\nStartServers 10\n")
http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 ./caddy
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" -H "Origin: https://www.websocket.org" http://localhost:8080

[mholt]

Hey @giner, sorry you're having troubles with the websocket proxy. Unfortunately, there's nothing in this issue that is helpful in debugging it. Websockets work fine for me using a similar configuration, so we need more details. We really need to see the full error messages or the log or the trace of requests -- something -- saying "it doesn't work" is nothing to go on. Also, your Caddyfile is missing the address of the site you are serving (on the first line).

[giner]

Would you please share what you mean by "similar configuration"? Because this particular configuration does not work. By this configuration I mean:
caddy receives http request and sends it as https to backend through http proxy (squid in my case). Http request does go well and returns body from the destination server but websocket request does not go through this chain. Without http proxy it works.

[giner]

@mholt I have updated details and the test-case.

[mholt]

Thanks. Does the same thing happen when you proxy to http:// instead of https://?

[giner]

Proxying to http:// does not work but this is expected because most of http proxies don't support websockets. This is the reason why I put https:// there.

[mholt]

I can't duplicate the behavior you're seeing. Is there something other than Kaazing that we could test with, that's like, really simple and free and preferably just a few lines of code? :smile:

[giner]

@mholt, I've updated the description (last section) and added tinyproxy. tinyproxy can be installed from a Linux distribution repo or using brew on OS X.

[mholt]

@giner Thanks, I'll check tinyproxy... it says your last edit on that post was 3 days ago, though. Are you sure it saved?

[giner]

Oh, right. It is saved now.

[mholt]

Now that Go 1.8 is out I have my hands full for a while, so if someone else wants to look into this... that would be great :)

[VanCoding]

I have some trouble proxying websockets as well.
I'm trying to run onlyoffice document server behind caddy, but for some reason onlyoffice establishes a lot of websocket connections when editing a file, and finally loses connection completely after a few seconds. When accessing it directly, it works fine.

Using onlyoffice to debug this won't be helpful as well, I think.
But there's definitely a problem with websockets in the current version.

update
what might be an interesting side note: I run the docker version of onlyoffice document server, which internally has nginx running as reverse proxy for the onlyoffice services. So, it's not onlyoffice that accepts caddy's connections, but nginx.

Browser -> Nginx -> onlyoffice works, but Browser -> Caddy -> Nginx -> onlyoffice does not.

So, it might be interesting to run any websocket application behind Nginx, which itself is behind Caddy, and see what happens.

I'm gonna try this out and let you know the results.

update
tried it with a hello world round tripping app that proxies through caddy and then nginx, and it works fine.
I'm gonna try some more advanced stuff now.

update
tried the same using SockJS, which onlyoffice seems to use under the hood. Works perfectly as well.
So either, the data that gets sent is the problem, or onlyoffice does something weird and caddy is not the problem.

[denniskaselow]

I've got the same problem. Without caddy I don't have a problem.

On the client: the WebSocket connection gets closed after 10 seconds with a CloseEvent.code 1006:

1006 CLOSE_ABNORMAL Reserved. Used to indicate that a connection was closed abnormally (that is, with no close frame being sent) when a status code is expected.

On the server: the connection also gets closed after 10 seconds but with code 1005:

1005 CLOSE_NO_STATUS Reserved. Indicates that no status code was provided even though one was expected.

Those close events are not initiated by my code.

Is there some kind of timeout in caddy that terminates connections after 10 seconds?

[mholt]

@denniskaselow Yes :) Your problem is probably different from the others here. Caddy 0.9.5 has timeouts enabled: https://github.com/mholt/caddy/releases/tag/v0.9.5 - https://caddyserver.com/docs/timeouts that you need to disable. They will be disabled by default in the next release tomorrow.

[VanCoding]

@mholt That was the issue for me as well!
Really strange, because my in my tests, the connection was not closed after 10 seconds...
But does not matter. It works! :)