exposing proxySocket on socket to support sniffing messages coming from proxy target

[thlorenz]

Basically I need access to the proxySocket in order to listen to messages coming back.

I realize the implementation is a bit hacky, but it's the only way I could think of ATM. I'm open for other suggestions.

Here is an example use case taken from chromium-remote-debugging-proxy

socket.on('data', function ondata(data) {
    if (socket.proxySocket) {
      socket.proxySocket.on('data', function ondata(data) {
        retHybi.parse(data)
      })
     socket.proxySocket = undefined;
    }
})

If there is an existing way to make this work, please let me know as well.

[jcrugzz]

@thlorenz what if we emit the proxySocket in an event on the httpProxy instance to be handled separately. It seems like that could work.

[thlorenz]

@jcrugzz that'd be even better cause then I'd know when I can subscribe to its event instead of having to test if its there yet or not.

Do you want me to update the PR to do that? Only question is what's our event emitter? The only one I see inside ws-incoming.js is the server. That'd also be hacky to emit things on the server I guess.

Any other emitters you see?

[thlorenz]

Well, I guess the socket is also an emitter, but that'd be almost equally hacky to emit some event from it.

emit the proxySocket in an event on the httpProxy instance

obviously that'd be ideal, but I don't see that we have access to it from within ws-incoming.js.

[jcrugzz]

@thlorenz naming is just terrible here. The server object thats passed in is the actual proxy instance.

[thlorenz]

OK, will update the PR tonight (will just rewrite it). .emit('proxy-socket', proxySocket) is ok - I mean the event name?

[jcrugzz]

@thlorenz make it proxySocket for consistency with other events. Other than that, just document the event in the readme and I'll merge when ready :).

[thlorenz]

I updated the PR to emit the proxySocket and updated the Readme, but I used a method in the example (hybiParseAndLogMessage) to indicate that you can't just log raw websocket data.
However implementation of that method isn't shown in the example to keep it simple.

Hope that's ok.

[jcrugzz]

LGTM

[jcrugzz]

@thlorenz thanks!

[minrk]

I get TypeError: Object false has no method 'emit' on this line in my code.

[thlorenz]

That is odd, why would the server be a boolean?
We could add a check to keep in from blowing up:

if (typeof server.emit === 'function') server.emit('proxySocket', proxySocket);

but then it'd still suck cause it would emit only sometimes.

[minrk]

It may well be a bug in my code. I create an HTTP server separately, and register proxy methods in its handlers.

[jcrugzz]

Ahh i missed that, fixed in 1.5.1. Its because when a callback is used on the web or ws method, it doesn't pass the instance into the function. Sub-ideal as it is always an event emitter instance now but it didn't always use to be.

[jcrugzz]

@thlorenz its because of this which should be changed. the callback mechanics may need to be tweaked in web-incoming

[thlorenz]

@jcrugzz thanks for fixing and sorry I missed that myself as well.

[glasser]

I'm a little confused as to how people are making use of this feature (renamed to open event in a later release). Am I missing something or is there no way of figuring out which call to proxy.ws this corresponds to (eg by also including req or something like that as an event argument, like the error event gets)?

(Use case: we're proxying to many backends, and want to place a readable event on the proxySocket so that we can learn if a given backend has had any recent traffic.)

[jcrugzz]

@glasser id be ok with emitting multiple arguments on that event. Submit a PR with an ordering that makes sense.