CORS preflight requests and Load Balancer sessions

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.

Thanks, Alfonso


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!

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.


according to the following stackoverflow common browsers would ignore Cookies being set in response to pre-flight OPTIONS requests (in 2017 already), such that this problem should not usually be triggered:

Best, Andreas