If we choose to support basic auth to the proxy server in the future, we should probably also support using https to make the "connect" request to the proxy server, so we are not sending the proxy username/password in the clear on the "connect" request's Proxy-Authorization: Basic base64-encoded-proxy-credentials header.
Also, if we choose to support basic auth to the proxy server in the future, we should consider allowing the @ character in usernames and passwords by introducing the \ character as an escape character. Of course, that would also imply that we would need to support escaping the escape character itself, e.g. \\.
Web proxies can also require other auth types, but we're not sure how common those would be. See Proxy-Authorization and Proxy-Authenticate for more information.
In our first draft of supporting web proxies, we decided not to support basic auth usernames and passwords for the
proxy_uriconfiguration option.If we choose to support basic auth to the proxy server in the future, we should probably also support using https to make the "connect" request to the proxy server, so we are not sending the proxy username/password in the clear on the "connect" request's
Proxy-Authorization: Basic base64-encoded-proxy-credentialsheader.Also, if we choose to support basic auth to the proxy server in the future, we should consider allowing the
@character in usernames and passwords by introducing the\character as an escape character. Of course, that would also imply that we would need to support escaping the escape character itself, e.g.\\.Web proxies can also require other auth types, but we're not sure how common those would be. See Proxy-Authorization and Proxy-Authenticate for more information.