You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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 anull
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 callingparse_url
with the protocol less value of theHTTP_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 theHTTP_HOST
or thedefault_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.
The text was updated successfully, but these errors were encountered: