Headers only returned for OPTIONS request...?

[Siyfion]

While the correct headers are being returned for an OPTIONS request, I believe that they also need to be returned in the actual request response as well.

As an example, I am using the Access-Control-Allow-Credentials header, the OPTIONS request gets returned correctly, but the actual response does not. Here's the flow:

OPTIONS /api/login HTTP/1.1
Host: labellogiclive.jit.su
Connection: keep-alive
Access-Control-Request-Method: POST
Pragma: no-cache
Cache-Control: no-cache
Origin: http://labellogiclive.jit.su
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Access-Control-Request-Headers: accept, origin, content-type
Accept: */*
Referer: http://labellogiclive.jit.su/user/login
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

HTTP/1.1 204 No Content
x-powered-by: Express
vary: Accept-Encoding
access-control-allow-origin: http://labellogiclive.jit.su
access-control-allow-methods: POST
access-control-allow-headers: accept, origin, content-type
access-control-allow-credentials: true
access-control-allow-max-age: 3600
set-cookie: connect.sess=s%3Aj%3A%7B%7D.RZPCUBnPSt9dBV6%2FCAegqeEuY%2FlfIPlCWM%2Fm9HZS5L%2FUY4xJ9DkQXjPR%2FzN0VLheAaqlk59sgPWU%2FBgTiL9N4Q; Path=/; HttpOnly
date: Mon, 29 Apr 2013 08:35:28 GMT
connection: keep-alive

POST https://labellogiclive.jit.su/api/login HTTP/1.1
Pragma: no-cache
Accept: application/json, text/plain, */*
Referer: http://labellogiclive.jit.su/user/login
Origin: http://labellogiclive.jit.su
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Content-Type: application/json;charset=UTF-8

Then I get an error:
XMLHttpRequest cannot load https://labellogiclive.jit.su/api/login. Credentials flag is true, but Access-Control-Allow-Credentials is not "true".

Looking at the server I can see it's returning a 200 OK response, but it never makes it to the browser. (I'm guessing that the error is generated prior to the response being logged)

[Siyfion]

I think that it's a simple case that the access-control-allow-credentials needs to be in the actual request response, as per:
http://www.w3.org/TR/cors/#resource-requests

In response to a simple cross-origin request or actual request the resource indicates whether or not to share the response.
...
If the resource supports credentials add a single Access-Control-Allow-Origin header, with the value of the Origin header as value, and add a single Access-Control-Allow-Credentials header with the case-sensitive string "true" as value.

[troygoode]

fixed by #4 and published to npm as 1.0.1