influx CLI includes well-known ports 80 and 443 explicitly in Host:, can break on PaaS

[swhiteman]

Running InfluxDB on one of the well-known ports for HTTP/S, i.e. 80 or 443 -- rather than a custom port like 8086 -- can cause all CLI connections to fail.

This is because the CLI always sends the port, regardless of whether it's custom or WKP. So the Host: header www.example.com:80 or SNI www.example.com:443 goes on the wire.

This is alright if you're connecting directly to the InfluxDB HTTPd, but is a problem when you host InfluxDB inside a container/VM that's published via a reverse proxy (as is required by PaaS hosts and other multitier setups) because every Host: header needs to be explicitly configured on the intermediate proxy.

And

Host: www.example.com:80

is explicitly different from

Host: www.example.com

This condition afflicts, for one example, the CleverCloud PaaS hosting infrastructure.

With CleverCloud, you set your app (regardless of platform -- Go, Java, NodeJs, Docker, etc.) to listen on 8080. Then CC exposes it on port 80 & 443.

That works perfectly for InfluxDB (tweaked from 8086 to 8080) and when you test with cURL everything is fine.

But it fails with the CLI, since CC recognizes and routes http://your.custom.app.name to your app, but not http://your.custom.app.name:80. Because of the explicit port, you end up on their 404 page. (There's no configuration option within CC to add an additional Host: header. You can usually add a Host: if you're running your own reverse proxy, but that obviously doesn't cover all modern deployments.)

I custom-compiled an influx.exe to get around the problem. Not being a Go developer I don't think I should submit a PR but the problem is on Line 82 of client/influxdb.go.

What should happen here is if the port is well-known (80 or 443) there should be no :port appended to the URL. This is fully backward-compatible (it's unthinkable that someone could be listening on host:80 but not on plain host).