New issue
Advanced search Search tips

Issue 677325 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

net/ has two methods to split a "host:port" string.

Project Member Reported by mmenke@chromium.org, Dec 28 2016

Issue description

1)  HostPortPair::FromString creates a host port pair.  It works by splitting a string around all ":"'s, and if there are two members in the resulting vector, trying to parse the second as a valid port number.  This does not work on IPv6 hosts (Despite HostPortPair::ToString() adding brackets around IPv6 hosts, and HostPortPair::From string claiming it does the oppose of what what HostPortPair::ToString does).  On failure, it just returns an empty HostPortPair.

2)  url_util.cc has ParseHostAndPort.  This uses url::ParseAuthority to post the string as if it were part of a URL.  It fails if there's a username/password, or no hostname or port, or if the port component is length 0 (So only works on "host:port" with non-empty host/ports, and disallows @'s in the hostname), and removes "[]"'s around IPv6 hostnames.  It relies on whatever port number validation GURL uses.

Having two different implementations of methods to get host+port from strings seems like a bad idea, unless there's a real need for it.  It seems to me like ParseHostAndPort is the more correct method, and we should switch HostPortPair over to using it, behind-the-scenes, unless there's a compelling reason not to.
 

Comment 1 by mmenke@chromium.org, Dec 28 2016

Also worth mentioning ParseHostAndPort may be more computationally expensive.  I don't think we call it that often.  If that's a real concern, it would probably still make more sense to get them both doing the same thing, after improving one or the other of them.

Comment 2 by mmenke@chromium.org, Dec 28 2016

Components: Internals>Network
And, for the record, looks like ParseHostAndPort may allow lone hostnames, just not lone hostnames followed by a colon and no port number, so there's one potential difference we may need to keep.
Project Member

Comment 3 by sheriffbot@chromium.org, Feb 15 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by mmenke@chromium.org, Feb 15 2018

Status: WontFix (was: Untriaged)
No time to work on this.  :(

Comment 5 by eroman@chromium.org, Feb 15 2018

On a bit of a related tangent, the nomenclature around "host" strings is a continuing source of bugs.

Is it a URL "host" which may be decorated by brackets, or is it a host that can be passed to the name resolution layer).

For a recent example see https://bugs.chromium.org/p/chromium/issues/detail?id=797778 and all the confused callsites.

Comment 6 by eroman@chromium.org, Feb 15 2018

On a related tangent, the nomenclature around "host" strings is a
continuing source of bugs.

Is it a URL "host" which may be decorated by brackets, or is it a host that
can be passed to the name resolution layer)?

For a recent example see
https://bugs.chromium.org/p/chromium/issues/detail?id=797778 and the
confused callsites.

Comment 7 by eroman@chromium.org, Feb 15 2018

On a related tangent, the nomenclature around "host" strings is a
continuing source of bugs.

Is it a URL "host" which may be decorated by brackets, or is it a host that
can be passed to the name resolution layer)?

For a recent example see
https://bugs.chromium.org/p/chromium/issues/detail?id=797778 and the
confused callsites.

Comment 8 by eroman@chromium.org, Feb 15 2018

On a related tangent, the nomenclature around "host" strings is a
continuing source of bugs.

Is it a URL "host" which may be decorated by brackets, or is it a host that
can be passed to the name resolution layer)?

For a recent example see
https://bugs.chromium.org/p/chromium/issues/detail?id=797778 and the
confused callsites.

Comment 9 by eroman@chromium.org, Feb 15 2018

On a related tangent, the nomenclature around "host" strings is a
continuing source of bugs.

Is it a URL "host" which may be decorated by brackets, or is it a host that
can be passed to the name resolution layer)?

For a recent example see
https://bugs.chromium.org/p/chromium/issues/detail?id=797778 and the
confused callsites.
On a related tangent, the nomenclature around "host" strings is a
continuing source of bugs.

Is it a URL "host" which may be decorated by brackets, or is it a host that
can be passed to the name resolution layer)?

For a recent example see
https://bugs.chromium.org/p/chromium/issues/detail?id=797778 and the
confused callsites.
On a related tangent, the nomenclature around "host" strings is a
continuing source of bugs.

Is it a URL "host" which may be decorated by brackets, or is it a host that
can be passed to the name resolution layer)?

For a recent example see
https://bugs.chromium.org/p/chromium/issues/detail?id=797778 and the
confused callsites.

Sign in to add a comment