Lb_policy cookie issues with confluence

[nnbmpf]

Hi,

1. The problem I’m having:

Hi, we using Confluence Datacenter and caddy as Loadbalancer
Who does not know what is confluence - its a application where you can create pages and documentation and you can use collaborative editing like in google docs for example.

Example Config:

                reverse_proxy /synchrony/* {
                        to con01:8091 con02:8091
                        lb_policy cookie
                }

                reverse_proxy * {
                        to con01:8090 con02:8090
                        lb_policy cookie
                }

Confluence using a service called synchrony to manage the collaborative editing.

The problem is now:
If we log in to Confluence, we might land on node 1 and get a cookie set, but if we then edit a page, Confluence calls the block under /synchrony/* and there the lb_policie cookie also takes effect and sets a new cookie for e.g. node 2 and overwriting the first cookie. My expectation would have been, caddy sees there is already a cookie in the browser session and doesn’t set the set-cookie header again. But caddy does and I have to log in again and again.
Is there anything I can do about this? Can i connect somehow the block for * and /synchrony/* for using the same cookie (policie)?

2. Error messages and/or full log output:

I have no error messages

3. Caddy version:

v2.6.4 h1:2hwYqiRwk1tf3VruhMpLcYTg+11fCdr8S3jhNAdnPy8=

4. How I installed and ran Caddy:

apt install caddy

a. System environment:

Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy

[francislavoie]

The cookie value stores the actual upstream address used. If the available upstream addresses in one reverse_proxy is different than the other, then it’s impossible to synchronize them.

One way you could hack it is by making a second proxy layer in Caddy itself (i.e. have Caddy proxy to itself) then to the correct upstream.

example.com {
	reverse_proxy {
		to :8001 :8002
		lb_policy cookie
	}
}

:8001 {
	reverse_proxy /synchrony/* con01:8091
	reverse_proxy con01:8090
}

:8002 {
	reverse_proxy /synchrony/* con02:8091
	reverse_proxy con02:8090
}

This way the routing decision is made by a virtual site, but the connection selection is done by a single proxy.