Skip IPv6 probes when resolving IPv4 literals. The probes aren't

Skip IPv6 probes when resolving IPv4 literals.  The probes aren't
necessary as they at most restrict to IPv4 results which doesn't change
the resolver's result for IPv4 literals.

BUG=453456
Committed: https://crrev.com/370f1c72d1c40e64d977f5514c999fdf625caa6c
Cr-Commit-Position: refs/heads/master@{#316589}

[mmenke, 2015-02-13 15:03:27]

mmenke@chromium.org changed reviewers:
+ mmenke@chromium.org

[mmenke, 2015-02-13 15:03:27]

https://codereview.chromium.org/926593003/diff/1/net/dns/host_resolver_impl.cc
File net/dns/host_resolver_impl.cc (right):

https://codereview.chromium.org/926593003/diff/1/net/dns/host_resolver_impl.c...
net/dns/host_resolver_impl.cc:2165: &num_components) !=
url::CanonHostInfo::IPV4) {
Doing this twice seems weird...Maybe we should just do the ResolveAsIP call
first?  I suppose if we care about not resolving IPv6 literals when we have no
IPv6 support, we still have to do the probe, but I'm skeptical whether we really
get anything from that.

[pauljensen, 2015-02-13 15:33:09]

https://codereview.chromium.org/926593003/diff/1/net/dns/host_resolver_impl.cc
File net/dns/host_resolver_impl.cc (right):

https://codereview.chromium.org/926593003/diff/1/net/dns/host_resolver_impl.c...
net/dns/host_resolver_impl.cc:2165: &num_components) !=
url::CanonHostInfo::IPV4) {
On 2015/02/13 15:03:27, mmenke wrote:
> Doing this twice seems weird...Maybe we should just do the ResolveAsIP call
> first?  I suppose if we care about not resolving IPv6 literals when we have no
> IPv6 support, we still have to do the probe, but I'm skeptical whether we
really
> get anything from that.

I changed the code to parse it just once.  WDYT?

[pauljensen, 2015-02-13 15:34:51]

Hmm, perhaps adding the ip_literal to the Key makes more sense.

[pauljensen, 2015-02-13 15:36:26]

On 2015/02/13 15:34:51, pauljensen wrote:
> Hmm, perhaps adding the ip_literal to the Key makes more sense.

Hmm, maybe not.  Key is mostly for HostCache usage.

[mmenke, 2015-02-13 16:20:08]

On 2015/02/13 15:36:26, pauljensen wrote:
> On 2015/02/13 15:34:51, pauljensen wrote:
> > Hmm, perhaps adding the ip_literal to the Key makes more sense.
> 
> Hmm, maybe not.  Key is mostly for HostCache usage.

I'm having enough trouble figuring out what's going on with set 2 that I think
set 1 is much preferable.

[pauljensen, 2015-02-13 18:26:31]

On 2015/02/13 16:20:08, mmenke wrote:
> On 2015/02/13 15:36:26, pauljensen wrote:
> > On 2015/02/13 15:34:51, pauljensen wrote:
> > > Hmm, perhaps adding the ip_literal to the Key makes more sense.
> > 
> > Hmm, maybe not.  Key is mostly for HostCache usage.
> 
> I'm having enough trouble figuring out what's going on with set 2 that I think
> set 1 is much preferable.

Done.  Went back to PS 1.

[mmenke, 2015-02-13 18:29:58]

On 2015/02/13 18:26:31, pauljensen wrote:
> On 2015/02/13 16:20:08, mmenke wrote:
> > On 2015/02/13 15:36:26, pauljensen wrote:
> > > On 2015/02/13 15:34:51, pauljensen wrote:
> > > > Hmm, perhaps adding the ip_literal to the Key makes more sense.
> > > 
> > > Hmm, maybe not.  Key is mostly for HostCache usage.
> > 
> > I'm having enough trouble figuring out what's going on with set 2 that I
think
> > set 1 is much preferable.
> 
> Done.  Went back to PS 1.

LGTM.  Having both ResolveAsIP and ParseIPLiteralToNumber with completely
different behavior was why I found set 2 so confusing.

[pauljensen, 2015-02-13 19:56:32]

New patchsets have been uploaded after l-g-t-m from mmenke@chromium.org

[pauljensen, 2015-02-17 16:08:16]

The CQ bit was checked by pauljensen@chromium.org

[commit-bot: I haz the power, 2015-02-17 16:08:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/926593003/60001

[commit-bot: I haz the power, 2015-02-17 16:59:23]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2015-02-17 17:00:32]

Patchset 4 (id:??) landed as
https://crrev.com/370f1c72d1c40e64d977f5514c999fdf625caa6c
Cr-Commit-Position: refs/heads/master@{#316589}