Provide IP and HTTP headers in both HTTP and Websocket server #120
Conversation
|
Support +1 |
lib/server/parse-websocket.js
Outdated
|
|
||
| params.ip = opts.trustProxy | ||
| ? socket.upgradeReq.headers['x-forwarded-for'] || socket.upgradeReq.connection.remoteAddress | ||
| : (socket.upgradeReq.connection.remoteAddress && socket.upgradeReq.connection.remoteAddress.replace(common.REMOVE_IPV4_MAPPED_IPV6_RE, '')) // force ipv4 |
There was a problem hiding this comment.
Why was the extra socket.upgradeReq.connection.remoteAddress && check needed here? The http case doesn't have that. Can it be removed?
There was a problem hiding this comment.
I was afraid that socket.upgradeReq.connection.remoteAddress could not be exposed in some strange webrtc implementation and we raise an error.
But in that case why not check every member? You're right I will remove it.
|
Actually, come to think of it... any webrtc peer can send a message that contains an Can you update your PR to be more specific about each type of peer by adding an explicit var peer = self.peers[params.addr || params.peer_id]with this instead: var id = params.type === 'ws' ? params.peer_id : params.addr
var peer = self.peers[id]Thoughts? |
|
I think that adding a type to the params makes sense, some might want to know the source of the peer and having consistent keys seems good too. I agree that addr and port does not have the same signification in WS and other servers but I like the idea to have it available. I will update this PR soon to add a type param and remove extra check. Thanks for the review. |
|
|
||
| if (opts.action === 'announce' || s[0] === '/announce') { | ||
| params.action = common.ACTIONS.ANNOUNCE | ||
| params.type = common.PEER_TYPES.http |
There was a problem hiding this comment.
Going to move this out of the if-statement so it's set when the action is 'scrape', too.
Provide IP and HTTP headers in both HTTP and Websocket server
|
7.4.0. |
|
I was not sure about creating the enum in common, just wanted to follow existing patterns. Thank you |
3 participants
It might be useful to have some information about the peer on the tracker.
Since the HTTP server already provides ip address, I did the same in the websocket server.
To go further, I also provided the HTTP headers in both servers.
My use case is GeoIP and User Agent parsing to have statistics on the network.