[bug] CORS headers are not following specification

[akamensky]

In my code:

io.origins('http://a.local:80');

If I do request from http://b.local:80, the response headers are:

400 Bad Request
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://b.local
Connection: close
Content-Length: 5
Content-Type: application/octet-stream
Date: Fri, 12 Sep 2014 04:24:46 GMT
Server: nginx/1.4.6 (Ubuntu)
Set-Cookie: io=***

Which is wrong because Origin header tells us that we actually are allowed there. This is also incorrect from specification point of view.
From www.w3.org:

The Access-Control-Allow-Origin header indicates whether a resource can be shared based by returning the value of the Origin request header, "*", or "null" in the response.

Same time the standard does not specify response code.

Possible solution:

• Either return Access-Control-Allow-Origin: null (as per specs), or completely drop CORS headers as it will trigger browser to display console error of missing header (latter is my preferred option)
• Suggestion is to change from 400 Bad Request to 403 Forbidden as it more precisely reflects actual status of response (request itself may be not _bad_, but it is not allowed there).

Please vote if you agree and I will provide PR for this issue.

[akamensky]

Please vote if you agree and I will provide PR for this issue

[rauchg]

403 is fine as long as the client handles it like it handles 400 now

[akamensky]

@guille, Client actually does handle them exactly same way, both treated as error response and thus request marked as failed (at least that is how all major browsers do it). The code is more of a conventional way to show humans who check those logs what sort of error happened.

What about first point? should i do option 1 or 2? (1= Access-Control-Allow-Origin: null, 2= no header)

[akamensky]

Okay, look like in fact this bug belongs to engine.io, will close it here and rise new one in that repository.