Looks like the python bitcoinrpc authproxy stuff uses python "urlparse" that chokes on "/" in passwords.
AFAICT (?) it's python that is in the wrong here, but broken httpauth handling is common.
I used base58 encoding for the old code that would provide a suggested rpcpassword when you tried to run the daemon without one. I think base58 is free of any characters that will screw up url handling... and there are no compatibility issues with just changing what cookieauth uses.
This is very odd. The password is encoded as base64 before sending it in a HTTP header. It should never end up in an URL. Where are you seeing this? Can you provide a traceback?
(to be clear, I think changing it to use base58 makes sense, but I get slightly worried if passwords end up in URLs)
Hmm I think I get the URL part; it's not about the HTTP protocol itself, but the endpoint is encoded in the form http://user:pass@127.0.0.1/.
In this case you need to url-encode the password. So this doesn't work:
http://user:/PASS/@127.0.0.1/`
But this should:
http://user:%2FPASS%2F@127.0.0.1/`
It can be dangerous to skip this quoting step (use urllib.quote('/PASS/','')).
Edit: I've checked RFC2617:
basic-credentials = base64-user-pass
base64-user-pass = <base64 [4] encoding of user-pass, except not limited to 76 char
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
So in the password every ASCII character is allowed, in the userid any character except :. I don't mind to restrict the set of characters here, on the other hand if this fails this is indicative of improper input escaping, which have other risks.
GAH, even the %2F escaping doesn't work, as Python urlparse, which is used inside that AuthServiceProxy constructor won't unescape it:
>>> x=urlparse.urlparse("http://1234:%2F4567%2F@t%3Fest.com")
>>> x.password
'%2F4567%2F'