ethstats: fix URL parser for '@' or ':' in nodename

[meowsbits]

Fixes the case (example below) where the value passed to --ethstats flag would be parsed wrongly because the nodename and/or password value contained "special" characters @ or :.

--ethstats "ETC Labs Metrics @meowsbits":mypass@ws://mordor.dash.fault.dev:3000

Stats server unreachable err="malformed ws or wss URL"

[holiman]

Hm, quirky that we didn't use the proper syntax from the beginning, with <protocol>username:password@<location>:

a = new URL("http://userna  me@baz:password@example.com")
URL
hash: ""
host: "example.com"
hostname: "example.com"
href: "http://userna%20%20me%40baz:password@example.com/"
origin: "http://example.com"
password: "password"
pathname: "/"
port: ""
protocol: "http:"
search: ""

[holiman]

name@ws://mordor.dash.fault.dev should also work (without the :)

[holiman]

At least if it worked before...

[meowsbits]

Roger. Not sure if it did before... but it does now 😂

[fjl]

Damn. This is one of these cases where we should really use the stdlib URL parser. It can handle this.

[holiman]

Well, would have been able to handle proper usename:pw-urls, but we used some bastard format, so I doubt it can :)

[karalabe]

I think we can attempt to change it to the standard format. I don't think it's common for anyone to explicitly specify ws or wss. That was important to me to make it work without having to care about SSL or not. So if we assume it's not a used feature, we can move the position of ws:// from the middle out to the front, as long as we keep supporting prefix-less versions. That part is IMHO important because it's rare that stats pages are set up correctly with domains and SSL, so better leave the complexity to be auto-discovered vs dump it onto the user.

[meowsbits]

Another issue is the user info field. Currently the bastard pattern supports arbitrary unencoded user strings, like

"Foundation Benchmarking(mon02)":mypass@example.com:8888
"2Miners.com Ethereum SOLO 🇩🇪":mypass@example.com:8888

(with spaces and delimiters) and stuff. RFC3986 (and the standard lib url.Parse) will require percent-encoding for reserved characters.

Handling this on the backend (doing the encoding before parsing) is obviously possible, but will add complexity.

[fjl]

Thanks for the PR, and sorry for the very delayed review!