When using DO’s managed Load Balancers with sticky sessions the LB adds a cookie to “mark” which LB node has served that request and keep sending further requests to the same node.

However, when CORS preflight requests are involved (often for any kind of API service), the client doesn’t send any pre-existing cookies back with the OPTIONS preflight requests (this is as defined by the protocol).
In those cases, the LB would just pick a node based on the current policy and send a new cookie back with the response. This will cause the client to send back the new value for the cookie with subsequent requests, effectively switching to a different node in the LB.

I don’t think there’s much that the client can do to “force” the original cookie - since the trace is lost in the preflight request. However, I’m wondering if there is anything that I’m missing and that would help.

Alternatively, would there be an alternative mechanism that DO could implement (e.g. headers) that might pass through the preflight phase?
Or even just not setting the cookie in the responses to OPTIONS requests, to allow the client to keep the old value.


Submit an answer

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!