want to continue question
How to get pip to work behind a proxy server
I have Windows Server and Python 3.5 (64).
In password my user include #.
I try to use some solve:
"C:\Program Files\Python35\scripts\pip.exe" install --proxy http://proxy_user:email@example.com:1111 TwitterApi
"C:\Program Files\Python35\scripts\pip.exe" install --proxy "http://proxy_user:pwd#123"@proxy.su:1111 TwitterApi
"C:\Program Files\Python35\scripts\pip.exe" install --proxy http://"proxy_user:pwd#123"@proxy.su:1111 TwitterApi
"C:\Program Files\Python35\scripts\pip.exe" install --proxy http://proxy_user:"pwd#123"@proxy.su:1111 TwitterApi
File "c:\program files\python35\lib\site-packages\pip\_vendor\requests\package
s\urllib3\util\url.py", line 189, in parse_url
pip._vendor.requests.packages.urllib3.exceptions.LocationParseError: Failed to p
Quick way out: Enter it in the encoded form i.e.
# -> %23
A better way for pip to handle this might be to add a
--proxy-authflag that takes : and does the encoding for the user before adding it to the Proxy URL.
Issue - This is something not allowed:
Strictly speaking, the literal # character is not valid in the userinfo portion of a URI, according to RFC 3986, and should be percent encoded. However, it's not exactly a surprise that many tools handle this ok: there's clearly no actual ambiguity about that character. Note, however, that if there were an @ symbol in the password you'd definitely have to urlencode it: for that reason, it's a good habit to get into to urlencode your passwords before they go into URIs.
The response to a submitted issue parse_url fails when given credentials in the URL with '/', '#', or '?':
The authority component is preceded by a double slash ("
//") and is terminated by the next slash ("
/"), question mark ("?"), or number sign ("
#") character, or by the end of the URI. In other words, the current behaviour is correct in expecting the authority to be terminated by the first
/(or ? or
#) it finds after the preceeding
//. Am I sympathetic to people trying to use proxy URIs with pip? Absolutely. I think hacking together something that violates the RFC has the potential for nasty surprises later on.