On Thursday 12 April 2012 at 23:13, Isaac Schlueter wrote: > This is definitely a wart in the API, but not one that we're likely to > fix in v0.8. It may require rethinking a few things, and we are not > prepared to make major changes to the HTTP layer right now.
Noted. This seems to be the consensus. For the record, between the previous post and now, there's been some discussion on a pull request I opened for the branch: https://github.com/joyent/node/pull/3036 I've also reached out to WebSocket library authors on Twitter, and all around, everyone seems to value backwards compatibility a lot more than I do. A learning moment. :) > Can you write up the feature request as an issue? Let's get it on the > list for v0.9. I can open a separate issue on it, if you want. It basically boils down to having a ServerResponse for these requests as well. Today, I moved ahead and implemented this in Connect. It touches some ServerResponse private stuff I believe, and of course distances itself from the Node.js event listener signature. But the main benefit here is that existing middleware works swell this way, using the same code path. The Connect branch is over at: https://github.com/stephank/connect/tree/upgrade-response Hopefully, this will work better as a practical example. The list of stock Connect middleware that can be applied to upgrade requests this way is not small, basically anything that doesn't deal with the request or response body: basicAuth, cookieParser, cookieSession, csrf, errorHandler, logger, methodOverride, query, responseTime, session. -- Stéphan Kochen Two Screen, Angry Bytes
