Apache HTTP Server Version 2.4

Apache > HTTP Server > Documentation > Version 2.4

# 섹션 설정

이 문서는 최신판 번역이 아닙니다. 최근에 변경된 내용은 영어 문서를 참고하세요.

설정파일에 있는 지시어는 서버 전체에 적용되거나, 특정 디렉토리, 파일, 호스트, URL에만 적용될 수 있다. 이 문서는 다른 지시어의 적용범위를 제한하기위해 설정 섹션이나 `.htaccess` 파일을 사용하는 방법을 설명한다.

## 설정 섹션의 종류

관련된 모듈 | 관련된 지시어
--- | ---
`core` `mod_proxy` | `<Directory>` `<DirectoryMatch>` `<Files>` `<FilesMatch>` `<IfDefine>` `<IfModule>` `<Location>` `<LocationMatch>` `<Proxy>` `<ProxyMatch>` `<VirtualHost>`

섹션에는 두가지 종류가 있다. 대부분은 매요청마다 처리된다. 해당하는 요청에만 안에 포함한 지시어를 적용한다. 반대로, `<IfDefine>`과 `<IfModule>`은 서버가 시작할때와 꺼질때만 처리한다. 시작할때 상태가 참이면 안에 있는 지시어가 모든 요청에 적용된다. 참이 아니면 안에 있는 지시어는 무시한다.

`<IfDefine>` 지시어는 `httpd` 명령행에 적절한 파라미터가 있는 경우에만 안에 포함한 지시어를 적용한다. 다음 설정을 예로 들면, 서버를 `httpd -DClosedForNow`로 시작할 경우에만 모든 요청이 다른 사이트로 리다이렉션된다:

`<IfDefine ClosedForNow>
Redirect / http://otherserver.example.com/
</IfDefine>`

`<IfModule>` 지시어도 특정 모듈이 서버에 포함된 경우에만 안에 든 지시어를 적용한다는 점을 제외하고는 매우 비슷하다. 모듈을 서버에 정적으로 컴파일하거나 동적으로 컴파일한후 설정파일 앞에 `LoadModule` 줄이 있어야 한다. 이 지시어는 특정 모듈의 설치유무에 따라 설정파일이 다를 필요가 있을때만 사용해야 한다. 모듈이 없는 경우 유용한 오류문이 나오지않을 수 있기 때문에 언제나 사용하길 원하는 지시어를 안에 두면 안된다.

다음 예에서 `mod_mime_magic`이 있을때만 `MimeMagicFiles` 지시어를 처리한다.

`<IfModule mod_mime_magic.c>
MimeMagicFile conf/magic
</IfModule>`

`<IfDefine>`과 `<IfModule>`의 검사 앞에 "!"을 붙여 조건을 역으로 할 수 있다. 또, 여러 섹션들을 겹쳐서 사용하여 더 복잡한 효과를 얻을 수 있다.

## 파일시스템과 웹공간

가장 자주 사용되는 설정 섹션은 파일시스템과 웹공간(webspace)의 특정 장소에 대한 설정을 변경하는 것들이다. 먼저 이 둘의 차이를 이해하는 것이 중요하다. 파일시스템은 운영체제 입장에서 디스크를 보는 관점이다. 예를 들어, 기본값으로 아파치를 설치를 하면 유닉스 파일시스템의 경우 `/usr/local/apache2`, 윈도우즈 파일시스템의 경우 `"c:/Program Files/Apache Group/Apache2"`에 설치된다. (아파치는 윈도우즈에서 조차 항상, 역슬래쉬가 아닌, 슬래쉬를 사용함을 주의하라.) 반대로 웹공간은 웹서버가 제공하고 클라이언트가 보게될 사이트의 관점이다. 그래서 유닉스에서 기본 아파치 설치를 한 경우 웹경로의 경로 `/dir/`은 파일시스템 경로 `/usr/local/apache2/htdocs/dir/`에 해당한다. 웹공간은 데이타베이스 등에서 동적으로 생성될 수 있기때문에 반드시 파일시스템에 직접 대응될 필요는 없다.

### 파일시스템 섹션

`<Directory>`와 `<Files>` 지시어와 정규표현식을 사용하는 지시어는 파일시스템의 특정 부분에 지시어를 적용한다. `<Directory>` 지시어에 포함된 지시어들은 지정한 파일시스템 디렉토리와 그 하위 디렉토리에 적용된다. .htaccess 파일을 사용해도 결과는 같다. 다음 설정을 예로 들면, 디렉토리 목록(index)이 `/var/web/dir1` 이하 디렉토리에서 디렉토리 목록(index)이 가능하다.

`<Directory /var/web/dir1>
Options +Indexes
</Directory>`

`<Files>` 섹션에 포함된 지시어들은 어떤 디렉토리에 있는지 관계없이 지정한 이름을 가진 파일에 적용된다. 설정파일의 주설정부분에 있는 다음 설정을 예로 들면, 장소와 관계없이 `private.html`이란 이름을 한 파일의 접근을 거부한다.

`<Files private.html>
Order allow,deny
Deny from all
</Files>`

파일시스템의 특정 부분에 있는 파일을 지칭하기위해 `<Files>`와 `<Directory>` 섹션을 같이 사용한다. 다음 설정을 예로 들면, `/var/web/dir1/private.html`, `/var/web/dir1/subdir2/private.html`, `/var/web/dir1/subdir3/private.html` 같이 `/var/web/dir1/` 디렉토리 아래에 있는 이름이 `private.html`인 파일의 접근을 거부한다.

`<Directory /var/web/dir1>
<Files private.html>
Order allow,deny
Deny from all
</Files>
</Directory>`

### 웹공간 섹션

`<Location>` 지시어와 이에 해당하는 정규표현식을 사용하는 지시어는 반대로 특정 웹공간의 설정을 바꾼다. 다음 설정을 예로 들면, /private으로 시작하는 URL-경로의 접근이 거부된다. 여기에는 `http://yoursite.example.com/private`, `http://yoursite.example.com/private123`, `http://yoursite.example.com/private/dir/file.html` 같이 `/private` 문자열로 시작하는 요청이 해당된다.

`<Location /private>
Order Allow,Deny
Deny from all
</Location>`

`<Location>` 지시어는 파일시스템에 대응할 필요가 없다. 다음 예는 어떻게 특정 URL을 `mod_status`가 제공하는 아파치 내부 핸들러로 대응시키는지를 보여준다. 파일시스템에 `server-status`라는 파일은 필요없다.

`<Location /server-status>
SetHandler server-status
</Location>`

### 와일드카드와 정규표현식

`<Directory>`, `<Files>`, `<Location>` 지시어에서 C 표준 파이브러리의 `fnmatch`와 같은 쉘에서 사용하는 와일드카드 문자를 사용할 수 있다. "*" 문자는 어떤 문자열이라도 나타내고, "?" 문자는 어떤 문자 한개를 나타내며, "[seq]"는 seq 중에 한 문자를 나타낸다. 어떤 와일드카드도 "/" 문자를 나타내지는 못한다. 그래서 이 문자는 직접 사용해야 한다.

더 유연한 설정이 필요하면 perl호환 정규표현식을 사용하는 `<DirectoryMatch>`, `<FilesMatch>`, `<LocationMatch>`를 사용할 수 있다. 그러나 아래 설정의 결합에 관한 절에서 정규표현식 섹션을 사용하면 지시어가 적용되는 방법이 어떻게 변하는지 살펴봐라.

모든 사용자 디렉토리 설정을 변경하는 비정규표현식 와일드카드 섹션은 다음과 같다:

`<Directory /home/*/public_html>
Options Indexes
</Directory>`

정규표현식 섹션을 사용하여 한번에 여러 종류의 그림파일에 대한 접근을 거부할 수 있다:

`<FilesMatch \.(?i:gif|jpe?g|png)$>
Order allow,deny
Deny from all
</FilesMatch>`

### 무엇을 사용하나

파일시스템 섹션과 웹공간 섹션 중 하나를 선택하는 것은 실제로 매우 쉽다. 파일시스템에 있는 객체에 지시어를 적용할때는 항상 `<Directory>`나 `<Files>`를 사용한다. (데이타베이스에서 생성한 웹페이지와 같이) 파일시스템에 있지 않는 객체에 지시어를 적용할때는 `<Location>`을 사용한다.

파일시스템에 있는 객체의 접근을 제한하기위해 `<Location>`을 사용하면 절대 안된다. 여러 다른 웹공간 장소(URL)가 같은 파일시스템 장소에 대응될 수 있으므로, 걸어둔 제한을 우회할 수 있기 때문이다. 다음 설정의 예를 살펴보자:

`<Location /dir/>
Order allow,deny
Deny from all
</Location>`

이 설정은 `http://yoursite.example.com/dir/`을 요청한다면 잘 작동한다. 그러나 대소문자를 구별하지않는 파일시스템을 사용한다면 어떻게되나? `http://yoursite.example.com/DIR/`을 요청하여 쉽게 제한을 우회할 수 있다. 반대로 `<Directory>` 지시어는 어떻게 요청하였는지 관계없이 그 장소에서 서비스되는 내용에 적용된다. (예외는 파일시스템 링크를 사용하는 경우다. 심볼링크를 사용하여 한 디렉토리를 파일시스템의 여러 장소에 둘 수 있다. `<Directory>` 지시어는 심볼링크를 따라간다. 그러므로 높은 수준의 보안을 위해서는 적절한 `Options` 지시어를 사용하여 심볼링크를 무시해야 한다.)

아마도 당신은 대소문자를 구별하는 파일시스템을 사용하므로 이런 일이 일어나지 않는다고 생각할지도 모른다. 그러나 다른 방법으로도 여러 웹공간 위치가 한 파일시스템 위치에 대응될 수 있음을 기억하라. 그래서 가능하면 항상 파일시스템 섹션을 사용해야 한다. 그러나 이 규칙에 예외가 하나 있다. 설정 제한을 `<Location />` 섹션에 두면 이 섹션이 특정 URL이 아닌 모든 요청에 적용되므로 완벽하게 안전하다.

## 가상호스트

`<VirtualHost>` 섹션은 특정 호스트에 적용되는 지시어들을 포함한다. 이는 한 컴퓨터에서 각각 다른 설정을 사용한 여러 호스트를 서비스할때 유용하다. 더 자세한 정보는 가상호스트 문서를 참고하라.

## 프록시

`<Proxy>`와 `<ProxyMatch>` 섹션은 지정한 URL에 대해 `mod_proxy` 프록시 서버를 거쳐 접근하는 경우에만 적용된다. 다음 설정을 예로 들면, 프록시 서버를 통해 `cnn.com` 웹사이트에 접근할 수 없다.

`<Proxy http://cnn.com/*>
Order allow,deny
Deny from all
</Proxy>`

## 안에 어떤 지시어를 사용할 수 있나?

어떤 설정 섹션안에 사용할 수 있는 지시어를 알려면 지시어의 사용장소를 확인하라. `<Directory>`에서 사용가능한 지시어는 `<DirectoryMatch>`, `<Files>`, `<FilesMatch>`, `<Location>`, `<LocationMatch>`, `<Proxy>`, `<ProxyMatch>` 섹션에서도 사용가능하다. 그러나, 예외가 있다:

- `AllowOverride` 지시어는 `<Directory>` 섹션에서만 사용할 수 있다.
- `FollowSymLinks`, `SymLinksIfOwnerMatch`, `Options`는 `<Directory>` 섹션이나 `.htaccess` 파일에서만 사용할 수 있다.
- `Options` 지시어는 `<Files>`과 `<FilesMatch>` 섹션에서 사용할 수 없다.

## 섹션들이 결합하는 방법

설정 섹션은 매우 특별한 방법으로 적용된다. 이 순서가 설정 지시어를 해석하는 방법에 중요한 영향을 주기때문에 이 방법을 이해하는 것이 중요하다.

결합하는 순서는:

1. (정규표현식을 사용하지않는) `<Directory>`와 `.htaccess`는 동시에 일어난다 (경우에 따라 `.htaccess`이 `<Directory>`를 무시하도록 설정할 수 있다)
2. `<DirectoryMatch>` (그리고 `<Directory ~>`)
3. `<Files>`와 `<FilesMatch>`는 동시에 일어난다
4. `<Location>`과 `<LocationMatch>`는 동시에 일어난다

`<Directory>`를 제외하고 각 섹션들을 설정파일에 나온 순서대로 처리된다. (위의 순서 1) `<Directory>`는 디렉토리 내용이 가장 짧은 것에서 긴쪽으로 처리된다. 그래서 예를 들어, `<Directory /var/web/dir>`을 `<Directory /var/web/dir/subdir>` 이전에 처리한다. 같은 디렉토리를 지칭하는 여러 `<Directory>` 섹션이 있다면 이들을 설정파일 순서대로 처리한다. `Include` 지시어로 포함한 설정은 `Include` 지시어 위치에 포함한 파일 내용이 있는 것처럼 처리한다.

`<VirtualHost>` 섹션 안에 포함된 섹션은 가상호스트 정의 밖에 있는 해당 섹션 이후에 적용된다. 그래서 가상호스트 안에서 주서버의 설정사항을 수정할 수 있다.

`mod_proxy`가 요청 서비스할때, `<Proxy>` 섹션의 처리순서는 `<Directory>` 섹션과 같다.

다음에 나오는 섹션은 이전 섹션의 결과를 수정한다.

### 기술적 주의

실제로 `<Location>`/`<LocationMatch>`는 (`Aliases`와 `DocumentRoot`를 사용하여 URL을 파일명으로 변환하는) 이름번역 단계 이전에 처리된다. 변역이 끝난 이후에는 완전히 무시한다.

### 예제

다음은 겹합하는 순서를 설명하는 예다. 이들 모두 요청에 적용된다고 가정하면 지시어는 A > B > C > D > E 순서로 처리된다.

`<Location />
E
</Location>
<Files f.html>
D
</Files>
<VirtualHost *>
<Directory /a/b>
B
</Directory>
</VirtualHost>
<DirectoryMatch "^.*b$">
C
</DirectoryMatch>
<Directory /a/b>
A
</Directory>
`

더 현실적인 예는 다음과 같다. `<Location>` 섹션을 나중에 처리하므로 `<Directory>` 섹션에 있는 접근제한과 관계없이 서버에 무제한 접근을 가능하다. 즉, 결합하는 순서는 중요하므로 주의하라!

`<Location />
Order deny,allow
Allow from all
</Location>
# 악! 이 <Directory> 섹션은 아무런 효과가 없다
<Directory />
Order allow,deny
Allow from all
Deny from badguy.example.com
</Directory>`