lminiero
commented
2 months ago Next, a pre-flight OPTIONS request is made by the browser. The Load Balancer cookie is not included by the browser here.
Sounds like an issue on the client side, then, not Janus. Janus is doing its job by sending the 4xx error on the path it doesn't recognize. As such, not sure what you're asking us to do. Closing as not an issue.
What version of Janus is this happening on? 1.1.3
Have you tested a more recent version of Janus too? Yes
Was this working before? No
Is there a gdb or libasan trace of the issue? no
Additional context I ran into an issue on our servers. We are running Janus on multiple server instances behind a load balancer. For polling, the requests go through the ELB with sticky sessions turned on. Our real-time service on a domain and from that domain we call Janus services, here pre-flight requests (OPTIONS), by browser. Here is what happens on the client when the polling transport is used:
A Janus handshake POST request occurs to create a session. The response comes back valid with an id and the headers include the Load Balancer cookie. Next, a pre-flight OPTIONS request is made by the browser. The Load Balancer cookie is not included by the browser here. As a result, the OPTIONS request is routed to a potentially different server which will not recognize the session (RID and EV) in the query string. When the request is routed to the wrong server, Janus responds with a 4xx HTTP status code. Since the pre-flight request fails, the browser also fails the actual GET polling request and every such pre-flight request fails.
Sometimes, the pre-flight request is made before a call to create session. Load Balancer puts the cookie in response to that pre-flight request. Next Create session request includes the cookie . it worked till here, Next , if there is another Pre-flight request, the cookie is discarded by browser, and ELB sends a new cookie in the response. Next requests are having stale cookies and hence requests are discarded.