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.
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
Click below to sign up and get $100 of credit to try our products over 60 days!