xhr-polling protocol responses should have "no-transform" or a MIME type other than "application/javascript"

Responses to the "/xhr" and "/xhr_send" URLs have "Content-Type: application/javascript". Middlebox compression proxies may attempt to minimize these responses since they look like Javascript code. One typical optimization is newline removal, but this optimization breaks sockjs since xhr-polling uses "\n" as a frame delimiter. For example, see this bug report:
https://code.google.com/p/chromium/issues/detail?id=553828

It is strange to use "Content-Type: application/javascript" since the xhr-polling responses are data, not executable javascript. This confuses compression proxies since the response is not being used as the Content-Type would suggest. The responses aren't even JSON (although I realize JSON can be embedded in the response). I believe sockjs should do one of the following:

1. Set "Cache-Control: no-transform" on the /xhr and /xhr_send responses. Looks like greggman just submitted a change to do exactly this, so you can probably just close this bug "already fixed" :-) See commit https://github.com/sockjs/sockjs-node/commit/7845866b0c1af24795f4a53cbf6a0e8f0468d7b5

2. Use a different Content-Type, such as "application/x-sockjs-xhr-polling" or event "text/plain".

Inspect the /xhr and /xhr_send response handling and compare the current headers with commit 7845866b0c1af24795f4a53cbf6a0e8f0468d7b5. Confirm whether Cache-Control: no-transform or a non-JavaScript MIME type is already present, and verify that newline frame delimiters remain intact.