On Thursday 12 April 2012 at 23:37, Mikeal Rogers wrote: > The thing is, once there is an UPGRADE, it's not HTTP anymore.
HTTP still specifies that Upgrade must be followed by a response. HTTP only stops when the response is a 101, and the headers have been sent. > Node doesn't offer any core API objects for parsing and encoding to > websockets, it pushes all of that to higher level libraries like socket.io > (http://socket.io), so the current API is "good enough" for them. I humbly disagree. These libraries all duplicate parts of ServerResponse. SockJS has a method `fake_response` just for that. Though the API doesn't limit the library itself, it limits flexibility outside the library, e.g. middleware. > I don't think it's a good idea to emit "request" and create a normal HTTP > ServerRequest object for websockets. I'm open to hearing alternative APIs for > dealing with them but what is the goal of such an API? If it's to add > encoder/decoder objects for websockets in core we might need to push back. I concur, and I don't even think we should emit `request`; the current separation of handlers for upgrade/connect is a good thing. The main benefit is the response object, and using that to incrementally build the response. -- Stéphan Kochen Two Screen, Angry Bytes
