Question about load balancing

[Z3NTL3]

So what I am wanting is to load balance with least conn algorithm. But while doing so, I do not want my client to lose his session details as the flow of my app continues. So for that, is it right to use header up to set the session cookie? Look at the example below

flow:
client server request -> backend pick least conn server -> pass cookie header when it is present to uplink server stream -> server receives request

reverse_proxy :5000 :3000 {
    lb_policy least_conn
    header_up  Cookie {cookie.*}
}

[Z3NTL3]

    lb_policy least_conn {
             header cookie
    }
}``` From the docs i see we can provide a header map to upstream specific headers, so this is the best for my purpose right?

[francislavoie]

No, you need to specifically use the cookie policy for it to be sticky. Only that policy considers a cookie value for determining the upstream to choose.

That header_up line is useless, all headers including cookies are sent upstream transparently. That line will probably break the cookies header, actually.

Something I've been considering is making the secondary policy configurable. Currently, most policies just do random as the fallback, but it would be useful to use a different policy instead when falling back.

[Z3NTL3]

No, you need to specifically use the cookie policy for it to be sticky. Only that policy considers a cookie value for determining the upstream to choose.

That header_up line is useless, all headers including cookies are sent upstream transparently. That line will probably break the cookies header, actually.

Something I've been considering is making the secondary policy configurable. Currently, most policies just do random as the fallback, but it would be useful to use a different policy instead when falling back.

But the only supported HMAC hashing is 256 and not 512, my backend uses sha512 not 256 i read from the docs that it will do set cookie when theree was no cookie present.

The only thing i want is upstream a session when it is present not to set a session cookie when it was not present
Is the below config valid for that?

# tbh idk if the syntax is valid but i guess it is<name> [<options...>]
reverse_proxy :5000 :3000 {
    lb_policy least_conn {
          cookie sessionId "secret 1234" # uses sha256 hmac hashing to set cookie when no cookie is present but i wish sha512..
    }
}

[francislavoie]

The only thing i want is upstream a session when it is present not to set a session cookie when it was not present

That's not a supported usecase currently. We could probably make that an option, i.e. read_only to avoid writing a cookie value.

But the only supported HMAC hashing is 256 and not 512, my backend uses sha512 not 256 i read from the docs that it will do set cookie when theree was no cookie present.

Keep in mind that the contents of the hash need to be a precise value, i.e. the upstream address as known by Caddy. You can't use just any session cookie for this. So for that reason, the hashing algorithm Caddy uses doesn't need to match the algorithm your backend uses for sessions. Instead, your backend should use the same hashing algorithm as Caddy for the sticky cookie. To clarify, you would need to use a second cookie for this, your session cookie can't be reused.

Is the below config valid for that?

No, fallback functionality doesn't exist yet.

[francislavoie]

To explain further, the reason your session cookie can't be reused is that this would mean Caddy would need to store in memory the list of all the sessions it has ever seen as a mapping to the upstream we proxied it to. That would use way too much memory. The cookie policy uses no storage, because it delegates the storage to the cookie itself, so the client is the one that stores which upstream it had connected to.

I'm not convinced a read_only option makes sense, because it would mean your upstream needs to be aware of which upstream was chosen (so you'd need to either pass the upstream address as Caddy knows it as a request header upstream, or you'd need to hardcode or guess the upstream address in your backend by the machine it's running on). You should just let Caddy create the cookie itself.

[Z3NTL3]

To explain further, the reason your session cookie can't be reused is that this would mean Caddy would need to store in memory the list of all the sessions it has ever seen as a mapping to the upstream we proxied it to. That would use way too much memory. The cookie policy uses no storage, because it delegates the storage to the cookie itself, so the client is the one that stores which upstream it had connected to.

I'm not convinced a read_only option makes sense, because it would mean your upstream needs to be aware of which upstream was chosen (so you'd need to either pass the upstream address as Caddy knows it as a request header upstream, or you'd need to hardcode or guess the upstream address in your backend by the machine it's running on). You should just let Caddy create the cookie itself.

Can wee see in future that we can choose whether caddy uses sha256 or sha512 to compute the cookie hash, bcs atm only sha256 from what i see, and thnx for the help tbh

[francislavoie]

I don't see any reason to make the hashing algorithm customizable. As I said, the cookie value only makes sense to be controlled by Caddy. But if you wanted to force a specific upstream... if you can compute a sha512 hash, you can also compute a sha256 hash.

[Z3NTL3]

Oke thnx

[francislavoie]

Implemented fallback in #5488

[Z3NTL3]

Implemented fallback in #5488

damn, thanks <3