Incorrect hostname lookup when relying on `$_SERVER['HTTP_HOST']`

[erikfrerejean]

Affected Version

Seen on 5.1.0 but probably affects 4.x as well

Description

When using the \SilverStripe\Control\Director::hostName() method to get the hostname of the current request you under certain circumstances get a null when you expect a properly formatted hostname. This happens when \SilverStripe\Control\Director::host() returns the $_SERVER['HTTP_HOST'] header which lacks the protocol of the current request, as defined in the rfc (https://www.rfc-editor.org/rfc/rfc7230#section-5.4) although I've noticed that on certain localhost setups it incorrectly does include the protocol. When calling parse_url with the protocol less value of the HTTP_HOST header (as long there is no port number embedded!) parse_url will assume that it is a path and not the hostname, causing a null to return.

Since the configuration override default_base_url which is used in other cases expects a protocol to be set to be used in this instance you'll end up with inconsistent behavior across environments based upon whether or not the HTTP_HOST or the default_base_url is used to resolve the hostname.

Steps to Reproduce

Not really reproducable steps as it depends on the setup. See: https://3v4l.org/blk8f for the observed behavior.

[GuySartorelli]

Thank you for reporting this. Looks like you might have a way to resolve this based on the output in that link. Would you like to take a stab at implementing a fix?

[erikfrerejean]

@GuySartorelli sure, if Director is the appropriate place to fix this I'll give it a go 👍

[davejtoews]

Seeing this issue on 4.13 as well. Was a real mystery as it only occurred in our Silverstripe Cloud environment, but not in local or other environments.