Upgrading to 2.4 from 2.2

Compile-Time Configuration Changes

@@ -81,7 +83,7 @@

configure: By default, only a basic set of modules is loaded. The other LoadModule directives are commented - out.

+ out in the configuration file.

configure: the "most" module set gets built by default

@@ -110,15 +112,15 @@ which the authorization directives are applied.

Directives that control how authorization modules respond when they don't match - the authenticated user have been removed: This includes - AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative, + the authenticated user have been removed: This includes + AuthzLDAPAuthoritative, AuthzDBDAuthoritative, AuthzDBMAuthoritative, AuthzGroupFileAuthoritative, AuthzUserAuthoritative, and AuthzOwnerAuthoritative. These directives have been replaced by the - more expressive RequireAny, + more expressive RequireAny, RequireNone, and RequireAll.

If you use mod_authz_dbm, you must port your +

If you use mod_authz_dbm, you must port your configuration to use Require dbm-group ... in place of Require group ....

@@ -136,24 +138,33 @@ although for compatibility with old configurations, the new module mod_access_compat is provided.

Mixing old and new directives

Mixing old directives like Order, Allow or Deny with new ones like + Require is technically possible + but discouraged. mod_access_compat was created to support + configurations containing only old directives to facilitate the 2.4 upgrade. + Please check the examples below to get a better idea about issues that might arise. +

Here are some examples of old and new ways to do the same access control.

In this example, all requests are denied.

In this example, there is no authentication and all requests are denied.

2.2 configuration:

Order deny,allow
 Deny from all

2.4 configuration:

Require all denied

In this example, all requests are allowed.

In this example, there is no authentication and all requests are allowed.

2.2 configuration:

Order allow,deny
 Allow from all

2.4 configuration:

Require all granted

In the following example, all hosts in the example.org domain +

In the following example, there is no authentication and all hosts in the example.org domain are allowed access; all other hosts are denied access.

2.2 configuration:

Order Deny,Allow
@@ -162,8 +173,113 @@ Allow from example.org

2.4 configuration:

Require host example.org

+ +

In the following example, mixing old and new directives leads to + unexpected results.

+ +

Mixing old and new directives: NOT WORKING AS EXPECTED

DocumentRoot "/var/www/html"
+
+<Directory "/">
+    AllowOverride None
+    Order deny,allow
+    Deny from all
+</Directory>
+
+<Location "/server-status">
+    SetHandler server-status
+    Require 127.0.0.1
+</Location>
+
+access.log - GET /server-status 403 127.0.0.1
+error.log - AH01797: client denied by server configuration: /var/www/html/server-status

Why httpd denies access to servers-status even if the configuration seems to allow it? + Because mod_access_compat directives take precedence + over the mod_authz_host one in this configuration + merge scenario.

+ +

This example conversely works as expected:

+ +

Mixing old and new directives: WORKING AS EXPECTED

DocumentRoot "/var/www/html"
+
+<Directory "/">
+    AllowOverride None
+    Require all denied
+</Directory>
+
+<Location "/server-status">
+    SetHandler server-status
+    Order deny,allow
+    Deny from all
+    Allow From 127.0.0.1
+</Location>
+
+access.log - GET /server-status 200 127.0.0.1

So even if mixing configuration is still + possible, please try to avoid it when upgrading: either keep old directives and then migrate + to the new ones on a later stage or just migrate everything in bulk. +

In many configurations with authentication, where the value of the + Satisfy was the default of ALL, snippets + that simply disabled host-based access control are omitted:

+ +

2.2 configuration:

Order Deny,Allow
+Deny from all
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user

2.4 configuration:

# No replacement needed
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user

+ +

In configurations where both authentication and access control were meaningfully combined, the + access control directives should be migrated. This example allows requests meeting both criteria:

2.2 configuration:

Order allow,deny
+Deny from all
+# Satisfy ALL is the default
+Satisfy ALL
+Allow from 127.0.0.1
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user

2.4 configuration:

AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+<RequireAll>
+  Require valid-user
+  Require ip 127.0.0.1
+</RequireAll>

+ +

In configurations where both authentication and access control were meaningfully combined, the + access control directives should be migrated. This example allows requests meeting either criteria:

2.2 configuration:

Order allow,deny
+Deny from all
+Satisfy any
+Allow from 127.0.0.1
+AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+Require valid-user

2.4 configuration:

AuthBasicProvider File
+AuthUserFile /example.com/conf/users.passwd
+AuthName secure
+# Implicitly <RequireAny>
+Require valid-user
+Require ip 127.0.0.1

Other configuration changes

@@ -227,7 +343,7 @@ Allow from example.org jsessionid. -

mod_cache: The second parameter to +

mod_cache: The second parameter to CacheEnable only matches forward proxy content if it begins with the correct protocol. In 2.2 and earlier, a parameter of '/' matched all @@ -261,6 +377,13 @@ Allow from example.org option has been removed in favour of per-module LogLevel configuration.

mod_proxy_scgi: The default setting for + PATH_INFO has changed from httpd 2.2, and + some web applications will no longer operate properly with + the new PATH_INFO setting. The previous setting + can be restored by configuring the proxy-scgi-pathinfo + variable.

mod_ssl: CRL based revocation checking now needs to be explicitly configured through SSLCARevocationCheck.

@@ -301,7 +424,7 @@ Allow from example.org no longer supported.

SSLProxyCheckPeerCN

and

SSLProxyCheckPeerExpire

now default to On, causing proxy requests to HTTPS hosts - with bad or outdated certificates to fail with a 502 status code (Bad + with bad or outdated certificates to fail with a 502 status code (Bad gateway)

htpasswd now uses MD5 hash by default on @@ -327,7 +450,7 @@ Allow from example.org

The functionality provided by mod_authn_alias in previous versions (i.e., the AuthnProviderAlias directive) - has been moved into mod_authn_core. + has been moved into mod_authn_core.

mod_cgid uses the servers Timeout to limit the length of time to wait for CGI output. @@ -359,9 +482,9 @@ Allow from example.org - load module mod_access_compat, or update configuration to 2.4 authorization directives.

Ignoring deprecated use of DefaultType in line NN of /path/to/httpd.conf - remove DefaultType and replace with other configuration settings.

Invalid command 'AddOutputFilterByType', perhaps misspelled 
+

Invalid command 'AddOutputFilterByType', perhaps misspelled
       or defined by a module not included in the server configuration
-       - AddOutputFilterByType 
+

- AddOutputFilterByType has moved from the core to mod_filter, which must be loaded.

Errors serving requests: @@ -396,7 +519,7 @@ var comments_identifier = 'http://httpd.apache.org/docs/trunk/upgrading.html'; } })(window, document); //-->

See also

Compile-Time Configuration Changes

Mixing old and new directives

2.2 configuration:

2.4 configuration:

2.2 configuration:

2.4 configuration:

2.2 configuration:

2.4 configuration:

Mixing old and new directives: NOT WORKING AS EXPECTED

Mixing old and new directives: WORKING AS EXPECTED

2.2 configuration:

2.4 configuration:

2.2 configuration:

2.4 configuration:

2.2 configuration:

2.4 configuration:

Other configuration changes