When using polling a failed request returns with a CORS error.

[nherment]

Hi,

When doing a CORS polling request, if the request fails the verification (here), the browser does not show the error returned by engine.io but show a CORS error instead.

This makes troubleshooting very difficult.

I believe that this is happening because the CORS headers are added only when the request is recognized as xhr-polling.

The CORS headers are supposedly added during the handshake.

Steps to reproduce

2 domains: subA.domain.com subB.domain.com

// this request emerged from a webpage on subA.domain.com
$.get(
    'https://subB.domain.com/engine.io/?EIO=2&transport=polling&sid=thisSidIsNotValid'
  );
XMLHttpRequest cannot load https://subB.domain.com/engine.io/?EIO=2&transport=polling&sid=thisSidIsNotValid. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://subA.domain.com' is therefore not allowed access.

Not sure how easy it would be to fix this.

It's happening with engine.io 0.7.9 but after looking at the code I believe it should be reproducible on the current master branch.

[kapouer]

Isn't this related to #177 ?

[mokesmokes]

What happens if you timestamp the request to bust caching? Cached responses/headers will often screw up cross origin requests. If for some reason your browser cached a same-origin request to the same resource - this is the error you will see when you try to get the resource cross origin.

[nherment]

@kapouer I don't think it is related unless I miss something.

@mokesmokes I tried and it does not help

[mokesmokes]

What does the Chrome network panel show you? Is the request actually going out to the server? Look at the request and response headers, etc.

[nherment]

It is a typical CORS error. I can see the request headers not the response. The server is answering the request with a HTTP 400 code but the browser is blocking the response. I assume it is because the response headers are missing the CORS headers.

I think I understand the problem pretty well. I'd be happy to chat about it over skype or hangout.

[mokesmokes]

Yup, I see it. sendErrorMessage() should be setting CORS headers if required. It's a bug.

[trabus]

I have been experiencing this as well, but have been able to isolate the cause for our situation, and it is scale related.

We are using a hardware load balancer in front of several servers, which was using cookies for stickiness. However, OPTIONS preflights don't usually contain cookies, and so they were getting routed to the wrong server frequently. Because the request was sent to the wrong server, it sees the request coming to a non-existent socket and responds with a 400/Bad request. The response code is contained in the transport, so any misdirected requests will see these errors.

To temporarily fix this, we are intercepting all OPTIONS requests and responding from the load balancer. I would like to propose the idea of responding to all preflight requests from the server level, to mitigate this issue.

I have successfully done this locally already by moving the OPTIONS response code to server.js, but wanted to get thoughts before submitting a pull request.

[mokesmokes]

But the bug occurs even without preflighted requests. I think the fix should be as I wrote in the my previous comment.

[defunctzombie]

@mokesmokes can you provide a patch?

[mokesmokes]

Yup, will do.

[nherment]

Thanks !
Cc @vanchi-zendesk @samshull