hostnames containing underbar should lead to CF-RouteInvalid error

[jsievers]

Issue

cf push can create routes with invalid hostnames containing the underbar character.

Context

cf push --hostname test_underbar succeeds and the app can be accessed, but the route registered

urls: test_underbar.<APPS_DOMAIN>

is using an invalid hostname according to
https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames

because it contains an underbar character.
This can lead to problems with clients that validate the URL.
E.g.
new java.net.URI("https://test_underbar.sample.com").getHost()

returns null

Steps to Reproduce

push any sample app with underbar in the hostname
cf push --hostname test_underbar

Expected result

cf push should fail with an error message. Actually if you try using other invalid characters like e.g. % (percent), you get an error message:

FAILED
Server error, status code: 400, error code: 210001, message: The route is invalid: host format

I would expect a similar error message for hostnames containing the underbar character.

If you try to push e.g. a hostname containing spaces,

$ CF_TRACE=true cf push --hostname 'a b'
Creating route a%20b.<APP_DOMAIN>
OK

REQUEST: [2017-07-26T09:13:47+02:00]
POST /v2/routes?async=true&inline-relations-depth=1 HTTP/1.1
Host: api.<REDACTED>
Authorization: [PRIVATE DATA HIDDEN]
Connection: close
Content-Type: application/json
User-Agent: go-cli 6.28.0+9e024bdbd.2017-06-27 / darwin

{"host":"a b","domain_guid":"9aa474f9-3f82-4967-a2e1-dfe0cd155064","space_guid":"d2451f2a-2672-492f-afd7-b61cc56bcce0"}

RESPONSE: [2017-07-26T09:13:48+02:00]
HTTP/1.1 400 Bad Request
Connection: close
Content-Length: 110
Content-Type: application/json;charset=utf-8
Date: Wed, 26 Jul 2017 07:13:43 GMT
Server: nginx
X-Content-Type-Options: nosniff
X-Ratelimit-Limit: 80000
X-Ratelimit-Remaining: 79988
X-Ratelimit-Reset: 1501056803
X-Vcap-Request-Id: 306c9e27-27a1-47e1-7581-6b4ed6d3adde
X-Vcap-Request-Id: a4b6f3d2-84a4-4027-7dea-313764ddc8a6::42fea190-d8b3-4e68-a1d0-76959b5342cd

{
  "description": "The route is invalid: host format",
  "error_code": "CF-RouteInvalid",
  "code": 210001
}

OK

FAILED
Server error, status code: 400, error code: 210001, message: The route is invalid: host format

you see that it tries to URL-encode the hostname 'a b' to 'a%20b' which would be correct for the path segment of a URL, but not for a hostname.

By contrast, if you specify underbars in the app name (not the host), the route created will automatically have underbars (or spaces for that matter) replaced by dashes to form a valid hostname:

$ cf push test_underbar

Creating route test-underbar.<APP_DOMAIN>
OK

Binding test-underbar.<APP_DOMAIN> to test_underbar...

Since 'host' can also be used to specify a subdomain, not sure how to distinguish this scenario because for subdomain names, underbar is allowed according to

https://en.wikipedia.org/wiki/Hostname#Restrictions_on_valid_hostnames
and
https://stackoverflow.com/questions/2180465/can-domain-name-subdomains-have-an-underscore-in-it

Current result

cf push succeeds and the route with an invalid hostname is created.

Possible Fix

validate host name and return CF-RouteInvalid error for hostnames containing characters other than upper/lowercase a-z, 0-9 or or dash.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/149548999

The labels on this github issue will be updated when the story is started.

[ljfranklin]

@zrob seems like an easy bit of validation to add. Seem like something the community pair could pick up?

[tcdowney]

@jsievers I think @zrob was leaning towards leaving out this validation as some CF users may already have apps with underscores in the hostname that we wouldn't want to break, so we'll hold off on this for the moment.

[zrob]

@jsievers we took a stab at solving this, but found issues for users that already had routes with underscores. because this change may break existing users and b/c in reality these routes function fine with most devices, we're going to keep the lenient validation.