is_apache in vars.php does not always work

[amandato]

The $is_apache variable does not always work when using an Apache module like security2_module with the SecServerSignature option. By removing the word "Apache" from the name of the server vars.php will no longer detect that the server is Apache.

A simple solution is to add an addition check:

function_exists('apache_get_version')!== false

Any Apache only function will work.

See attached patch from WP 4.4.2

I discovered this caused issues with the RewriteRules, randomly WordPress would add index.php/ within the permalinks when editing the permalink options in the wp-admin.

Not sure if this should be called a bug or an enhancement, leave it up to core team to decide that.

I would not remove the first 2 checks though, it is possible that the apache_get_version is disabled in the php.ini. I would recommend adding the option to the current checks just to be 100% sure.

[amandato]

Patch for this ticket from WinMerge (let me know if you need a different patch format)

[amandato]

Did I place this ticket in the right component?

[lllor]

Hello,
what happened to the patch? do you need another patch format? The bug still exists in the latest version...

[lllor]

Well, alternative solution:

in wp-config.php

$_SERVERSERVER_SOFTWARE? = "Apache";

[crobbinsdg]

I've encountered instances where the Server header lacks explicit mention of Apache or LiteSpeed. It's worth noting that as of 2024, it is common to see the Server header removed as a security best practice or changed through popular proxy cache services.

The OWASP Secure Headers Project explicitly advises removing the Server header to minimize potential information disclosure.
​https://owasp.org/www-project-secure-headers/#prevent-information-disclosure-via-http-headers

Cloudflare's widely used proxy cache service defaults to replacing the Server header value with "cloudflare".

In my experience, numerous WordPress security and caching plugins rely on variables such as $is_apache, $is_nginx, $is_IIS, and $is_iis7 to determine how to configure their features.

If better defining these variables proves challenging, a potential solution could involve providing more formal ways for developers to explicitly define their environment. This could be achieved through methods like wp-config definitions, offering an alternative way to convey this critical information.