Invalid info_hash error on tracker server

[Kevin-Deason]

Right out of the box I am having issues.

I download the .zip from here and extract.

install dependencies, create a simple tracker(not client) with the sample code.

it runs, says server is listening on port 1337

but no matter what, all torrents I try to track give invalid info_hash.

I have googled all over and I have found the reason why but nor a solution.

Utorrent sends the infohash as below
%BF k %EA %EF %B6 2 %F1 %87 %D4 %BE A %84 %B4 %03 %CB x9 %01 %EC %A6

and the actual infohash is as below(without spaces)
BF 6B EA EF B6 32 F1 87 D4 BE 41 84 B4 03 CB 78 39 01 EC A6

This is due to the way it should be encoded(as per specification)

Note that all binary data in the URL (particularly info_hash and peer_id) must be properly escaped. This means any byte not in the set 0-9, a-z, A-Z, '.', '-', '_' and '~', must be encoded using the "%nn" format, where nn is the hexadecimal value of the byte. (See RFC1738 for details.)
For a 20-byte hash of \x12\x34\x56\x78\x9a\xbc\xde\xf1\x23\x45\x67\x89\xab\xcd\xef\x12\x34\x56\x78\x9a,
The right encoded form is %124Vx%9A%BC%DE%F1%23Eg%89%AB%CD%EF%124Vx%9A

Any advice as to how to solve this?

Your help would be appreciated

[feross]

You're right -- I've confirmed that this is an issue. I suspect that we're handling the encoding/decoding incorrectly on both the client and server.

[feross]

Thank you for reporting this issue. We were naively using encodeURIComponent and decodeURIComponent which assumes the client will send UTF-8 data to the tracker. However, in practice, clients just urlencode the data (equivalent of the escape and unescape function).

The issue is fixed and published as 2.0.0.