Set default value for $_SERVER[‘HTTP_HOST’]

Hi @prestonwordsworth,
We can’t go with that approach, as that value is specifically needed for the plugin to work as it is used in many places. So, hardcoding it with some specific domain would be a really bad idea as the plugin is used across multiple domains. Rather, I think it is best for you to see why that value is not there in the first place as it is supposed to be there.

You’re absolutely right, @isaumya. I was wondering too why the value isn’t there in the first place. The WP-CLI handbook, however, has this to say:

The $_SERVER superglobal is an array typically populated by a web server with information such as headers, paths, and script locations. PHP CLI doesn’t populate this variable, nor does WP-CLI, because many of the variable details are meaningless at the command line.

Which appears to imply the superglobal isn’t populated by default. Do you know where $_SERVER is supposed to be defined?

Our fix for now is to do the hardcoding in wp-config.php, which seems to be what they advise.

Hi @prestonwordsworth,
The super global is populated at the server level at the time of processing PHP requests. Moreover this plugin does nothing over CLI. It only process request that actually comes though the browser, I mean real user requests for which the super global is supposed to be there.

Thanks for putting us on the right avenue, @isaumya! For the benefit of those who may have stumbled on the same thing in their error log, here’s the relevant doc:

PHP will create additional elements with values from request headers. These entries will be named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens. For example, the Accept-Language header would be available as $_SERVER['HTTP_ACCEPT_LANGUAGE'].

So ‘HTTP_HOST’ is contents of the Host: header from the current request, if present.

In our specific case, the request came from a user agent belonging to our hosting company. My suspicion is the request was sent directly to our ip address, hence the lack of a Host: header.

Turns out this was caused by bots scanning the site by directly visiting our ip address, which would naturally circumvent CF’s hostname-based WAF. Such traffic can be blocked at server level like this:

SetEnvIfNoCase Host "^\d|^$" bot


# Controls who can get stuff from this server.

    	<RequireAll>
            Require all granted
            Require not env bot
    	</RequireAll>

Hi @prestonwordsworth,
That’s a good finding. Thanks for sharing the server rule for others.