Proxy weechat relay with caddy

I am trying to connect to my weechat (irc client) relay running behind caddy with glowing-bear (a web client).

I already asked the glowing-bear guys for help: Proxy with caddy · Issue #840 · glowing-bear/glowing-bear · GitHub

They have example configurations for proxies with nginx and apache here.

My current Caddyfile looks like this:

irc.example.com {
    proxy /weechat localhost:9000 {
        header_upstream Host {host}
        websocket
    }
}

Connecting to localhost:9000 directly works just fine. Weechat’s relay on port 9000 is configured to not use TLS.
It works with a self-signed certificate and with glowing-bear connecting to weechat directly.

The problem must be with my caddy setup… Can anybody help?

So you’re getting back an unexpected 400 response code? Sounds like Caddy or your web client is making a bad request to the backend… but what that means for the backend is hard to say for sure. Have you been able to tweak or reduce the problem down more to eliminate some of the complexity and maybe identify where that code is coming in?

Hi, I’m facing this same issue and I think it has to do with one of the headers Caddy is adding when it proxys the request. When I get the raw requests from WeeChat this is what I see with Caddy:

23:48 --> [1] weechat GET /weechat HTTP/1.1
23:48 Host: 127.0.0.1:8001
23:48 User-Agent: Go-http-client/1.1
23:48 Connection: Upgrade
23:48 Sec-Websocket-Key: 57Ss+Zf4hO5yIr6yx5AumA==
23:48 Sec-Websocket-Version: 13
23:48 Upgrade: websocket
23:48 X-Forwarded-For: xxx.xxx.xxx.xxx
23:48 Accept-Encoding: gzip
23:48 
23:48 <-- [1] weechat HTTP/1.1 400 Bad Request

With the nginx config added below (which is working) I see the following:

23:33 --> [1] weechat GET /weechat HTTP/1.1
23:33 Upgrade: websocket
23:33 Connection: upgrade
23:33 Host: weechat
23:33 Sec-WebSocket-Key: YG3fFz5tp38lwOsxz45/Yw==
23:33 Sec-WebSocket-Version: 13
23:33 
23:33 <-- [1] weechat HTTP/1.1 101 Switching Protocols
23:33 Upgrade: websocket
23:33 Connection: Upgrade
23:33 Sec-WebSocket-Accept: 3ZqCrujw+6rssCmfO+aOH4zczFU=

Here is the nginx config I am using:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}                                                                                                                                                                         
upstream weechat {
    server 127.0.0.1:8001;
}

server {
    listen       443 ssl;
    server_name  _;

    ssl_certificate ...;
    ssl_certificate_key ...;

    location /weechat {
        proxy_pass http://weechat;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_read_timeout 8h;
    }
}

And the caddy config I am using:

my-domain.com:9000 {
    proxy /weechat http://127.0.0.1:8001 {
        websocket
    }

    log stdout
    errors stdout
}

I have also tried to isolate the issue by preventing caddy from sending the extra headers (Accept-Encoding, User-Agent & X-Forwarded-For) to the backend but either it is not possible to remove these headers or I am doing something wrong. The config I used for that was:

my-domain.com:9000 {
    proxy /weechat http://127.0.0.1:8001 {
        header_upstream -Accept-Encoding
        header_upstream -User-Agent
        header_upstream -X-Forwarded-For

        websocket
    }

    log stdout
    errors stdout
}

If you think this is a bug in Caddy, could you please open an issue on GitHub so we don’t forget about it?

Thanks.

I’d be interested in the outcome of this, too - I tried Weechat/Glowing Bear a while back but ran into issues (I didn’t document them at the time unfortunately), I eventually gave up on them and am using Lounge & ZNC instead, which I’m not 100% happy with so far.

[quote=“matt, post:4, topic:801”]
If you think this is a bug in Caddy, could you please open an issue on GitHub so we don’t forget about it?

Thanks.[/quote]

Well I’m not sure if those headers should be possible to be removed? If you think they should be removable then I will create an issue.

I had a read of the source code & it doesn’t seem as though Caddy is adding them so if I’m right about that then they must be added by the go networking library.

1 Like

Open an issue on Github anyway, because either the header stripping is not working properly, or the documentation is incomplete and should also include a list of headers that can’t be stripped.

1 Like

Just wanted to add a link here to the issue. Summary of the outcome being that Caddy is behaving correctly and it was a bug in WeeChat which will be fixed in their next release.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.