I'm not sure it's meaningful to pass additional headers in this phase of the handshake. Websockets are not HTTP; they are a separate protocol tunneled over HTTP. The websocket protocol does not specify that the server can send additional headers in its handshake (
http://tools.ietf.org/html/rfc6455#section-4.2.2; note that the client side *does* say that clients can send arbitrary additional headers) and client implementations probably wouldn't know what to do with them if the server did send any (for example, there's no place for them to be exposed in the javascript interface:
http://dev.w3.org/html5/websockets/).
As for CORS headers in particular, they should not be required for websockets because websockets are not subject to the usual same-origin policy. Instead, the client reliably reports the origin to the server and it is the server's responsibility to see if the origin is one it expects before trusting any implicit authenticators (cookies or HTTP basic/digest auth). This seems like a risky policy to me since it's very different from the way the rest of the web security model works^H^H^H^H^Hbehaves, but that's how websockets are specified.
-Ben