Apache 2.4 이상 버전에서 403 에러가 발생. error.log 를 보니 다음과 같은 에러가 있었다.
[Tue Dec 11 17:49:19.350384 2012] [authz_core:error] [pid 5308:tid 1576] [client 127.0.0.1:53603] AH01630: client denied by server configuration: /DOCUMENT_ROOT
아마도 우분투를 업그레이드하면서 (2.2에서 2.4로 업그레이드) 기존에쓰던 conf 파일 옵션값이 문제를 일으킨모양이다.
apache 2.2
<Directory /DOCUMENT_ROOT>
~~~
Order allow,deny
Allow from all
</Directory>
apache 2.4 최신
<Directory /DOCUMENT_ROOT>
~~~
Require all granted
</Directory>
아래는 apache 공식사이트 설명문서다.
https://httpd.apache.org/docs/2.4/upgrading.html
2.2 configuration:
Order deny,allow Deny from all
2.4 configuration:
Require all denied
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, 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 Deny from all 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 local </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:
# 2.2 config that disables host-based access control and uses only authentication Order Deny,Allow Allow from all AuthType Basic AuthBasicProvider file AuthUserFile /example.com/conf/users.passwd AuthName secure Require valid-user
2.4 configuration:
# No replacement of disabling host-based access control needed AuthType Basic 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 AuthType Basic AuthBasicProvider file AuthUserFile /example.com/conf/users.passwd AuthName secure Require valid-user
2.4 configuration:
AuthType Basic 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 AuthType Basic AuthBasicProvider file AuthUserFile /example.com/conf/users.passwd AuthName secure Require valid-user
2.4 configuration:
AuthType Basic AuthBasicProvider file AuthUserFile /example.com/conf/users.passwd AuthName secure # Implicitly <RequireAny> Require valid-user Require ip 127.0.0.1
