Fix handling of setting a single proxy in Proxy Settings API

Fix handling of setting a single proxy in Proxy Settings API

Previously, setting a singleProxy entry in the Proxy Settings API meant that we set http, https, and ftp proxies individually. I.e. the Proxy settings was "http=http://foo;https=https://foo;ftp=ftp://foo". With this change it becomes "foo".

BUG=67779
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=74286

[battre, 2011-02-02 12:35:50]

Please review or dispatch to another reviewer. Thanks.

[eroman, 2011-02-08 01:11:07]

LGTM.

I think I see a bug in the forming of host:port strings, however feel free to
address that as a separate changelist, doesn't need to block this one.

http://codereview.chromium.org/6312088/diff/1/chrome/browser/extensions/exten...
File chrome/browser/extensions/extension_proxy_api.cc (right):

http://codereview.chromium.org/6312088/diff/1/chrome/browser/extensions/exten...
chrome/browser/extensions/extension_proxy_api.cc:193: proxy_pref.append(":");
It is not generally safe to form host:port pairs simply by concatenating
hostname and ports.

Can you use net::ProxyServer here instead?

A specific case which won't work is IPv6 literals.
Unfortunatly in IPv6, colon is a possible character in the IP address.

So if the host was say ::1 and the port was "80", it would be wrong to form the
concatenated destination as ::1:80. Instead the IPv6 literal needs to be
enclosed in square brackets:

[::1]:80

To avoid these problems, we use HostAndPortPair::ToString() to form the correct
string in cases when the hostname is an IP literal.

I realize that problem is not new with this change, but the new code seems to be
continuing the same problem.

I am ok with handling this issue separately (don't need to do it as part of this
CL).