Update minimum supported Apache version to >= 2.4.7

I agree with specifying Apache 2.4.7 as the minimum version.

+1 from me as well.

Unfortunately RHEL/CentOS 7 appear to ship with 2.4.6. I am not sure if the setifempty option has been backported to these packages.

If this is only a recommendation, “specifying Apache 2.4.7 as the minimum version” is OK.

I would not want to see sites stop running because for various reasons they cannot update their Apache stack.

The preferred way of resolving #2854817: Duplicate X-Content-Type-Options headers both with the value nosniff would make it incompatible with Apache 2.4.6 and earlier. It would also be an easy fix to manually change the htaccess file to remove the incompatibility if someone is stuck for some reason. (How can someone be secure using such an old version?)

@Liam Morland in the case of RHEL/CentOS, Red Hat backport all applicable security fixes but no new features.

Just tested and it looks like this is a no go on RHEL/CentOS 7 unfortunately. These distros are supported with security updates until 2024 - although it is worth noting that to run Drupal they already need additional PHP packages, as they only ship with PHP 5.4 out of the box.

$ docker run -it --rm centos:7 /bin/bash

[root@a36f7ed1cb7a /]# cat /etc/redhat-release 
CentOS Linux release 7.7.1908 (Core)

[root@a36f7ed1cb7a /]# yum install httpd
...
---> Package httpd.x86_64 0:2.4.6-90.el7.centos will be installed

[root@a36f7ed1cb7a /]# httpd -V    
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using 172.17.0.2. Set the 'ServerName' directive globally to suppress this message
Server version: Apache/2.4.6 (CentOS)
Server built:   Aug  8 2019 11:41:18
...

[root@a36f7ed1cb7a /]# echo "Header setifempty X-Content-Type-Options nosniff" > /etc/httpd/conf.d/test.conf
[root@a36f7ed1cb7a /]# httpd -t
AH00526: Syntax error on line 1 of /etc/httpd/conf.d/test.conf:
first argument must be 'add', 'set', 'append', 'merge', 'unset', 'echo', 'edit', or 'edit*'.

For the sake of completeness: on the .deb side of the fence, everything is fine even Ubuntu 16.04 is 2.4.18 https://launchpad.net/ubuntu/xenial/+source/apache2 and the stable-before-oldstable Debian which still has support until this summer https://packages.debian.org/jessie/apache2 is 2.4.10

To give you an idea just how old this stuff is, XAMPP is a good example: when they went 2.4.7 six years ago they also shipped PHP 5.5 and MySQL 5.6. https://www.apachefriends.org/blog/news-article-232017.html

RHEL life cycles are a complex animal. https://endoflife.software/operating-systems/linux/red-hat-enterprise-li... If we take the End of Full Support, RHEL 7 is already dead and by the time 8.9 / 9.0 releases End of Maintenance Support 1 will also be practically upon us but if we wanted to support RHEL in all its stages then even RHEL 5.0 (!) is not fully out of support. Since you can't run an unchanged RHEL 7 already anyways, is it very ardous to require a newer Apache as well?

It seems reasonable to me to require the lowest version that enables #3114079-7: Update minimum supported Apache version to >= 2.4.7 to be resolved. People on older versions aren't completely stuck - they can modify the .htaccess.

We've been basing PHP and database requirements on the most recent LTS releases for things like RHEL and Debian, not the oldest ones still in support, so I think it's OK to require an upgrade (either of apache or distribution) for the very oldest cases.

RTBCing but also tagging to get an extra +/-1 from xjm before we change the docs. And adding various tags.

We need a follow-up issue to make the code changes then.

update system_requirements() has heaps of stuff about Apache 2.2.16...

  // Tests clean URL support.
  if ($phase == 'install' && $install_state['interactive'] && !$request_object->query->has('rewrite') && strpos($software, 'Apache') !== FALSE) {
    // If the Apache rewrite module is not enabled, Apache version must be >=
    // 2.2.16 because of the FallbackResource directive in the root .htaccess
    // file. Since the Apache version reported by the server is dependent on the
    // ServerTokens setting in httpd.conf, we may not be able to determine if a
    // given config is valid. Thus we are unable to use version_compare() as we
    // need have three possible outcomes: the version of Apache is greater than
    // 2.2.16, is less than 2.2.16, or cannot be determined accurately. In the
    // first case, we encourage the use of mod_rewrite; in the second case, we
    // raise an error regarding the minimum Apache version; in the third case,
    // we raise a warning that the current version of Apache may not be
    // supported.
    $rewrite_warning = FALSE;
    $rewrite_error = FALSE;
    $apache_version_string = 'Apache';

    // Determine the Apache version number: major, minor and revision.
    if (preg_match('/Apache\/(\d+)\.?(\d+)?\.?(\d+)?/', $software, $matches)) {
      $apache_version_string = $matches[0];

      // Major version number
      if ($matches[1] < 2) {
        $rewrite_error = TRUE;
      }
      elseif ($matches[1] == 2) {
        if (!isset($matches[2])) {
          $rewrite_warning = TRUE;
        }
        elseif ($matches[2] < 2) {
          $rewrite_error = TRUE;
        }
        elseif ($matches[2] == 2) {
          if (!isset($matches[3])) {
            $rewrite_warning = TRUE;
          }
          elseif ($matches[3] < 16) {
            $rewrite_error = TRUE;
          }
        }
      }
    }
    else {
      $rewrite_warning = TRUE;
    }

    if ($rewrite_warning) {
      $requirements['apache_version'] = [
        'title' => t('Apache version'),
        'value' => $apache_version_string,
        'severity' => REQUIREMENT_WARNING,
        'description' => t('Due to the settings for ServerTokens in httpd.conf, it is impossible to accurately determine the version of Apache running on this server. The reported value is @reported, to run Drupal without mod_rewrite, a minimum version of 2.2.16 is needed.', ['@reported' => $apache_version_string]),
      ];
    }

    if ($rewrite_error) {
      $requirements['Apache version'] = [
        'title' => t('Apache version'),
        'value' => $apache_version_string,
        'severity' => REQUIREMENT_ERROR,
        'description' => t('The minimum version of Apache needed to run Drupal without mod_rewrite enabled is 2.2.16. See the <a href=":link">enabling clean URLs</a> page for more information on mod_rewrite.', [':link' => 'http://drupal.org/docs/8/clean-urls-in-drupal-8']),
      ];
    }

    if (!$rewrite_error && !$rewrite_warning) {
      $requirements['rewrite_module'] = [
        'title' => t('Clean URLs'),
        'value' => t('Disabled'),
        'severity' => REQUIREMENT_WARNING,
        'description' => t('Your server is capable of using clean URLs, but it is not enabled. Using clean URLs gives an improved user experience and is recommended. <a href=":link">Enable clean URLs</a>', [':link' => 'http://drupal.org/docs/8/clean-urls-in-drupal-8']),
      ];
    }
  }

We also need to update \Drupal\Component\FileSecurity\FileSecurity::denyPublicAccess(), \Drupal\Composer\Plugin\VendorHardening\FileSecurity::denyPublicAccess and \Drupal\Composer\Plugin\VendorHardening\FileSecurity::denyPublicAccess as they have Apache 2.0-2.2 code. Or do we leave that it *just to be safe*?

And we need to update core/INSTALL.txt

It feels odd not having a patch on this issue.

Actually removing code that supports older Apache versions I think we should do in a follow-up, but INSTALL.txt is probably in scope here.

There isn't a patch because all it is really doing is defining it to not be a bug if #2854817: Duplicate X-Content-Type-Options headers both with the value nosniff is fixed in a way that is incompatible with older Apache. system_requirements() could be made to test for the Apache version.

It would be valid to leave in the Apache 2.2 and 2.0 stuff on the basis that if you're using Apache 2.4, it needs to be >= 2.4.7, but older branches of Apache are still supported (though they are not supported by Apache, so they really ought not to be used).

Patch that updates INSTALL.txt :)

The issue is set to 8.9.x but this feels like something we shouldn't do until 9.0.x, right?

After exhaustive testing on multiple architectures, I can confirm the patch in #16.

I dunno but to have text that says the to run Drupal without mod_rewrite, a minimum version of 2.2.16 is needed is very odd if we're updating the minimum supported version to be 2.4.7.

I think we should resolve the policy question here and remove older Apache code in a child issue. That would immediately unblock the preferred solution to #2854817: Duplicate X-Content-Type-Options headers both with the value nosniff.

I've opened #3118714: Review apache specific code in light of requiring >= 2.4.7 to address my concerns in a follow-up.

Added a CR and a release note, but the patch needs a re-roll.

Did that locally.

Committed c88513f and pushed to 9.0.x. Thanks!

I installed the latest MAMP 5 on my mac, still apache is at 2.2 and I am getting this error while upgrading a D8 site to D9
How do I resolve this?

Issue: https://www.drupal.org/project/upgrade_status/issues/3145991

I've been fighting with this problem for a while now. I'm on a CentOS server that uses Plesk as the controlling software. CentOS that installs with Plesk is CentOS 7.8.2003. It ships with a max Apache version of 2.4.6. So far I've got nothing but bad news regarding upgrading to 2.4.7. I have MariaDB upgraded to 10.x so that's no problem, and PHP is at 7.4, but I just don't know what else to do about my Apache version. Until it gets included in some future update, I can't move all my sites to D9.

EDIT: even though it says I have 2.4.6 the copy running on this version of CentOS has all the features backported from newer versions.

EDIT#2: I just found out that I can't do any third party upgrades on my server without violating my user license with Plesk. So I can't upgrade Drupal to 9 until CentOS itself includes a later version of Apache, or Plesk includes CentOS 8.

Please note that Red Hat Enterprise Linux 8 (RHEL8) is not approved for use on U.S. federal government servers (see https://access.redhat.com/articles/2918071) for compliance status, meaning that the latest version of RHEL that Federal users can upgrade to us RHEL7. The only version of Apache certified for use on RHEL7 is 2.4.6, and upgrading beyond this version on RHEL7 servers is strongly discouraged (unlike PHP and other requirements). Requiring 2.4.7 will effectively block all U.S. Federal web sites running RedHate Enterprise Linux from upgrading from Drupal 8 to Drupal 9. Even if RHEL8 gains approval for use on U.S. Federal government servers today, many of these sites will not be able to upgrade to RHEL8 before Drupal 8's EOL in November 2021 and will be forced to consider a different CMS.

Contrary to the OP's comment, Apache 2.4.6 in neither ancient not unmaintained, as it is actively updated and maintained by RedHat, who has back-ported all security updates (but not feature updates) into the release.

Update: I was able to replace the httpd package with httpd24-httpd from the officially supported Red Hat Software Collections (RHSCL) httpd24 repository without any issues on a few different RHEL7 machines. This upgraded the system to Apache 2.4.34, and the instructions to do so are well described here: https://unix.stackexchange.com/questions/138899

Thank you mikegodin #29. My server people agree that the 2.4.6 version we have will not be changed for quite a while. I've been able to upgrade, and fix everything else, so now the only hold up is a perfectly safe version of Apache.

We are running CentOS 7 with Apache 2.4.46 and had no problems upgrading to Drupal 9.

Apache 2.4.46 is the latest supported version to the date I posted this and most hosts out there do not support anything that is not the official latest version. Many hosts consider 2.4.7 as not yet official and will not carry it or offer support to sites running it.

Liquidweb mentioned that if Apache 2.4.7 is the minimum, then they do not support Drupal 9 sites.
However, they did mention that they have a sites running Drupal 9 with the latest Apache 2.4.46 with no issues.
Seems like the Apache 2.4.7 minimum is just a "recommendation"?

The preferred way of resolving #2854817: Duplicate X-Content-Type-Options headers both with the value nosniff would make it incompatible with Apache 2.4.6 and earlier. That is a major reason for defining this minimum.

On the other hand, some supported versions of Linux distributions included Apache 2.4.6 with security patches applied. So, people can be running a currently-supported Linux distribution and still have Apache 2.4.6.

That is a great point Liam.

I will double check with my host to see if they applied those patches.

Thank you.