On Apr 12, 2012, at April 12, 20122:59 PM, Stéphan Kochen wrote: > 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.
So, without getting too deep in to the API proposal, you'd like the "upgrade" event to be passed an HTTP ServerResponse object? > > -- > Stéphan Kochen > Two Screen, Angry Bytes > >
