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
