As it stands now, `http.js` behavior for upgrade requests is to rid itself of responsibility for the socket the moment it sees one.
Right off the bat I'd like to ask: Is there a particular reason why we can't have a proper response object for Upgrade requests? Per the HTTP 1.1 spec, even Upgrade requests *must* be followed by a response, 101 or otherwise. Are changes to the `upgrade` event API possible (for 0.8 or later), or is that right out? Besides the API, I can trigger some possibly undesired behavior: On both 0.6.13 and 0.7.6, because we have no response object for upgrade requests, these responses are not queued like the others. This is probably unusual client behavior, but imagine there's one that pipelines the following two requests: GET / HTTP/1.1 Host: localhost:3000 Accept: */* GET / HTTP/1.1 Host: localhost:3000 Connection: Upgrade Upgrade: dummy I can't find anything in the spec that says this is wrong. In Node, it can trigger out-of-order responses on servers that take time to process the regular GET, but respond immediately to the Upgrade. Take the following example server: var http = require('http'); var server = http.createServer(); server.on('request', function(req, res) { // Artificially delay. setTimeout(function() { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }, 500); }); server.on('upgrade', function(req, sock, head) { sock.write("HTTP/1.1 101 Switching Protocols\r\n" + "Upgrade: dummy\r\n" + "Connection: Upgrade\r\n" + "\r\n"); // Keep it open for a while, // or we won't see the other response. setTimeout(function() { sock.end(); }, 1000); }); server.listen(3000, '127.0.0.1'); Fire the two requests at this server with something like netcat, and it responds as follows: HTTP/1.1 101 Switching Protocols Upgrade: dummy Connection: Upgrade HTTP/1.1 200 OK Content-Type: text/plain Date: Thu, 29 Mar 2012 09:50:29 GMT Connection: keep-alive Transfer-Encoding: chunked c Hello World 0