Apache HTTP Server Version 2.0
Apache HTTP Server Version 2.0
아파치가 특정 주소와 포트에서 서비스하도록 설정하기.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
아파치를 시작하면 아파치는 컴퓨터의 어떤 포트와 주소에 연결하여, 들어오는 요청을 기다린다. 기본적으로 아파치는 컴퓨터의 모든 주소에서 기다린다. 그러나 아파치가 특정 포트나 선택한 주소만을 기다리게 해야할 경우가 있다. 또 이 문제는 아파치가 어떻게 다른 IP 주소, 호스트명, 포트에 반응할지를 결정하는 가상호스트 기능과도 관련되있다.
Listen 지시어는
서버가 특정 포트나 주소와 포트 조합에서만 요청을 받게
한다. Listen
지시어에 포트 번호만 지정하면, 서버는 모든 인터페이스에서
지정한 포트를 기다린다. 여러 Listen 지시어로 기다릴 여러
주소와 포트를 지정할 수도 있다. 서버는 열거한 주소와 포트로
요청이 들어오면 응답한다.
예를 들어, 서버가 80번과 8000번 포트 모두에서 연결을 받도록 하려면:
Listen 80
Listen 8000
서버가 지정한 두 인터페이스와 포트에서 연결을 기다리도록 하려면,
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
IPv6 주소는 다음과 같이 대괄호로 묶어야 한다:
Listen [2001:db8::a00:20ff:fea7:ccea]:80
IPv6를 구현한 플래폼이 늘고 있고 APR이 이들 플래폼 대부분에서 IPv6를 지원하기때문에, 아파치는 IPv6 소켓을 할당하여 IPv6로 받은 요청을 처리할 수 있다.
아파치 관리자에게 복잡한 부분은 IPv6 소켓이 IPv4 연결과 IPv6 연결을 모두 처리할 수 있느냐는 점이다. 대부분의 플래폼에서는 IPv4-대응(mapped) IPv6 주소를 사용하여 IPv6 소켓에서 IPv4 연결을 받지만, FreeBSD와 NetBSD와 OpenBSD은 시스템전체 정책때문에 기본적으로 허용하지 않는다. 그러나 기본적으로 허용하지않는 시스템이라도 아파치를 위해 특별한 설정 파라미터로 변경할 수 있다.
아파치가 최소한의 소켓을 사용하여 IPv4 연결과 IPv6 연결을
모두 받도록하려면 IPv4-대응 IPv6 주소를 사용해야 한다. 그러기위해서
컴파일때 구성 옵션 --enable-v4-mapped를 사용하고,
다음과 같이 일반적인 Listen 지시어를 사용한다:
Listen 80
--enable-v4-mapped를 사용할때 아파치가 만드는
기본 설정파일의 Listen 지시어는 위와 같다.
--enable-v4-mapped는 FreeBSD, NetBSD, OpenBSD를
제외한 모든 플래폼에서 기본값이고, 아마도 당신의 아파치도
마찬가지일 것이다.
플래폼과 APR의 지원여부와 관계없이 아파치가 IPv4 연결만을 받도록하려면, 다음 예제와 같이 모든 Listen 지시어에 IPv4 주소를 사용한다:
Listen 0.0.0.0:80
Listen 192.170.2.1:80
IPv4 연결과 IPv6 연결을 서로 다른 소켓으로 받으려면,
컴파일때 구성 옵션 --disable-v4-mapped를 사용하고
다음과 같이 Listen 지시어를 따로 사용한다:
Listen [::]:80
Listen 0.0.0.0:80
--disable-v4-mapped를 사용할때 아파치가 만드는
기본 설정파일의 Listen 지시어는 위와 같다.
--disable-v4-mapped는 FreeBSD, NetBSD, OpenBSD에서
기본값이다.
Listen은 가상호스트를 만들지 않는다. 이는 단지 주서버가
어떤 주소와 포트를 기다릴지만 알려준다. <VirtualHost> 지시어를
사용하지 않으면, 서버는 받은 모든 요청을 똑같이 처리한다.
그러나 <VirtualHost>로 여러 주소와 포트에
대해 다른 행동을 지정할 수 있다. 가상호스트를 만들려면
먼저 서버에게 사용할 주소와 포트를 알려줘야 한다. 그리고
특정 주소와 포트에 대한 가상호스트의 행동을 지정할
<VirtualHost>
섹션이 필요하다. 주서버가 기다리지않는 주소와 포트를 사용하는
<VirtualHost>는
접근할 수 없음을 주의하라.
Apache HTTP Server Version 2.0
이 문서는 아파치 웹서버를 설정하는 파일들을 설명한다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
일반 문서 파일인 설정파일에 지시어를 사용하여 아파치를
설정한다. 주설정파일을 보통 httpd.conf라고
부른다. 이 파일의 위치는 컴파일시 정해지나, -f
명령행 옵션으로 지정해줄 수 있다. 또 다른 설정파일을 Include 지시어를 사용하여 포함할
수 있고, 와일드카드를 사용하여 많은 설정파일을 포함할 수도
있다. 이 경우 지시어를 어떤 설정파일에나 사용해도 된다.
주설정파일을 수정하면 아파치를 시작하거나 재시작한 이후에
반영된다.
서버는 mime 문서타입을 담은 파일도 읽는다. 파일명은
TypesConfig 지시어로
설정하고, 기본값은 mime.types이다.
아파치 설정파일은 한줄에 한 지시어를 사용한다. 줄 마지막 문자가 백슬래쉬 "\"이면 지시어가 다음 줄에서 계속됨을 뜻한다. 이 경우 백슬래쉬 뒤에 어떤 문자나 공백도 나오면 안된다.
설정파일의 지시어는 대소문자를 구별하지 않지만, 지시어의 아규먼트는 대소문자를 구별하는 경우가 있다. 해쉬문자 "#"로 시작하는 줄은 주석으로 무시한다. 주석을 설정 지시어와 같은 줄에 사용할 수 없다. 빈줄과 지시어 앞에 나오는 공백은 무시하므로, 간결하게 보이도록 지시어를 줄들임할(indent) 수 있다.
apachectl configtest나 -t 명령행
옵션을 사용하여 아파치를 실행하지 않고도 설정파일의 문법
오류를 검사할 수 있다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
아파치는 모듈화된 서버다. 이는 매우 기본적인 기능만이
서버 핵심에 포함되있음을 뜻한다. 아파치는 모듈을 읽어들여서 기능을
확장한다. 기본적으로 컴파일하면 서버에 base 모듈들이 포함된다.
서버를 동적으로 읽어들이는 모듈을
사용할 수 있게 컴파일하였다면 모듈을 따로 컴파일하여 아무때나
LoadModule 지시어로
추가할 수 있다. 그렇지 않으면 모듈을 추가하거나 빼기위해
아파치를 다시 컴파일해야 한다. 설정 지시어를 IfModule 블록으로 감싸서 특정
모듈이 있는 경우에만 선택적으로 처리할 수 있다.
현재 서버에 어떤 모듈이 컴파일되있는지 보려면 -l
명령행 옵션을 사용한다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
주설정파일에 있는 지시어는 서버 전체에 적용된다. 지시어가
서버의 일부에만 적용되게 하려면 지시어를 <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, <LocationMatch> 섹션 안에 두어야한다.
이 섹션들은 그들이 감싸는 지시어의 적용범위를 파일시스템이나
URL의 특정 위치로 한정한다. 또, 서로 겹쳐서 사용할 수 있기때문에
매우 세밀한 설정이 가능하다.
아파치는 여러 다른 웹사이트를 동시에 서비스하는
능력이 있다. 이를 가상호스트라고 한다.
지시어를
<VirtualHost>
섹션 안에 두어 특정 웹사이트에만 지시어를 적용할 수 있다.
지시어는 대부분 어떤 섹션에 나와도 되지만, 어떤 지시어는 특정 장소에서 의미가 없다. 예를 들어 프로세스 생성을 조절하는 지시어는 주서버설정 장소에서만 사용할 수 있다. 지시어가 어떤 섹션에 위치할 수 있는지 알려면 지시어의 사용장소를 확인하라. 더 자세한 정보는 어떻게 Directory, Location, Files 섹션이 동작하나를 참고하라.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
아파치는 특별한 파일을 사용하여 설정을
나눠서(분권적으로) 관리할 수 있다. 이 특별한 파일을 보통
.htaccess라고 부르지만, 이름은 AccessFileName 지시어로
지정할 수 있다. .htaccess 파일에 있는 지시어는
파일이 있는 디렉토리와 모든 하위디렉토리에 적용된다.
.htaccess 파일은 주설정파일과 같은 문법을
따른다. .htaccess 파일은 매 요청때마다 읽기때문에
파일을 수정하면 즉시 효과를 볼 수 있다.
어떤 지시어를 .htaccess 파일에 사용할 수
있는지 알려면 지시어의 사용장소를
확인하라. 서버 관리자는 주설정파일의 AllowOverride 지시어로
.htaccess 파일에 어떤 지시어를 사용할 수 있는지
조절할 수 있다.
.htaccess 파일에 대한 더 자세한 정보는
.htaccess 투토리얼을
참고하라.
Apache HTTP Server Version 2.0
아파치는 HTTP/1.1 규약에 기술된 내용협상(content negotiation)을 지원한다. 내용협상은 media type, 언어, 문자집합, 인코딩 등에 대해 브라우저가 제공한 선호도에 따라 자원의 가장 적합한 표현을 선택한다. 또 불완전한 협상 정보를 보내는 브라우저의 요청을 지능적으로 처리하는 기능도 있다.
기본적으로 컴파일되는 mod_negotiation
모듈이 내용협상 기능을 제공한다.
자원은 여러 다른 표현을 가질 수 있다. 예를 들어, 다른 언어나 다른 media type 혹은 둘 모두가 다른 표현들이 있을 수 있다. 가장 적당한 표현을 선택하는 한가지 방법은 사용자에게 목록 페이지를 보여주고 선택하게 하는 것이다. 그러나 서버가 자동으로 선택하는 것도 가능하다. 이는 브라우저가 요청의 일부로 그들이 선호하는 표현에 대한 정보를 보내기때문에 가능하다. 예를 들어, 브라우저는 가능한한 불어로, 그러나 없다면 영어로 정보를 보고싶다고 알려줄 수 있다. 브라우저는 요청의 헤더로 그들의 기호를 나타낸다. 오직 불어로된 표현만을 요청한다면 브라우저는 다음과 같이 보낸다.
Accept-Language: fr
이런 기호는 표현이 언어별로 다를 경우에만 고려된다.
다음은 더 복잡한 요청의 예로 브라우저가 불어와 영어를 받을 수 있지만, 불어를 더 선호하고, 여러 media type을 받을 수 있지만, 일반 텍스트 보다는 HTML, 다른 media type 보다는 GIF와 JPEG을 선호한다고 알려준다.
Accept-Language: fr; q=1.0, en; q=0.5
Accept: text/html; q=1.0, text/*; q=0.8, image/gif; q=0.6, image/jpeg; q=0.6, image/*; q=0.5, */*; q=0.1
아파치는 HTTP/1.1 규약에 정의된 '서버 주도(server driven)'
내용협상을 지원한다. 아파치는 Accept,
Accept-Language, Accept-Charset,
Accept-Encoding 요청 헤더를 모두 지원한다.
또, 아파치는 RFC 2295와 RFC 2296에 정의된 실험적인 내용협상인
'자연스러운(transparent)' 요청 헤더도 지원한다. 그러나 이
RFC에 정의된 '기능 협상(feature negotiation)'은 지원하지
않는다.
자원(resource)은 (RFC 2396) URI로 구별하는 개념적인 존재다. 아파치와 같은 웹서버는 자원의 표현(representations)을 제공한다. 표현은 지정된 media type, 문자집합, 인코딩 등을 가진 바이트들로 되있다. 자원은 여러 표현과 (때로는 없을 수도 있다) 연관된다. 자원에 여러 표현이 있다면 자원을 협상가능하다고(negotiable) 부르며, 이때 각 표현을 변형(variant)이라고 한다. 협상가능한 자원의 변형 종류를 협상의 범위(dimension)라고 한다.
자원을 협상하기위해 서버는 각 변형에 대한 정보가 필요하다. 다음 두가지 방법중 하나로 정보를 얻는다:
*.var 파일) 사용하거나,type map은 type-map이란 핸들러와 연결된
(혹은 이전 아파치 설정과 호환을 위해 MIME type이
application/x-type-map인) 문서다. 이 기능을
사용하려면 설정에서 type-map 핸들러에 대한
파일 확장자를 지정해야 한다. 서버 설정파일에 다음과 같이
설정하는 것이 좋다.
AddHandler type-map .var
Type map 파일은 해당하는 자원과 이름이 같아야 하고,
각 변형에 대한 항목이 있어야 한다. 항목은 여러 HTTP형식
헤더 줄로 구성된다. 변형에 대한 각각의 항목들은 빈줄로
구분한다. 항목안에서 빈줄을 사용할 수 없다. (이렇게 할
필요가 없고, 있어도 무시하지만) 여러 항목이 공통으로 가지고
있는 내용으로 map 파일을 시작하는 것이 보통이다. 다음은
map 파일 예다. 이 파일의 이름은 foo.var로,
foo라는 자원을 설명한다.
URI: foo
URI: foo.en.html
Content-type: text/html
Content-language: en
URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de
typemap 파일이 파일명 확장자 보다, 심지어 Multiviews를 사용하여도, 우선권을 가짐을 주의하라. 변형이 서로 다른 품질을 가진다면, 다음과 같이 (JPEG, GIF, ASCII-art에 해당하는) media type에 "qs" 파라미터로 품질(source quality)을 표시할 수 있다:
URI: foo
URI: foo.jpeg
Content-type: image/jpeg; qs=0.8
URI: foo.gif
Content-type: image/gif; qs=0.5
URI: foo.txt
Content-type: text/plain; qs=0.01
qs 값은 0.000에서 1.000 사이다. qs 값이 0.000인 변형은 절대 선택되지 않음을 주의하라. 'qs' 값이 없는 변형은 1.0으로 취급된다. qs 값은 클라이언트의 능력과는 관계없이 다른 변형들과 비교하여 그 변형의 상대적인 '품질'을 나타낸다. 예를 들어, 사진을 나타내려는 경우 JPEG 파일이 ASCII 파일보다는 항상 높은 품질을 가진다. 그러나 자원이 원래 ASCII art였다면 ASCII 표현이 JPEG 표현보다 더 높은 품질을 가질 수 있다. 그러므로 어떤 변형의 qs 값은 표현하려는 자원의 성질에 따라 다르다.
지원하는 모든 헤더 목록은 mod_negotation typemap 문서를 참고하라.
MultiViews는 디렉토리별 옵션이므로,
httpd.conf의
<Directory>,
<Location>,
<Files>
섹션 혹은 (AllowOverride가
적절히 설정되었다면) .htaccess 파일의
Options 지시어에 설정할
수 있다. Options All은 MultiViews를
포함하지않음을 주의하라. 따로 직접 써줘야 한다.
MultiViews를 사용하면 다음과 같은 일이 일어난다:
서버가 /some/dir/foo에 대한 요청을 받고
/some/dir/foo에 MultiViews가 동작하며
/some/dir/foo가 존재하지 않을 경우,
서버는 디렉토리에서 이름이 foo.*인 파일들을 모든 포함하는
가상의 type map을 만든다. 클라이언트가 요청한 media type과
content-encoding을 가지고 이중에 가장 적합한 것을 선택한다.
MultiViews는 서버가 디렉토리를 참조할때
파일을 찾는 DirectoryIndex 지시어에도
적용된다. 설정파일이 다음과 같다면,
DirectoryIndex index
index.html과 index.html3이
모두 있다면 서버는 이둘 중에 하나를 결정한다. 둘 모두 없고
index.cgi가 있다면, 서버는 그것을 실행한다.
디렉토리를 읽을때 파일중 하나가 Charset, Content-Type,
Language, Encoding를 판단하는 mod_mime이 모르는
확장자를 가진다면, 결과는 MultiViewsMatch 지시어 설정에
달렷다. 이 지시어는 핸들러, 필터, 다른 확장형들이 MultiViews
협상에 참여할지 여부를 결정한다.
아파치가 type-map 파일이나 디렉토리에 있는 파일명들로 주어진 자원에 대한 변형 목록을 얻게되면 '최적의' 변형을 결정하기위해 두 방법중 하나를 사용한다. 아파치 내용협상 기능을 사용하기위해 정확히 협상이 어떻게 일어나는지 자세히 알 필요는 없다. 그러나 궁금한 사람을 위해 이 방법을 설명한다.
두가지 협상방법이 있다:
| 범위 | 설명 |
|---|---|
| Media Type | 브라우저는 Accept 헤더로 선호를 나타낸다.
각 항목은 품질계수를 가질 수 있다. 변형의 설명도 품질계수를
("qs" 파라미터) 가질 수 있다. |
| Language | 브라우저는 Accept-Language 헤더로 선호를
나타낸다. 각 항목은 품질계수를 가질 수 있다. 변형은
여러 언어를 가질 (혹은 아무 언어도 없을) 수 있다. |
| Encoding | 브라우저는 Accept-Encoding 헤더로 선호를
나타낸다. 각 항목은 품질계수를 가질 수 있다. |
| Charset | 브라우저는 Accept-Charset 헤더로 선호를
나타낸다. 각 항목은 품질계수를 가질 수 있다. 변형은
media type의 파라미터로 문자집합을 나타낼 수 있다. |
아파치는 브라우저에게 보낼 '최적의' 변형을 (있다면) 선택하기위해 아래 알고리즘을 사용한다. 이 알고리즘은 변경할 수 없다. 다음와 같이 동작한다:
Accept 헤더의 품질계수와 변형의
media type에 대한 품질값을 곱하여 가장 높은 값을
가진 변형을 선택한다.Accept-Language 헤더에 (있다면)
나온 언어의 순서 혹은 LanguagePriority
지시어에 (있다면) 나온 언어의 순서를 가지고 가장
적합한 언어를 가진 변형을 선택한다.Accept-Charset 헤더를 가지고 가장
적합한 charset media 파라미터를 가진 변형을 찾는다.
헤더가 없다면 ISO-8859-1 문자집합을 가장 선호한다.
text/* media type을 가지지만 명시적으로
특정 문자집합과 연결되지않은 변형은 ISO-8859-1로
가정한다.Vary는 협상의 범위를
나타내게 된다. (브라우저와 캐쉬는 자원을 캐쉬할때 이 정보를
사용할 수 있다.) 끝.Vary 헤더는 변형의 범위를 나타낸다.아파치는 종종 위의 아파치 협상 알고리즘을 엄격히 지키지않고
품질계수를 변경한다. 이유는 완전하고 정확한 정보를 보내지않는
브라우저에게 (알고리즘의) 더 나은 결과를 보내기 위해서다.
널리 쓰이는 브라우저중 일부는 자주 잘못된 변형을 선택하도록
Accept 헤더를 보낸다. 브라우저가 완전하고 올바른
정보를 보낸다면, 조작을 하지않는다.
Accept: 요청 헤더는 media type에 대한 선호를
나타낸다. 또, *는 어떤 문자열이라도 가능하기때문에 "image/*"나
"*/*" 같이 '와일드카드' media type을 사용할 수도 있다. 그래서
다음과 같은 요청은:
Accept: image/*, */*
"image/"로 시작하는 어떤 type과 다른 어떤 type도 가능함을 의미한다. 어떤 브라우저는 자신이 실제로 다룰 수 있는 type에 추가로 와일드카드를 보낸다. 예를 들면:
Accept: text/html, text/plain, image/gif, image/jpeg, */*
이유는 직접 열거한 type을 선호하지만 다른 표현이 있다면 그것도 괜찮음을 나타내기 위해서다. 브라우저가 실제로 원한 것은 다음과 같이 명시적으로 품질값을 사용한 것이다.
Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
직접 열거한 type은 품질계수가 없어서 기본값인 (가장 높은) 1.0을 가진다. 와일드카드 */*는 낮은 선호도 0.01을 가지므로 직접 열거한 type에 맞는 변형이 없는 경우에만 다른 type들이 사용된다.
Accept: 헤더에 q 계수가 전혀 없고
"*/*"가 있다면, 아파치는 바람직한 행동을 위해 q 값으로 0.01을
지정한다. 또, "type/*" 형태의 와일드카드에는 ("*/*"보다는
더 선호하도록) 0.02를 지정한다. Accept: 헤더에서
q 계수를 가지는 media type이 있다면 이런 특별한 값을 추가하지
않는다. 그래서 명시적인 정보를 보내는 브라우저의
요청은 요청한데로 처리한다.
아파치 2.0은 언어 협상이 실패한 경우 부드럽게 복구하기위해 협상 알고리즘에 새로 예외를 몇개 추가했다.
클라이언트가 서버에 페이지를 요청했을때 서버가 브라우저가
보낸 Accept-language에 맞는 페이지를 단 한개만
찾으면 문제가 없지만, 그러지 않은 경우 서버는 클라이언트에게
"No Acceptable Variant"나 "Multiple Choices" 응답을 보낸다.
이런 오류문을 피하기위해 이 경우 Accept-language를
무시하고 클라이언트의 요청에 명확히 맞지는 않지만 문서를
보내도록 아파치를 설정할 수 있다. ForceLanguagePriority
지시어는 서버가 이런 오류문중 하나 혹은 둘다를 무시하고
LanguagePriority
지시어로 판단하도록 한다.
또, 서버는 맞는 언어를 못찾은 경우 부모언어를 찾을 수도
있다. 예를 들어 클라이언트가 영국영어를 뜻하는
en-GB 언어로 문서를 요청한 경우, HTTP/1.1 표준에
따르면 서버는 en으로만 표시된 문서를 일반적으로
선택하지 못한다. (그래서 영국영어를 이해하는 독자가 일반적인
영어도 이해할 수 있으므로 Accept-Language 헤더에
en-GB만 포함하고 en을 포함하지않으면
거의 확실히 잘못된 설정임을 유의하라. 불행히도 현재 많은
클라이언트들은 이런 식으로 기본설정되있다.) 다른 언어를
찾지 못하여 서버가 "No Acceptable Variants" 오류를 보내거나
LanguagePriority로
돌아가야 한다면, 서버는 하위언어 규약을 무시하고
en-GB를 en 문서에 대응한다.
암묵적으로 아파치는 부모언어를 매우 낮은 품질값으로
클라이언트의 허용언어 목록에 추가한다. 그러나 클라이언트가
"en-GB; q=0.9, fr; q=0.8"을 요청하고 서버에 "en"과 "fr"
문서가 있다면, "fr" 문서가 선택됨을 주의하라. 이는 HTTP/1.1
표준을 지키고, 올바로 설정된 클라이언트와 효율적으로
동작하기위함이다.
사용자가 선호하는 언어를 알아내기위한 (쿠키나 특별한
URL-경로 같은) 고급 기법을 지원하기위해 아파치 2.0.47부터
mod_negotiation은 prefer-language라는
환경변수를 인식한다. 이 환경변수가
존재하고 적절한 언어태그를 포함한다면,
mod_negotiation은 해당하는 변형을 선택하려고
시도한다. 그런 변형이 없다면 일반적인 협상과정을 시작한다.
SetEnvIf Cookie "language=en" prefer-language=en
SetEnvIf Cookie "language=fr" prefer-language=fr
아파치는 다음과 같이 자연스러운 내용확장 프로토콜을 (RFC 2295)
확장한다. 변형 목록의 새로운 {encoding ..}는 특정
content-encoding을 가진 변형만을 지칭한다. RVSA/1.0 알고리즘은
(RFC 2296) 목록에서 인코딩된 변형을 인식할 수 있고, 인코딩이
Accept-Encoding 요청 헤더에 맞는 경우 인코딩된
변형들도 후보로 사용하도록 확장되었다. RVSA/1.0 구현은 최적의
변형을 찾기 전에 계산된 품질계수를 소수점 5자리에서 반올림하지
않는다.
언어(language) 협상을 사용한다면 파일은 여러 확장자를 가지고 확장자의 순서는 보통 관계없으므로 파일명에 여러 다른 이름규칙을 사용할 수 있다. (자세한 내용은 mod_mime 문서를 참고하라.)
전형적인 파일은 MIME-type 확장자 (예를 들어,
html), 경우에 따라 encoding 확장자 (예를
들어, gz), 파일에 여러 언어 변형이 있는
경우 물론 언어 확장자를 (예를 들어, en)
가진다.
예제:
다음은 몇몇 파일명과 그 파일에 대한 유효하고 유효하지않은 하이퍼링크를 보인다:
| 파일명 | 유효한 하이퍼링크 | 유효하지않은 하이퍼링크 |
|---|---|---|
| foo.html.en | foo foo.html |
- |
| foo.en.html | foo | foo.html |
| foo.html.en.gz | foo foo.html |
foo.gz foo.html.gz |
| foo.en.html.gz | foo | foo.html foo.html.gz foo.gz |
| foo.gz.html.en | foo foo.gz foo.gz.html |
foo.html |
| foo.html.gz.en | foo foo.html foo.html.gz |
foo.gz |
위 표를 보면 하이퍼링크에 어떤 확장자도 없는 이름을
(예를 들어, foo) 항상 사용할 수 있음을
알 수 있다. 이 경우 장점은 문서의 실제 종류를 숨길 수 있어서,
예를 들어 하이러링크 참조를 수정하않고
html 파일을 shtml이나
cgi로 변경할 수 있다는 점이다.
계속 하이퍼링크에 MIME-type을 (예를 들어,
foo.html) 사용하고 싶다면 (encoding 확장자가
있다면 이것도 포함하여) 언어 확장자를 MIME-type 확장자보다
오른쪽에 (예를 들어, foo.html.en)
두어야한다.
캐쉬가 표현을 저장하면 표현과 요청 URL을 연관시킨다. 다음번 그 URL을 요청하면 캐쉬는 저장된 표현을 사용한다. 그러나 서버와 협상이 가능한 자원인 경우 첫번째 요청한 변형만 캐쉬되어 이후 요청은 캐쉬된 잘못된 응답을 얻을 수 있다. 이를 막기위해 아파치는 보통 내용협상후 반환되는 모든 요청에 HTTP/1.0 클라이언트가 캐쉬를 못하도록 표시를 한다. 또, 아파치는 협상한 응답의 캐쉬를 허용하는 HTTP/1.1 프로토콜의 기능을 지원한다.
CacheNegotiatedDocs
지시어는 HTTP/1.0 호환 클라이언트(브라우저 혹은 캐쉬)가
보낸 요청에 대해 협상한 응답을 캐쉬할 수 있게 한다. 이 지시어는
서버나 가상호스트 설정에 사용하며, 아규먼트를 받지않는다.
이 지시어는 HTTP/1.1 클라이언트의 요청과는 관계가 없다.
내용협상에 대한 다른 정보는 Alan J. Flavell가 쓴 Language Negotiation Notes를 참고하라. 그러나 이 문서는 아직 아파치 2.0의 변화를 반영하지 않을 수 있다.
Apache HTTP Server Version 2.0
웹마스터는 오류나 문제가 발생했을때 아파치의 응답을 설정할 수 있다.
서버가 오류나 문제를 발견했을때 보낼 사용자정의 응답을 정의할 수 있다.
스크립트가 죽은 경우 "500 Server Error" 응답 대신 사용자에게 더 친근한 문구를 사용하거나 다른 (같은 사이트나 외부 사이트의) URL로 리다이렉션을 할 수 있다.
NCSA httpd 1.3은 사용자에게 무의미하고 지루한 오류문을 보냈다. 문제가 발생한 이유를 로그에 남길 수도 없었다.
서버는 다음과 같은 일을 할 수 있다:
다른 사이트의 URL로 리다이렉션하는 것이 유용할 수 있지만, 이 경우 문제를 설명하거나 로그하는데 필요한 정보중 일부만 전달된다.
오류에 대한 정보를 전달하기위해 아파치는 CGI식의 새로운 환경변수를 정의한다:
REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap,
image/jpeg
REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05
9000/712)
REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
REDIRECT_QUERY_STRING=
REDIRECT_REMOTE_ADDR=121.345.78.123
REDIRECT_REMOTE_HOST=ooh.ahhh.com
REDIRECT_SERVER_NAME=crash.bang.edu
REDIRECT_SERVER_PORT=80
REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
REDIRECT_URL=/cgi-bin/buggy.pl
REDIRECT_ 접두사에 주목하라.
최소한 REDIRECT_URL과
REDIRECT_QUERY_STRING은 (cgi-script나
cgi-include일) 새 URL로 넘겨진다. 다른 변수는 오류가
발생하기 이전에 (역주; 이름에서 REDIRECT_를
뺀 환경변수가) 존재한 경우에만 있다.
ErrorDocument가
외부로 (같은 서버라도 http:와
같은 스킴(scheme)으로 시작한다면) 리다이렉션한다면
이중 어떤 것도 설정되지 않는다.
AllowOverride가
적절히 설정되었다면 .htaccess 파일에서
ErrorDocument를 사용할
수 있다.
다음은 예이다...
ErrorDocument 500 /cgi-bin/crash-recover
ErrorDocument 500 "Sorry, our script crashed. Oh dear"
ErrorDocument 500 http://xxx/
ErrorDocument 404 /Lame_excuses/not_found.html
ErrorDocument 401 /Subscription/how_to_subscribe.html
문법은,
ErrorDocument <3-digit-code> <action>
가능한 action은,
URL로 리다이렉션하는 아파치 행동은 스크립트/server-include에 환경변수를 더 넘겨주도록 변경되었다.
리다이렉션되는 스크립트에 표준 CGI 변수들이 넘어간다. 어디에서 리다이렉션이 일어났는지 알 수 없다.
리다이렉션된 스크립트는 새로운 환경변수들을 사용할
수 있다. 모두 앞에 REDIRECT_가 붙어있다.
REDIRECT_ 환경변수는 원래 CGI 환경변수명
앞에 REDIRECT_를 붙여서 만든다. 예를
들어, HTTP_USER_AGENT는
REDIRECT_HTTP_USER_AGENT가 되었다. 이런 변수에
추가로 스크립트가 원래 URL을 알도록 아파치는
REDIRECT_URL과 REDIRECT_STATUS를
정의한다. 원래 URL과 리다이렉션된 URL 모두 접근 로그에
기록할 수 있다.
ErrorDocument가 같은 서버에 있는 CGI 스크립트로
리다이렉션한다면, 스크립트는 클라이언트에게 오류 상황을
확실히 전달하기위해 출력에 "Status:" 헤더
필드를 포함해야 한다. 예를 들어, Perl로 작성한 ErrorDocument
스크립트는 다음과 같다:
...
print "Content-type: text/html\n";
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
...
404 Not Found와 같은 특정 오류
상황에 대한 스크립트라면, 대신 (역주; 고정된)
특정 상태코드와 오류문을 사용할 수 있다.
(클라이언트에게 리다이렉션을 요청하기위해) 응답에
Location: 헤더를 포함한다면, 스크립트는
반드시 (302 Found 같은) 적절한
Status: 헤더를 출력해야 함을 주의하라. 그렇지않으면
Location: 헤더가 아무 소용없게 될 수 있다.
Apache HTTP Server Version 2.0
This document has not been updated to take into account changes made in the 2.0 version of the Apache HTTP Server. Some of the information may still be relevant, but please use it with care.
These are some notes on the Apache API and the data structures you have to deal with, etc. They are not yet nearly complete, but hopefully, they will help you get your bearings. Keep in mind that the API is still subject to change as we gain experience with it. (See the TODO file for what might be coming). However, it will be easy to adapt modules to any changes that are made. (We have more modules to adapt than you do).
A few notes on general pedagogical style here. In the interest of conciseness, all structure declarations here are incomplete -- the real ones have more slots that I'm not telling you about. For the most part, these are reserved to one component of the server core or another, and should be altered by modules with caution. However, in some cases, they really are things I just haven't gotten around to yet. Welcome to the bleeding edge.
Finally, here's an outline, to give you some bare idea of what's coming up, and in what order:
We begin with an overview of the basic concepts behind the API, and how they are manifested in the code.
Apache breaks down request handling into a series of steps, more or less the same way the Netscape server API does (although this API has a few more stages than NetSite does, as hooks for stuff I thought might be useful in the future). These are:
SetEnv, which don't really fit well elsewhere.These phases are handled by looking at each of a succession of modules, looking to see if each of them has a handler for the phase, and attempting invoking it if so. The handler can typically do one of three things:
OK.DECLINED. In this case, the server behaves in all
respects as if the handler simply hadn't been there.Most phases are terminated by the first module that handles them;
however, for logging, `fixups', and non-access authentication checking,
all handlers always run (barring an error). Also, the response phase is
unique in that modules may declare multiple handlers for it, via a
dispatch table keyed on the MIME type of the requested object. Modules may
declare a response-phase handler which can handle any request,
by giving it the key */* (i.e., a wildcard MIME type
specification). However, wildcard handlers are only invoked if the server
has already tried and failed to find a more specific response handler for
the MIME type of the requested object (either none existed, or they all
declined).
The handlers themselves are functions of one argument (a
request_rec structure. vide infra), which returns an integer,
as above.
At this point, we need to explain the structure of a module. Our
candidate will be one of the messier ones, the CGI module -- this handles
both CGI scripts and the ScriptAlias config file command. It's actually a great deal
more complicated than most modules, but if we're going to have only one
example, it might as well be the one with its fingers in every place.
Let's begin with handlers. In order to handle the CGI scripts, the
module declares a response handler for them. Because of ScriptAlias, it also has handlers for the
name translation phase (to recognize ScriptAliased URIs), the type-checking phase (any
ScriptAliased request is typed
as a CGI script).
The module needs to maintain some per (virtual) server information,
namely, the ScriptAliases in
effect; the module structure therefore contains pointers to a functions
which builds these structures, and to another which combines two of them
(in case the main server and a virtual server both have ScriptAliases declared).
Finally, this module contains code to handle the ScriptAlias command itself. This particular
module only declares one command, but there could be more, so modules have
command tables which declare their commands, and describe where
they are permitted, and how they are to be invoked.
A final note on the declared types of the arguments of some of these
commands: a pool is a pointer to a resource pool
structure; these are used by the server to keep track of the memory which
has been allocated, files opened, etc., either to service a
particular request, or to handle the process of configuring itself. That
way, when the request is over (or, for the configuration pool, when the
server is restarting), the memory can be freed, and the files closed,
en masse, without anyone having to write explicit code to track
them all down and dispose of them. Also, a cmd_parms
structure contains various information about the config file being read,
and other status information, which is sometimes of use to the function
which processes a config-file command (such as ScriptAlias). With no further ado, the
module itself:
/* Declarations of handlers. */
int translate_scriptalias (request_rec *);
int type_scriptalias (request_rec *);
int cgi_handler (request_rec *);
/* Subsidiary dispatch table for response-phase
* handlers, by MIME type */
handler_rec cgi_handlers[] = {
{ "application/x-httpd-cgi", cgi_handler },
{ NULL }
};
/* Declarations of routines to manipulate the
* module's configuration info. Note that these are
* returned, and passed in, as void *'s; the server
* core keeps track of them, but it doesn't, and can't,
* know their internal structure.
*/
void *make_cgi_server_config (pool *);
void *merge_cgi_server_config (pool *, void *, void *);
/* Declarations of routines to handle config-file commands */
extern char *script_alias(cmd_parms *, void *per_dir_config, char *fake,
char *real);
command_rec cgi_cmds[] = {
{ "ScriptAlias", script_alias, NULL, RSRC_CONF, TAKE2,
"a fakename and a realname"},
{ NULL }
};
module cgi_module = {
STANDARD_MODULE_STUFF, NULL, /* initializer */ NULL, /* dir config creator */ NULL, /* dir merger */ make_cgi_server_config, /* server config */ merge_cgi_server_config, /* merge server config */ cgi_cmds, /* command table */ cgi_handlers, /* handlers */ translate_scriptalias, /* filename translation */ NULL, /* check_user_id */ NULL, /* check auth */ NULL, /* check access */ type_scriptalias, /* type_checker */ NULL, /* fixups */ NULL, /* logger */ NULL /* header parser */ };
The sole argument to handlers is a request_rec structure.
This structure describes a particular request which has been made to the
server, on behalf of a client. In most cases, each connection to the
client generates only one request_rec structure.
The request_rec contains pointers to a resource pool
which will be cleared when the server is finished handling the request;
to structures containing per-server and per-connection information, and
most importantly, information on the request itself.
The most important such information is a small set of character strings describing attributes of the object being requested, including its URI, filename, content-type and content-encoding (these being filled in by the translation and type-check handlers which handle the request, respectively).
Other commonly used data items are tables giving the MIME headers on
the client's original request, MIME headers to be sent back with the
response (which modules can add to at will), and environment variables for
any subprocesses which are spawned off in the course of servicing the
request. These tables are manipulated using the ap_table_get
and ap_table_set routines.
Note that the Content-type header value cannot
be set by module content-handlers using the ap_table_*()
routines. Rather, it is set by pointing the content_type
field in the request_rec structure to an appropriate
string. e.g.,
r->content_type = "text/html";
Finally, there are pointers to two data structures which, in turn,
point to per-module configuration structures. Specifically, these hold
pointers to the data structures which the module has built to describe
the way it has been configured to operate in a given directory (via
.htaccess files or <Directory> sections), for private data it has built in the
course of servicing the request (so modules' handlers for one phase can
pass `notes' to their handlers for other phases). There is another such
configuration vector in the server_rec data structure pointed
to by the request_rec, which contains per (virtual) server
configuration data.
Here is an abridged declaration, giving the fields most commonly used:
struct request_rec {
pool *pool;
conn_rec *connection;
server_rec *server;
/* What object is being requested */
char *uri;
char *filename;
char *path_info;
char *args; /* QUERY_ARGS, if any */
struct stat finfo; /* Set by server core;
* st_mode set to zero if no such file */
char *content_type;
char *content_encoding;
/* MIME header environments, in and out. Also,
* an array containing environment variables to
* be passed to subprocesses, so people can write
* modules to add to that environment.
*
* The difference between headers_out and
* err_headers_out is that the latter are printed
* even on error, and persist across internal
* redirects (so the headers printed for
* ErrorDocument handlers will have
them).
*/
table *headers_in;
table *headers_out;
table *err_headers_out;
table *subprocess_env;
/* Info about the request itself... */
int header_only; /* HEAD request, as opposed to GET */ char *protocol; /* Protocol, as given to us, or HTTP/0.9 */ char *method; /* GET, HEAD, POST, etc. */ int method_number; /* M_GET, M_POST, etc. */
/* Info for logging */
char *the_request;
int bytes_sent;
/* A flag which modules can set, to indicate that
* the data being returned is volatile, and clients
* should be told not to cache it.
*/
int no_cache;
/* Various other config info which may change
* with .htaccess files
* These are config vectors, with one void*
* pointer for each module (the thing pointed
* to being the module's business).
*/
void *per_dir_config; /* Options set in config files, etc. */ void *request_config; /* Notes on *this* request */
};
Most request_rec structures are built by reading an HTTP
request from a client, and filling in the fields. However, there are a
few exceptions:
*.var file), or a CGI script which returned a local
`Location:', then the resource which the user requested is going to be
ultimately located by some URI other than what the client originally
supplied. In this case, the server does an internal redirect,
constructing a new request_rec for the new URI, and
processing it almost exactly as if the client had requested the new URI
directly.ErrorDocument
is in scope, the same internal redirect machinery comes into play.Finally, a handler occasionally needs to investigate `what would happen if' some other request were run. For instance, the directory indexing module needs to know what MIME type would be assigned to a request for each directory entry, in order to figure out what icon to use.
Such handlers can construct a sub-request, using the
functions ap_sub_req_lookup_file,
ap_sub_req_lookup_uri, and ap_sub_req_method_uri;
these construct a new request_rec structure and processes it
as you would expect, up to but not including the point of actually sending
a response. (These functions skip over the access checks if the
sub-request is for a file in the same directory as the original
request).
(Server-side includes work by building sub-requests and then actually
invoking the response handler for them, via the function
ap_run_sub_req).
As discussed above, each handler, when invoked to handle a particular
request_rec, has to return an int to indicate
what happened. That can either be
OK -- the request was handled successfully. This may or
may not terminate the phase.DECLINED -- no erroneous condition exists, but the module
declines to handle the phase; the server tries to find another.Note that if the error code returned is REDIRECT, then
the module should put a Location in the request's
headers_out, to indicate where the client should be
redirected to.
Handlers for most phases do their work by simply setting a few fields
in the request_rec structure (or, in the case of access
checkers, simply by returning the correct error code). However, response
handlers have to actually send a request back to the client.
They should begin by sending an HTTP response header, using the
function ap_send_http_header. (You don't have to do anything
special to skip sending the header for HTTP/0.9 requests; the function
figures out on its own that it shouldn't do anything). If the request is
marked header_only, that's all they should do; they should
return after that, without attempting any further output.
Otherwise, they should produce a request body which responds to the
client as appropriate. The primitives for this are ap_rputc
and ap_rprintf, for internally generated output, and
ap_send_fd, to copy the contents of some FILE *
straight to the client.
At this point, you should more or less understand the following piece
of code, which is the handler which handles GET requests
which have no more specific handler; it also shows how conditional
GETs can be handled, if it's desirable to do so in a
particular response handler -- ap_set_last_modified checks
against the If-modified-since value supplied by the client,
if any, and returns an appropriate code (which will, if nonzero, be
USE_LOCAL_COPY). No similar considerations apply for
ap_set_content_length, but it returns an error code for
symmetry.
int default_handler (request_rec *r)
{
int errstatus;
FILE *f;
if (r->method_number != M_GET) return DECLINED;
if (r->finfo.st_mode == 0) return NOT_FOUND;
if ((errstatus = ap_set_content_length (r, r->finfo.st_size))
||
(errstatus = ap_set_last_modified (r, r->finfo.st_mtime)))
return errstatus;
f = fopen (r->filename, "r");
if (f == NULL) {
log_reason("file permissions deny server access", r->filename, r);
return FORBIDDEN;
}
register_timeout ("send", r);
ap_send_http_header (r);
if (!r->header_only) send_fd (f, r);
ap_pfclose (r->pool, f);
return OK;
}
Finally, if all of this is too much of a challenge, there are a few
ways out of it. First off, as shown above, a response handler which has
not yet produced any output can simply return an error code, in which
case the server will automatically produce an error response. Secondly,
it can punt to some other handler by invoking
ap_internal_redirect, which is how the internal redirection
machinery discussed above is invoked. A response handler which has
internally redirected should always return OK.
(Invoking ap_internal_redirect from handlers which are
not response handlers will lead to serious confusion).
Stuff that should be discussed here in detail:
ap_auth_type,
ap_auth_name, and ap_requires.ap_get_basic_auth_pw, which sets the
connection->user structure field
automatically, and ap_note_basic_auth_failure,
which arranges for the proper WWW-Authenticate:
header to be sent back).When a request has internally redirected, there is the question of
what to log. Apache handles this by bundling the entire chain of redirects
into a list of request_rec structures which are threaded
through the r->prev and r->next pointers.
The request_rec which is passed to the logging handlers in
such cases is the one which was originally built for the initial request
from the client; note that the bytes_sent field will only be
correct in the last request in the chain (the one for which a response was
actually sent).
One of the problems of writing and designing a server-pool server is that of preventing leakage, that is, allocating resources (memory, open files, etc.), without subsequently releasing them. The resource pool machinery is designed to make it easy to prevent this from happening, by allowing resource to be allocated in such a way that they are automatically released when the server is done with them.
The way this works is as follows: the memory which is allocated, file opened, etc., to deal with a particular request are tied to a resource pool which is allocated for the request. The pool is a data structure which itself tracks the resources in question.
When the request has been processed, the pool is cleared. At that point, all the memory associated with it is released for reuse, all files associated with it are closed, and any other clean-up functions which are associated with the pool are run. When this is over, we can be confident that all the resource tied to the pool have been released, and that none of them have leaked.
Server restarts, and allocation of memory and resources for per-server configuration, are handled in a similar way. There is a configuration pool, which keeps track of resources which were allocated while reading the server configuration files, and handling the commands therein (for instance, the memory that was allocated for per-server module configuration, log files and other files that were opened, and so forth). When the server restarts, and has to reread the configuration files, the configuration pool is cleared, and so the memory and file descriptors which were taken up by reading them the last time are made available for reuse.
It should be noted that use of the pool machinery isn't generally
obligatory, except for situations like logging handlers, where you really
need to register cleanups to make sure that the log file gets closed when
the server restarts (this is most easily done by using the function ap_pfopen, which also arranges for the
underlying file descriptor to be closed before any child processes, such as
for CGI scripts, are execed), or in case you are using the
timeout machinery (which isn't yet even documented here). However, there are
two benefits to using it: resources allocated to a pool never leak (even if
you allocate a scratch string, and just forget about it); also, for memory
allocation, ap_palloc is generally faster than
malloc.
We begin here by describing how memory is allocated to pools, and then discuss how other resources are tracked by the resource pool machinery.
Memory is allocated to pools by calling the function
ap_palloc, which takes two arguments, one being a pointer to
a resource pool structure, and the other being the amount of memory to
allocate (in chars). Within handlers for handling requests,
the most common way of getting a resource pool structure is by looking at
the pool slot of the relevant request_rec; hence
the repeated appearance of the following idiom in module code:
int my_handler(request_rec *r)
{
struct my_structure *foo;
...
foo = (foo *)ap_palloc (r->pool, sizeof(my_structure));
}
Note that there is no ap_pfree --
ap_palloced memory is freed only when the associated resource
pool is cleared. This means that ap_palloc does not have to
do as much accounting as malloc(); all it does in the typical
case is to round up the size, bump a pointer, and do a range check.
(It also raises the possibility that heavy use of
ap_palloc could cause a server process to grow excessively
large. There are two ways to deal with this, which are dealt with below;
briefly, you can use malloc, and try to be sure that all of
the memory gets explicitly freed, or you can allocate a
sub-pool of the main pool, allocate your memory in the sub-pool, and clear
it out periodically. The latter technique is discussed in the section
on sub-pools below, and is used in the directory-indexing code, in order
to avoid excessive storage allocation when listing directories with
thousands of files).
There are functions which allocate initialized memory, and are
frequently useful. The function ap_pcalloc has the same
interface as ap_palloc, but clears out the memory it
allocates before it returns it. The function ap_pstrdup
takes a resource pool and a char * as arguments, and
allocates memory for a copy of the string the pointer points to, returning
a pointer to the copy. Finally ap_pstrcat is a varargs-style
function, which takes a pointer to a resource pool, and at least two
char * arguments, the last of which must be
NULL. It allocates enough memory to fit copies of each of
the strings, as a unit; for instance:
ap_pstrcat (r->pool, "foo", "/", "bar", NULL);
returns a pointer to 8 bytes worth of memory, initialized to
"foo/bar".
A pool is really defined by its lifetime more than anything else. There are some static pools in http_main which are passed to various non-http_main functions as arguments at opportune times. Here they are:
permanent_poolpconfptemppchildptransr->poolFor almost everything folks do, r->pool is the pool to
use. But you can see how other lifetimes, such as pchild, are useful to
some modules... such as modules that need to open a database connection
once per child, and wish to clean it up when the child dies.
You can also see how some bugs have manifested themself, such as
setting connection->user to a value from
r->pool -- in this case connection exists for the
lifetime of ptrans, which is longer than
r->pool (especially if r->pool is a
subrequest!). So the correct thing to do is to allocate from
connection->pool.
And there was another interesting bug in mod_include
/ mod_cgi. You'll see in those that they do this test
to decide if they should use r->pool or
r->main->pool. In this case the resource that they are
registering for cleanup is a child process. If it were registered in
r->pool, then the code would wait() for the
child when the subrequest finishes. With mod_include this
could be any old #include, and the delay can be up to 3
seconds... and happened quite frequently. Instead the subprocess is
registered in r->main->pool which causes it to be
cleaned up when the entire request is done -- i.e., after the
output has been sent to the client and logging has happened.
As indicated above, resource pools are also used to track other sorts
of resources besides memory. The most common are open files. The routine
which is typically used for this is ap_pfopen, which takes a
resource pool and two strings as arguments; the strings are the same as
the typical arguments to fopen, e.g.,
...
FILE *f = ap_pfopen (r->pool, r->filename, "r");
if (f == NULL) { ... } else { ... }
There is also a ap_popenf routine, which parallels the
lower-level open system call. Both of these routines arrange
for the file to be closed when the resource pool in question is
cleared.
Unlike the case for memory, there are functions to close files
allocated with ap_pfopen, and ap_popenf, namely
ap_pfclose and ap_pclosef. (This is because, on
many systems, the number of files which a single process can have open is
quite limited). It is important to use these functions to close files
allocated with ap_pfopen and ap_popenf, since to
do otherwise could cause fatal errors on systems such as Linux, which
react badly if the same FILE* is closed more than once.
(Using the close functions is not mandatory, since the
file will eventually be closed regardless, but you should consider it in
cases where your module is opening, or could open, a lot of files).
More text goes here. Describe the cleanup primitives in terms of
which the file stuff is implemented; also, spawn_process.
Pool cleanups live until clear_pool() is called:
clear_pool(a) recursively calls destroy_pool()
on all subpools of a; then calls all the cleanups for
a; then releases all the memory for a.
destroy_pool(a) calls clear_pool(a) and then
releases the pool structure itself. i.e.,
clear_pool(a) doesn't delete a, it just frees
up all the resources and you can start using it again immediately.
On rare occasions, too-free use of ap_palloc() and the
associated primitives may result in undesirably profligate resource
allocation. You can deal with such a case by creating a sub-pool,
allocating within the sub-pool rather than the main pool, and clearing or
destroying the sub-pool, which releases the resources which were
associated with it. (This really is a rare situation; the only
case in which it comes up in the standard module set is in case of listing
directories, and then only with very large directories.
Unnecessary use of the primitives discussed here can hair up your code
quite a bit, with very little gain).
The primitive for creating a sub-pool is ap_make_sub_pool,
which takes another pool (the parent pool) as an argument. When the main
pool is cleared, the sub-pool will be destroyed. The sub-pool may also be
cleared or destroyed at any time, by calling the functions
ap_clear_pool and ap_destroy_pool, respectively.
(The difference is that ap_clear_pool frees resources
associated with the pool, while ap_destroy_pool also
deallocates the pool itself. In the former case, you can allocate new
resources within the pool, and clear it again, and so forth; in the
latter case, it is simply gone).
One final note -- sub-requests have their own resource pools, which are
sub-pools of the resource pool for the main request. The polite way to
reclaim the resources associated with a sub request which you have
allocated (using the ap_sub_req_... functions) is
ap_destroy_sub_req, which frees the resource pool. Before
calling this function, be sure to copy anything that you care about which
might be allocated in the sub-request's resource pool into someplace a
little less volatile (for instance, the filename in its
request_rec structure).
(Again, under most circumstances, you shouldn't feel obliged to call
this function; only 2K of memory or so are allocated for a typical sub
request, and it will be freed anyway when the main request pool is
cleared. It is only when you are allocating many, many sub-requests for a
single main request that you should seriously consider the
ap_destroy_... functions).
One of the design goals for this server was to maintain external compatibility with the NCSA 1.3 server --- that is, to read the same configuration files, to process all the directives therein correctly, and in general to be a drop-in replacement for NCSA. On the other hand, another design goal was to move as much of the server's functionality into modules which have as little as possible to do with the monolithic server core. The only way to reconcile these goals is to move the handling of most commands from the central server into the modules.
However, just giving the modules command tables is not enough to divorce
them completely from the server core. The server has to remember the
commands in order to act on them later. That involves maintaining data which
is private to the modules, and which can be either per-server, or
per-directory. Most things are per-directory, including in particular access
control and authorization information, but also information on how to
determine file types from suffixes, which can be modified by
AddType and DefaultType directives, and so forth. In general,
the governing philosophy is that anything which can be made
configurable by directory should be; per-server information is generally
used in the standard set of modules for information like
Aliases and Redirects which come into play before the
request is tied to a particular place in the underlying file system.
Another requirement for emulating the NCSA server is being able to handle
the per-directory configuration files, generally called
.htaccess files, though even in the NCSA server they can
contain directives which have nothing at all to do with access control.
Accordingly, after URI -> filename translation, but before performing any
other phase, the server walks down the directory hierarchy of the underlying
filesystem, following the translated pathname, to read any
.htaccess files which might be present. The information which
is read in then has to be merged with the applicable information
from the server's own config files (either from the <Directory> sections in
access.conf, or from defaults in srm.conf, which
actually behaves for most purposes almost exactly like <Directory
/>).
Finally, after having served a request which involved reading
.htaccess files, we need to discard the storage allocated for
handling them. That is solved the same way it is solved wherever else
similar problems come up, by tying those structures to the per-transaction
resource pool.
Let's look out how all of this plays out in mod_mime.c,
which defines the file typing handler which emulates the NCSA server's
behavior of determining file types from suffixes. What we'll be looking
at, here, is the code which implements the AddType and AddEncoding commands. These commands can appear in
.htaccess files, so they must be handled in the module's
private per-directory data, which in fact, consists of two separate
tables for MIME types and encoding information, and is declared as
follows:
typedef struct {
table *forced_types; /* Additional AddTyped stuff */
table *encoding_types; /* Added with AddEncoding... */
} mime_dir_config;When the server is reading a configuration file, or <Directory> section, which includes
one of the MIME module's commands, it needs to create a
mime_dir_config structure, so those commands have something
to act on. It does this by invoking the function it finds in the module's
`create per-dir config slot', with two arguments: the name of the
directory to which this configuration information applies (or
NULL for srm.conf), and a pointer to a
resource pool in which the allocation should happen.
(If we are reading a .htaccess file, that resource pool
is the per-request resource pool for the request; otherwise it is a
resource pool which is used for configuration data, and cleared on
restarts. Either way, it is important for the structure being created to
vanish when the pool is cleared, by registering a cleanup on the pool if
necessary).
For the MIME module, the per-dir config creation function just
ap_pallocs the structure above, and a creates a couple of
tables to fill it. That looks like this:
void *create_mime_dir_config (pool *p, char *dummy)
{
mime_dir_config *new =
(mime_dir_config *) ap_palloc (p, sizeof(mime_dir_config));
new->forced_types = ap_make_table (p, 4);
new->encoding_types = ap_make_table (p, 4);
return new;
}
Now, suppose we've just read in a .htaccess file. We
already have the per-directory configuration structure for the next
directory up in the hierarchy. If the .htaccess file we just
read in didn't have any AddType
or AddEncoding commands, its
per-directory config structure for the MIME module is still valid, and we
can just use it. Otherwise, we need to merge the two structures
somehow.
To do that, the server invokes the module's per-directory config merge function, if one is present. That function takes three arguments: the two structures being merged, and a resource pool in which to allocate the result. For the MIME module, all that needs to be done is overlay the tables from the new per-directory config structure with those from the parent:
void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv)
{
mime_dir_config *parent_dir = (mime_dir_config *)parent_dirv;
mime_dir_config *subdir = (mime_dir_config *)subdirv;
mime_dir_config *new =
(mime_dir_config *)ap_palloc (p, sizeof(mime_dir_config));
new->forced_types = ap_overlay_tables (p, subdir->forced_types,
parent_dir->forced_types);
new->encoding_types = ap_overlay_tables (p, subdir->encoding_types,
parent_dir->encoding_types);
return new;
}
As a note -- if there is no per-directory merge function present, the
server will just use the subdirectory's configuration info, and ignore
the parent's. For some modules, that works just fine (e.g., for
the includes module, whose per-directory configuration information
consists solely of the state of the XBITHACK), and for those
modules, you can just not declare one, and leave the corresponding
structure slot in the module itself NULL.
Now that we have these structures, we need to be able to figure out how
to fill them. That involves processing the actual AddType and AddEncoding commands. To find commands, the server looks in
the module's command table. That table contains information on how many
arguments the commands take, and in what formats, where it is permitted,
and so forth. That information is sufficient to allow the server to invoke
most command-handling functions with pre-parsed arguments. Without further
ado, let's look at the AddType
command handler, which looks like this (the AddEncoding command looks basically the same, and won't be
shown here):
char *add_type(cmd_parms *cmd, mime_dir_config *m, char *ct, char *ext)
{
if (*ext == '.') ++ext;
ap_table_set (m->forced_types, ext, ct);
return NULL;
}
This command handler is unusually simple. As you can see, it takes
four arguments, two of which are pre-parsed arguments, the third being the
per-directory configuration structure for the module in question, and the
fourth being a pointer to a cmd_parms structure. That
structure contains a bunch of arguments which are frequently of use to
some, but not all, commands, including a resource pool (from which memory
can be allocated, and to which cleanups should be tied), and the (virtual)
server being configured, from which the module's per-server configuration
data can be obtained if required.
Another way in which this particular command handler is unusually
simple is that there are no error conditions which it can encounter. If
there were, it could return an error message instead of NULL;
this causes an error to be printed out on the server's
stderr, followed by a quick exit, if it is in the main config
files; for a .htaccess file, the syntax error is logged in
the server error log (along with an indication of where it came from), and
the request is bounced with a server error response (HTTP error status,
code 500).
The MIME module's command table has entries for these commands, which look like this:
command_rec mime_cmds[] = {
{ "AddType", add_type, NULL, OR_FILEINFO, TAKE2,
"a mime type followed by a file extension" },
{ "AddEncoding", add_encoding, NULL, OR_FILEINFO, TAKE2,
"an encoding (e.g., gzip), followed by a file extension" },
{ NULL }
};
The entries in these tables are:
(void *) pointer, which is passed in the
cmd_parms structure to the command handler ---
this is useful in case many similar commands are handled by
the same function.AllowOverride option, and an additional mask
bit, RSRC_CONF, indicating that the command may
appear in the server's own config files, but not in
any .htaccess file.TAKE2 indicates two pre-parsed arguments. Other
options are TAKE1, which indicates one
pre-parsed argument, FLAG, which indicates that
the argument should be On or Off,
and is passed in as a boolean flag, RAW_ARGS,
which causes the server to give the command the raw, unparsed
arguments (everything but the command name itself). There is
also ITERATE, which means that the handler looks
the same as TAKE1, but that if multiple
arguments are present, it should be called multiple times,
and finally ITERATE2, which indicates that the
command handler looks like a TAKE2, but if more
arguments are present, then it should be called multiple
times, holding the first argument constant.NULL).Finally, having set this all up, we have to use it. This is ultimately
done in the module's handlers, specifically for its file-typing handler,
which looks more or less like this; note that the per-directory
configuration structure is extracted from the request_rec's
per-directory configuration vector by using the
ap_get_module_config function.
int find_ct(request_rec *r)
{
int i;
char *fn = ap_pstrdup (r->pool, r->filename);
mime_dir_config *conf = (mime_dir_config *)
ap_get_module_config(r->per_dir_config, &mime_module);
char *type;
if (S_ISDIR(r->finfo.st_mode)) {
r->content_type = DIR_MAGIC_TYPE;
return OK;
}
if((i=ap_rind(fn,'.')) < 0) return DECLINED;
++i;
if ((type = ap_table_get (conf->encoding_types, &fn[i])))
{
r->content_encoding = type;
/* go back to previous extension to try to use it as a type */
fn[i-1] = '\0';
if((i=ap_rind(fn,'.')) < 0) return OK;
++i;
}
if ((type = ap_table_get (conf->forced_types, &fn[i])))
{
r->content_type = type;
}
return OK;
}
The basic ideas behind per-server module configuration are basically the same as those for per-directory configuration; there is a creation function and a merge function, the latter being invoked where a virtual server has partially overridden the base server configuration, and a combined structure must be computed. (As with per-directory configuration, the default if no merge function is specified, and a module is configured in some virtual server, is that the base configuration is simply ignored).
The only substantial difference is that when a command needs to
configure the per-server private module data, it needs to go to the
cmd_parms data to get at it. Here's an example, from the
alias module, which also indicates how a syntax error can be returned
(note that the per-directory configuration argument to the command
handler is declared as a dummy, since the module doesn't actually have
per-directory config data):
char *add_redirect(cmd_parms *cmd, void *dummy, char *f, char *url)
{
server_rec *s = cmd->server;
alias_server_conf *conf = (alias_server_conf *)
ap_get_module_config(s->module_config,&alias_module);
alias_entry *new = ap_push_array (conf->redirects);
if (!ap_is_url (url)) return "Redirect to non-URL";
new->fake = f; new->real = url;
return NULL;
}
Apache HTTP Server Version 2.0
The allocation mechanism's within APR have a number of debugging modes that can be used to assist in finding memory problems. This document describes the modes available and gives instructions on activating them.
free()d memory and other such
nonsense.The theory is simple. The FILL_BYTE (0xa5)
is written over all malloc'd memory as we receive it, and
is written over everything that we free up during a
clear_pool. We check that blocks on the free list always
have the FILL_BYTE in them, and we check during
palloc() that the bytes still have FILL_BYTE
in them. If you ever see garbage URLs or whatnot containing lots
of 0xa5s then you know something used data that's been
freed or uninitialized.
malloc() and free()d appropriately at the
end.This is intended to be used with something like Electric
Fence or Purify to help detect memory problems. Note that if
you're using efence then you should also add in ALLOC_DEBUG.
But don't add in ALLOC_DEBUG if you're using Purify because
ALLOC_DEBUG would hide all the uninitialized read errors
that Purify can diagnose.
In particular, it causes the table_{set,add,merge}n
routines to check that their arguments are safe for the
apr_table_t they're being placed in. It currently only works
with the unix multiprocess model, but could be extended to others.
This requires a recent gcc which supports
__builtin_return_address(). The error_log output will be a
message such as:
table_push: apr_table_t created by 0x804d874 hit limit of 10
Use l *0x804d874 to find the
source that corresponds to. It indicates that a apr_table_t
allocated by a call at that address has possibly too small an
initial apr_table_t size guess.
This requires a bit of an understanding of how alloc.c works.
Not all the options outlined above can be activated at the same time. the following table gives more information.
| ALLOC DEBUG | ALLOC USE MALLOC | POOL DEBUG | MAKE TABLE PROFILE | ALLOC STATS | |
|---|---|---|---|---|---|
| ALLOC DEBUG | - | No | Yes | Yes | Yes |
| ALLOC USE MALLOC | No | - | No | No | No |
| POOL DEBUG | Yes | No | - | Yes | Yes |
| MAKE TABLE PROFILE | Yes | No | Yes | - | Yes |
| ALLOC STATS | Yes | No | Yes | Yes | - |
Additionally the debugging options are not suitable for multi-threaded versions of the server. When trying to debug with these options the server should be started in single process mode.
The various options for debugging memory are now enabled in
the apr_general.h header file in APR. The various options are
enabled by uncommenting the define for the option you wish to
use. The section of the code currently looks like this
(contained in srclib/apr/include/apr_pools.h)
/*
#define ALLOC_DEBUG
#define POOL_DEBUG
#define ALLOC_USE_MALLOC
#define MAKE_TABLE_PROFILE
#define ALLOC_STATS
*/
typedef struct ap_pool_t {
union block_hdr *first;
union block_hdr *last;
struct cleanup *cleanups;
struct process_chain *subprocesses;
struct ap_pool_t *sub_pools;
struct ap_pool_t *sub_next;
struct ap_pool_t *sub_prev;
struct ap_pool_t *parent;
char *free_first_avail;
#ifdef ALLOC_USE_MALLOC
void *allocation_list;
#endif
#ifdef POOL_DEBUG
struct ap_pool_t *joined;
#endif
int (*apr_abort)(int retcode);
struct datastruct *prog_data;
} ap_pool_t;
To enable allocation debugging simply move the #define
ALLOC_DEBUG above the start of the comments block and rebuild
the server.
In order to use the various options the server must be rebuilt after editing the header file.
Apache HTTP Server Version 2.0
Apache 2.0 uses Doxygen to document the APIs and global variables in the code. This will explain the basics of how to document using Doxygen.
To start a documentation block, use /**
To end a documentation block, use */
In the middle of the block, there are multiple tags we can use:
Description of this functions purpose
@param parameter_name description
@return description
@deffunc signature of the function
The deffunc is not always necessary. DoxyGen does not
have a full parser in it, so any prototype that use a macro in the
return type declaration is too complex for scandoc. Those functions
require a deffunc. An example (using > rather
than >):
/**
* return the final element of the pathname
* @param pathname The path to get the final element of
* @return the final element of the path
* @tip Examples:
* <pre>
* "/foo/bar/gum" -> "gum"
* "/foo/bar/gum/" -> ""
* "gum" -> "gum"
* "wi\\n32\\stuff" -> "stuff"
* </pre>
* @deffunc const char * ap_filename_of_pathname(const char *pathname)
*/
At the top of the header file, always include:
/**
* @package Name of library header
*/
Doxygen uses a new HTML file for each package. The HTML files are named {Name_of_library_header}.html, so try to be concise with your names.
For a further discussion of the possibilities please refer to the Doxygen site.
Apache HTTP Server Version 2.0
This is a cut 'n paste job from an email (<022501c1c529$f63a9550$7f00000a@KOJ>) and only reformatted for better readability. It's not up to date but may be a good start for further research.
There are three basic filter types (each of these is actually broken down into two categories, but that comes later).
CONNECTIONAP_FTYPE_CONNECTION, AP_FTYPE_NETWORK)PROTOCOLAP_FTYPE_PROTOCOL,
AP_FTYPE_TRANSCODE)RESOURCEPROTOCOL, but internal redirects and sub-requests can change
the content without ending the request. (AP_FTYPE_RESOURCE,
AP_FTYPE_CONTENT_SET)It is important to make the distinction between a protocol and a resource filter. A resource filter is tied to a specific resource, it may also be tied to header information, but the main binding is to a resource. If you are writing a filter and you want to know if it is resource or protocol, the correct question to ask is: "Can this filter be removed if the request is redirected to a different resource?" If the answer is yes, then it is a resource filter. If it is no, then it is most likely a protocol or connection filter. I won't go into connection filters, because they seem to be well understood. With this definition, a few examples might help:
The further breakdown of each category into two more filter types is
strictly for ordering. We could remove it, and only allow for one
filter type, but the order would tend to be wrong, and we would need to
hack things to make it work. Currently, the RESOURCE filters
only have one filter type, but that should change.
This is actually rather simple in theory, but the code is
complex. First of all, it is important that everybody realize that
there are three filter lists for each request, but they are all
concatenated together. So, the first list is
r->output_filters, then r->proto_output_filters,
and finally r->connection->output_filters. These correspond
to the RESOURCE, PROTOCOL, and
CONNECTION filters respectively. The problem previously, was
that we used a singly linked list to create the filter stack, and we
started from the "correct" location. This means that if I had a
RESOURCE filter on the stack, and I added a
CONNECTION filter, the CONNECTION filter would
be ignored. This should make sense, because we would insert the connection
filter at the top of the c->output_filters list, but the end
of r->output_filters pointed to the filter that used to be
at the front of c->output_filters. This is obviously wrong.
The new insertion code uses a doubly linked list. This has the advantage
that we never lose a filter that has been inserted. Unfortunately, it comes
with a separate set of headaches.
The problem is that we have two different cases were we use subrequests. The first is to insert more data into a response. The second is to replace the existing response with an internal redirect. These are two different cases and need to be treated as such.
In the first case, we are creating the subrequest from within a handler
or filter. This means that the next filter should be passed to
make_sub_request function, and the last resource filter in the
sub-request will point to the next filter in the main request. This
makes sense, because the sub-request's data needs to flow through the
same set of filters as the main request. A graphical representation
might help:
Default_handler --> includes_filter --> byterange --> ...
If the includes filter creates a sub request, then we don't want the data from that sub-request to go through the includes filter, because it might not be SSI data. So, the subrequest adds the following:
Default_handler --> includes_filter -/-> byterange --> ...
/
Default_handler --> sub_request_core
What happens if the subrequest is SSI data? Well, that's easy, the
includes_filter is a resource filter, so it will be added to
the sub request in between the Default_handler and the
sub_request_core filter.
The second case for sub-requests is when one sub-request is going to
become the real request. This happens whenever a sub-request is created
outside of a handler or filter, and NULL is passed as the next filter to
the make_sub_request function.
In this case, the resource filters no longer make sense for the new request, because the resource has changed. So, instead of starting from scratch, we simply point the front of the resource filters for the sub-request to the front of the protocol filters for the old request. This means that we won't lose any of the protocol filters, neither will we try to send this data through a filter that shouldn't see it.
The problem is that we are using a doubly-linked list for our filter stacks now. But, you should notice that it is possible for two lists to intersect in this model. So, you do you handle the previous pointer? This is a very difficult question to answer, because there is no "right" answer, either method is equally valid. I looked at why we use the previous pointer. The only reason for it is to allow for easier addition of new servers. With that being said, the solution I chose was to make the previous pointer always stay on the original request.
This causes some more complex logic, but it works for all cases. My concern in having it move to the sub-request, is that for the more common case (where a sub-request is used to add data to a response), the main filter chain would be wrong. That didn't seem like a good idea to me.
The final topic. :-) Mod_Asis is a bit of a hack, but the
handler needs to remove all filters except for connection filters, and
send the data. If you are using mod_asis, all other
bets are off.
The absolutely last point is that the reason this code was so hard to
get right, was because we had hacked so much to force it to work. I
wrote most of the hacks originally, so I am very much to blame.
However, now that the code is right, I have started to remove some
hacks. Most people should have seen that the reset_filters
and add_required_filters functions are gone. Those inserted
protocol level filters for error conditions, in fact, both functions did
the same thing, one after the other, it was really strange. Because we
don't lose protocol filters for error cases any more, those hacks went away.
The HTTP_HEADER, Content-length, and
Byterange filters are all added in the
insert_filters phase, because if they were added earlier, we
had some interesting interactions. Now, those could all be moved to be
inserted with the HTTP_IN, CORE, and
CORE_IN filters. That would make the code easier to
follow.
Apache HTTP Server Version 2.0
This document is still in development and may be partially out of date.
In general, a hook function is one that Apache will call at some point during the processing of a request. Modules can provide functions that are called, and specify when they get called in comparison to other modules.
In order to create a new hook, four things need to be done:
Use the AP_DECLARE_HOOK macro, which needs to be given
the return type of the hook function, the name of the hook, and the
arguments. For example, if the hook returns an int and
takes a request_rec * and an int and is
called do_something, then declare it like this:
AP_DECLARE_HOOK(int, do_something, (request_rec *r, int n))
This should go in a header which modules will include if they want to use the hook.
Each source file that exports a hook has a private structure which is used to record the module functions that use the hook. This is declared as follows:
APR_HOOK_STRUCT(
APR_HOOK_LINK(do_something)
...
)
The source file that exports the hook has to implement a
function that will call the hook. There are currently three
possible ways to do this. In all cases, the calling function is
called ap_run_hookname().
If the return value of a hook is void, then all the
hooks are called, and the caller is implemented like this:
AP_IMPLEMENT_HOOK_VOID(do_something, (request_rec *r, int n), (r, n))
The second and third arguments are the dummy argument declaration and the dummy arguments as they will be used when calling the hook. In other words, this macro expands to something like this:
void ap_run_do_something(request_rec *r, int n)
{
...
do_something(r, n);
}
If the hook returns a value, then it can either be run until the first hook that does something interesting, like so:
AP_IMPLEMENT_HOOK_RUN_FIRST(int, do_something, (request_rec *r, int n), (r, n), DECLINED)
The first hook that does not return DECLINED
stops the loop and its return value is returned from the hook
caller. Note that DECLINED is the tradition Apache
hook return meaning "I didn't do anything", but it can be
whatever suits you.
Alternatively, all hooks can be run until an error occurs. This boils down to permitting two return values, one of which means "I did something, and it was OK" and the other meaning "I did nothing". The first function that returns a value other than one of those two stops the loop, and its return is the return value. Declare these like so:
AP_IMPLEMENT_HOOK_RUN_ALL(int, do_something, (request_rec *r, int n), (r, n), OK, DECLINED)
Again, OK and DECLINED are the traditional
values. You can use what you want.
At appropriate moments in the code, call the hook caller, like so:
int n, ret;
request_rec *r;
ret=ap_run_do_something(r, n);
A module that wants a hook to be called needs to do two things.
Include the appropriate header, and define a static function of the correct type:
static int my_something_doer(request_rec *r, int n)
{
...
return OK;
}
During initialisation, Apache will call each modules hook registering function, which is included in the module structure:
static void my_register_hooks()
{
ap_hook_do_something(my_something_doer, NULL, NULL, HOOK_MIDDLE);
}
mode MODULE_VAR_EXPORT my_module =
{
...
my_register_hooks /* register hooks */
};
In the example above, we didn't use the three arguments in
the hook registration function that control calling order.
There are two mechanisms for doing this. The first, rather
crude, method, allows us to specify roughly where the hook is
run relative to other modules. The final argument control this.
There are three possible values: HOOK_FIRST,
HOOK_MIDDLE and HOOK_LAST.
All modules using any particular value may be run in any
order relative to each other, but, of course, all modules using
HOOK_FIRST will be run before HOOK_MIDDLE
which are before HOOK_LAST. Modules that don't care
when they are run should use HOOK_MIDDLE. (I spaced
these out so people could do stuff like HOOK_FIRST-2
to get in slightly earlier, but is this wise? - Ben)
Note that there are two more values,
HOOK_REALLY_FIRST and HOOK_REALLY_LAST. These
should only be used by the hook exporter.
The other method allows finer control. When a module knows that it must be run before (or after) some other modules, it can specify them by name. The second (third) argument is a NULL-terminated array of strings consisting of the names of modules that must be run before (after) the current module. For example, suppose we want "mod_xyz.c" and "mod_abc.c" to run before we do, then we'd hook as follows:
static void register_hooks()
{
static const char * const aszPre[] = { "mod_xyz.c", "mod_abc.c", NULL };
ap_hook_do_something(my_something_doer, aszPre, NULL, HOOK_MIDDLE);
}
Note that the sort used to achieve this is stable, so
ordering set by HOOK_ORDER is preserved, as far
as is possible.
Ben Laurie, 15th August 1999
Apache HTTP Server Version 2.0
Many of the documents on these Developer pages are lifted from Apache 1.3's documentation. While they are all being updated to Apache 2.0, they are in different stages of progress. Please be patient, and point out any discrepancies or errors on the developer/ pages directly to the dev@httpd.apache.org mailing list.
Apache HTTP Server Version 2.0
This is a first attempt at writing the lessons I learned
when trying to convert the mod_mmap_static module to Apache
2.0. It's by no means definitive and probably won't even be
correct in some ways, but it's a start.
These now need to be of type apr_status_t and return a
value of that type. Normally the return value will be
APR_SUCCESS unless there is some need to signal an error in
the cleanup. Be aware that even though you signal an error not all code
yet checks and acts upon the error.
These should now be renamed to better signify where they sit
in the overall process. So the name gets a small change from
mmap_init to mmap_post_config. The arguments
passed have undergone a radical change and now look like
apr_pool_t *papr_pool_t *plogapr_pool_t *ptempserver_rec *sA lot of the data types have been moved into the APR. This means that some have had a name change, such as the one shown above. The following is a brief list of some of the changes that you are likely to have to make.
pool becomes apr_pool_ttable becomes apr_table_tThe new architecture uses a series of hooks to provide for
calling your functions. These you'll need to add to your module
by way of a new function, static void register_hooks(void).
The function is really reasonably straightforward once you
understand what needs to be done. Each function that needs
calling at some stage in the processing of a request needs to
be registered, handlers do not. There are a number of phases
where functions can be added, and for each you can specify with
a high degree of control the relative order that the function
will be called in.
This is the code that was added to mod_mmap_static:
static void register_hooks(void)
{
static const char * const aszPre[]={ "http_core.c",NULL };
ap_hook_post_config(mmap_post_config,NULL,NULL,HOOK_MIDDLE);
ap_hook_translate_name(mmap_static_xlat,aszPre,NULL,HOOK_LAST);
};This registers 2 functions that need to be called, one in
the post_config stage (virtually every module will need this
one) and one for the translate_name phase. note that while
there are different function names the format of each is
identical. So what is the format?
ap_hook_phase_name(function_name,
predecessors, successors, position);
There are 3 hook positions defined...
HOOK_FIRSTHOOK_MIDDLEHOOK_LASTTo define the position you use the position and then modify it with the predecessors and successors. Each of the modifiers can be a list of functions that should be called, either before the function is run (predecessors) or after the function has run (successors).
In the mod_mmap_static case I didn't care about the
post_config stage, but the mmap_static_xlat
must be called after the core module had done it's name
translation, hence the use of the aszPre to define a modifier to the
position HOOK_LAST.
There are now a lot fewer stages to worry about when creating your module definition. The old defintion looked like
module MODULE_VAR_EXPORT module_name_module =
{
STANDARD_MODULE_STUFF,
/* initializer */
/* dir config creater */
/* dir merger --- default is to override */
/* server config */
/* merge server config */
/* command handlers */
/* handlers */
/* filename translation */
/* check_user_id */
/* check auth */
/* check access */
/* type_checker */
/* fixups */
/* logger */
/* header parser */
/* child_init */
/* child_exit */
/* post read-request */
};The new structure is a great deal simpler...
module MODULE_VAR_EXPORT module_name_module =
{
STANDARD20_MODULE_STUFF,
/* create per-directory config structures */
/* merge per-directory config structures */
/* create per-server config structures */
/* merge per-server config structures */
/* command handlers */
/* handlers */
/* register hooks */
};Some of these read directly across, some don't. I'll try to summarise what should be done below.
The stages that read directly across :
/* dir config creater *//* create per-directory config structures *//* server config *//* create per-server config structures *//* dir merger *//* merge per-directory config structures *//* merge server config *//* merge per-server config structures *//* command table *//* command apr_table_t *//* handlers *//* handlers */The remainder of the old functions should be registered as hooks. There are the following hook stages defined so far...
ap_hook_post_config_init routines get
registeredap_hook_http_methodap_hook_open_logsap_hook_auth_checkerap_hook_access_checkerap_hook_check_user_idap_hook_default_portap_hook_pre_connectionap_hook_process_connectionap_hook_child_initap_hook_create_requestap_hook_fixupsap_hook_handlerap_hook_header_parserpost_read_request for thisap_hook_insert_filterap_hook_log_transactionap_hook_optional_fn_retrieveap_hook_post_read_requestap_hook_quick_handlerap_hook_translate_nameap_hook_type_checkerApache HTTP Server Version 2.0
Warning - this is a first (fast) draft that needs further revision!
Several changes in Apache 2.0 affect the internal request processing mechanics. Module authors need to be aware of these changes so they may take advantage of the optimizations and security enhancements.
The first major change is to the subrequest and redirect
mechanisms. There were a number of different code paths in
Apache 1.3 to attempt to optimize subrequest or redirect
behavior. As patches were introduced to 2.0, these
optimizations (and the server behavior) were quickly broken due
to this duplication of code. All duplicate code has been folded
back into ap_process_request_internal() to prevent
the code from falling out of sync again.
This means that much of the existing code was 'unoptimized'. It is the Apache HTTP Project's first goal to create a robust and correct implementation of the HTTP server RFC. Additional goals include security, scalability and optimization. New methods were sought to optimize the server (beyond the performance of Apache 1.3) without introducing fragile or insecure code.
All requests pass through ap_process_request_internal()
in request.c, including subrequests and redirects. If a module
doesn't pass generated requests through this code, the author is cautioned
that the module may be broken by future changes to request
processing.
To streamline requests, the module author can take advantage of the hooks offered to drop out of the request cycle early, or to bypass core Apache hooks which are irrelevant (and costly in terms of CPU.)
The request's parsed_uri path is unescaped, once and only
once, at the beginning of internal request processing.
This step is bypassed if the proxyreq flag is set, or the
parsed_uri.path element is unset. The module has no further
control of this one-time unescape operation, either failing to
unescape or multiply unescaping the URL leads to security
reprecussions.
All /../ and /./ elements are
removed by ap_getparents(). This helps to ensure
the path is (nearly) absolute before the request processing
continues.
This step cannot be bypassed.
Every request is subject to an
ap_location_walk() call. This ensures that
<Location> sections
are consistently enforced for all requests. If the request is an internal
redirect or a sub-request, it may borrow some or all of the processing
from the previous or parent request's ap_location_walk, so this step
is generally very efficient after processing the main request.
Modules can determine the file name, or alter the given URI
in this step. For example, mod_vhost_alias will
translate the URI's path into the configured virtual host,
mod_alias will translate the path to an alias path,
and if the request falls back on the core, the DocumentRoot is prepended to the request resource.
If all modules DECLINE this phase, an error 500 is
returned to the browser, and a "couldn't translate name" error is logged
automatically.
After the file or correct URI was determined, the
appropriate per-dir configurations are merged together. For
example, mod_proxy compares and merges the appropriate
<Proxy> sections.
If the URI is nothing more than a local (non-proxy) TRACE
request, the core handles the request and returns DONE.
If no module answers this hook with OK or DONE,
the core will run the request filename against the <Directory> and <Files> sections. If the request
'filename' isn't an absolute, legal filename, a note is set for
later termination.
Every request is hardened by a second
ap_location_walk() call. This reassures that a
translated request is still subjected to the configured
<Location> sections.
The request again borrows some or all of the processing from its previous
location_walk above, so this step is almost always very
efficient unless the translated URI mapped to a substantially different
path or Virtual Host.
The main request then parses the client's headers. This prepares the remaining request processing steps to better serve the client's request.
Needs Documentation. Code is:
switch (ap_satisfies(r)) {
case SATISFY_ALL:
case SATISFY_NOSPEC:
if ((access_status = ap_run_access_checker(r)) != 0) {
return decl_die(access_status, "check access", r);
}
if (ap_some_auth_required(r)) {
if (((access_status = ap_run_check_user_id(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check user. No user file?"
: "perform authentication. AuthType not set!",
r);
}
if (((access_status = ap_run_auth_checker(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check access. No groups file?"
: "perform authentication. AuthType not set!",
r);
}
}
break;
case SATISFY_ANY:
if (((access_status = ap_run_access_checker(r)) != 0)) {
if (!ap_some_auth_required(r)) {
return decl_die(access_status, "check access", r);
}
if (((access_status = ap_run_check_user_id(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check user. No user file?"
: "perform authentication. AuthType not set!",
r);
}
if (((access_status = ap_run_auth_checker(r)) != 0)
|| !ap_auth_type(r)) {
return decl_die(access_status, ap_auth_type(r)
? "check access. No groups file?"
: "perform authentication. AuthType not set!",
r);
}
}
break;
}The modules have an opportunity to test the URI or filename
against the target resource, and set mime information for the
request. Both mod_mime and
mod_mime_magic use this phase to compare the file
name or contents against the administrator's configuration and set the
content type, language, character set and request handler. Some modules
may set up their filters or other request handling parameters at this
time.
If all modules DECLINE this phase, an error 500 is
returned to the browser, and a "couldn't find types" error is logged
automatically.
Many modules are 'trounced' by some phase above. The fixups phase is used by modules to 'reassert' their ownership or force the request's fields to their appropriate values. It isn't always the cleanest mechanism, but occasionally it's the only option.
This phase is not part of the processing in
ap_process_request_internal(). Many
modules prepare one or more subrequests prior to creating any
content at all. After the core, or a module calls
ap_process_request_internal() it then calls
ap_invoke_handler() to generate the request.
Modules that transform the content in some way can insert their values and override existing filters, such that if the user configured a more advanced filter out-of-order, then the module can move its order as need be. There is no result code, so actions in this hook better be trusted to always succeed.
The module finally has a chance to serve the request in its
handler hook. Note that not every prepared request is sent to
the handler hook. Many modules, such as mod_autoindex,
will create subrequests for a given URI, and then never serve the
subrequest, but simply lists it for the user. Remember not to
put required teardown from the hooks above into this module,
but register pool cleanups against the request pool to free
resources as required.
Apache HTTP Server Version 2.0
When using any of the threaded mpms in Apache 2.0 it is important that every function called from Apache be thread safe. When linking in 3rd party extensions it can be difficult to determine whether the resulting server will be thread safe. Casual testing generally won't tell you this either as thread safety problems can lead to subtle race conditons that may only show up in certain conditions under heavy load.
When writing your module or when trying to determine if a module or 3rd party library is thread safe there are some common things to keep in mind.
First, you need to recognize that in a threaded model each individual thread has its own program counter, stack and registers. Local variables live on the stack, so those are fine. You need to watch out for any static or global variables. This doesn't mean that you are absolutely not allowed to use static or global variables. There are times when you actually want something to affect all threads, but generally you need to avoid using them if you want your code to be thread safe.
In the case where you have a global variable that needs to be global and accessed by all threads, be very careful when you update it. If, for example, it is an incrementing counter, you need to atomically increment it to avoid race conditions with other threads. You do this using a mutex (mutual exclusion). Lock the mutex, read the current value, increment it and write it back and then unlock the mutex. Any other thread that wants to modify the value has to first check the mutex and block until it is cleared.
If you are using APR, have a look
at the apr_atomic_* functions and the
apr_thread_mutex_* functions.
This is a common global variable that holds the error number of the
last error that occurred. If one thread calls a low-level function that
sets errno and then another thread checks it, we are bleeding error
numbers from one thread into another. To solve this, make sure your
module or library defines _REENTRANT or is compiled with
-D_REENTRANT. This will make errno a per-thread variable
and should hopefully be transparent to the code. It does this by doing
something like this:
#define errno (*(__errno_location()))
which means that accessing errno will call
__errno_location() which is provided by the libc. Setting
_REENTRANT also forces redefinition of some other functions
to their *_r equivalents and sometimes changes
the common getc/putc macros into safer function
calls. Check your libc documentation for specifics. Instead of, or in
addition to _REENTRANT the symbols that may affect this are
_POSIX_C_SOURCE, _THREAD_SAFE,
_SVID_SOURCE, and _BSD_SOURCE.
Not only do things have to be thread safe, but they also have to be
reentrant. strtok() is an obvious one. You call it the first
time with your delimiter which it then remembers and on each subsequent
call it returns the next token. Obviously if multiple threads are
calling it you will have a problem. Most systems have a reentrant version
of of the function called strtok_r() where you pass in an
extra argument which contains an allocated char * which the
function will use instead of its own static storage for maintaining
the tokenizing state. If you are using APR you can use apr_strtok().
crypt() is another function that tends to not be reentrant,
so if you run across calls to that function in a library, watch out. On
some systems it is reentrant though, so it is not always a problem. If
your system has crypt_r() chances are you should be using
that, or if possible simply avoid the whole mess by using md5 instead.
The following is a list of common libraries that are used by 3rd party
Apache modules. You can check to see if your module is using a potentially
unsafe library by using tools such as ldd(1) and
nm(1). For PHP, for example,
try this:
% ldd libphp4.so
libsablot.so.0 => /usr/local/lib/libsablot.so.0 (0x401f6000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402da000)
libsnmp.so.0 => /usr/lib/libsnmp.so.0 (0x402f9000)
libpdf.so.1 => /usr/local/lib/libpdf.so.1 (0x40353000)
libz.so.1 => /usr/lib/libz.so.1 (0x403e2000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x403f0000)
libmysqlclient.so.11 => /usr/lib/libmysqlclient.so.11 (0x40411000)
libming.so => /usr/lib/libming.so (0x40449000)
libm.so.6 => /lib/libm.so.6 (0x40487000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404a8000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x404e7000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40505000)
libssl.so.2 => /lib/libssl.so.2 (0x40532000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40560000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40624000)
libdl.so.2 => /lib/libdl.so.2 (0x40634000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40637000)
libc.so.6 => /lib/libc.so.6 (0x4064b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
In addition to these libraries you will need to have a look at any
libraries linked statically into the module. You can use nm(1)
to look for individual symbols in the module.
Please drop a note to dev@httpd.apache.org if you have additions or corrections to this list.
| Library | Version | Thread Safe? | Notes |
|---|---|---|---|
| ASpell/PSpell | ? | ||
| Berkeley DB | 3.x, 4.x | Yes | Be careful about sharing a connection across threads. |
| bzip2 | Yes | Both low-level and high-level APIs are thread-safe. However, high-level API requires thread-safe access to errno. | |
| cdb | ? | ||
| C-Client | Perhaps | c-client uses strtok() and
gethostbyname() which are not thread-safe on most C
library implementations. c-client's static data is meant to be shared
across threads. If strtok() and
gethostbyname() are thread-safe on your OS, c-client
may be thread-safe. | |
| cpdflib | ? | ||
| libcrypt | ? | ||
| Expat | Yes | Need a separate parser instance per thread | |
| FreeTDS | ? | ||
| FreeType | ? | ||
| GD 1.8.x | ? | ||
| GD 2.0.x | ? | ||
| gdbm | No | Errors returned via a static gdbm_error
variable | |
| ImageMagick | 5.2.2 | Yes | ImageMagick docs claim it is thread safe since version 5.2.2 (see Change log). |
| Imlib2 | ? | ||
| libjpeg | v6b | ? | |
| libmysqlclient | Yes | Use mysqlclient_r library variant to ensure thread-safety. For more information, please read http://www.mysql.com/doc/en/Threaded_clients.html. | |
| Ming | 0.2a | ? | |
| Net-SNMP | 5.0.x | ? | |
| OpenLDAP | 2.1.x | Yes | Use ldap_r library variant to ensure
thread-safety. |
| OpenSSL | 0.9.6g | Yes | Requires proper usage of CRYPTO_num_locks,
CRYPTO_set_locking_callback,
CRYPTO_set_id_callback |
| liboci8 (Oracle 8+) | 8.x,9.x | ? | |
| pdflib | 5.0.x | Yes | PDFLib docs claim it is thread safe; changes.txt indicates it has been partially thread-safe since V1.91: http://www.pdflib.com/products/pdflib/index.html. |
| libpng | 1.0.x | ? | |
| libpng | 1.2.x | ? | |
| libpq (PostgreSQL) | 7.x | Yes | Don't share connections across threads and watch out for
crypt() calls |
| Sablotron | 0.95 | ? | |
| zlib | 1.1.4 | Yes | Relies upon thread-safe zalloc and zfree functions Default is to use libc's calloc/free which are thread-safe. |
Apache HTTP Server Version 2.0
이 문서를 한 문장으로 요약할 수 있다. 아파치가 설정파일을 읽을때 DNS를 의존하지않도록 하라. 아파치가 설정파일을 읽는데 DNS가 필요하다면 서버는 신뢰성 문제 (시작이 안될 수도 있다) 혹은 서비스거부 공격과 (사용자가 다른 사용자에 대한 접근을 가로채는 것을 포함하여) 서비스도둑(theft of service) 공격에 시달릴 수 있다.
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
아파치가 정상적으로 동작하기위해서는 각 가상호스트에
대해 두가지 정보가 절대적으로 필요하다. 이 정보는
ServerName과 서버가
기다리고 응답할 최소 한개의 IP 주소이다. 이 예는 IP 주소가
없기때문에, 아파치는 DNS를 사용하여 www.abc.dom의
주소를 찾아야 한다. 서버가 설정파일을 읽을때 어떤 이유에서건
DNS를 사용할 수 없다면 가상호스트를 만들 수 없다.
이 가상호스트는 요청에 응답할 수 없다. (아파치 1.2 이전
버전에서는 심지어 서버가 부팅도 안한다.)
www.abc.dom의 주소가 10.0.0.1이라고 가정하자.
그리고 다음 설정을 보라:
<VirtualHost 10.0.0.1>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
이제 아파치는 이 가상호스트의 ServerName을
찾기위해 역DNS를 사용해야 한다. 역찾기가 실패하면 아파치는
가상호스트를 부분적으로 끈다. (아파치 1.2 이전 버전에서는
심지어 서버가 부팅도 안한다.) 즉, 이 경우 이름기반
가상호스트라면 가상호스트는 완전히 동작하지않고, ip기반이라면
대부분 동작한다. 그러나 아파치가 서버명을 포함하여 서버의
전체 URL을 만들어야 한다면 정상적인 URL을 만들지 못한다.
아래 경우 이 두가지 문제가 없다.
<VirtualHost 10.0.0.1>
ServerName www.abc.dom
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
(최소한) 두가지 종류의 서비스거부가 발생할 수 있다.
아파치 1.2 이전 버전의 경우 어떤 가상호스트에서라도
위에서 말한 두 DNS 검색이 실패하면 서버가 켜지지도 않는다.
DNS가 당신의 권한 밖의 문제일 수도 있다. 예를 들어,
abc.dom이 고객 사이트이고 고객이 자신의 DNS를
관리한다면, www.abc.dom 레코드를 지우기만 해도
(1.2 이전) 서버는 시작하지 못한다.
훨씬 더 교활한 방법도 있다. 다음 설정을 살펴보자:
<VirtualHost www.abc.dom>
ServerAdmin webgirl@abc.dom
DocumentRoot /www/abc
</VirtualHost>
<VirtualHost www.def.dom>
ServerAdmin webguy@def.dom
DocumentRoot /www/def
</VirtualHost>
당신이 www.abc.dom에 10.0.0.1,
www.def.dom에 10.0.0.2를 할당했다고 하자.
또, def.dom은 자체 DNS를 사용한다고 가정하자.
이 설정과 함께 def.dom을 abc.dom으로
가는 모든 통신을 가로챌 수 있는 장소에 두었다. 그렇다면 그들은
www.def.dom을 10.0.0.1로 설정하기만 하면 된다.
그들이 자체 DNS를 사용하기때문에 당신은 그들이 원하는데로
www.def.dom 레코드를 설정하는 것을 막을 수
없다.
(사용자가 http://www.abc.dom/whatever 형식의
URL을 입력하는 경우를 포함하여) 10.0.0.1로 오는 모든 요청을
def.dom 가상호스트가 서비스하게 된다. 왜 이런
일이 일어나는지 이해하려면 아파치가 어떻게 가상호스트로
오는 요청을 처리하는지에 대한 설명이 필요하다.
여기에 대강 설명되있다.
아파치 1.1에서 이름기반
가상호스트 지원이 포함되었기때문에 아파치는 웹서버를
실행하는 호스트의 IP 주소(들)를 알 필요가 생겼다. 이 주소는
(있다면) 전역 ServerName
혹은 C 함수 gethostname으로 (명령프롬프트에
"hostname"을 입력했을때와 같은 결과) 얻는다. 그러면 이 주소로
DNS 검색을 한다. 현재 이 검색은 피할 수 없다.
DNS 서버가 죽어서 이 검색이 실패할 것 같다면
/etc/hosts에 호스트명을 집어넣을 수 있다.
(컴퓨터가 정상적으로 부팅되었다면 아마 이미 들어있을 것이다.)
그리고 DNS가 실패하면 서버가 /etc/hosts를
사용하는지 확인하라. 사용하는 운영체제에 따라
/etc/resolv.conf 혹은 /etc/nsswitch.conf를
수정하면 될 것이다.
서버가 어떤 이유에서건 DNS를 검색하면 안된다면
HOSTRESORDER 환경변수를 "local"로 설정하고
아파치를 실행할 수 있다. mod_env를
사용하여 환경을 변경하지 않는다면 이 환경변수는
CGI에도 영향을 준다. 운영체제의 manpage나 FAQ를 참고하는
것이 좋다.
VirtualHost에 IP
주소를 사용하라
Listen에
IP 주소를 사용하라
ServerName을
가지게 하라
<VirtualHost _default_:*> 서버를
만들어라DNS와 관련된 상황은 매우 바람직하지 못하다. 아파치 1.2에서 우리는 DNS가 실패한 경우에도 최소한 서버가 켜지도록 노력했지만 결과는 나빴다. 어쨌든 설정파일에 직접 IP 주소를 요구하는 것은 번호를 다시 설정해야할 요즘 인터넷에 매우 바람직하지 못하다.
위에서 설명한 서비스도둑 공격을 막는 한가지 방법은 검색한 IP 주소에 다시 역DNS 검색을 하여 두 이름을 비교하는 것이다. 서로 다른 경우 가상호스트를 가동하지 않을 수 있다. 이 방법은 역DNS가 올바로 설정되야 한다. (FTP 서버나 TCP wrapper가 "중복-역" DNS 검색을 자주 사용하기때문에 대부분의 관리자에게 익숙할 것이다.)
어쨌든 IP 주소를 사용하지않으면 DNS가 실패한 경우 가상호스트 웹서버를 믿을 수 있게 시작할 수 없다. 설정의 일부를 무시하는 것과 같은 부분적인 해결책은 웹서버 전체를 시작하지않는 것보다 더 나쁠 수도 있다.
HTTP/1.1이 나왔고 브라우저와 프록시가 Host
헤더를 보내기 시작했으므로 IP기반 가상호스트를 완전히
사용하지않는 것이 가능해질 것이다. 그러면 웹서버는 설정중에서
DNS 검색을 할 필요가 없어진다. 그러나 1997년 3월에는 중요한
웹서버에 포함할 정도로 이름기반 가상호스트가 널리 사용되지
않았다.
Apache HTTP Server Version 2.0
아파치 웹서버는 관리자가 모듈들을 선택하여 서버에 포함할
기능을 결정할 수 있는 모듈화된 프로그램이다. 서버를 컴파할때
httpd 실행파일에 정적으로 모듈을 컴파일할
수 있다. 아니면 모듈을 httpd 실행파일과
분리하여 동적공유객체(Dynamic Shared Objects, DSO)로 컴파일할
수 있다. DSO 모듈은 서버를 컴파일할때 컴파일하거나, Apache
Extension Tool (apxs)을
사용하여 나중에 컴파일하여 추가할 수 있다.
이 문서는 DSO 모듈 사용법과 배경 이론을 설명한다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
아파치 핵심에 정적으로 컴파일해야할
mod_so.c라는 모듈은 아파치 모듈을
읽어들이기위한 DSO를 지원한다.
이 모듈은 core를 제외하고 DSO가
될 수 없는 유일한 모듈이다. 실제로 다른 모든 아파치 모듈은
설치 문서에서 설명한
configure의 --enable-module=shared
옵션을 사용하여 DSO로 컴파일할 수 있다. 모듈을
mod_foo.so와 같이 DSO로 컴파일한후 httpd.conf
파일에 mod_so의
LoadModule 명령어를
사용하여 서버 시작시 혹은 재시작시 그 모듈을 읽어들일 수
있다.
아파치 모듈(특히 제삼자가 만든 모듈)로 사용할 DSO 파일을 쉽게
만들기위해 apxs (APache
eXtenSion)라는 새로운 지원 프로그램이 있다. 이 프로그램은
아파치 소스 트리 밖에서 DSO로 사용할 모듈을
컴파일할때 사용한다. 개념은 쉽다. 아파치를 설치할때
configure와 make install이
아파치 C 헤더파일을 설치하고, DSO 파일을 컴파일하기위한
플래폼 특유의 컴파일러 옵션과 링커 옵션을 apxs
프로그램에 기록한다. 그래서 apxs를 사용하는 사용자는
아파치 배포본 소스 트리없이, 또 DSO 지원을 위한 플래폼 특유의
컴파일러 옵션와 링커 옵션에 신경을 쓰지않고 자신의 아파치
모듈 소스를 컴파일할 수 있다.
Apache 2.0의 DSO 기능에 대한 짧고 간략한 요약이다:
mod_foo.c를 DSO
mod_foo.so로:
$ ./configure --prefix=/path/to/install --enable-foo=shared
$ make install
mod_foo.c를 DSO
mod_foo.so로:
$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
$ make install
$ ./configure --enable-so
$ make install
mod_foo.c를
DSO mod_foo.so로:
$ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.la
모든 경우 일단 공유 모듈이 컴파일되면, httpd.conf에
LoadModule 지시어를
사용하여 아파치가 그 모듈을 읽어들이게 만든다.
현대적인 유닉스류에는 동적공유객체 (DSO)의 동적 링킹/로딩(dynamic linking/loading)이라고 하여, 특별한 형식의 실행코드 조각을 만들어 실행중인 실행프로그램의 주소공간에 읽어들이는 멋진 기능이 있다.
보통 두가지 방법으로 읽어들일 수 있다. 하나는 실행프로그램이
시작할때 ld.so라는 시스템 프로그램이 자동으로
읽어들이는 경우고, 다른 하나는 실행중인 프로그램이
dlopen()/dlsym() 시스템호출로 유닉스 로더(loader)의
시스템 인터페이스을 사용하여 직접 읽어들이는 경우다.
첫번째 경우 DSO를 보통 공유라이브러리(shared libraries)
혹은 DSO 라이브러리라고 부르며, 파일은
libfoo.so나 libfoo.so.1.2 같은
이름을 가진다. 이들은 시스템 디렉토리(보통 /usr/lib)에
있고, 컴파일시 링커 명령어에 -lfoo를 주어
실행파일과 연결한다. 이렇게 직접 써준 라이브러리는 실행파일에
참조되여서, 프로그램이 시작할때 링커 옵션 -R로
직접 지정한 경로, 환경변수 LD_LIBRARY_PATH로
지정한 경로 혹은 /usr/lib에서 유닉스 로더가
libfoo.so를 찾을 수 있다. 그러면 실행프로그램의
(아직 못찾은(unresolved)) 심볼(symbol)을 DSO에서 찾게된다.
DSO는 보통 실행프로그램의 심볼을 찾지않기 때문에 (DSO가
재사용가능한 일반적인 코드 라이브러리이므로) 찾기는 여기서
끝난다. 유닉스 로더가 심볼 찾기를 완전히 담당하므로 실행프로그램이
직접 DSO에서 심볼을 찾을 필요가 없다. (사실 ld.so를
부르는 코드는 정적이 아닌 모든 실행프로그램에 링크되는 실행시
시작코드의 일부다.) 공통된 라이브러리 코드를 동적으로 읽어들이는
장점은 명확하다. 라이브러리 코드가 모든 프로그램에 중복해서
저장되는 대신 libc.so와 같은 시스템 라이브러리에
한번만 저장되기 때문에 디스크 공간이 절약된다.
두번째 경우 DSO를 보통 공유객체(shared objects)
혹은 DSO 파일이라고 부르고, (규칙상 이름은
foo.so이지만) 파일의 확장자는 자유롭다. 이
파일들은 보통 프로그램 자체 디렉토리에 위치하고 실행프로그램에
자동으로 연결되지 않는다. 대신 실행프로그램은 실행시
dlopen()을 사용하여 DSO를 주소공간에
직접 읽어들여야 한다. 이때 실행프로그램은 DSO에서 심볼을
찾지 않는다. 대신 앞에서 본 유닉스 로더는 자동으로 실행파일과
실행파일이 이미 읽어들인 DSO 라이브러리(특히 항상 존재하는
libc.so의 모든 심볼)에서 DSO의 (아직 못찾은)
심볼을 찾는다. 그래서 DSO는 마치 처음부터 실행프로그램에
정적으로 링크된것과 같이 실행파일의 심볼을 알게된다.
DSO의 API를 이용하기위해서 마지막으로 실행프로그램은
dlsym()으로 DSO에서 특정 심볼을 찾아서, 앞으로
사용하기위해 디스패치(dispatch) 표 등에 저장한다.
다른 말로 실행프로그램은 사용할 모든 실볼을 직접 찾아야한다.
이런 구조의 장점은 프로그램의 일부를 프로그램이
필요할때까지 읽어들이지 않아도 (그래서 메모리를 낭비하지
않게) 된다는 점이다. 기본 프로그램의 기능을 확장하기위해
필요한 경우 이 부분을 동적으로 읽어들일 수 있다.
이런 DSO 구조가 자연스럽게 보이지만, 최소한 어려운 점이 한가지있다. 프로그램을 확장하기위해 DSO를 사용할때 DSO가 실행프로그램의 심볼을 찾는 일이다. 왜? DSO가 실행프로그램의 심볼을 "역으로 찾는 것"은 (라이브러리는 자신을 사용하는 프로그램에 대해 모른다는) 라이브러리 설계에 반하며, 모든 플래폼에서 지원되지않고 표준화되지도 않았기 때문이다. 실제로 실행파일의 전역심볼(global symbol)은 보통 익스포트(export)되지 않기때문에 DSO가 사용할 수 없다. DSO를 사용하여 실행중 프로그램을 확장하려면 링커에게 모든 전역심볼을 익스포트하도록 강제하는 것이 주된 해결책이다.
공유라이브러리는 DSO 방식의 설계원칙대로 전형적이기때문에 운영체제가 제공하는 거의 모든 종류의 라이브러리가 사용한다. 반대로 많은 프로그램은 프로그램을 확장하기위해 공유객체를 사용하지 않는다.
1998년 실행중 실제로 기능을 확장하기위해 DSO 구조를 사용한 소프트웨어 패키지는 (XS 구조와 DynaLoader 모듈을 사용한) Perl 5, Netscape Server 등으로 드물었다. 아파치는 이미 기능을 확장하기위해 모듈 개념을 사용했고 외부 모듈을 아파치 핵심기능에 연결하기위해 내부적으로 디스패치목록을 이용한 접근방법을 사용했기때문에 1.3 버전부터 이 대열에 합류했다. 그래서 아파치는 실행중 모듈을 읽어들이는데 DSO를 사용하도록 운명지워졌다.
앞에서 말한 DSO를 사용하면 다음과 같은 장점이 있다:
configure
옵션대신 httpd.conf의 LoadModule을 사용하여 실행중에
결합되므로 서버 패키지 실행이 더 유연하다. 예를 들어 한번의
아파치 설치만으로 다른 서버(표준 버전과 SSL 버전, 최소화
버전과 기능추가 버전 [mod_perl, PHP3] 등)를 실행할
수 있다.apxs를 가지고 아파치 소스 트리 밖에서
작업하고 apxs -i와 apachectl restart
명령어만으로 현재 개발한 모듈의 새 버전을 실행중인 아파치
서버에 반영할 수 있어서 더 쉽게 아파치 모듈을 개발할 수
있다.DSO는 다음과 같은 단점이 있다:
ld -lfoo)에
링크할 수 없는 플래폼이 있기때문에 (예를 들어 ELF기반
플래폼은 지원하지만 a.out기반 플래폼은 보통 이 기능을
지원하지 않는다) 모든 종류의 모듈에 DSO를 사용할 수 없다.
다른 말로 DSO 파일로 컴파일하는 모듈은 아파치 핵심과 아파치
핵심이 사용하는 C 라이브러리(libc)와 다른
동적/정적 라이브러리, 위치독립코드를 담고 있는 정적 라이브러리
아카이브(libfoo.a)의 심볼만을 사용할 수 있다.
다른 코드를 사용하려면 아파치 핵심이 그것을 참조하던지,
dlopen()으로 직접 코드를 읽어들여야 한다.Apache HTTP Server Version 2.0
아파치 웹서버는 환경변수(environment variable)라는 변수에 정보를 저장할 수 있다. 이 정보를 사용하여 로그나 접근제어 등 여러 작업을 조절한다. 또, 환경변수는 CGI 스크립트와 같은 외부 프로그램과 통신하는 수단이 된다. 이 문서는 환경변수를 다루고 사용하는 다양한 방법들을 설명한다.
이 변수들을 환경변수라고 부르지만, 운영체제에서 말하는 환경변수와 다르다. 이 변수는 아파치 내부에 저장되고 사용된다. 환경변수는 CGI 스크립트나 Server Side Include 스크립트로 넘겨질때만 실제 운영체제 환경변수가 된다. 서버를 실행하는 운영체제 환경을 수정하고 싶다면 운영체제 쉘에서 환경을 수정해야 한다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
아파치에서 환경변수를 설정하는 가장 기본적인 방법은
무조건적인 SetEnv 지시어를 사용하는 것이다. PassEnv 지시어를 사용하여
서버를 시작한 쉘에서 환경변수를 가져올 수도 있다.
더 유연하게, mod_setenvif가 제공하는 지시어는 요청마다
요청의 특징에 따라 환경변수를 설정한다. 예를 들어, 특정
브라우저로 (User-Agent) 요청하거나 특정 Referer (맞춤법이
틀리지 않았다) 헤더가 있는 경우에만 변수를 설정할 수
있다. 심지어 mod_rewrite에 있는 RewriteRule의
[E=...] 옵션을 사용하여 더 유연하게 환경변수를
설정할 수도 있다.
마지막으로 mod_unique_id는 각 요청에 대해 어떤 경우에도
"모든" 요청중에 확실히 유일한(겹치지않은) 값으로
UNIQUE_ID 환경변수를 설정한다.
CGI 스크립트와 SSI 문서는 아파치 설정에서 설정하였거나 쉘에서 가져온 환경변수 외에 추가로 CGI 규약이 규정한 요청에 대한 정보를 알려주는 환경변수들을 받는다.
suexec.c에 정의된다.| 관련된 모듈 | 관련된 지시어 |
|---|---|
환경변수의 주된 용도중 하나는 CGI 스크립트와 정보를 교환하는 것이다. 앞에서 설명했듯이 아파치 설정에서 설정한 변수외에 요청에 대한 표준 정보를 가진 변수가 CGI 스크립트로 넘어간다. 더 자세한 내용은 CGI 투토리얼을 참고하라.
mod_include의 INCLUDES 필터가 처리하는
서버파싱 (SSI) 문서는 echo 요소를 사용하여
환경변수를 출력할 수 있고, 환경변수를 사용하여 요청의
특징에 따라 흐름제어 요소로 페이지의 일부를 변경할 수
있다. 아파치는 또 SSI 문서에게 위에서 설명한 표준 CGI
환경변수를 제공한다. 더 자세한 내용은 SSI 투토리얼을 참고하라.
allow from env=과 deny from env=
지시어를 사용하여 환경변수 값에 따라 서버로의 접근을
조절할 수 있다. SetEnvIf와 같이 사용하면
클라이언트의 특징에 따라 자유롭게 서버로의 접근을 제어할
수 있다. 예를 들어, 특정 브라우저의 (User-Agent) 접근을
거부할 수 있다.
LogFormat의
%e 옵션을 사용하여 환경변수를 접근 로그에
기록할 수 있다. 또, CustomLog 지시어의
조건부 형식을 사용하면 환경변수의 상황에 따라 요청을
로그할지 여부를 결정할 수 있다. SetEnvIf와 같이 사용하여
어떤 요청을 로그할지 자유롭게 결정할 수 있다. 예를 들어,
파일명이 gif로 끝나는 요청은 로그하지 않거나,
외부 네트웍에 있는 클라이언트의 요청만을 로그할 수 있다.
Header
지시어는 클라이언트에게 응답을 보낼때 환경변수의 유무에
따라 어떤 HTTP 헤더를 포함할지 결정할 수 있다. 예를
들어, 클라이언트의 요청에 특정 헤더가 있는 경우에만
어떤 응답 헤더를 보낼 수 있다.
mod_ext_filter의 ExtFilterDefine
지시어로 설정한 외부 필터를 disableenv=와
enableenv= 옵션을 사용하여 환경변수에 따라
선택적으로 실행할 수 있다.
RewriteCond의
TestString에 %{ENV:...} 형식을
사용하면 mod_rewrite의 재작성 엔진이 환경변수에 따라
다르게 행동한다. mod_rewrite에서 앞에 ENV:를
붙이지않고 접근하는 변수는 실제 환경변수가 아님을 주의하라.
그들은 다른 모듈에서 읽을 수 없는 mod_rewrite에 한정된
변수다.
클라이언트와 원활한 동작하기위해 아파치는 특별한
클라이언트에 대해 자신의 행동을 수정한다. 보통 BrowserMatch에서
환경변수를 정의하여 이런 문제를 해결한다. 그러나 SetEnv와 PassEnv로도 가능하다.
요청이 이후 버전을 사용하더라도 HTTP/1.0 요청으로 처리한다.
응답을 클라이언트에게 보내기 전에 응답 헤더에서
Vary 필드를 뺀다. 어떤 클라이언트는 이
필드를 제대로 해석하지 못한다 (클라이언트의
이미 알려진 문제점 페이지 참고). 이 변수는 이런
문제를 해결한다. 또한, 이 변수는
force-response-1.0을 가정한다.
HTTP/1.0 요청을 하는 클라이언트에게 HTTP/1.0 응답을 강제한다. 원래 AOL 프록시에 문제가 있어서 만들어졌다. 어떤 HTTP/1.0 클라이언트는 HTTP/1.1 응답을 받으면 제대로 동작하지 않으므로, 이 문제를 해결하기위해 사용한다.
값이 "1"이면 text/html이 아닌 content-type에
대해 mod_deflate의 DEFLATE 출력필터를
사용하지 않는다.
이 옵션을 설정하면 mod_deflate의
DEFLATE 필터를 사용하지 않는다.
KeepAlive를
무시한다.
이 변수는 mod_negotiation의 행동에
영향을 미친다. 변수가 (en, ja,
x-klingon 등) 언어태그를 담고있다면,
mod_negotiation는 그 언어로 된 변형을
보내길 시도한다. 그런 변형이 없다면 일반적인 협상 과정을 시작한다.
서버가 더 조심히 클라이언트에게 리다이렉션을 보낸다. 보통 리다이렉션을 처리하는데 문제가 있는 클라이언트을 위해 사용한다. 원래 Microsoft의 WebFolders 소프트웨어가 DAV 메써드를 통해 디렉토리 자원의 리다이렉션을 처리하는데 문제가 있어서 만들어졌다.
2.0.40 이후 버전에 있다
아파치가 클라이언트의 요청에 대한 응답으로 리다이렉션을 보낼때 클라이언트가 자동으로 리다이렉션을 따라가지 못하는(혹은 않는) 경우에 대비하여 응답에 사용자에게 보여줄 문구를 포함한다. 아파치는 보통 이 글을 아파치가 사용하는 문자집합인 ISO-8859-1로 표시한다.
그러나 리다이렉션된 페이지가 다른 문자집합을 사용할 경우 어떤 이상한 브라우저 버전은 실제 페이지가 아니라 리다이렉션 페이지의 문자집합을 사용하려고 한다. 예를 들어, 그리스어가 이상하게 보일 수 있다.
이 환경변수는 아파치가 리다이렉션 페이지에 문자집합을 설정하지않도록 하여, 이런 브라우저가 실제 페이지의 문자집합을 올바로 사용하게 만든다.
클라이언트들의 이미 알려진 문제를 해결하기위해 httpd.conf에 다음 내용을 포함하길 바란다.
# # 다음 지시어들은 일반적인 HTTP 응답을 변경한다. # 첫번째 지시어는 Netscape 2.x와 이를 가장한 브라우저에게 # keepalive를 사용하지 않는다. 이들 브라우저 구현에 문제가 있다. # 두번째 지시어는 HTTP/1.1 구현이 잘못되었고 301이나 302 # (리다이렉션) 응답에 사용한 keepalive를 제대로 지원하지 # 못하는 Microsoft Internet Explorer 4.0b2를 위한 것이다. # BrowserMatch "Mozilla/2" nokeepalive BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 force-response-1.0 # # 다음 지시어는 기본적인 HTTP/1.1 응답을 이해하지 못하여 # HTTP/1.0 규약을 어기는 브라우저에게 HTTP/1.1 응답을 보내지 않는다. # BrowserMatch "RealPlayer 4\.0" force-response-1.0 BrowserMatch "Java/1\.0" force-response-1.0 BrowserMatch "JDK/1\.0" force-response-1.0
이 예제는 이미지에 대한 요청을 접근 로그에 기록하지 않는다. 특정 디렉토리에 대한 혹은 특정 호스트에서 온 요청을 로그하지 않도록 쉽게 수정할 수 있다.
SetEnvIf Request_URI \.gif image-request SetEnvIf Request_URI \.jpg image-request SetEnvIf Request_URI \.png image-request CustomLog logs/access_log common env=!image-request
이 예는 현재 서버외의 사용자가 페이지에 서버에 있는 이미지를 포함하지 못하도록 하는 방법을 설명한다. 이 설정을 권장하지는 않으며, 제한된 경우에만 동작한다. 우리는 모든 이미지가 /web/images 디렉토리 안에 있다고 가정한다.
SetEnvIf Referer "^http://www.example.com/" local_referal # Referer 정보를 보내지 않는 브라우저를 허용한다 SetEnvIf Referer "^$" local_referal <Directory /web/images> Order Deny,Allow Deny from all Allow from env=local_referal </Directory>
이 기법에 대한 자세한 설명은 ApacheToday 투토리얼 " Keeping Your Images from Adorning Other Sites"를 참고하라.
Apache HTTP Server Version 2.0
FAQ 최신판은 아파치 웹사이트 <http://httpd.apache.org/docs/2.0/faq/>에서 볼 수 있다.
아파치 2.0이 나온지 얼마 안되서 우리는 아직 자주 물어보는 질문 (FAQ)이 무엇인지 모른다. 내용이 채워질 때까지 여기에 해답이 없다면 아파치 1.3 FAQ도 참고하라.
아파치 서버 소프트웨어에 문제가 생기면 다음과 같은 단계를 따른다:
/usr/local/apache2/logs/error_log이지만,
정확한 위치는 설정파일의 ErrorLog 지시어를 참고하라.아파치에 대한 지식을 공유하길 원하는 활발한 사용자 공동체들이 있다. 일반적으로 이런 공동체에 참여하는 것이 문제의 답을 얻는 가장 좋고 빠른 방법이다.
USENET 뉴스그룹:
위의 단계를 모두 시도하고도 해결책이 없다면, 버그를 보고하여 웹서버 개발자들에게 문제를 알리길 바란다.
core dump를 만들며 서버가 죽는 경우라면 (가능하면) backtrace(역주; 문제가 실행파일의 정확히 어떤 지점에서 발생하였고, 프로그램이 그 지점까지 어떤 경로로 실행되었는지를 알려주는 정보)를 포함하길 바란다. 예를 들어,
# cd ServerRoot
# dbx httpd core
(dbx) where
(ServerRoot, httpd, core
파일의 실제 위치를 대신 사용하라. dbx 대신
gdb를 사용해야 할 수도 있다.)
40명 가량의 자발적으로 참여한 개발자만으로는 수백만의 사용자에게 아파치에 대해 일일이 지원할 수 없다. 무료 지원을 얻으려면 사용자 공간에 참여하길 권한다.
아파치에 대한 직업적인 유료 지원은 여러 회사에서 제공한다.
플래폼이 sendfile 시스템호출을 지원한다면,
아파치는 응답의 속도를 빠르게하기위해 이 시스템호출을 사용한다.
불행히도 어떤 시스템에서 아파치는 컴파일할때
sendfile이 정상적으로 작동하지 않는데도 정상적으로
작동한다고 오판한다. 이 문제는 네트웍 파일시스템이나 비표준
파일시스템을 사용할때 자주 발생한다.
이 문제의 증상은 오류 로그(error log)에 위의 문구를
기록하거나 크기가 0이 아닌 파일에 대해 크기가 0인 응답을
하는 경우이다. 동적으로 내용을 생성할때는
sendfile을 사용하지 않기때문에 일반적으로 정적인
파일을 요청할때만 문제가 발생한다.
문제를 해결하려면 서버가 sendfile을 사용하지
않도록 EnableSendfile
지시어를 사용한다. 또, 이와 유사한 문제에 대해 EnableMMAP을 참고하라.
win32에서 AcceptEx 시스템호출에 대한 오류문을
나오면, Win32DisableAcceptEx
지시어를 참고하라.
보통 CGI 스크립트에 문제가 있으면 브라우저에게 Internal
Server Error를 보내고 오류로그에 이 문구를 기록한다.
이런 문제를 디버깅할때 CGI 투토리얼이
도움이 될 수 있다.
Apache HTTP Server Version 2.0
플래폼이 sendfile 시스템호출을 지원한다면,
아파치는 응답의 속도를 빠르게하기위해 이 시스템호출을 사용한다.
불행히도 어떤 시스템에서 아파치는 컴파일할때
sendfile이 정상적으로 작동하지 않는데도 정상적으로
작동한다고 오판한다. 이 문제는 네트웍 파일시스템이나 비표준
파일시스템을 사용할때 자주 발생한다.
이 문제의 증상은 오류 로그(error log)에 위의 문구를
기록하거나 크기가 0이 아닌 파일에 대해 크기가 0인 응답을
하는 경우이다. 동적으로 내용을 생성할때는
sendfile을 사용하지 않기때문에 일반적으로 정적인
파일을 요청할때만 문제가 발생한다.
문제를 해결하려면 서버가 sendfile을 사용하지
않도록 EnableSendfile
지시어를 사용한다. 또, 이와 유사한 문제에 대해 EnableMMAP을 참고하라.
win32에서 AcceptEx 시스템호출에 대한 오류문을
나오면, Win32DisableAcceptEx
지시어를 참고하라.
보통 CGI 스크립트에 문제가 있으면 브라우저에게 Internal
Server Error를 보내고 오류로그에 이 문구를 기록한다.
이런 문제를 디버깅할때 CGI 투토리얼이
도움이 될 수 있다.
Apache HTTP Server Version 2.0
FAQ 최신판은 아파치 웹사이트 <http://httpd.apache.org/docs/2.0/faq/>에서 볼 수 있다. 또, 검색하고 출력하기 편하게 FAQ를 한 페이지로 볼 수 있다.
아파치 2.0이 나온지 얼마 안되서 우리는 아직 자주 물어보는 질문 (FAQ)이 무엇인지 모른다. 내용이 채워질 때까지 여기에 해답이 없다면 아파치 1.3 FAQ도 참고하라.
Apache HTTP Server Version 2.0
아파치 서버 소프트웨어에 문제가 생기면 다음과 같은 단계를 따른다:
/usr/local/apache2/logs/error_log이지만,
정확한 위치는 설정파일의 ErrorLog 지시어를 참고하라.아파치에 대한 지식을 공유하길 원하는 활발한 사용자 공동체들이 있다. 일반적으로 이런 공동체에 참여하는 것이 문제의 답을 얻는 가장 좋고 빠른 방법이다.
USENET 뉴스그룹:
위의 단계를 모두 시도하고도 해결책이 없다면, 버그를 보고하여 웹서버 개발자들에게 문제를 알리길 바란다.
core dump를 만들며 서버가 죽는 경우라면 (가능하면) backtrace(역주; 문제가 실행파일의 정확히 어떤 지점에서 발생하였고, 프로그램이 그 지점까지 어떤 경로로 실행되었는지를 알려주는 정보)를 포함하길 바란다. 예를 들어,
# cd ServerRoot
# dbx httpd core
(dbx) where
(ServerRoot, httpd, core
파일의 실제 위치를 대신 사용하라. dbx 대신
gdb를 사용해야 할 수도 있다.)
40명 가량의 자발적으로 참여한 개발자만으로는 수백만의 사용자에게 아파치에 대해 일일이 지원할 수 없다. 무료 지원을 얻으려면 사용자 공간에 참여하길 권한다.
아파치에 대한 직업적인 유료 지원은 여러 회사에서 제공한다.
Apache HTTP Server Version 2.0
이 문서는 아파치에서 필터를 사용하는 방법을 설명한다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
필터(filter)는 서버가 보내거나 받는 자료에 적용되는 작업이다. 클라이언트가 서버에게 보내는 자료는 입력필터(input filter)가 처리하고, 서버가 클라이언트에게 보내는 자료는 출력필터(output filter)가 처리한다. 자료에 여러 필터를 사용할 수 있고, 직접 필터의 순서를 지정할 수 있다.
아파치는 이어받기(byte-range) 요청 등을 처리하기위해
내부적으로 필터를 사용한다. 또, 설정 지시어를
사용하여 선택가능한 필터를 제공하는 모듈도 있다.
SetInputFilter,
SetOutputFilter,
AddInputFilter,
AddOutputFilter,
RemoveInputFilter,
RemoveOutputFilter
지시어로 자료를 처리하는 필터를 조절한다.
현재 아파치 웹서버 배포본은 사용자가 선택할 수 있는 다음과 같은 필터를 제공한다.
mod_include가 처리하는 Server-Side Includesmod_deflate를 사용하여 출력을
클라이언트로 보내기 전에 압축
또, mod_ext_filter 모듈을 사용하여
외부 프로그램을 필터로 사용할 수도 있다.
Apache HTTP Server Version 2.0
이 문서는 웹 서비스 일반에 대한, 특히 아파치와 관련된, 용어들을 정의한다. 각 개념에 대한 자세한 정보는 링크를 참고하라. (역주; 현재 단어의 순서는 한글 순서가 아니라, 영문자 순서입니다. 용어번역표는 여기를 참고하길 바랍니다.)
INCLUDES 출력필터는 문서의 Server
Side Includes를 처리한다.www가 호스트명이고
example.com이 도메인명일때,
www.example.com은 완전한 도메인명이다.cgi-script
핸들러는 CGI로 처리할 파일을 지정한다./usr/local/apache2/conf/httpd.conf이지만, 실행할때
혹은 컴파일때 설정으로 변경할 수 있다.GET,
POST, PUT 등이 있다.text/html, image/gif,
application/octet-stream 등이다. MIME-type은 HTTP의
Content-Type 헤더 (header)로
전송한다./images/.*(jpg|gif)$"로 지칭할 수
있다. 아파치는 PCRE 라이브러리를
사용하여 Perl호환 정규표현식을 지원한다.tar 도구를 사용하여 파일들을 모은 묶음. 아파치는
tar 파일을 압축하거나 pkzip으로 압축하여 배포된다.http나 https같은 스킴(scheme), 호스트명,
경로로 구성된다. 이 페이지의 URL은
http://httpd.apache.org/docs/2.0/glossary.html이다.Apache HTTP Server Version 2.0
이 문서는 아파치에서 핸들러를 사용하는 방법을 설명한다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
파일을 요청할때 아파치가 내부적으로 수행할 작업을 "핸들러(handler)"라고 한다. 일반적으로 파일은 파일 종류에 따라 암묵적인 핸들러를 가지고 있다. 모든 파일은 보통 간단히 서버가 서비스하지만, 어떤 파일 종류는 따로 "처리된다(handled)".
Apache 1.1부터 핸들러를 명시적으로 사용할 수 있게 되었다. 파일 종류와 관계없이 핸들러를 파일의 확장자나 위치에 따라 지정할 수 있다. 이는 더 훌륭한 방법이고 파일을 종류와 핸들러 둘 모두와 연계할 수 있기때문에 좋다. (여러 확장자를 가진 파일도 참고)
핸들러는 서버나 모듈로 구현하여, Action 지시어로 추가할
수 있다. 표준 배포본에 있는 기본 핸들러는 다음과 같다:
default_handler()를 사용하여 파일을 보낸다.
(core)mod_asis)mod_cgi)mod_imap)mod_info)mod_status)mod_negotiation)다음 지시어는 확장자가 html인 파일을
요청할 경우 footer.pl CGI 스크립트를 띄운다.
Action add-footer /cgi-bin/footer.pl
AddHandler add-footer .html
CGI 스크립트는
(PATH_TRANSLATED 환경변수가 지칭하는) 원래
요청한 문서를 적절히 수정한 후 보낸다.
다음 지시어는 HTTP 헤더를 포함하는 파일에
send-as-is 핸들러를 지시한다.
/web/htdocs/asis/ 디렉토리 안에 있는 모든
파일은 확장자와 관계없이 send-as-is 핸들러가
처리한다.
<Directory /web/htdocs/asis>
SetHandler send-as-is
</Directory>
핸들러 기능을 구현하기위해 사용함직한
Apache API가 추가되었다.
특히 request_rec 구조체에 새로운 필드가
추가되었다:
char *handler
모듈이 핸들러를 사용하려면, 요청의
invoke_handler 단계 이전에
r->handler에 핸들러 이름을 지정해주기만
하면 된다. 핸들러는 content type 대신 핸들러 이름을 사용한
것을 제외하고는 전과 같이 구현되었다. 꼭 지킬 필요는 없지만
핸들러 이름에 슬래쉬를 사용하지 않고, 단어들 사이에 빼기
기호를 사용하는 것이 일반적이다. 그래서 핸들러 이름이
media type과 겹치지 않는다.
Apache HTTP Server Version 2.0
인증(authentication)은 자신이 누구라고 주장하는 사람을 확인하는 절차이다. 권한부여(authorization)는 가고 싶은 곳으로 가도록 혹은 원하는 정보를 얻도록 허용하는 과정이다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
당신의 웹사이트에 있는 정보가 소수의 사람들만의 비밀이거나 이들만을 위한 정보라면, 이 글에서 설명하는 기법을 사용하여 당신이 보길 원하는 사람만 페이지를 보도록 할 수 있다.
이 글은 웹사이트의 일부를 보호하기위해 많은 사람들이 사용하는 "표준적인" 방법을 다룬다.
이 글에서 다루는 지시어는 서버의 주설정파일(일반적으로
<Directory>
섹션)이나 디렉토리별 설정파일(.htaccess 파일)에서
사용한다.
.htaccess 파일을 사용하려면 이 파일에 있는
인증 지시어를 허용하도록 서버를 설정해야 한다. 이를 위해
디렉토리별 설정파일에 어떤 지시어를 사용할 수 있는지를 결정하는
AllowOverride 지시어를
사용한다.
여기서는 인증을 다루기 때문에, 다음과 같은
AllowOverride 지시어가 필요하다.
AllowOverride AuthConfig
혹은 지시어를 직접 서버 주설정파일에 적는다면, 그 파일에 쓰기 권한이 물론 있어야 한다.
그리고 보호할 파일이 어디있는지 알기위해 서버의 디렉토리 구조에 대해 조금 알아야한다. 이 일은 어렵지않고, 적당한 때에 자세히 설명할 것이다.
이제 서버의 디렉토리를 암호로 보호하는 기본적인 방법을 설명한다.
먼저 암호파일을 만들어야 한다. 이 파일은 웹에서 접근할
수 없는 곳에 있어야 한다. 다른사람이 암호파일을 다운로드하지
못하게하기 위해서다. 예를 들어, 문서들이
/usr/local/apache/htdocs에 있다면 암호파일(들)은
/usr/local/apache/passwd에 둔다.
아파치에 포함된 htpasswd 도구를 사용하여
암호파일을 만든다. 이 프로그램은 아파치를 설치한 곳의
bin 디렉토리에 있다. 파일을 만들려면 다음과
같이 입력한다.
htpasswd -c /usr/local/apache/passwd/passwords rbowen
htpasswd는 암호를 물어보고, 확인을 위해
암호를 다시 입력하라고 요청한다.
# htpasswd -c /usr/local/apache/passwd/passwords rbowen
New password: mypassword
Re-type new password: mypassword
Adding password for user rbowen
물론 htpasswd이 실행파일 경로에 없다면
실행파일의 전체 경로를 입력해야 한다. 내가 사용하는 서버에서는
/usr/local/apache/bin/htpasswd에 실행파일이
있다.
다음으로 서버가 암호를 요청하도록 설정하고, 서버에게
어떤 사용자의 접근을 허용할지 알려줘야 한다.
httpd.conf를 편집하거나 .htaccess
파일을 사용하여 설정한다. 예를 들어,
/usr/local/apache/htdocs/secret 디렉토리를
보호하려면, 아래 지시어를
/usr/local/apache/htdocs/secret/.htaccess 파일이나
httpd.conf의 <Directory
/usr/local/apache/apache/htdocs/secret> 섹션에 적어야
한다.
AuthType Basic
AuthName "Restricted Files"
AuthUserFile /usr/local/apache/passwd/passwords
Require user rbowen
지시어를 하나씩 살펴보자. AuthType 지시어는 사용자를 인증할
방법을 선택한다. 가장 일반적인 방법은 Basic으로,
mod_auth가 구현한다. 그러나 Basic
인증은 브라우저가 서버로 암호를 암호화하지 않고 보낸다.
그러므로 기밀 자료를 보호하기위해 이 방법을 사용하면 안된다.
아파치는 AuthType Digest라는 인증 방법도 지원한다.
이 방법은 mod_auth_digest가 구현하며, 매우
안전하다. 가장 최근 클라이언트들만이 Digest 인증을 지원한다고
한다.
AuthName 지시어는
인증에 사용할 영역(realm)을 지정한다. 영역은
두가지 역할을 한다. 첫번째는 클라이언트가 보통 이 정보를
암호 대화창에 보여준다. 두번째는 영역 정보를 사용하여
클라이언트가 특정 인증구역에 어떤 암호를 보낼지 결정한다.
예를 들어, 일단 클라이언트가 "Restricted Files"
영역에 인증이 성공하였다면, 클라이언트는 자동으로 같은 서버에서
"Restricted Files" 영역으로 표시된 구역에 대해
동일한 암호를 시도한다. 그래서 여러 제한 구역이 같은 영역을
공유하면 사용자가 여러번 암호를 입력하지 않아도 된다. 물론
보안상 이유로 클라이언트는 서버의 호스트명이 다르면 항상
새로 암호를 물어본다.
AuthUserFile
지시어는 우리가 방금 htpasswd로 만든 암호파일의
경로를 설정한다. 사용자가 많다면 요청마다 매번 사용자를
인증하기위해 일반 문서파일을 검색하는데 시간이 상당히 많이
걸릴 수 있다. 아파치는 빠른 데이타베이스 파일에 사용자 정보를
저장할 수 있다. mod_auth_dbm 모듈은 AuthDBMUserFile 지시어를
제공한다. dbmmanage
프로그램을 사용하여 암호파일을 만들고 다룬다. 아파치 모듈
데이타베이스에는 여러 다른 인증 방식을 제공하는 제삼자가
만든 모듈들이 있다.
마지막으로 Require
지시어는 서버의 특정 영역에 접근할 수 있는 사용자를 지정하여
권한부여를 한다. 다음 절은 require 지시어를
사용하는 다양한 방법을 설명한다.
위의 지시어는 디렉토리로 (사용자명이 rbowen인)
한 사람만을 들여보낸다. 대부분의 경우 여러 사람을 들여보내고
싶을 것이다. 이제 AuthGroupFile을
사용할 때다.
여러 사람을 들여보내고 싶다면 그룹명과 그 그룹에 어떤 사용자들이 있는지 알려주는 그룹파일이 필요하다. 이 파일의 형식은 매우 간단하여, 아무 편집기로나 만들 수 있다. 파일내용은 다음과 같다.
GroupName: rbowen dpitts sungo rshersey
그냥 공백으로 구분한 긴 그룹 구성원 목록일 뿐이다.
기존의 암호파일에 사용자를 추가하려면 다음과 같이 입력한다
htpasswd /usr/local/apache/passwd/passwords dpitts
전과 같지만, 새로 파일을 만들지 않고 기존 파일에 사용자를
추가한다. (-c 옵션은 새로 암호파일을 만든다).
이제 .htaccess 파일을 다음과 같이 수정한다.
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /usr/local/apache/passwd/passwords
AuthGroupFile /usr/local/apache/passwd/groups
Require group GroupName
그러면 GroupName 그룹에 속하며
password 파일에 항목이 있는 사용자가 올바른
암호를 입력하면 접근을 허용한다.
여러 일반 사용자를 들여보내는 다른 방법이 있다. 그룹파일을 만들 필요없이 다음 지시어를 사용하기만 하면 된다.
Require valid-user
Require user rbowen 대신 이 지시어를 사용하면
암호파일에 있는 누구라도 올바른 암호를 입력하기만 하면 접근을
허용한다. 그룹별로 다른 암호파일을 사용하여 그룹과 비슷한
효과를 얻을 수도 있다. 이 경우 아파치가 파일 두개(암호파일과
그룹파일)가 아닌 파일 한개(암호파일)만 검사하면 된다는 것이
장점이다. 그러나 여러 암호파일을 관리해야 하고, AuthUserFile 지시어에
정확한 암호파일을 지정해야 하는 것은 단점이다.
Basic 인증 방식은 서버에서 문서를 요청할 때마다 사용자명과 암호를 확인한다. 심지어 같은 페이지를 새로 고침할 때도 페이지와 (그림이 암호로 보호하는 디렉토리에 있는 경우) 페이지에 있는 모든 그림에 대해 다시 확인한다. 짐작하듯이 속도가 조금 느려진다. 암호파일을 열어서 사용자명을 찾을 때까지 사용자 목록을 살펴봐야 하기때문에 암호파일 크기가 커질 수록 더 느려진다. 그리고 이 작업을 페이지를 요청할 때마다 진행한다.
그래서 현실적으로 한 암호파일에 저장할 수 있는 사용자수에는 한계가 있다. 이 한계는 사용하는 서버의 성능에 따라 다르지만, 항목이 수백개가 넘는다면 느려진다고 생각하고 다른 인증 방법을 고려해야 한다.
사용자명과 암호를 사용한 인증이 다가 아니다. 종종 접속한 장소와 같은 다른 정보를 가지고 사용자를 들여보내고 싶을 때가 있다.
Allow와
Deny 지시어는
문서를 요청한 컴퓨터의 호스트명 혹은 호스트 주소를 가지고
접근을 허용하거나 거부한다. Order 지시어는 이 두
지시어와 같이 사용하여, 아파치에게 어떤 순서로 규칙을 적용할지
알린다.
이들 지시어 사용법은 다음과 같다.
Allow from address
여기서 address는 IP 주소(혹은 IP 주소 일부)나 완전한 도메인명(혹은 도메인명 일부)이다. 원한다면 여러 주소나 도메인명을 사용할 수 있다.
예를 들어, 누군가가 게시판에 광고를 올리고 있다면 다음과 같이 접근을 막을 수 있다.
Deny from 205.252.46.165
그 주소에서 들어오는 방문자는 이 지시어가 보호하는 페이지를 볼 수 없다. IP 주소 대신 다음과 같이 컴퓨터명을 사용할 수도 있다.
Deny from host.example.com
또, 전체 도메인의 접근을 막으려면 주소나 도메인명의 일부를 사용한다.
Deny from 192.101.205
Deny from cyberthugs.com moreidiots.com
Deny from ke
Order를
Deny와 Allow 지시어와 같이
사용하여 실제로 원하는 대상을 막을 수 있다.
Order deny,allow
Deny from all
Allow from dev.example.com
Allow
지시어만 사용하면, 해당 호스트의 사용자를 허용하고 거기에
추가로 모든 사람을 허용하므로 원하는 결과를 얻지 못한다.
당신은 특정 사람만 허용하길 원한다.
mod_auth와
mod_access 문서에 접근제어가 동작하는
방법에 대한 더 많은 정보가 있다.
Apache HTTP Server Version 2.0
| 관련된 모듈 | 관련된 지시어 |
|---|---|
CGI (Common Gateway Interface)는 웹서버가 보통 CGI 프로그램 혹은 CGI 스크립트라고 부르는, (웹페이지 내용을 만드는) 외부 프로그램과 통신하는 방법을 정의한다. 웹사이트에서 동적인 페이지를 만드는 가장 흔하고 간단한 방법이다. 이 문서는 아파치 웹서버에 CGI를 구성하는 방법을 소개하고, CGI 프로그램을 작성해본다.
CGI 프로그램이 올바로 동작하려면 CGI 실행이 가능하도록 아파치를 설정해야 한다. 설정하는 방법은 여러가지다.
ScriptAlias
지시어를 사용하면 아파치는 특정 디렉토리를 CGI 프로그램용으로
둔다. 아파치는 이 디렉토리에 있는 모든 파일이 CGI
프로그램이라고 가정하여 클라이언트가 자원을 요청하면 자원을
실행하려고 시도한다.
ScriptAlias
지시어는 다음과 같이 사용한다.
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
위 예제는 아파치를 기본 장소에 설치한 경우
httpd.conf 설정파일에 있는 내용이다. ScriptAlias 지시어는 Alias 지시어와 같이 URL
앞부분을 특정 디렉토리로 대응한다.
Alias와
ScriptAlias는 보통 DocumentRoot 디렉토리 밖에 있는
디렉토리에 사용한다. Alias와
ScriptAlias의 차이점은
ScriptAlias가 추가로 URL 앞부분으로
시작하는 모든 파일을 CGI 프로그램으로 취급하는 점이다.
그래서 위의 설정은 아파치에게 /cgi-bin/으로
시작하는 자원을 요청하면
/usr/local/apache2/cgi-bin/ 디렉토리에서
찾아서 CGI 프로그램으로 처리하라고 알린다.
예를 들어, URL
http://www.example.com/cgi-bin/test.pl을
요청하면 아파치는
/usr/local/apache2/cgi-bin/test.pl 파일을
실행하여 결과를 반환한다. 물론 파일이 존재하고 실행가능하며
어떤 방법으로든 출력을 해야 한다. 그렇지 않으면 아파치는
오류문을 보낸다.
보통 보안상 이유때문에 CGI 프로그램은 ScriptAlias한 디렉토리에
한정한다. 그래서 관리자는 누가 CGI 프로그램을 사용할 수
있는지 엄격히 감독할 수 있다. 그러나 적당한 보안조치를
취했다면 아무 디렉토리에서나 CGI 프로그램을 실행하지 않을
이유가 없다. 예를 들어, UserDir 지시어를 사용하여
사용자가 자신의 홈디렉토리에 웹페이지를 가지는 경우를
가정하자. 사용자가 자신의 CGI 프로그램을 사용하고 싶은데
cgi-bin 디렉토리에 접근권한이 없다면, 다른
곳에서라도 CGI 프로그램을 실행하고 싶을 것이다.
아무 디렉토리에서나 CGI 실행을 허용하려면 두 과정이
필요하다. 먼저, AddHandler나 SetHandler 지시어를 사용하여
cgi-script 핸들러를 작동해야 한다. 두번째로,
Options 지시어에
ExecCGI를 지정해야 한다.
서버의 주설정파일에 직접 Options 지시어를 사용하여 특정
디렉토리에서 CGI 실행을 허용할 수 있다.
<Directory /usr/local/apache2/htdocs/somedir>
Options +ExecCGI
</Directory>
위 지시어로 아파치는 CGI 파일의 실행을 허용한다. 어떤
파일이 CGI 파일인지도 서버에게 알려야 한다. 다음 AddHandler 지시어는 서버에게
확장자가 cgi나 pl인 파일은 모두
CGI 프로그램이라고 알린다.
AddHandler cgi-script .cgi .pl
.htaccess 투토리얼은
httpd.conf에 접근권한이 없는 경우에 CGI 프로그램을
사용할 수 있는 방법을 알려준다.
아래 설정을 사용하면 사용자 디렉토리에서 .cgi로
끝나는 파일을 CGI 프로그램으로 실행한다.
<Directory /home/*/public_html>
Options +ExecCGI
AddHandler cgi-script .cgi
</Directory>
다음을 사용하면 사용자 디렉토리의 cgi-bin
하위디렉토리에 있는 모든 파일을 CGI 프로그램으로 인식한다.
<Directory /home/*/public_html/cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Directory>
``일반적인'' 프로그래밍과 CGI 프로그래밍 사이에는 두가지 주된 차이점이 있다.
첫번째 차이는 CGI 프로그램은 다른 출력을 하기전에 먼저 MIME-type 헤더를 출력해야 한다는 점이다. HTTP 헤더는 클라이언트에게 클라이언트가 어떤 내용을 받게될지 미리 알린다. 보통 다음과 같다.
Content-type: text/html
두번째 차이는 HTML 혹은 브라우저가 보여줄 수 있는 형식으로 출력해야 한다는 점이다. 대부분의 경우 HTML을 출력하지만, 때때로 gif 그림과 같이 HTML이 아닌 내용을 출력하는 CGI 프로그램을 작성하는 경우도 있다.
두가지를 제외하고는 CGI 프로그램 작성은 이미 만들어 보았을 다른 프로그램들과 매우 비슷하다.
다음은 브라우저에 한 줄을 찍는 CGI 프로그램 예제다.
그대로 first.pl이라는 파일에 저장하고,
cgi-bin 디렉토리에 복사한다.
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello, World.";
Perl에 익숙하지 않더라도 무슨 일이 일어나는지 알 수
있다. 첫번째 줄은 아파치(혹은 사용하는 쉘)에게
/usr/bin/perl 위치에 있는 인터프리터을 사용하여
이 프로그램 파일을 실행하라고 알린다. 두번째 줄은 방금
말한 content-type 선언을 출력하고 carriage-return 줄바꿈을
두번 출력한다. 그러면 헤더 뒤에 HTTP 헤더의 끝을 뜻하는
빈줄이 생기고, 본문이 시작한다. 세번째 줄은 "Hello, World."
문자열을 출력한다. 이것으로 끝이다.
브라우저를 실행하고 주소를 입력한다
http://www.example.com/cgi-bin/first.pl
파일 장소를 입력하면, 브라우저창에 Hello, World.
한 줄이 보인다. 흥분되지는 않지만, 한번 동작하는 것을
보았으니 이제 다른 것을 시도해 볼 수 있다.
웹에서 CGI 프로그램에 접근할때 브라우저에 나올 수 있는 내용은 기본적으로 네가지다.
Content-Type을 설정하였는지 확인한다.서버는 당신과 동일한 계정으로 동작하지 않음을 명심하라.
즉, 서버가 시작하면 서버는 비특권 사용자 권한(보통
nobody나 www)으로 동작한다.
그래서 당신이 소유한 파일을 실행하려면 권한이 필요하다.
파일에 nobody가 실행하기에 충분한 권한을
주기위해 보통 모두에게 파일의 실행 권한을 준다.
chmod a+x first.pl
또, 프로그램이 다른 파일을 읽거나 쓴다면 이 파일에도 적절한 권한이 필요하다.
명령행에서 프로그램을 실행하면 자동으로 어떤 정보가
쉘로 전달된다. 예를 들어, PATH는 쉘에게 당신이
말한 파일을 찾을 장소를 알려준다.
웹서버가 프로그램을 CGI 프로그램으로 실행할때는
PATH가 다를 수 있다. (예를 들어,
sendmail 같이) CGI 프로그램 안에서 실행하는
명령어는 완전한 경로로 명시해야 쉘이 명령어를 찾을 수
있다.
경로 문제는 다음과 같이 CGI 프로그램 첫번째 줄에 나오는
스크립트 인터프리터 (보통 perl) 경로에서
자주 발생한다.
#!/usr/bin/perl
실제로 인터프리터의 경로인지 확인한다.
또, CGI 프로그램이 다른 환경변수를 사용한다면 아파치가 이 변수들을 프로그램에게 전달해야 한다.
CGI 프로그램이 실패하는 경우 대부분 프로그램 자체 문제때문이다. 특히 위의 두가지 실수를 하지 않았고 이 글을 계속 보고 있다면 더더욱 그렇다. 먼저 웹서버에서 실행하기 전에 명령행에서 프로그램을 실행해본다. 예를 들어, 다음과 같이 실행한다.
cd /usr/local/apache2/cgi-bin
./first.pl
(perl 인터프리터를 실행하지 마라. 쉘과
아파치는 스크립트 첫번째 줄에 있는 경로 정보를 사용하여 인터프리터를
찾아야 한다.)
프로그램은 제일 먼저 Content-Type을 포함한
HTTP 헤더들을 출력하고 빈 줄을 출력해야 한다. 다른 것을
출력한다면 웹서버에서 실행할 경우 아파치는 Premature
end of script headers를 반환한다. 자세한 내용은
위의 CGI 프로그램 작성하기를 참고하라.
오류 로그는 당신 편이다. 무언가 잘못되면 오류 로그에 문구가 생긴다. 오류 로그를 제일 먼저 살펴봐야 한다. 웹사이트를 호스팅하는 곳에서 오류 로그를 보지 못하게 한다면, 아마도 다른 업체를 알아봐야 한다. 오류 로그를 보는 방법을 익히면, 대부분의 문제를 빨리 파악하여 해결할 수 있다.
suexec 지원 프로그램을
사용하면 어떤 가상호스트 혹은 어떤 사용자 디렉토리에 있는지에
따라 CGI 프로그램을 다른 사용자 권한으로 실행할 수 있다.
Suexec는 매우 엄격하게 권한을 검사하며, 검사를 하나라도
통과하지 못하면 CGI 프로그램을 실행하지 않고 Premature
end of script headers를 반환한다.
suexec를 사용하고 있는지 알려면 apachectl -V를
실행하여 SUEXEC_BIN 위치를 확인한다. 아파치가
시작할때 그 장소에서 suexec 실행파일을 발견하면, suexec를
사용할 수 있다.
suexec를 완전히 이해하지 못했다면 사용해서는 안된다.
suexec를 사용하지 않으려면 SUEXEC_BIN 위치에
있는 suexec 실행파일을 지우고 (혹은 파일명을
바꾸고) 서버를 재시작하면 된다. suexec에 대해 읽은 다음 그래도
사용하고 싶다면, suexec -V를 실행하여 suexec
로그파일 위치를 알아내고 로그파일에서 당신이 어떤 규칙을
어기고 있는지 찾는다.
CGI 프로그래밍에 익숙해질수록 뒤에서 벌어지는 일을 이해하면 도움이 된다. 구체적으로 브라우저와 서버가 서로 통신하는 방법을 말하는 것이다. 몰라도 "Hello, World."를 출력하는 프로그램을 작성할 수 있지만 이런 프로그램은 별로 쓸모가 없기때문이다.
환경변수는 당신이 컴퓨터를 사용하는 동안 당신 주위를
떠다니는 값이다. 환경변수는 path (컴퓨터가 당신이 입력한
명령어에 해당하는 실제 파일을 찾는 장소), 사용자명, 터미널
종류와 같이 유용한 정보다. 일반적인 환경변수를 모두 보려면
명령행 프롬프트에서 env를 입력한다.
CGI를 실행할때도 서버와 브라우저는 각자의 환경변수를 서로 교환한다. 이 정보에는 브라우저 종류 (Netscape, IE, Lynx), 서버 종류 (아파치, IIS, WebSite), 실행하는 CGI 프로그램명 등이 있다.
CGI 프로그래머는 이런 변수들을 사용할 수 있고, 환경변수는 클라이언트-서버 통신에는 일부분을 차지한다. 전체 필수 변수 목록은 http://hoohoo.ncsa.uiuc.edu/cgi/env.html에 있다.
아래 간단한 Perl CGI 프로그램은 자신에게 전달된 모든
환경변수를 보여준다. 아파치 배포본의 cgi-bin
디렉토리에 이와 비슷한 프로그램이 두개 있다. 몇몇 변수는
필수이고 나머지는 선택적이다. 그래서 공식 목록에 없는
변수도 보인다. 또, 아파치는 기본적으로 제공하는 환경변수
외에 여러가지 방법으로 직접 환경변수를
추가할 수 있다.
#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $key (keys %ENV) {
print "$key --> $ENV{$key}<br>";
}
또, 서버와 클라이언트는 표준입력(STDIN)과
표준출력(STDOUT)으로 통신한다. 일상적인 경우
STDIN은 키보드나 프로그램이 처리하는 파일을
나타내고, STDOUT은 보통 콘솔이나 화면을 뜻한다.
CGI 프로그램에게 웹 양식(form)을 POST하면
양식에 입력한 자료를 특별한 형식으로 묶어서 CGI 프로그램의
STDIN으로 전달한다. 그러면 프로그램은 키보드나
파일에서 얻은 자료를 처리하듯이 자료를 처리할 수 있다.
"특별한 형식"은 매우 간단하다. 항목 이름과 값을 등호(=)로 연결하고, 항목 이름과 값의 쌍들을 서로 앤퍼샌드(&)로 연결한다. 공백, 앰퍼샌드, 등호 같은 부자연스러운 문자는 혼동하지 않도록 16진수로 변환한다. 완전한 자료 문자열은 다음과 같이 생겼다.
name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey
종종 URL 뒤에서 이런 문자열을 보게 된다. 이 경우 서버는
문자열을 QUERY_STRING이라는 환경변수에 저장한다.
이를 GET 요청이라고 한다. FORM
태그의 METHOD 속성을 지정하여 HTML 양식(form)이
자료를 GET할지 POST할지 결정한다.
이제 프로그램은 이런 문자열을 유용한 정보로 쪼개야 한다. 다행히도 이런 자료 처리를 돕고 CGI 프로그램의 다른 여러 면을 살피는 라이브러리와 모듈들이 있다.
CGI 프로그램을 작성할때 지루한 작업을 대신해주는 코드 라이브러리 혹은 모듈을 사용할지 고려해봐야 한다. 이런 것을 사용하면 버그가 줄고 더 빨리 프로그램을 개발할 수 있다.
Perl로 CGI 프로그램을 작성한다면 CPAN에서 관련 모듈들을 찾을
수 있다. CGI 개발에 가장 널리 사용되는 모듈은
CGI.pm이다. 대부분의 프로그램에 충분한 최소
기능을 구현한 CGI::Lite도 고려해 볼 수 있다.
C로 CGI 프로그램을 작성한다면 선택의 여지가 많다. 이중
하나가 http://www.boutell.com/cgic/에
있는 CGIC 라이브러리다.
웹에 매우 많은 CGI 정보가 있다. 뉴스그룹 comp.infosystems.www.authoring.cgi에서 여러 사람들과 CGI 문제를 논의할 수 있다. HTML Writers Guild의 -servers 메일링리스트는 질문에 대한 답을 찾기에 훌륭한 장소다. http://www.hwg.org/lists/hwg-servers/에서 더 많은 것을 알 수 있다.
그리고 물론 CGI 프로그램 동작에 대한 모든 내용을 설명한 CGI 규약을 읽어야 할지도 모른다. NCSA에 원본 문서가 있고, 수정한 초안은 Common Gateway Interface RFC 프로젝트에 있다.
메일링리스트나 뉴스그룹에 현재 격고 있는 CGI 문제에 대해 질문할때는 발생한 현상과 원래 기대한 결과, 실제로 발생한 현상이 어떻게 다른지, 사용하는 서버, CGI 프로그램을 작성한 언어, 가능하면 해당 코드를 자세히 적어라. 그러면 해결책을 찾기 쉬워진다.
아파치 소스코드가 잘못되었다고 확신하지 않는 한 CGI 질문을 아파치 버그 데이터베이스에 올리면 절대로 안된다.
Apache HTTP Server Version 2.0
.htaccess 파일을 사용하여 디렉토리별로 설정을
변경할 수 있다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
.htaccess 파일(혹은 "분산 설정파일")을
사용하면 디렉토리별로 설정을 변경할 수 있다. 여러 설정 지시어가
있는 파일을 특정 문서 디렉토리에 두면, 그 디렉토리와 모든
하위디렉토리에 지시어를 적용한다.
.htaccess 파일명을 다르게 사용하고 싶다면,
AccessFileName 지시어를
사용하여 변경할 수 있다. 예를 들어, .config
파일명을 사용하려면 서버 설정파일에 다음과 같이 추가한다.
AccessFileName .config
일반적으로 .htaccess 파일은 주설정파일과 문법이
같다. AllowOverride
지시어가 이 파일에 나올 수 있는 내용을 결정한다. 이 지시어는
.htaccess 파일에서 허용하는 지시어 분류를 지정한다.
지시어를 .htaccess 파일에서 사용할 수 있다면,
해당 지시어 문서의 Override 항목은 지시어를 허용하기위해
AllowOverride에 사용할
값을 알려준다.
예를 들어, AddDefaultCharset
지시어 문서를 보면 이 지시어를 .htaccess 파일에서
사용할 수 있다. (지시어 요약에서 사용장소 항목을 보라.)
Override
줄에 FileInfo가 있다. 그래서 이 지시어를
.htaccess 파일에서 사용하기위해서는 최소한
AllowOverride FileInfo가 필요하다.
특정 지시어를 .htaccess 파일에서 사용할
수 있는지 궁금하면 지시어 문서의 사용장소 항목에 ".htaccess"가
있는지 확인한다.
일반적으로 주서버파일에 접근할 수 없는 경우가 아니라면
.htaccess 파일을 사용하면 안된다. 예를 들어,
사용자 인증이 항상 .htaccess 파일에 있어야
한다는 것은 잘못 알려진 오해다. 이는 사실이 아니다. 주서버설정에
사용자 인증 설정을 적을 수 있고, 사실 이러길 권한다.
.htaccess 파일은 컨텐츠 제공자가 디렉토리별로
서버 설정을 다르게하고 싶지만 서버 시스템에 root 권한이
없는 경우에 사용한다. 서버 관리자가 설정을 자주 변경하고
싶지 않은 경우 일반 사용자가 직접 .htaccess
파일을 수정하도록 허용하는 것이 바람직하다. 예를 들어, 한
컴퓨터에 여러 사용자 사이트를 서비스하는 ISP에서 사용자가
자신의 설정을 변경하고 싶은 경우가 그러하다.
그러나 일반적으로 .htaccess 파일은 가급적
피해야 한다. .htaccess 파일에서 허용하는 지시어는
주설정파일의 <Directory> 섹션과 같은 효과가
있다.
다음 두가지 큰 이유때문에 .htaccess 파일
사용을 피해야 한다.
첫번째는 성능이다. AllowOverride가 .htaccess
파일을 사용하도록 허용하면, 아파치는 디렉토리마다
.htaccess 파일을 찾는다. 그래서
.htaccess 파일을 허용하면 실제로 파일을 사용하지
않는 경우에도 성능이 떨어진다! 또, .htaccess
파일은 문서를 요청할때마다 읽어들인다.
게다가 적용해야 하는 전체 지시어를 모으기위해 아파치는
모든 상위 디렉토리에서 .htaccess 파일을 찾는다.
(어떻게 지시어를 적용하나 절을 참고.)
그래서 /www/htdocs/example 디렉토리에 있는
파일을 요청하면, 아파치는 다음 파일들을 찾아야 한다.
/.htaccess
/www/.htaccess
/www/htdocs/.htaccess
/www/htdocs/example/.htaccess
그래서 그 디렉토리에 있는 파일을 접근할 때마다 설정파일이
전혀 없어도 파일시스템을 4번 더 접근해야 한다.
(/에서도 .htaccess 파일을 허용한
경우를 말한다. 보통은 허용하지 않는다.)
두번째 이유는 보안이다. 사용자에게 서버설정 변경 권한을
주면 당신이 감당할 수 없는 변화가 일어날 수 있다. 사용자에게
이런 권한을 줄지 곰곰이 생각하라. 또, 사용자가 원하는 것보다
적은 권한을 주면 기술지원요청이 들어온다. 사용자에게 가능한
권한 수준을 명확히 알려라. 사용자에게 AllowOverride를 어떻게 설정하였는지
정확히 알리고 관련 문서를 제공하면 앞으로 혼란을 피할 수
있다.
지시어를 /www/htdocs/example 디렉토리의
.htaccess 파일을 두는 것과 주서버설정의
<Directory /www/htdocs/example> Directory
설정에 두는 것은 완전히 같다.
/www/htdocs/example에 있는
.htaccess 섹션:
/www/htdocs/example에 있는
.htaccess 파일 내용
AddType text/example .exm
httpd.conf 파일에 있는 섹션
<Directory /www/htdocs/example>
AddType text/example .exm
</Directory>
그러나 파일을 요청할 때마다 설정을 읽지않고 아파치가 시작할때 한번만 설정을 읽기때문에 같은 설정을 서버설정파일에 사용하면 성능이 더 빠르다.
AllowOverride 지시어를
none으로 설정하면 .htaccess 파일을
완전히 사용할 수 없다.
AllowOverride None
.htaccess 파일을 발견한 디렉토리와 그 디렉토리의
모든 하위디렉토리에 .htaccess 파일에 있는 설정
지시어를 적용한다. 그래서 상위디렉토리의 .htaccess
파일을 주의해야 한다. 발견한 순서로 지시어를 적용한다. 특정
디렉토리에 있는 .htaccess 파일은 상위디렉토리에
있는 .htaccess 파일의 지시어를 무효로 만들
수 있고, 상위디렉토리에 있는 지시어는 더 상위디렉토리 혹은
주설정파일에 있는 지시어를 무효로 만들 수 있다.
예제:
/www/htdocs/example1 디렉토리에 다음과 같은
.htaccess 파일이 있다.
Options +ExecCGI
(주의: .htaccess 파일에 "Options" 지시어를 사용하려면
"AllowOverride Options"가 필요하다.)
/www/htdocs/example1/example2 디렉토리에는
다음과 같은 .htaccess 파일이 있다.
Options Includes
이 두번째 .htaccess 파일의
Options Includes가 이전 설정을 완전히 무효로
만들기때문에 /www/htdocs/example1/example2
디렉토리는 CGI 실행을 허용하지 않는다.
인증 방법을 알기위해 바로 이곳부터 읽는다면 주의할 것이
있다. 암호 인증을 하려면 .htaccess 파일이
필요하다는 오해가 널리 퍼져있다. 이는 사실이 아니다.
주설정파일의 <Directory> 섹션에 인증 지시어를
두는 것이 더 권장하는 방법이고, 서버의 주설정파일을 수정할
수 없는 경우에만 .htaccess 파일을 사용해야
한다. 언제 .htaccess 파일을 사용해야 하는지와
사용하지 말아야 하는지는 위에서
설명하였다.
앞에서 말했지만 아직도 .htaccess 파일이
필요하다고 생각되면 아래 설정이 도움이 될 것이다.
이 지시어가 동작하려면 "AllowOverride AuthConfig"가
있어야 한다.
.htaccess 파일 내용.
AuthType Basic
AuthName "Password Required"
AuthUserFile /www/passwords/password.file
AuthGroupFile /www/passwords/group.file
Require Group admins
이 지시어가 동작하기위해서는
AllowOverride AuthConfig 지시어가 필요함을
명심하라.
인증과 권한부여에 대한 자세한 설명은 인증 투토리얼을 보길 바란다.
또다른 일반적인 .htaccess 파일의 용도는
특정 디렉토리에서 Server Side Includes를 가능하게 만드는
것이다. 원하는 디렉토리의 .htaccess 파일에
다음과 같은 설정 지시어를 사용하면 된다.
Options +Includes
AddType text/html shtml
AddHandler server-parsed shtml
이 지시어가 동작하려면 AllowOverride Options와
AllowOverride FileInfo가 모두 필요함을 명심하라.
server-side includes에 대한 자세한 설명은 SSI 투토리얼을 보길 바란다.
마지막으로 .htaccess 파일을 사용하여 특정
디렉토리에서 CGI 프로그램 실행을 허용하고 싶다면, 다음과
같은 설정을 사용한다.
Options +ExecCGI
AddHandler cgi-script cgi pl
혹은 이 디렉토리에 있는 모든 파일을 CGI 프로그램으로 처리하고 싶다면 다음과 같은 설정도 가능하다.
Options +ExecCGI
SetHandler cgi-script
이 지시어가 동작하려면 AllowOverride Options와
AllowOverride FileInfo가 모두 필요함을 명심하라.
CGI 프로그래밍과 설정에 대한 자세한 설명은 CGI 투토리얼을 보길 바란다.
.htaccess 파일에 둔 설정 지시어가 원하는
기능을 하지 않는 경우 여러가지 이유가 있을 수 있다.
가장 일반적인 문제는 설정 지시어를 가능하게 만드는 AllowOverride를 설정하지 않은
경우다. 문제가 되는 파일 영역에 AllowOverride None이
없는지 확인한다. .htaccess 파일을 아무렇게나
적은 다음 페이지를 다시 접근하여 쉽게 검사해볼 수 있다.
서버 오류가 나오지 않으면 거의 확실히
AllowOverride None을 사용한 경우다.
반대로 문서에 접근할때 서버 오류가 발생하면 아파치 오류로그를
살펴봐라. 아마도 .htaccess 파일에 있는 지시어를
허용하지 않는다고 할 것이다. 아니고 문법 오류가 있다면 오류를
고친다.
Apache HTTP Server Version 2.0
인증(authentication)은 자신이 누구라고 주장하는 사람을 확인하는 절차이다. 권한부여(authorization)는 가고 싶은 곳으로 가도록 혹은 원하는 정보를 얻도록 허용하는 과정이다.
참고: 인증, 권한부여, 접근제어
CGI (Common Gateway Interface)는 웹서버가 보통 CGI 프로그램 혹은 CGI 스크립트하고 부르는, (웹페이지 내용을 만드는) 외부 프로그램과 상호작용하는 방법을 정의한다. 웹사이트에서 동적인 페이지를 만드는 가장 흔하고 간단한 방법이다. 이 문서는 아파치 웹서버에 CGI를 구성하는 방법을 소개하고, CGI 프로그램을 작성해본다.
참고: CGI: 동적 페이지 생성
.htaccess 파일.htaccess 파일을 사용하여 디렉토리별로
설정을 변경할 수 있다. 여러 설정 지시어가 있는 파일을
특정 문서 디렉토리에 두면, 그 디렉토리와 모든 하위디렉토리에
지시어를 적용한다.
참고: .htaccess
파일
SSI (Server Side Includes)는 HTML 페이지에 사용하는 지시어로, 페이지를 서비스할때 서버가 처리한다. SSI를 사용하면 CGI 프로그램이나 다른 동적인 기술로 페이지 전체를 만들어서 서비스하지 않고도 HTML 페이지에 동적으로 생성한 내용을 추가할 수 있다.
Apache HTTP Server Version 2.0
여러 사용자가 있는 시스템에서 UserDir 지시어를 사용하면
각 사용자는 자신의 홈디렉토리 안에 웹사이트를 만들 수 있다.
URL http://example.com/~username/에 접근하면
사용자 "username"의 홈디렉토리에서 UserDir 지시어로 지정한
하위디렉토리에 있는 페이지를 가져오게 된다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
UserDir
지시어는 사용자별 페이지를 가져올 디렉토리를 지정한다. 이
지시어의 사용법은 여러가지다.
슬래쉬로 시작하지않는 경로를 지정하면 각 사용자의 홈디렉토리에 상대적인 디렉토리 경로로 처리한다. 예를 들어, 아래 설정의 경우:
UserDir public_html
URL http://example.com/~rbowen/file.html은
파일 경로 /home/rbowen/public_html/file.html을
뜻한다.
슬래쉬로 시작하는 경로를 지정하면 지정한 디렉토리에 사용자명을 더한 디렉토리 경로를 사용한다. 예를 들어, 아래 설정의 경우:
UserDir /var/html
URL http://example.com/~rbowen/file.html은
파일 경로 /var/html/rbowen/file.html을 뜻한다.
별표 (*)를 포함한 경로를 지정하면 별표를 사용자명으로 대체한 경로를 사용한다. 예를 들어, 아래 설정의 경우:
UserDir /var/www/*/docs
URL http://example.com/~rbowen/file.html은
파일 경로 /var/www/rbowen/docs/file.html을
뜻한다.
UserDir 문서에 있는 문법을 사용하여 사용자별 웹디렉토리 기능을 이용할 수 있는 사용자를 제한할 수 있다:
UserDir enabled
UserDir disabled root jro fish
위 설정은 disabled 문장에 열거한 사람을
제외하고 모든 사용자에게 웹디렉토리 기능을 허락한다. 또,
다음과 같이 몇몇 사용자를 제외하고 기능을 허락하지 않을
수도 있다:
UserDir disabled
UserDir enabled rbowen krietz
UserDir
문서에 있는 다른 예들도 참고하라.
사용자마다 cgi-bin 디렉토리를 부여하려면 <Directory> 지시어를
사용하여 사용자 홈디렉토리의 특정 하위디렉토리를 cgi 가능하게
만든다.
<Directory /home/*/public_html/cgi-bin/>
Options ExecCGI
SetHandler cgi-script
</Directory>
UserDir이 public_html이라고
가정하면, 다음과 같이 그 안에 있는 cgi 프로그램
example.cgi를 실행할 수 있다.
http://example.com/~rbowen/cgi-bin/example.cgi
사용자가 자신의 웹공간에 대한 웹서버 설정을 수정하려면,
.htaccess 파일을 사용할 수 있어야 한다. AllowOverride를 사용자가 수정할
수 있는 지시어에 적합한 값으로 설정하라. 어떻게 동작하는지에
대한 자세한 졍보는 .htaccess
투토리얼을 참고하라.
Apache HTTP Server Version 2.0
Server-side includes를 사용하여 HTML 문서에 동적인 내용을 추가할 수 있다.
| 관련된 모듈 | 관련된 지시어 |
|---|---|
이 글은 보통 SSI라고 부르는 Server Side Includes를 설명한다. SSI가 가능하도록 서버를 설정하는 방법과 HTML 페이지에 동적인 내용을 추가하는 기본적인 SSI 사용법을 소개한다.
이 글의 뒷부분은 SSI 지시어 조건문과 같은 고급기법을 설명한다.
SSI (Server Side Includes)는 HTML 페이지에 사용하는 지시어로, 페이지를 서비스할때 서버가 처리한다. SSI를 사용하면 CGI 프로그램이나 다른 동적인 기술로 페이지 전체를 만들어서 서비스하지 않고도 HTML 페이지에 동적으로 생성한 내용을 추가할 수 있다.
SSI를 사용할지 아니면 프로그램으로 페이지 전체를 생성할지 결정은 페이지에서 정적인 부분이 많은지와 페이지를 서비스할 때마다 어느정도를 다시 계산해야할지에 달렸다. SSI는 현재 시간과 같이 적은 정보를 추가하는데 좋다. 그러나 페이지를 서비스할때 페이지의 대부분을 생성해야 한다면 다른 방법을 찾아봐야 한다.
서버가 SSI를 처리하려면 httpd.conf 파일이나
.htaccess 파일에서 다음 지시어를 사용해야 한다.
Options +Includes
그러면 아파치는 파일에서 SSI 지시어를 처리한다. 설정에는
보통 여러 Options 지시어가
있고, 이 지시어들은 서로 덮어써서 무효로 만들다. 그래서
지시어를 맨마지막에 처리하기위해 보통 SSI를 원하는 특정
디렉토리에서 Options를 사용한다.
모든 파일에서 SSI 지시어를 처리하는 것은 아니다. 아파치에게
어떤 파일을 처리할지 알려줘야 한다. 두가지 방법이 있다.
하나는 다음과 같은 지시어로 .shtml과 같은 특정
파일 확장자를 가진 파일을 처리하는 방법이다.
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
이 방법의 단점은 이미 있는 페이지에 SSI 지시어를 추가하는
경우 SSI 지시어를 처리하기위해 .shtml 확장자를
부여하기때문에 파일명과 이 페이지의 모든 링크를 변경해야
하는 점이다.
다른 방법은 XBitHack
지시어를 사용하는 방법이다.
XBitHack on
XBitHack는
실행권한이 있는 파일에서 SSI 지시어를 처리한다. 그래서 이미
있는 페이지에 SSI 지시어를 추가한다면 파일명을 변경하지
않고 chmod로 파일에 실행권한을 주면 된다.
chmod +x pagename.html
하지 말아야 할 것 하나. 가끔 .shtml 파일명에
골치를 앓지말고 모든 .html 파일을 SSI 처리하라고
충고하는 사람이 있다. 이 사람들은 아마도 XBitHack에 대해 모르는
것 같다. 명심할 점은 이렇게 하면 아파치는 파일에 SSI 지시어가
없더라도 클라이언트로 보내는 모든 파일을 살펴봐야 한다는
것이다. 성능이 매우 느려질 수 있으며, 좋은 생각이 아니다.
물론 윈도우즈에서는 실행권한이란 것이 없기때문에 후자를 사용할 수 없다.
내용이 동적이여서 계산하기 어렵기때문에 아파치 기본 설정은 SSI 페이지의 최근수정일과 content length HTTP 헤더를 보내지 않는다. 그래서 문서를 캐쉬하지 못하고 클라이언트가 느끼는 성능이 떨어진다. 두가지 해결방법이 있다.
XBitHack Full 설정은 사용한다. 그러면
아파치는 포함하는(include) 파일들의 수정일은 무시한체
원래 요청한 파일의 날짜만 보고 최근수정일을 알아낸다.mod_expires에 있는 지시어를 사용하여
파일에 직접 만기일을 설정하면 브라우저와 프록시가 문서를
캐쉬할 수 있다.SSI 지시어의 사용법은 다음과 같다.
<!--#element attribute=value attribute=value ... -->
HTML 주석같이 생겼기때문에 SSI 기능을 가동하지 않아도 HTML 소스에는 나오지만 브라우저는 무시한다. SSI를 올바로 설정하면 지시어를 결과값으로 바꾼다.
element는 다음중 하나다. 다음 회에 더 자세히 설명할 것이다. 지금은 SSI로 할 수 있는 몇가지 예를 보인다
<!--#echo var="DATE_LOCAL" -->
echo element는 변수값을 그대로 출력한다.
CGI 프로그램에 제공하는 환경변수들 외에도 여러 표준 변수가
있다. 또, set element를 사용하여 직접 변수를
정의할 수도 있다.
날짜 출력 형식이 마음에 들지 않는다면, 다음과 같이
config element의 timefmt attribute를
사용한다.
<!--#config timefmt="%A %B %d, %Y" -->
Today is <!--#echo var="DATE_LOCAL" -->
이 문서는 <!--#flastmod file="index.html" -->에 마지막으로 수정되었다
이 element도 timefmt 형식 설정에 달렸다.
일반적인 SSI 사용법중 하나로, 많이들 애용하는 ``방문수 카운터'' 같은 CGI 프로그램 결과를 출력한다.
<!--#include virtual="/cgi-bin/counter.pl" -->
다음은 HTML 문서에 사용할 수 있는 몇가지 SSI 예제다.
앞에서 SSI를 사용하여 사용자에게 문서의 최근수정일을 알릴 수 있다고 말했다. 그러나 실제 방법은 알려주지 않았다. 다음 코드를 HTML 문서에 사용하면 페이지에 시간 기록을 남긴다. 물론 위에서 설명한대로 SSI가 올바로 작동해야 한다.
<!--#config timefmt="%A %B %d, %Y" -->
이 문서는 <!--#flastmod file="ssi.shtml" -->에 마지막으로 수정되었다;
물론 ssi.shtml대신 원하는 실제 파일명을
사용한다. 아무 페이지에라도 붙여넣을 수 있는 범용코드를
원한다면, 파일명 대신 LAST_MODIFIED 변수를
사용한다.
<!--#config timefmt="%D" -->
This file last modified <!--#echo var="LAST_MODIFIED" -->
timefmt 형식에 대한 자세한 정보는 검색엔진에서
strftime을 찾아봐라. 문법은 같다.
여러 페이지가 있는 사이트를 관리한다면 페이지 전체를 수정하는 것은, 특히 페이지들이 표준 외관을 가지도록 수정하는 것은 정말로 괴롭다.
페이지 상단(header)과 하단(footer)을 파일로 포함하여
이런 수정의 부담을 덜 수 있다. 모든 페이지에서
include SSI 명령어를 사용하여 페이지 하단 파일
하나를 포함하면 된다. include element의
file attribute나 virtual attribute로
포함할 파일을 지정한다. file attribute는 현재
디렉토리에 상대적인 파일경로다. 즉, (/로 시작하는)
절대파일경로나 경로 안에 ../를 사용할 수 없다. 아마도 서비스하는
문서의 상대 URL을 지정할 수 있는 virtual attribute가
더 유용할 것이다. 경로를 /로 시작할 수 있지만, 포함하려는
파일이 서비스하는 파일과 같은 서버에 있어야 한다.
<!--#include virtual="/footer.html" -->
나는 보통 이 두가지를 합쳐서 포함할 페이지 하단 파일에
LAST_MODIFIED 지시어를 넣는다. 포함하려는 파일에도
SSI 지시어가 나올 수 있으며, 이렇게 포함한 파일이 다른 파일을
포함하는 식으로 여러번 계속 포함할 수도 있다.
시간 형식 config(설정) 외에 두가지를 더
config(설정)할 수 있다.
보통 SSI 지시어가 잘못되면 다음과 같은 문구가 나온다
[an error occurred while processing this directive]
이 문구를 변경하고 싶다면 config element의
errmsg attribute를 사용하여 변경한다.
<!--#config errmsg="[It appears that you don't know how to use SSI]" -->
사이트를 서비스하기 전에 모든 SSI 지시어 문제를 해결하여 사용자가 이런 문구를 보지 않길 바란다. (그렇지?)
그리고 sizefmt attribute가 반환하는 파일크기
형식을 config(설정)할 수 있다. 바이트로 크기를
보여주려면 bytes, 적절히 Kb나 Mb로 크기를
보여주려면 abbrev를 사용한다.
나는 다음 달에 작은 CGI 프로그램과 SSI를 같이 사용하는
글을 쓸 예정이다. 지금은 exec element로 할
수 있는 다른 것들을 설명할 것이다. SSI는 실제 쉘을 (정확히는
/bin/sh나 Win32를 사용한다면 DOS 쉘) 사용하여
명령어를 실행한다. 예를 들어, 다음은 디렉토리 목록을 보여준다.
<pre>
<!--#exec cmd="ls" -->
</pre>
or, on Windows
<pre>
<!--#exec cmd="dir" -->
</pre>
dir 출력에 브라우저가 혼동할
``<dir>'' 문자열이 포함되있기때문에,
윈도우즈에서 이 지시어를 사용하면 결과가 조금 이상할 것이다.
이 기능은 exec 태그에 사용한 어떤 명령어라도
실행할 수 있기때문에 매우 위험하다. ``방명록''과 같이 사용자가
웹페이지 내용을 수정할 수 있는 환경이라면, 이 기능을 절대로
사용해선 안된다. Options 지시어에
IncludesNOEXEC 아규먼트를 사용하여 SSI를 허용하지만
exec 기능을 막을 수 있다.
내용을 출력하는 기능 외에 아파치 SSI는 변수 설정이 가능하고, 비교문과 조건문에 이 변수를 사용할 수 있다.
이 글에서 설명하는 대부분의 기능은 아파치 1.2 이후부터 사용할 수 있다. 물론, 아파치 1.2 이상을 사용하지 않는다면 아마도 빨리 업그레이드해야 한다. 해라. 지금 해라. 기다릴 것이다.
set 지시어를 사용하여 나중에 사용할 변수를
설정할 수 있다. 앞으로 변수가 필요하기때문에 먼저 설명한다.
문법은 다음과 같다.
<!--#set var="name" value="Rich" -->
다음과 같이 값을 문자그대로 설정하지 않고 환경변수나 위에서 설명한 변수(예를
들어, LAST_MODIFIED)와 같이 다른 변수를 사용하여
변수값을 설정할 수도 있다. 이때 변수명 앞에 달러 표시($)를
붙여서 문자열이 아닌 변수임을 표시한다.
<!--#set var="modified" value="$LAST_MODIFIED" -->
변수값에 달러 문자를 그대로 입력하려면 달러 표시 앞에 백슬래쉬를 사용한다.
<!--#set var="cost" value="\$100" -->
마지막으로 긴 문자열 중간에 변수를 사용하는데 뒤에 있는 문자도 변수명으로 오인하여 혼동되는 경우, 변수명을 대괄호로 묶어서 확실히 한다. (좋은 예를 찾기 힘들지만, 무슨 말인지 이해하길 바란다.)
<!--#set var="date" value="${DATE_LOCAL}_${DATE_GMT}" -->
변수를 설정하고 비교할 수 있으니 조건문이 가능하다. 이제
SSI가 일종의 간단한 프로그래밍언어가 된다.
mod_include는 조건문을 만드는 if,
elif, else, endif
구조를 제공한다. 실제 한 페이지로 여러 논리적인 페이지를
만들 수 있다.
조건문 구조는 다음과 같다.
<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->
test_condition에는 어떤 논리비교라도 사용할
수 있다. 값을 다른 값과 비교하거나, 특정 값이 ``참''인지
검사한다. (문자열이 비어있지 않으면 참이다.) 사용가능한
비교 연산자를 모두 보려면, mod_include
문서를 참고하라. 다음은 조건문을 사용한 몇가지 예제다.
설정파일에 다음 줄을 추가한다.
BrowserMatchNoCase macintosh Mac
BrowserMatchNoCase MSIE InternetExplorer
클라이언트가 맥킨토시에서 실행하는 Internet Explorer라면 환경변수 ``Mac''과 ``InternetExplorer'' 모두 참으로 설정한다.
그리고 SSI 문서에 다음과 같이 적는다.
<!--#if expr="${Mac} && ${InternetExplorer}" -->
여기에 사과문가 나온다
<!--#else -->
여기에 멋진 JavaScript 코드가 나온다
<!--#endif -->
내가 매킨토시 IE에 반감이 있는 것은 아니다. 나는 단지 저번주에 다른 곳에서는 문제가 없는 JavaScript 코드가 매킨토시 IE에서는 동작하지 않아서 몇시간을 고생했다. 위는 임시 해결책이다.
(직접 정의하였건 일반 환경변수이건) 어떤 변수라도 조건문에
사용할 수 있다. 아라치는 SetEnvIf나 다른 관련
지시어로 환경변수를 설정할 수 있기때문에 CGI 없이도 멋지게
동적인 내용을 만들 수 있다.
SSI는 확실히 CGI나 동적인 웹페이지를 생성하는 다른 기술을 대체할 수 없다. 그러나 많은 추가 작업없이 페이지에 동적인 내용을 조금 추가하기에는 훌륭한 방법이다.
�쀾菩 �� �^肥�m��180r �2�c�(�9-�/Cx�$"P0R��?:L m핅�->�0롦曉�#{�%炯L�'”j妬�뱷�F왽N泌\�@績>�Kn ?�0 믜2S#뀕P=
N�@�(02+춗< L 쳐k칠dW�曼=yQM�& 쬒츏拂� �bm鈴-忿
贇m�B�委=�귧谷a�=_�荑�a剖� 믟V�7G促쩭힡`W�^:1�뜤� )뀕:}T棧�h딵�싊0吊� �I�p궣l9귁蓑� �^�修傳紘�,�.武,逑��[!�@UuHOFSr쎺�]0��7*均伎��X룲&�7넕�-陝쎧赳欠�껿뭣�"뒃9�!�B J롧풝���M� 9�▶?K-D)쪚t艱爪뇚츟�@)걝j�0e�&`Q �U 촎띧i랻尨8G�n�W륋Y��[机]机.��=姆 롬륰~5�C,$#G빳cK搔셾��9㈇A�@ Apache HTTP Server Version 2.0 Apache HTTP Server Version 2.0 이 문서는 유닉스와 유닉스류 시스템에서 아파치를 컴파일하고
설치하는 것만을 다룬다. 윈도우즈에서 컴파일하고 설치하는 방법은
마이크로소프트 윈도우즈에서
아파치 사용을 참고하라. 다른 플래폼에 대해서는 플래폼 문서를 참고하라. 아파치 2.0의 구성과 설치 환경은 1.3과 매우 다르다.
아파치 1.3은 쉬운 설치를 위해 자체 스크립트를 사용했다.
아파치 2.0은 이제 다른 여러 오픈소스 프로젝트와 비슷한 환경을
만들기위해 만약 작은 버전을 한단계 업그레이드한다면 (예를 들어,
2.0.50에서 2.0.51), 업그레이드
장으로 바로 가길 바란다. NN은 현재 작은 버전 숫자로, PREFIX는
서버가 설치될 파일시스템 경로로 대체해야 한다. PREFIX를
지정하지 않으면 기본값으로 아래는 아파치 웹서버를 컴파일하고 설치하기위한 요구사항부터
컴파일과 설치 과정을 각각 자세히 설명한다. 아파치를 컴파일하기위해 다음과 같은 것들이 필요하다: 아파치는 여러 미러 목록이 있는 아파치 웹서버
다운로드 사이트에서 다운로드할 수 있다. 유닉스류 시스템을
사용한다면 소스코드를 다운받아서 컴파일하는 편이 낫다. 쉽게
(아래에서 설명) 컴파일할 수 있고, 자신의 용도에 알맞게 서버를
맞출 수 있다. 또, 최신 버전 바이너리 배포본이 없는 경우도
많다. 바이너리를 다운받는다면 배포본에 있는
다운로드후 다운받은 파일이 완전하고
변경되지않은 아파치 웹서버임을 확인하는 것이 중요하다.
PGP 서명을 가지고 다운로드한 타볼(tarball)을 검사하여 확인한다.
자세한 방법은 다운로드
페이지에 있고, PGP
사용법을 설명하는 상세한 예도 있다. 아파치 웹서버 타볼에서 소스를 푸는 작업은 단순히 압축과
tar를 푸는 것이다: 그러면 현재 디렉토리 아래에 배포본의 소스코드를 담은
새로운 디렉토리가 생긴다. 서버를 컴파일하기 전에 그
디렉토리로 다음 과정은 특정 플래폼과 개인적인 필요에 따라 아파치
소스 트리를 구성하는 일이다. 이를 위해 배포본의 최상위 디렉토리에
있는 모두 기본 옵션을 사용하여 소스 트리를 구성하려면 간단히
가장 중요한 옵션은 아파치가 정상적으로 작동하기위해 아파치를
구성하고 설치할 장소인 모듈을 포함하거나 빼서 아파치에 포함할
기능을
선택한다. Base
상태인 모듈은 기본적으로 아파치에 포함된다. 다른 상태의
모듈은 가끔 여러분이 선택할 수 있는 가능성을 보여주기위해 다음은
특정 컴파일러와 플래그를 사용하고 나중에 DSO로 읽어들일
두 모듈 이제 다음 명령어 하나로 아파치의 여러 부분을 컴파일할
수 있다: 여기서 좀 기다려라. 펜티엄 III/리눅스 2.2 시스템에서
기본 구성을 컴파일하는데 약 3분 정도 걸린다. 이 시간은
하드웨어와 포함한 모듈수에 따라 크게 변한다. 이제 다음 명령어로 패키지를 (위의 업그레이드한다면 이 설치 과정이 기존 설정파일이나 문서를
덮어쓰지 않는다. 다음으로 사용가능한 설정 지시어에
대한 완전한 설명과 이 문서의 가장 최근 판은 docs/manual/이나 http://httpd.apache.org/docs/2.0/에 있는 아파치 설명서를
참고하라. 이제 다음과 같이 아파치 웹서버를 시작할 수 있다: 그리고 URL 업그레이드한다면 먼저 사이트에 영향을 줄 수 있는 변화가
있는지 알아보기위해 발표문과 소스 배포본의 작은 버전을 한단계 업그레이드하는 것은 (예를 들어,
2.0.55에서 2.0.57) 쉽다. 이전에 설치했던 소스를 가지고 있다면, 업그레이드가 더
쉬워진다. 이전 소스 최상위에 있는 Apache HTTP Server Version 2.0 보통 아파치는 Windows NT, 2000, XP에서는 서비스로,
Windows 95과 ME에서는 콘솔 프로그램으로 실행된다. 자세한
내용은 서비스로
아파치를 실행하기와 콘솔 프로그램으로
아파치를 실행하기. 유닉스에서 httpd
프로그램은 백그라운드에서 계속 요청을 처리하는 데몬으로
실행된다. 이 문서는 설정파일에서 apachectl
스크립트를 사용하여 시작하는 과정에서 문제가 없다면, 서버는 터미널에서
떨어지고 명령 프롬프트가 거의 즉시 나오게된다. 이는 서버가
실행됨을 의미한다. 브라우저로 서버에 연결하여 아파치가 시작하는 과정중에 심각한 문제가 발생하면,
종료하기 전에 문제를 알리는 문구를 콘솔이나 기타 문제해결 방법은 아파치 FAQ를
참고하라. 시스템이 재시작한 후에도 서버가 계속 실행되길 바란다면,
시스템 시작파일(보통 Apache HTTP Server Version 2.0 Apache License "License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files. "Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work. You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your
work. To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives. Apache HTTP Server Version 2.0 효율적으로 웹서버를 관리하려면 발생하는 문제와 함께 서버의
활동과 성능에 대해 알아야 한다. 아파치 웹서버는 매우 종합적이고
유연한 로그 기능을 제공한다. 이 문서는 로그 기능을 설정하는
방법과 로그에 들어갈 내용을 설명한다. 누군가에게 아파치의 로그파일이 있는 디렉토리에 쓰기권한이
있다면 (보통 root) 서버를 실행하는 uid를 거의 확실히 얻을
수 있다. 이를 고려하지않고 로그가 저장된 디렉토리에 쓰기권한을
주지 마라. 자세한 내용은 보안 팁 문서를 참고하라. 또, 클라이언트가 제공한 정보는 로그파일에 거의 그대로
기록된다. 그래서 악의가 있는 클라이언트가 로그파일에 제어문자를
넣을 수 있으므로, 로그를 다룰때는 주의해야 한다. 오류 로그는 보통 (전형적으로 유닉스 시스템에서는
오류 로그의 형식은 상대적으로 자유롭고 자세하다. 그러나
대부분의 오류 로그 항목에 공통적으로 나오는 정보가 있다.
예를 들어, 항목은 보통 다음과 같다. 로그 항목에서 첫번째 항목은 날짜와 시간이다. 두번째
항목은 보고하는 오류의 심각성을 나타낸다. 오류 로그에는 매우 다양한 종류의 문구가 나올 수 있다.
대부분은 위와 비슷하다. CGI 스크립트의 디버깅 출력도 오류
로그에 기록된다. CGI 스크립트가 오류 로그에 정보를 추가하가나 생략할 수 없다. 그러나
요청에 대한 오류 로그의 경우 접근
로그에도 대응하는 항목이 생긴다. 예를 들어, 위의 경우
상태코드가 403인 접근 로그 항목이 생긴다. 접근 로그는
사용자정의할 수 있으므로 이 파일을 참고하여 오류 상황에
대한 추가정보를 얻을 수 있다. 검사할때 어떤 문제가 생기는지 오류 로그를 계속 살펴보는
것이 좋다. 유닉스 시스템에서 다음과 같이 한다: 서버 접근 로그는 서버가 처리하는 모든 요청을 기록한다.
물론 접근 로그에 정보를 기록하는 것은 로그 관리의 시작일
뿐이다. 다음 단계는 이 정보를 분석하여 유용한 통계를 만드는
것이다. 이 문서는 일반적인 로그 분석에 대해서 다루지 않으며,
로그 분석은 실제 웹서버가 할 일이 아니다. 로그 분석에 대한
정보와 로그를 분석하는 소프트웨어에 대해서는 Open Directory나
Yahoo를
참고하라. 아파치 웹서버는 이전부터 mod_log_referer, mod_log_agent,
접근 로그의 형식은 매우 사용자정의 가능하다. 형식은 C의
printf(1) 형식문자열과 매우 유사한 형식문자열을 사용하여
지정한다. 다음 절에 예를 들었다. 형식문자열에 사용가능한
모든 내용을 알려면 접근 로그의 전형적인 설정은 다음과 같다. 그러면 지정한 로그 형식문자열을 별명
앞의 설정은 공통로그형식(Common Log Format, CLF)이라는
형식으로 로그 항목을 기록한다. 여러 다른 웹서버들도 이런
표준 형식으로 로그를 만들며, 여러 로그 분석 프로그램에서
읽을 수 있다. CLF로 만든 로그파일 항목은 다음과 같다: 이제 로그 항목의 각 부분을 설명한다.
자주 사용되는 다른 형식문자열은 결합된로그형식(Combined
Log Format)이다. 다음과 같이 사용한다. 이 형식은 두 항목을 더 추가한 것을 제외하고는 Common
로그 형식과 완전히 같다. 추가된 항목들은 퍼센트 지시어
추가된 항목은: 설정파일에 여러 또, 이 예는 클라이언트 요청의 성격에 따라 해당 항목을 접근 로그에
기록하지않고 싶을 때가 있다. 환경변수를
사용하면 쉽게 해결된다. 먼저, 클라이언트가 특정 조건을
만족하면 환경변수를 설정한다. 이 작업에는 보통 다른 예로 영어권 사용자의 요청만을 한 로그파일에 기록하고,
비영어권 사용자의 요청은 다른 로그파일에 기록하는 경우를
생각해보자. 조건부 로그는 매우 강력하고 유연하지만, 이것이 로그
내용을 조절하는 유일한 방법은 아니다. 로그파일은 서버의
모든 행동을 기록할때 더 유용하다. 나중에 원하지않는 요청을
제외하고 로그파일을 분석하는 것이 더 쉽다. 조금 바쁜 서버조차도 로그파일에 저장되는 정보량은 매우
많다. 접속 로그는 보통 만번 요청당 1MB 이상 증가한다. 결과적으로
기존의 로그를 옮기거나 지우는 방법으로 로그를 주기적으로
순활할 필요가 있다. 아파치는 파일을 열고있는 동안에는 계속
이전 로그파일에 쓰기때문에 서버가 실행중일때 로그를 순환할
수 없다. 대신 로그파일을 옮기거나 지운후 서버를 재시작하여, 로그파일을 새로 열어야
한다. 점잖은 재시작을 사용하면 서버는 클라이언트와
기존의 혹은 대기된 연결을 잃지않고 새 로그파일을 열 수 있다.
그러나 이를 위해 서버는 오래된 요청의 서비스를 끝내는 동안
이전 로그파일을 계속 사용해야 한다. 그러므로 재시작한후
로그파일을 처리하기 전에 얼마간 기다릴 필요가 있다. 일반적으로
다음과 같이 로그를 순환하고, 디스크공간을 절약하기위해 이전
로그를 압축한다: 로그를 순환하는 다른 방법은 다음 절에서 설명할 파이프 로그를 사용하는 것이다. 아파치 웹서버는 오류 로그와 접근 로그를 파일에 직접
쓰지않고 파이프를 통해 다른 프로세스로 보낼 수 있다. 이
기능을 사용하면 서버에 코드를 추가하지않고도 매우 유연하게
로그를 처리할 수 있다. 로그를 파이프에 쓰기위해 파일명
자리에 파이프문자 " 파이프로 연결된 로그 프로세스는 부모 아파치 httpd 프로세스가
띄우고, 프로세스의 userid도 같다. 즉, 파이프로 연결된 로그
프로그램은 보통 root로 실행된다. 그러므로 프로그램을 간단하고
안전하게 만드는 것이 매우 중요하다. 파이프로 부르는 전체 명령어를 따옴표로 묶음을 명심하라.
이 예는 접근 로그에 대한 것이지만, 오류 로그도 마찬가지다. 서버를 재시작하지않고 로그를 순환할 수 있는 것이 파이프
로그를 사용하는 중요한 이유다. 아파치 웹서버는 이를 위해
rotatelogs라는 간단한
프로그램을 포함한다. 예를 들어 24시간마다 로그를 순환한다면: 다른 사이트에 cronolog라는 비슷하지만
훨씬 더 유연한 로그 순환 프로그램이 있다. 조건부 로그와 같이 파이프 로그는 매우 강력한 도구지만,
나중에 처리하는 등의 더 간단한 방법이 가능한 경우 사용해서는
안된다. 많은 가상호스트가 있는 서버를
운영할때 여러가지 방법으로 로그파일을 다룰 수 있다. 먼저,
호스트가 한개인 서버와 같이 로그를 사용할 수 있다. 접근 로그의 경우 매우 좋은 해결책이 있다. 로그 형식문자열에
가상호스트에 대한 정보를 추가하면 모든 호스트가 같은 로그를
사용하고, 나중에 로그를 가상호스트별로 나눌 수 있다. 예를
들어, 다음 지시어를 봐라. 아파치 웹서버는 시작할때 디버깅을 돕기위해 mod_rewrite의 강력하고
복잡한 기능을 사용한다면 디버깅을 위해 거의 항상 Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. This document describes an easy way to provide your Apache
HTTP Server with a set of customized error messages which take
advantage of Content
Negotiation and By using SSI, all Error documents can be shared across different servers, or
even hosts, because all varying information is inserted at the
time the error document is returned on behalf of a failed
request. Content Negotiation then selects the appropriate language
version of a particular error message text, honoring the
language preferences passed in the client's request. (Users
usually select their favorite languages in the preferences
options menu of today's browsers). When an error document in
the client's primary language version is unavailable, the
secondary languages are tried or a default (fallback) version
is used. You have full flexibility in designing your error documents
to your personal taste (or your company's conventions). For
demonstration purposes, we present a simple generic error
document scheme. For this hypothetic server, we assume that all
error messages... An example of a "document not found" message for a german
client might look like this: All links in the document as well as links to the server's
administrator mail address, and even the name and port of the
serving virtual host are inserted in the error document at
"run-time", i.e., when the error actually occurs. For this concept to work as easily as possible, we must take
advantage of as much server support as we can get: The resulting The directory for the error messages (here:
By defining the The names of the individual error documents are now
determined like this (I'm using 403 as an example, think of it
as a placeholder for any of the configured error
documents): By putting as much layout information in two special "include
files", the error documents can be reduced to a bare minimum. One of these layout files defines the HTML document header
and a configurable list of paths to the icons to be shown in
the resulting error document. These paths are exported as a set
of SSI environment variables and are later evaluated by the
"footer" special file. The title of the current error (which is
put into the TITLE tag and an H1 header) is simply passed in
from the main error document in a variable called
By changing this file, the layout of all generated
error messages can be changed in a second. (By
exploiting the features of SSI, you can easily define
different layouts based on the current virtual host, or even
based on the client's domain name). The second layout file describes the footer to be displayed
at the bottom of every error message. In this example, it shows
an apache logo, the current server time, the server version
string and adds a mail reference to the site's webmaster. For simplicity, the header file is simply called
Both files are included into the error document by using the
directives See the listings below to see an
actual HTML implementation of the discussed example. After all this preparation work, little remains to be said
about the actual documents. They all share a simple common
structure: In the listings section, you can see an
example of a [400 Bad Request] error document. Documents as
simple as that certainly cause no problems to translate or
expand. Do we need a special handling for languages other than those we
have translations for? We did set the LanguagePriority, didn't
we?! Well, the LanguagePriority directive is for the case where
the client does not express any language priority at all. But
what happens in the situation where the client wants one of the
languages we do not have, and none of those we do have? Without doing anything, the Apache server will usually
return a [406 no acceptable variant] error, listing the choices
from which the client may select. But we're in an error message
already, and important error information might get lost when
the client had to choose a language representation first. So, in this situation it appears to be easier to define a
fallback language (by copying or linking, e.g., the
english version to a language-less version). Because the
negotiation algorithm prefers "more specialized" variants over
"more generic" variants, these generic alternatives will only
be chosen when the normal negotiation did not succeed. A simple shell script to do it (execute within the
errordocs/ dir): As of Apache-1.3, it is possible to use the
Most proxy errors return an error code of [500 Internal
Server Error]. To find out whether a particular error document
was invoked on behalf of a proxy error or because of some other
server error, and what the reason for the failure was, you can
check the contents of the new The following excerpt demonstrates how to exploit the
So, to summarize our example, here's the complete listing of
the Here is the complete for browser types which support animated GIFs). and this is the If you have tips to contribute, send mail to martin@apache.org Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. A descriptor, also commonly called a file
handle is an object that a program uses to read or write
an open file, or open network socket, or a variety of other
devices. It is represented by an integer, and you may be
familiar with The operating system enforces a limit on the number of
descriptors that a program can have open at a time. There are
typically three limits involved here. One is a kernel
limitation, depending on your operating system you will either
be able to tune the number of descriptors available to higher
numbers (this is frequently called FD_SETSIZE). Or you
may be stuck with a (relatively) low amount. The second limit
is called the hard resource limit, and it is sometimes
set by root in an obscure operating system file, but frequently
is the same as the kernel limit. The third limit is called the
soft resource limit. The soft limit is always less
than or equal to the hard limit. For example, the hard limit
may be 1024, but the soft limit only 64. Any user can raise
their soft limit up to the hard limit. Root can raise the hard
limit up to the system maximum limit. The soft limit is the
actual limit that is used when enforcing the maximum number of
files a process can have open. To summarize: You control the hard and soft limits using the
Unfortunately, it's not always this simple. As mentioned
above, you will probably run into some system limitations that
will need to be worked around somehow. Work was done in version
1.2.1 to improve the situation somewhat. Here is a partial list
of systems and workarounds (assuming you are using 1.2.1 or
later). Under BSDI 2.0 you can build Apache to support more
descriptors by adding Similar to the BSDI 2.0 case, you should define
By default Linux has a kernel maximum of 256 open
descriptors per process. There are several patches available
for the 2.0.x series which raise this to 1024 and beyond, and
you can find them in the "unofficial patches" section of the Linux Information HQ.
None of these patches are perfect, and an entirely different
approach is likely to be taken during the 2.1.x development.
Applying these patches will raise the FD_SETSIZE used to
compile all programs, and unless you rebuild all your
libraries you should avoid running any other program with a
soft descriptor limit above 256. As of this writing the
patches available for increasing the number of descriptors do
not take this into account. On a dedicated webserver you
probably won't run into trouble. Solaris has a kernel hard limit of 1024 (may be lower in
earlier versions). But it has a limitation that files using
the stdio library cannot have a descriptor above 255. Apache
uses the stdio library for the ErrorLog directive. When you
have more than approximately 110 virtual hosts (with an error
log and an access log each) you will need to build Apache
with AIX version 3.2?? appears to have a hard limit of 128
descriptors. End of story. Version 4.1.5 has a hard limit of
2000. Edit the If you have details on another operating system, please
submit it through our Bug Report
Page. In addition to the problems described above there are
problems with many libraries that Apache uses. The most common
example is the bind DNS resolver library that is used by pretty
much every unix, which fails if it ends up with a descriptor
above 256. We suspect there are other libraries that similar
limitations. So the code as of 1.2.1 takes a defensive stance
and tries to save descriptors less than 16 for use while
processing each request. This is called the low slack
line. Note that this shouldn't waste descriptors. If you really
are pushing the limits and Apache can't get a descriptor above
16 when it wants it, it will settle for one below 16. In extreme situations you may want to lower the low slack
line, but you shouldn't ever need to. For example, lowering it
can increase the limits 240 described above under Solaris and
BSDI 2.0. But you'll play a delicate balancing game with the
descriptors needed to serve a request. Should you want to play
this game, the compile time parameter is
Finally, if you suspect that all this slack stuff is causing
you problems, you can disable it. Add Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. Starting with the Apache 1.2 betas, people are reporting
many more connections in the FIN_WAIT_2 state (as reported
by The FIN_WAIT_2 state is somewhat unusual in that there
is no timeout defined in the standard for it. This means
that on many operating systems, a connection in the
FIN_WAIT_2 state will stay around until the system is
rebooted. If the system does not have a timeout and too
many FIN_WAIT_2 connections build up, it can fill up the
space allocated for storing information about the
connections and crash the kernel. The connections in
FIN_WAIT_2 do not tie up an httpd process. There are numerous reasons for it happening, some of them
may not yet be fully clear. What is known follows. Several clients have a bug which pops up when dealing with
persistent connections (aka
keepalives). When the connection is idle and the server
closes the connection (based on the If you are lucky, this means that the buggy client will
fully close the connection and release the resources on
your server. However, there are some cases where the socket
is never fully closed, such as a dialup client
disconnecting from their provider before closing the
client. In addition, a client might sit idle for days
without making another connection, and thus may hold its
end of the socket open for days even though it has no
further use for it. This is a bug in the browser or
in its operating system's TCP implementation. The clients on which this problem has been verified to
exist: This does not appear to be a problem on: It is expected that many other clients have the same
problem. What a client should do is
periodically check its open socket(s) to see if they have
been closed by the server, and close their side of the
connection if the server has closed. This check need only
occur once every few seconds, and may even be detected by a
OS signal on some systems (e.g., Win95 and NT
clients have this capability, but they seem to be ignoring
it). Apache cannot avoid these FIN_WAIT_2
states unless it disables persistent connections for the
buggy clients, just like we recommend doing for Navigator
2.x clients due to other bugs. However, non-persistent
connections increase the total number of connections needed
per client and slow retrieval of an image-laden web page.
Since non-persistent connections have their own resource
consumptions and a short waiting period after each closure,
a busy server may need persistence in order to best serve
its clients. As far as we know, the client-caused FIN_WAIT_2 problem
is present for all servers that support persistent
connections, including Apache 1.1.x and 1.2. While the above bug is a problem, it is not the whole
problem. Some users have observed no FIN_WAIT_2 problems
with Apache 1.1.x, but with 1.2b enough connections build
up in the FIN_WAIT_2 state to crash their server. The most
likely source for additional FIN_WAIT_2 states is a
function called The code in There are several possible workarounds to the problem, some
of which work better than others. The obvious workaround is to simply have a timeout for the
FIN_WAIT_2 state. This is not specified by the RFC, and
could be claimed to be a violation of the RFC, but it is
widely recognized as being necessary. The following systems
are known to have a timeout: The following systems are known to not have a
timeout: There is a
patch available for adding a timeout to the FIN_WAIT_2
state; it was originally intended for BSD/OS, but should be
adaptable to most systems using BSD networking code. You
need kernel source code to be able to use it. It is possible to compile Apache 1.2 without using the
To compile without the On most systems, there is an option called
To try it, add The exact way to increase them may depend on your
OS; look for some reference to the number of "mbufs" or
"mbuf clusters". On many systems, this can be done by
adding the line If you are unable to do any of the above then you
should, as a last resort, disable KeepAlive. Edit your
httpd.conf and change "KeepAlive On" to "KeepAlive
Off". Below is a message from Roy Fielding, one of the authors
of HTTP/1.1. The need for a server to linger on a socket after a close
is noted a couple times in the HTTP specs, but not
explained. This explanation is based on discussions between
myself, Henrik Frystyk, Robert S. Thau, Dave Raggett, and
John C. Mallery in the hallways of MIT while I was at W3C. If a server closes the input side of the connection
while the client is sending data (or is planning to send
data), then the server's TCP stack will signal an RST
(reset) back to the client. Upon receipt of the RST, the
client will flush its own incoming TCP buffer back to the
un-ACKed packet indicated by the RST packet argument. If
the server has sent a message, usually an error response,
to the client just before the close, and the client
receives the RST packet before its application code has
read the error message from its incoming TCP buffer and
before the server has received the ACK sent by the client
upon receipt of that buffer, then the RST will flush the
error message before the client application has a chance to
see it. The result is that the client is left thinking that
the connection failed for no apparent reason. There are two conditions under which this is likely to
occur: The solution in all cases is to send the response, close
only the write half of the connection (what shutdown is
supposed to do), and continue reading on the socket until
it is either closed by the client (signifying it has
finally read the response) or a timeout occurs. That is
what the kernel is supposed to do if SO_LINGER is set.
Unfortunately, SO_LINGER has no effect on some systems; on
some other systems, it does not have its own timeout and
thus the TCP memory segments just pile-up until the next
reboot (planned or not). Please note that simply removing the linger code will
not solve the problem -- it only moves it to a different
and much harder one to detect. Apache HTTP Server Version 2.0 Below is a list of additional documentation pages that apply
to the Apache web server development project. Some of the documents below have not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. Describes a solution which uses XSSI and negotiation to
custom-tailor the Apache ErrorDocuments to taste, adding the
advantage of returning internationalized versions of the
error messages depending on the client's language
preferences. Describes how Apache uses file descriptors and talks
about various limits imposed on the number of descriptors
available by various operating systems. A description of the causes of Apache processes going
into the A list of problems in HTTP clients which can be mitigated
by Apache. Notes about how to (run-time and compile-time) configure
Apache for highest performance. Notes explaining why Apache
does some things, and why it doesn't do other things (which
make it slower/faster). Some "do"s - and "don't"s - for keeping your Apache web
site secure. This document supplements the A list of external resources which help to accomplish common
tasks with the Apache HTTP server. This document acts as a reference page for most of the relevant
standards that Apache follows. Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. Over time the Apache Group has discovered or been notified
of problems with various clients which we have had to work
around, or explain. This document describes these problems and
the workarounds available. It's not arranged in any particular
order. Some familiarity with the standards is assumed, but not
necessary. For brevity, Navigator will refer to Netscape's
Navigator product (which in later versions was renamed
"Communicator" and various other names), and MSIE will
refer to Microsoft's Internet Explorer product. All trademarks
and copyrights belong to their respective companies. We welcome
input from the various client authors to correct
inconsistencies in this paper, or to provide us with exact
version numbers where things are broken/fixed. For reference, RFC1945
defines HTTP/1.0, and RFC2068
defines HTTP/1.1. Apache as of version 1.2 is an HTTP/1.1
server (with an optional HTTP/1.0 proxy). Various of these workarounds are triggered by environment
variables. The admin typically controls which are set, and for
which clients, by using This is a legacy issue. The CERN webserver required
Various clients have had broken implementations of
keepalive (persistent connections). In particular the
Windows versions of Navigator 2.0 get very confused when the
server times out an idle connection. The workaround is present
in the default config files: Note that this matches some earlier versions of MSIE, which
began the practice of calling themselves Mozilla in
their user-agent strings just like Navigator. MSIE 4.0b2, which claims to support HTTP/1.1, does not
properly support keepalive when it is used on 301 or 302
(redirect) responses. Unfortunately Apache's
To quote from section 3.1 of RFC1945: Since Apache is an HTTP/1.1 server, it indicates so as part of
its response. Many client authors mistakenly treat this part of
the response as an indication of the protocol that the response
is in, and then refuse to accept the response. The first major indication of this problem was with AOL's
proxy servers. When Apache 1.2 went into beta it was the first
wide-spread HTTP/1.1 server. After some discussion, AOL fixed
their proxies. In anticipation of similar problems, the
The pre-1.1 Java Development Kit (JDK) that is used in many
clients (including Navigator 3.x and MSIE 3.x) exhibits this
problem. As do some of the early pre-releases of the 1.1 JDK.
We think it is fixed in the 1.1 JDK release. In any event the
workaround: RealPlayer 4.0 from Progressive Networks also exhibits this
problem. However they have fixed it in version 4.01 of the
player, but version 4.01 uses the same MSIE 4.0b2 has this problem. Its Java VM makes requests in
HTTP/1.1 format but the responses must be in HTTP/1.0 format
(in particular, it does not understand chunked
responses). The workaround is to fool Apache into believing the
request came in HTTP/1.0 format. This workaround is available in 1.2.2, and in a
patch against 1.2.1. All versions of Navigator from 2.0 through 4.0b2 (and
possibly later) have a problem if the trailing CRLF of the
response header starts at offset 256, 257 or 258 of the
response. A BrowserMatch for this would match on nearly every
hit, so the workaround is enabled automatically on all
responses. The workaround implemented detects when this
condition would occur in a response and adds extra padding to
the header to push the trailing CRLF past offset 258 of the
response. On multipart responses some clients will not accept quotes
(") around the boundary string. The MIME standard recommends
that such quotes be used. But the clients were probably written
based on one of the examples in RFC2068, which does not include
quotes. Apache does not include quotes on its boundary strings
to workaround this problem. A byterange request is used when the client wishes to
retrieve a portion of an object, not necessarily the entire
object. There was a very old draft which included these
byteranges in the URL. Old clients such as Navigator 2.0b1 and
MSIE 3.0 for the MAC exhibit this behaviour, and it will appear
in the servers' access logs as (failed) attempts to retrieve a
URL with a trailing ";xxx-yyy". Apache does not attempt to
implement this at all. A subsequent draft of this standard defines a header
Navigator (versions 2 and 3) sends both The Adobe Acrobat Reader plugin makes extensive use of
byteranges and prior to version 3.01 supports only the
Netscape Communicator appears to not issue the non-standard
The HTTP specifications say that it is legal to merge
headers with duplicate names into one (separated by commas).
Some browsers that support Cookies don't like merged headers
and prefer that each Navigator versions 2 through 4 will erroneously re-request
GIF89A animations on each loop of the animation if the first
response included an In certain situations Navigator 3.01 through 3.03 appear to
incorrectly issue a POST without the request body. There is no
known workaround. It has been fixed in Navigator 3.04,
Netscapes provides some information.
There's also
some information about the actual problem. The http client in the JDK1.2beta2 and beta3 will throw away
the first part of the response body when both the headers and
the first part of the body are sent in the same network packet
AND keep-alive's are being used. If either condition is not met
then it works fine. See also Bug-ID's 4124329 and 4125538 at the java developer
connection. If you are seeing this bug yourself, you can add the
following BrowserMatch directive to work around it: We don't advocate this though since bending over backwards
for beta software is usually not a good idea; ideally it gets
fixed, new betas or a final release comes out, and no one uses
the broken old software anymore. In theory. Navigator (all versions?) will cache the
MSIE versions 3.00 and 3.02 (without the Y2K patch) do not
handle cookie expiry dates in the year 2000 properly. Years
after 2000 and before 2000 work fine. This is fixed in IE4.01
service pack 1, and in the Y2K patch for IE3.02. Users should
avoid using expiry dates in the year 2000. The Lynx browser versions 2.7 and 2.8 send a "negotiate:
trans" header in their requests, which is an indication the
browser supports transparent content negotiation (TCN). However
the browser does not support TCN. As of version 1.3.4, Apache
supports TCN, and this causes problems with these versions of
Lynx. As a workaround future versions of Apache will ignore
this header when sent by the Lynx client. MSIE 4.0 does not handle a Vary header properly. The Vary
header is generated by mod_rewrite in apache 1.3. The result is
an error from MSIE saying it cannot download the requested
file. There are more details in PR#4118. A workaround is to add the following to your server's
configuration files: (This workaround is only available with releases
after 1.3.6 of the Apache Web server.) Apache HTTP Server Version 2.0 아파치 2.0은 기능과 포팅가능성과 성능의 균형이 맞도록
설계한 범용 웹서버이다. 벤치마크 기록을 세우기위해 설계하지
않았지만 아파치 2.0은 실제 많은 경우 높은 성능을 낸다. 아파치 1.3과 비교해서 2.0 버전은 처리량과 확장성(scalability)을
높이기위해 많은 최적화를 했다. 기본값으로 대부분 최적화한
값을 사용한다. 그러나 컴파일시 혹은 실행시 설정이 성능에
큰 영향을 줄 수 있다. 이 문서는 아파치 2.0의 성능을 향상하기위해
서버 관리자가 설정할 수 있는 옵션을 설명한다. 어떤 설정
옵션은 웹서버가 하드웨어와 운영체제의 기능을 더 잘 활용하도록
하는 반면, 어떤 옵션은 속도를 위해 기능을 희생한다. 웹서버 성능에 가장 큰 영향을 주는 것은 메모리다. 스왑은
요청당 지연시간을 사용자가 "충분히 빠르다고" 생각하지 못하게
늘리기때문에 웹서버는 스왑을 하면 안된다. 느려지면 사용자는
정지하고 다시 접속하여 부하가 계속 증가한다. 나머지는 평범하다: 충분히 빠른 CPU, 충분히 빠른 네트웍카드,
충분히 빠른 디스크, 여기서 "충분히 빠른"은 실험을 해서 결정해야
한다. 운영체제는 보통 각자 알아서 선택할 일이다. 그러나 일반적으로
유용하다고 판명된 몇가지 지침이 있다: 선택한 운영체제의 최신 안정 버전과 패치를 실행한다.
많은 운영체제 제작사는 최근 TCP 스택과 쓰레드 라이브러리에
많은 속도향상을 했다. 운영체제가 아파치 1.3 이전에 로그처리 작업이 서버 성능에 악영향을 미치므로 실제
사용하는 웹서버가 아닌 다른 컴퓨터에서 로그파일을 후처리하길
바란다. 그러나 CGI에서 DNS명이 필요할 뿐이라면, 필요한 특정
CGI에서만 URL 공간에서 이 경우 최소한 URL 공간에서 overrides를 허용한다면 (보통
가능하고 진짜 조금의 성능향상에도 관심이 있다면 내용협상을
막는다. 실제로 협상의 이득은 성능저하보다 작다. 서버를
빠르게 할 수 있다. 다음과 같이 와일드카드를 사용하는 대신: 완전한 목록을 사용한다: 가장 흔한 것을 앞에 둔다. 또, 디렉토리에서 파일들을 찾는 사이트에 내용협상이 필요하다면 협상을 위해 예를 들어, server-side-include를 처리하는 등 아파치
2.0이 전송할 파일을 읽을때 운영체제가 여러 플래폼에서 메모리대응을 성능을 향상한다. 그러나
메모리대응이 서버의 성능을 떨어트리고 심지어 안정성을
해치는 경우가 있다: 어떤 운영체제에서 NFS 마운트한 파일시스템에 있는 파일을 메모리대응하는
도중에 다른 NFS 클라이언트에 있는 프로세스가 파일을
지우거나 파일크기를 줄이면, 웹서버 프로세스가 다음
번에 메모리대응한 파일내용을 읽을때 bus error가 발생할
수 있다. 위의 조건에 해당하면 전송하는 파일을 메모리대응하지
않도록 아파치는 운영체제가 여러 플래폼에서 sendfile을 사용하면 read와 send를 따로
할 필요가 없어서 빨라진다. 그러나 sendfile을 사용하면
웹서버의 안정성을 해치게되는 경우가 있다: sendfile 지원이 잘못되었고 컴파일 시스템이 이점을
발견하지 못하는 플래폼이 있다. 특히 다른 컴퓨터에서
실행파일을 컴파일하여 sendfile 지원이 잘못된 컴퓨터로
가져온 경우에 가능하다. 커널은 자신의 캐쉬를 사용하여 NFS로 마운트한 파일을
안정적으로 서비스할 수 없는 경우가 있다. 위의 조건에 해당하면 파일을 sendfile 전송하지 않도록
아파치 1.3 이전에는 초당 한개 규칙은 자식을 새로 시작하면서 서버에 무리를
주지 않으려고 정했다. 컴퓨터가 자식을 시작하느라 바쁘면
요청을 서비스할 수 없다. 그러나 이 규칙이 아파치의 체감
성능에 악영향을 주어 변경하였다. 아파치 1.3에서 초당 한개
규칙은 완화되었다. 코드는 자식 한개를 만들고, 1초 쉬고,
두개를 만들고, 1초 쉬고, 네개를 만들고, 이런 식으로 초당
자식을 32개 만들때까지 지수로 증가한다. 자식수가 이 경우 반응속도가 빨라져서 프로세스 생성과 관련하여 연결유지(keep-alive)를 사용한다면 자식들은 이미 열린
연결에서 추가 요청을 기다리며 아무것도 하지않기때문에 계속
바쁘다. 아파치 2.x는 다중처리모듈
(MPMs)이라는 교체할 수 있는 동기화 모델을 지원한다. 아파치를
컴파일할때 MPM을 선택해야 한다. 이 MPM들과 다른 MPM에 대해 더 자세한 정보는 MPM 문서를 참고하길 바란다. 메모리 사용량이 성능에서 가장 중요한 요인이기때문에
실제로 사용하지 않는 모듈을 제거해보자. 모듈을 DSO로 컴파일했다면 간단히 그
모듈에 대한 반대로 모듈이 아파치 실행파일에 정적으로 링크되있다면
원하지 않는 모듈을 제거하기위해 아파치를 재컴파일해야
한다. 여기서 당연히 어떤 모듈을 사용하고 사용하지 말지
의문이 생긴다. 정답은 웹사이트마다 다르다. 그러나 아마도
최소한 기본적으로 APR은 각 운영체제/CPU 플래폼에서 가장 효율적인
방법을 사용하여 이 명령을 구현한다. 예를 들어, 여러 최신
CPU에는 하드웨어로 atomic compare-and-swap (CAS) 연산을
하는 명령어가 있다. 그러나 어떤 플래폼에서 APR은 이런
명령어가 없는 오래된 CPU와 호환성을 위해 더 느린 mutex기반
구현을 기본적으로 사용한다. 이런 플래폼에서 아파치를
컴파일할때 아파치를 최신 CPU에서만 실행할 계획이라면,
아파치를 구성할때 아파치를 컴파일할때 아래 문서는 아파치 웹서버 2.0 버전에서 변경된 내용을
담고 있지 않다. 아직도 유효한 정보가 있지만, 주의해서
사용하길 바란다. 유닉스 소켓 API의 단점을 설명한다. 웹서버가 여러 포트
혹은 여러 주소를 기다리기위해 여러 그러나 위의 단순한 구현에는 심각한 고갈(starvation)
문제가 있다. 여러 자식이 동시에 이 반복문을 실행하면,
요청을 기다리며 모두 한가지는 소켓을 대기하지 않도록 (non-blocking) 만드는
방법이다. 이 경우 자식이 다른 방법은 아파치가 사용하는 방법으로 내부 반복문에
한 자식만을 들여보낸다. 반복문은 다음과 같다 (차이를
강조했음): 실행시 이 방법은 잠금파일을 잠그기위해 이 방법은 잠금파일을 잠그기위해 (1.3과 그 이후) 이 방법을 SysV식 세마포어를 사용하여
mutex를 구현한다. 불행히도 SysV식 세마포어는 나쁜
부작용이 있다. 하나는 아파치가 세마포어를 정리하지
않고 죽을 수 있는 점이다 ( (1.3과 그 이후) 이 방법은 POSIX mutex를 사용하기때문에
POSIX 쓰레드 규약을 완전히 구현한 아키텍쳐라면 모두
사용가능하지만, (2.5 이후) Solaris에서만 그것도 특정
구성에서만 동작하는 듯하다. 이 방법을 시도해본다면
서버가 멈춰서 응답을 안하는지 살펴봐야 한다. 정적
내용만 서비스하는 서버는 잘 동작하는 것 같다. (2.0과 그 이후) 이 방법은 POSIX 세마포어를 사용한다.
mutex를 가진 프로세스의 쓰레드가 죽는다면(segfault)
세마포어 소유권이 회복되지 않아서 웹서버가 멈춘다. 시스템에 위 목록에 없는 직렬화(serialization) 방법이
있다면 그 방법을 사용하는 코드를 APR에 추가할 가치가 있다. 고려는 해봤지만 구현하지않은 다른 방법은 부분적으로
반복문을 직렬화하는 방법이다. 즉, 프로세서를 몇개만 들여보내는
것이다. 이 방법은 여러 자식을 동시에 실행할 수 있어서
직렬화때문에 전체 대역폭을 활용하지 못하는 다중프로세서
컴퓨터에서만 관심을 가져볼 수 있다. 앞으로 살펴볼 부분이지만,
매우 병렬화된 웹서버가 흔하지 않아서 우선순위가 낮다. 최상의 성능을 얻기위해서는 여러 앞의 설명은 다중소켓 서버에는 좋지만, 소켓이 한개인
서버는 어떤가? 연결이 도착할때까지 모든 자식이
그래서 우리는 여러 아키텍쳐에서 소켓이 한개인 경우에도
직렬화하면 더 "잘" 동작함을 발견했다. 그래서 거의 대부분의
경우 기본적으로 직렬화를 사용한다. 리눅스에서 (커널 2.0.30,
128Mb 메모리에 듀얼 Pentium pro) 실험한 결과 소켓 한개를
직렬화하면 하지 않은 경우에 비해 초당 요청이 3% 미만
줄어들었다. 그러나 직렬화를 하지 않은 경우 요청당 100ms
지연이 발생했다. 이 지연은 아마도 LAN에서 발생하는 긴
연결선때문일 것이다. 소켓이 한개인 경우 직렬화를 사용하지
않으려면
draft-ietf-http-connection-00.txt 8절에서 설명하듯이
안정적인 웹서버가 되려면, 통신의 양 방향을
독립적으로 닫을 수 있어야 한다 (TCP 연결은 쌍방향이고,
방향은 서로 독립적이다). 이점을 다른 서버에서는 자주
간과하지만, 아파치는 1.2부터 정확히 구현해왔다. 이 기능을 부주의하게 아파치에 추가했을때 여러 유닉스
버전에서 많은 문제가 발생했다. TCP 규약은
방법은 두가지다. 하나는 소켓 옵션 아파치는 보통 ( 이 코드는 연결을 닫을때 더 CPU를 사용하지만, 안정적인
구현을 위해 필요하다. HTTP/1.1이 더 널리 퍼지고 모든 연결을
유지한다면(persistent), 연결을 받는 비용은 여러 요청을
처리하면서 상쇄될 것이다. 위험하게도
아파치의 부모와 자식은 scoreboard라는 것을 통해 서로
통신한다. 이상적으로는 scoreboard를 공유메모리로 구현해야
한다. 우리 개발자가 해당 운영체제에 접근할 수 있거나 상세한
포팅 결과를 받은 경우 보통 공유메모리를 사용하여 구현한다.
나머지는 디스크에 있는 파일을 사용하여 구현한다. 디스크에
있는 파일은 느리고 신뢰도가 떨어진다 (기능도 더 적다).
모듈을 동적으로 읽어들이지 않는다면 (가능한 조금이라도
성능을 높이기위해 이 글을 읽는다면 아마도 모듈을 동적으로
읽어들이지 않을 것이다), 서버를 컴파일할때
다음은 Solaris 8에서 worker MPM을 사용한 아파치 2.0.38의
시스템호출 기록(trace)이다. 아래 명령어를 사용하여 기록을
얻었다: 다른 시스템에는 클라이언트는 웹서버에게 크기가 10KB인 정적 파일을 요청한다.
정적인 파일을 요청하지 않거나 내용협상하는 요청을 한 경우
기록이 매우 다르다 (때로는 매우 알아보기 힘들다). 위에서 연결대기(listener) 쓰레드가 LWP #67에서 실행됨을
알 수 있다. 연결은 받아들이고(accept) 연결대기 쓰레드는
worker 쓰레드를 깨워서 요청을 처리하게 한다. 아래 기록에서
요청을 처리하는 worker 쓰레드가 LWP #65임을 알 수 있다. 가상호스트를 구현하기위해 아파치는 연결을 받아들인
지역(local) 소켓 주소를 알아야 한다. (가상호스트를 사용하지
않거나 다음 worker 쓰레드는 클라이언트의 연결(파일기술자 9)을
대기안함(non-blocking) 상태로 바꾼다. worker 쓰레드는 클라이언트로 부터 요청을 읽는다. 웹서버 설정은 이 경우 웹서버는 한번의 worker 쓰레드는 연결을 지연닫기(lingering close)한다. 마지막으로 worker 쓰레드는 방금 전송한 파일을 닫고,
연결대기(listener) 쓰레드가 다른 연결을 할당할 때까지
정지한다. 그동안 연결대기 쓰레드는 연결을 (모든 worker가 작업중이면
연결대기 쓰레드를 멈추는 worker MPM의 흐름제어 기능에 따라)
worker 쓰레드에 할당하자마자 다른 연결을 받아들일 수 있다.
이 기록에는 나오지 않지만, worker 쓰레드가 방금 받은 연결을
처리하는 동안 다음 Apache HTTP Server Version 2.0 이 문서에는 간단한 설명과 함께 아파치 웹서버가 따르는
모든 관련 표준을 열거한다. 아래 정보에 더하여 다음 자료도 살펴봐야 한다: 이 문서는 아직 완전하지 않다. 어떤 모듈을 컴파일하고 사용하는지와 관계없이 기본적으로
웹서버인 아파치는 다음 IETF 권고(recommendation)를 따른다: 하이퍼텍스트 마크업 언어 (Hypertext Markup Language,
HTML)와 관련하여 아파치는 다음 IETF 권고와 W3C 권고를 따른다: 인증방법에 대해 아파치는 다음 IETF 권고를 따른다: 아래 링크에 ISO와 다른 언어/국가 코드 정보가 있다: Apache HTTP Server Version 2.0 원저자 이 문서는 아파치 다른 말로: 이제 내가 직접 만들었거나 다른 사람들이 만든 많은 실용적인
해결책이 나온다. 예제에서 URL 재작성의 흑마술을 마음껏 배우길
바란다. 한 리소스에 대해 여러 URL을 가지는 웹서버가 있다.
보통 (실제 사용하고 알려져야 할) 기준이 되는 URL과,
단축 혹은 내부 용도의 URL이 있다. 사용자가 요청에
어떤 URL을 사용하던지 기준이 되는 URL만을 보여줘야
한다. 기준이 되지않는 모든 URL을 브라우저가 알도록 고치기위해
외부 HTTP 리다이렉션한다. 예를 들어 아래 규칙은
웹서버의 우리는 URL 디렉토리를 지칭하는 URL의 마지막 슬래쉬 문제가
없다면 모든 웹관리자는 환호할 것이다. 슬래쉬가 없다면,
즉 이 미묘한 문제의 해결방법은 서버가 자동으로 마지막
슬래쉬를 추가하는 것이다. 브라우저가 나머지 그림 등을
올바로 요청할 수 있도록, 외부 리다이렉션을 해야 한다.
내부 리다이렉션을 한다면 디렉토리 페이지에만 동작하여
이 페이지가 상대 URL로 포함하는 그림을 브라우저가
요청할때 찾을 수 없다. 예를 들어, 외부 리다이렉션을
사용하지 않을때 그래서 이를 해결하기위해 다음과 같이 설정한다: 홈디렉토리의 최상위 인트라넷 웹서버군의 모든 웹서버에 동일하고 일관된
URL 구조를 만들고 싶다. 즉, 모든 (정의상 서버에 속하여
서버에 의존적인!) URL을 서버 독립적으로 만든다!
웹 이름공간에 서버독립적인 동일한 구조를 부여해야 한다:
URL은 실제 서버를 지칭하면 안된다. 서버군이 자동으로
실제 서버로 유도한다. 먼저 사용자, 그룹, 독립체의 위치 정보를 저장한
(분산된) 외부맵에 실제 서버 정보를 얻어온다. 외부맵은
다음과 같은 형식이다 우리는 이 정보를 각각 다음과 같이 리다이렉션한다 아래 규칙은 맵파일을 사용하여 이 작업을 한다 (server0은
맵에 항목이 없는 경우 사용할 기본서버라고 가정한다): 많은 웹관리자는 웹서버의 모든 홈디렉토리를 다른
웹서버로 이전한 경우 해결책을 물어본다. 이 방법은
이전 서버를 대체할 새로운 서버를 구성하는데 시간이
걸리는 경우에 필요하다. 사용자가 수천명인 사이트는 보통 홈디렉토리 구조를
만든다. 즉, 예를 들어 이름이 사용자명의 첫번째 문자인
하위디렉토리에 홈디렉토리를 둔다. 그래서,
물결표시가 있는 URL을 위와 같은 구조로 변환하기위해
다음 규칙을 사용한다. 이 예는 실로 하드코어적이다: 디렉토리별
1996년 7월 이 저장소를 멋있는 웹 인터페이스를 통해
세상에 공개하기로 결정햇다. "멋있다"는 말은, 최상위
디렉토리에 CGI 스크립트를 두지 않고도, 저장소 계층구조를
직접 브라우질하길 바란다는 뜻이다. 왜? 저장소를 나중에
FTP로도 접근할 수 있도록 만들 예정이였기때문에 웹이나
CGI와 관련된 내용을 같이 두기 싫었다. 해결책은 두 부분으로 나뉜다: 먼저 디렉토리 수준에서
필요한 모든 페이지를 동적으로 만드는 CGI 스크립트가
필요하다. 나는 이 스크립트들을 다음과 같이
첫번째 규칙은 마지막에 슬래쉬가 없는 요청을 위해서
사용했다! 두번째 규칙이 실제 작업을 한다. 그리고 디렉토리별
설정파일 해석을 위한 힌트: 사람들은 NCSA 웹서버에서 현대적인 아파치 웹서버로
자연스럽게 옮겨가길 바란다. 그래서 오래된 NCSA
모든 요청에서 앞부분을 동적으로 제거하는 전역 규칙을
사용한다: 가끔 웹서버가 여러 디렉토리에서 파일을 찾아야 할
때가 있다. 이 경우 MultiViews나 다른 방법은 도움이
안된다. 여러 디렉토리에서 파일을 찾는 규칙을 직접 프로그램한다. 요청들간에 상태정보를 유지하기위해 URL에 정보를
인코딩하는 방법도 있다. 그러나 단지 이 정보를 제거하기위해
모든 페이지에 CGI wrapper를 사용하고 싶지 않다. 재작성 규칙을 사용하여 상태정보를 추출하고, 추출한
정보를 나중에 XSSI나 CGI에서 사용하기위해 환경변수에
저장한다. 그래서 URL 가상호스트를 사용하지 않고 같은 컴퓨터로 DNS A
레코드를 설정하여
HTTP/1.0 요청의 경우 방법이 없지만, Host: HTTP
헤더를 포함한 HTTP/1.1 요청은 다음 규칙을 사용하여
내부적으로 지역 도메인 재작성 조건을 사용하면 된다: URL 재작성에 대해서 웹서버 A에 해당 파일이 없는
경우 웹서버 B로 요청을 리다이렉션하는 방법을 자주
물어본다. 보통 Perl로 작성한 첫번째 방법은 빠르지만 유연성이 떨어지고 완전하지
않다: 이 방법의 단점은 가끔 리다이렉션하는 URL을 더 조절할 필요가 있다.
아파치 내부 URL escape 함수는 " 직접 리다이렉션하는 NPH-CGI 스크립트를 사용한 해결책이
필요하다. escape를 하지 않기때문이다 (NPH=non-parseable
headers). 먼저 다음 서버설정을 하여 (재작성 규칙의
끝부분에 사용해야 한다) 새로운 URL scheme
그러면 그러면 http://www.perl.com/CPAN에
있는 대단한 CPAN (Comprehensive Perl Archive Network)을
아는가? 이 주소는 세계에 흩어진 여러 CPAN 미러 FTP
서버중 클라이언트에 가까이 있는 서버로 리다이렉션한다.
이를 FTP 접근 중계 서비스라고 한다. CPAN은 CGI 스크립트를
사용하지만, 먼저 시간에 따라 다른 내용을 서비스하는 경우 많은 웹관리자는
잠시 특별한 페이지로 리다이렉션하기위해 CGI 스크립트를
사용한다. 재작성 조건에서 사용할 수 있는 여러 URL 여러 이름을 기본이름으로 재작성한후 새로운 확장자를
가진 파일이 있는지 검사한다. 있다면 그 파일명을 사용하고,
없으면 URL을 원래 상태로 재작성한다. 최근 다음 규칙으로 이전 URL을 내부적으로 새로운 URL로
재작성한다: 다시 새로운 URL로 HTTP 리다이렉션하다. 그러면 브라우저가
새로운 URL를 보이고 변경사실을 사용자가 알게된다: 최소한 중요한 최상위 페이지는 브라우저에 최적화된
내용으로 서비스해야할 경우가 있다. 즉, 최신 Netscape
브라우저에게는 최상의 버전을, Lynx 브라우저에게는
최저 버전을, 나머지 브라우저에는 평균적인 버전을
제공한다. 브라우저가 내용협상을 위해 자신의 종류에 대한 정보를
제공하지 않기때문에 내용협상을 사용할 수 없다. 대신
HTTP "User-Agent" 헤더를 사용한다. 다음 규칙은 HTTP
"User-Agent" 헤더가 "Mozilla/3"으로 시작하면
외부 호스트에 우리 사이트로 가져오고 싶은 좋은
웹페이지가 있다고 가정하자. FTP 서버의 경우 직접 외부
자료의 최신복사본을 유지하는 이를 위해 Proxy Throughput 기능을 (플래그
실제 자료를 방화벽이 보호하는 (내부) 인트라넷 웹서버에
( 먼저 방화벽이 내부 웹서버를 보호하고 외부 웹서버만이
내부 웹서버에서 자료를 얻을 수 있게 한다. 다음과 같이
패킷필터링 방화벽을 설정한다: 실제 설정문법에 알맞게 고쳐라. 없는 자료를 내부적으로
proxy throughput 기능을 통해 요청하는
매우 다양한 방법으로 이 문제를 해결할 수 있다.
먼저 DNS를 사용한 잘 알려진 방법을 설명하고,
가장 간단한 로드밸런싱 방법은 그리고 다음 항목을 추가한다: 잘못된 것처럼 보이지만, 실제로 http://www.stanford.edu/~schemers/docs/lbnamed/lbnamed.html에
있는 이 방법은 그리고 하드웨어를 사용한 해결책도 있다. Cisco는 TCP/IP
수준에서 로드밸런싱을 하는 LocalDirector라는 괴물을
판다. 실제로는 웹서버군 앞단에 위치하는 일종의
회로수준 게이트웨이다. 자금이 충분하고 고성능
해결책이 필요하다면 이것을 사용하라. 네트웍에는 멋진 CGI 프로그램들이 많다. 그러나 사용하기
번거러워서 많은 웹관리자가 사용하지 않는다. 아파치의
MIME-type에 따른 Action 핸들러 기능도 CGI 프로그램이
특별한 URL을 (정확히 이제 다른 멋진 프로그램, (URL 하위트리에 대한
깔끔하지 않다. 링크에 영역의 위치와
CGI 위치를 모두 적어야 하기때문이다.
영역을 재구성한다면 여러 하이퍼링크를 수정하는데 많은
시간이 걸릴 것이다. 해결책은 자동으로 적절한 CGI를 실행하는 새로운
특별한 URL 형식을 만드는 것이다. 다음과 같이 설정한다: 이제 내부적으로 다음과 같이 자동변환된다 같은 방법으로 링크 뒤에 어떻게 브라우저와 사용자가 모르게 자연스럽게 정적
페이지 URL을 CGI 스크립트로 재작성하고, MIME-type을 수정하여
CGI 스크립트로 실행하게 한다. 그래서
이 방법은 실로 비기이다: 동적으로 페이지를 생성하지만,
정적으로 페이지를 서비스한다. 즉, 페이지는 순수하게
(파일시스템에서 읽은 내용을 그대로) 정적 페이지로
전달되지만, 없을 경우 웹서버가 동적으로 생성한다.
그러면 누가 (혹은 cron 작업이) 정적 컨텐츠를 지우지않는
한 CGI가 생성한 페이지를 정적으로 서비스한다. 컨텐츠를
지우면 내용을 갱신한다. 여기서 복잡한 웹페이지를 만들때 편집자가 내용을 수정할
때마다 자동으로 페이지를 새로 고침하는 웹브라우저가
있으면 얼마나 좋을까? 불가능한가? 가능하다! MIME multipart 기능과 웹서버 NPH 기능,
이제 다음 URL에 접근하면 다음 URL을 내부적으로 부른다 이제 NPH-CGI 스크립트만 남았다. 보통 "독자에게
연습으로 남겨둠"이라고 말하지만 ;-) 나는 이것도 제공한다. 가상호스트가 몇개만 있다면 아파치의 이 기능을 제공하려면 Proxy Throughput
기능을 (플래그 어떻게 하면 특정 웹공간의 페이지를 긁어모으는 귀찮은
로봇을 막을 수 있나? "Robot Exclusion Protocol" 항목을
저장한 (아마도 디렉토리가 깊어서 로봇이 돌아다니면 서버에
부담이 큰 경우) 웹공간 그림을 100% 보호할 수는 없지만, 최소한 브라우저가
HTTP Referer 헤더를 보내는 경우 제한할 수 있다. 어떻게 외부에서 서버에 접근할 수 없는 호스트 목록을
설정할 수 있나? 아파치 >= 1.3b6에서: 아파치 <= 1.3b6에서: 어떻게 특정 호스트 혹은 특정 호스트의 사용자가
아파치 프록시를 사용할 수 없도록 하나? 먼저 아파치 웹서버를 컴파일할때 구성파일에서
...그리고 다음은 user@host에 따라 거부한다: 가끔 매우 특별한 인증이 필요할 때가 있다. 예를
들어, 미리 설정해둔 사용자인지 검사한다. 이들에게만
( 친구만 접근이 가능하도록 재작성 규칙들을 사용한다: "Referer" HTTP 헤더에 따라 원하는대로 참조페이지를
설정할 수 있는 유연한 URL 변환기를 만들 수 있는가? 다음과 같이 복잡한 규칙을... ... 재작성 맵과 같이 사용한다: 그러면 요청을 자동으로 (맵에서 값으로 " FAQ: 어떻게 이런저런 잡다한 문제를 풀 수 있는가?
외부 설명하기위해 모든 Apache HTTP Server Version 2.0 웹서버를 운영할때 도움이 될 보안 관련 힌트와 팁이다.
어떤 것은 일반적이고, 어떤 것은 아파치에만 해당하는 것이다. 아파치 웹서버는 안전과 보안 문제에 관심이 많은 개발자
공동체로 유명하다. 그러나 크건 작건 발표후 발견되는 문제들을
피할 수 없다. 그래서 소프트웨어를 최신버전으로 유지하는
것이 중요하다. 아파치에서 직접 웹서버를 다운로드했다면,
새로운 버전과 보안 업데이트를 알려주는 아파치
웹서버 발표 메일링리스트를 구독하길 강력히 권한다.
아파치 소프트웨어를 배포하는 많은 제삼자들도 비슷한 서비스를
제공한다. 물론 웹서버 코드때문에 웹서버가 공격을 당하는 경우는
많지 않다. 그보다 추가 코드, CGI 스크립트, 하위 운영체제의
문제로 공격을 당하는 경우가 많다. 그러므로 항상 주의하며
시스템의 모든 소프트웨어를 업데이트해야 한다. 보통 root 사용자가 아파치를 시작한 후, 요청을 서비스하기위해
그러면 /, /usr, /usr/local 은 root만이 수정할 수 있다.
httpd 실행파일을 설치할때 다음과 같이 보호해야 한다: htdocs 하위디렉토리는 다른 사용자들이 수정할 수 있도록
만들 수 있다 -- root는 그곳에 있는 파일을 실행하지도, 만들지도
않아야 한다. root가 아닌 사용자가 root가 실행하거나 쓰기가능한 파일을
수정할 수 있다면 시스템의 root 권한을 훔칠 수 있다. 예를
들어, 누군가 httpd 실행파일을 변경하였다면 다음번 시작할때
임의의 코드를 실행하게 된다. logs 디렉토리가 (root가 아닌
사용자에게) 쓰기가능하다면 누군가 로그파일을 다른 시스템파일로
심볼링크를 걸어서 root가 파일에 임의의 자료를 덮어쓸 수
있다. 로그파일이 (root가 아닌 사용자에게) 쓰기가능하다면
누군가 로그에 이상한 자료를 기록할 수 있다. Server Side Includes (SSI)는 서버 관리자에게 보안상 몇가지
잠재적인 위험이다. 첫번째 위험은 서버의 부하를 늘리는 점이다. 아파치는 파일에
SSI 지시어가 있는지 여부와 관계없이 모든 SSI 파일을 분석해야
한다. 조금 부하가 늘지만, 서버를 여러 사람이 같이 사용하는
환경에서는 심각할 수 있다. 또, SSI 파일은 일반적인 CGI 스크립트와 동일한 위험을
가진다. SSI 파일에서 "exec cmd"를 사용하면 httpd.conf에서
아파치를 실행하도록 설정한 사용자와 그룹 권한으로 CGI
스크립트나 프로그램을 실행할 수 있다. 장점을 활용하면서 SSI 파일의 보안을 향상시키는 방법이
있다. SSI 파일이 가져올 수 있는 피해를 격리하기위해 서버관리자는
일반적인 CGI 절에서 설명하는 방법으로
suexec를 사용할 수 있다 .html이나 .htm 확장자를 SSI 파일로 사용하는 것은 위험하다.
특히 여러 사람이 공유하거나 통신량이 많은 서버 환경에서
위험하다. SSI 파일은 일반적으로 많이 사용하는 .shtml 같은
별도의 확장자를 가져야 한다. 그러면 서버 부하를 최소화하고
위험요소를 쉽게 관리할 수 있다. 다른 방법은 SSI 페이지가 스크립트나 프로그램을 실행하지
못하도록 만드는 것이다. 결국 당신은 항상 CGI 스크립트/프로그램의 저자를 신뢰해야
하고, 고의건 실수이건 CGI의 잠재적인 보안상 허점을 발견할
수 있어야 한다. 기본적으로 CGI 스크립트는 웹서버 사용자
권한으로 시스템에서 어떤 명령어라도 실행할 수 있기때문에
주의있게 확인하지 않으면 매우 위험하다. 모든 CGI 스크립트가 같은 사용자로 실행되기때문에 다른
스크립트와 (고의건 실수이건) 충돌할 가능성이 있다. 예를
들어, 사용자 A는 사용자 B를 매우 싫어하여, 사용자 B의 CGI
데이터베이스를 지워버리는 스크립트를 작성할 수 있다. 아파치
1.2 버전부터 포함되었고 아파치 서버에서 특별한 훅(hook)으로
동작하는 suEXEC는 스크립트를
다른 사용자로 실행하는 방법중 하나다. 다른 대중적인 방법에는
CGIWrap이 있다. 다음 조건을 만족할때만 사용자가 어떤 디렉토리에서라도
CGI 스크립트를 실행하도록 허용할 수 있다: 특정 디렉토리에서만 CGI를 실행할 수 있도록 제한하면 관리자는
이들 디렉토리를 통제할 수 있다. 이 경우는 scriptalias하지
않은 CGI보다 확실히 안전하다. 단, 신뢰하는 사용자만 디렉토리에
접근할 수 있고, 관리자가 새로운 CGI 스크립트/프로그램의
잠재적인 보안상 허점을 검사할 용이가 있다면. 대부분의 사이트는 scriptalias하지 않은 CGI 방식 대신
이 방식을 사용한다.
mod_php, mod_perl, mod_tcl, mod_python 같이 서버의 일부로
동작하는 임베디드 스크립트는 서버와 같은 사용자로 ( 정말로 안전한 서버를 운영하려면 사용자가
서버 설정파일에 다음을 추가한다 그러면 사용가능하도록 명시적으로 허용한 디렉토리를 제외하고는
사람들은 종종 아파치의 기본 접근에 대해 잘못 알고있다.
즉, 서버가 일반적인 URL 대응 규칙을 사용하여 파일을 찾을
수 있다면, 특별히 조치를 하지 않는한 클라이언트에게 파일이
서비스될 수 있다. 예를 들어, 아래와 같은 경우: 그러면 클라이언트는 전체 파일시스템을 돌아다닐 수 있다.
이를 막기위해 서버설정에서 다음과 같은 조치를 한다: 그러면 파일시스템 위치에 대해 기본 접근이 거부된다.
원하는 영역에 접근할 수 있도록 다음과 같은 실제로 서버에서 무슨 일이 있어나고 있는지 알려면 로그파일을 살펴봐야 한다. 로그파일은
이미 일어난 일만을 보고하지만, 서버에 어떤 공격이 있었는지
알려주고 현재 필요한 만큼 안전한지 확인하게 해준다. 여러가지 예: 첫번째 예는 잘못된
Source.JSP 요청으로 서버정보를 알아낼 수 있는 Tomcat의
취약점를 이용하려는 공격 횟수를 알려주고, 두번째 예는
접근이 거부된 최근 클라이언트 10개를 다음과 같이 보여준다: 잘 알 듯이 로그파일은 이미 발생한 사건만을 보고한다.
그래서 클라이언트가 즉, 당신은 서버 설정파일에서 다음 부분을 주석처리했을
것이다: Apache HTTP Server Version 2.0 This document has not been fully updated
to take into account changes made in the 2.0 version of the
Apache HTTP Server. Some of the information may still be
relevant, but please use it with care. The following documents give you step-by-step instructions
on how to accomplish common tasks with the Apache HTTP server.
Many of these documents are located at external sites and are
not the work of the Apache Software Foundation. Copyright to
documents on external sites is owned by the authors or their
assignees. Please consult the official Apache
Server documentation to verify what you read on external
sites. If you have a pointer to an accurate and well-written
tutorial not included here, please let us know by submitting it
to the Apache Bug
Database. Apache HTTP Server Version 2.0 이 다중처리 모듈(MPM)은 BeOS에서 기본적으로 사용한다.
한 조절 프로세스가 요청을 처리할 쓰레드들을 만든다. Apache HTTP Server Version 2.0 This directive controls whether requests that contain trailing
pathname information that follows an actual filename (or
non-existent file in an existing directory) will be accepted or
rejected. The trailing pathname information can be made
available to scripts in the For example, assume the location The three possible arguments for the
The primary purpose of the While processing a request the server looks for
the first existing configuration file from this list of names in
every directory of the path to the document, if distributed
configuration files are enabled for that
directory. For example: before returning the document
This directive specifies a default value for the media type
charset parameter (the name of a character encoding) to be added
to a response if and only if the response's content-type is either
This directive activates a particular output filter for a request depending on the
response MIME-type. The following example uses the If you want the content to be processed by more than one filter, their
names have to be separated by semicolons. It's also possible to use one
The configuration below causes all script output labeled as
Enabling filters with However, if you want to make sure, that the filters will be
applied, assign the content type to a resource explicitly, for
example with The by-type output filters are never applied on proxy requests. The Turning Allowing encoded slashes does not imply decoding.
Occurrences of When the server finds an When this directive is set to When this directive is set to The directive-type can be one of the following
groupings of directives. Example: In the example above all directives that are neither in the group
This directive sets the name of the authorization realm for a
directory. This realm is given to the client so that the user
knows which username and password to send.
For example: The string provided for the This directive selects the type of user authentication for a
directory. Only This directive is used to control how Apache finds the
interpreter used to run CGI scripts. For example, setting
This directive enables the generation of
MD5 is an algorithm for computing a "message digest"
(sometimes called "fingerprint") of arbitrary-length data, with
a high degree of confidence that any alterations in the data
will be reflected in alterations in the message digest. The Note that this can cause performance problems on your server
since the message digest is computed on every request (the
values are not cached). There will be times when the server is asked to provide a
document whose type cannot be determined by its MIME types
mappings. The server must inform the client of the content-type of the
document, so in the event of an unknown type it uses the
would be appropriate for a directory which contained many GIF
images with filenames missing the Note that unlike Be careful with the directory-path arguments:
They have to literally match the filesystem path which Apache uses
to access the files. Directives applied to a particular
Extended regular
expressions can also be used, with the addition of the
would match directories in If multiple (non-regular expression) for access to the document Regular expressions are not considered until after all of the
normal sections have been applied. Then all of the regular
expressions are tested in the order they appeared in the
configuration file. For example, with the regular expression section won't be considered until after
all normal Note that the default Apache access for
and then override this for directories you
want accessible. See the Security Tips page for more
details. The directory sections occur in the would match directories in This directive sets the directory from which then an access to
The This directive controls whether the This memory-mapping sometimes yields a performance improvement.
But in some environments, it is better to disable the memory-mapping
to prevent operational problems: For server configurations that are vulnerable to these problems,
you should disable memory-mapping of delivered files by specifying: For NFS mounted files, this feature may be disabled explicitly for
the offending files by specifying: This directive controls whether This sendfile mechanism avoids separate read and send operations,
and buffer allocations. But on some platforms or within some
filesystems, it is better to disable this feature to avoid
operational problems: For server configurations that are vulnerable to these problems,
you should disable this feature by specifying: For NFS or SMB mounted files, this feature may be disabled explicitly
for the offending files by specifying: In the event of a problem or error, Apache can be configured
to do one of four things, The first option is the default, while options 2-4 are
configured using the URLs can begin with a slash (/) for local web-paths (relative
to the Additionally, the special value Note that when you specify an Microsoft Internet Explorer (MSIE) will by default ignore
server-generated error messages when they are "too small" and substitute
its own "friendly" error messages. The size threshold varies depending on
the type of error, but in general, if you make your error document
greater than 512 bytes, then MSIE will show the server-generated
error rather than masking it. More information is available in
Microsoft Knowledge Base article Q294807. Although most error messages can be overriden, there are certain
circumstances where the internal messages are used regardless of the
setting of Prior to version 2.0, messages were indicated by prefixing
them with a single unmatched double quote character. The If the file-path
begins with a pipe (|) then it is assumed to be a command to spawn
to handle the error log. Using SECURITY: See the security tips
document for details on why your security could be compromised
if the directory where log files are stored is writable by
anyone other than the user that starts the server. When entering a file path on non-Unix platforms, care should be taken
to make sure that only forward slashed are used even though the platform
may allow the use of back slashes. In general it is a good idea to always
use forward slashes throughout the configuration files.
The The If a directory's configuration includes
The The filename argument should include a filename, or
a wild-card string, where would match most common Internet graphics formats. Note that unlike The would match most common Internet graphics formats. When placed into an Note that unlike You can override any This directive enables DNS lookups so that host names can be
logged (and passed to CGIs/SSIs in Regardless of the setting, when The default is This directive enables RFC1413-compliant logging of the
remote user name for each connection, where the client machine
runs identd or something similar. This information is logged in
the access log. The information should not be trusted in any way except for
rudimentary usage tracking. Note that this can cause serious latency problems accessing
your server since every request requires one of these lookups
to be performed. When firewalls are involved each lookup might
possibly fail and add 30 seconds of latency to each hit. So in
general this is not very useful on public servers accessible
from the Internet. The The test in the In the former case, the directives between the start and end
markers are only processed if the parameter named
parameter-name is defined. The second format reverses
the test, and only processes the directives if
parameter-name is not defined. The parameter-name argument is a define as given on
the The The test in the In the former case, the directives between the start and end
markers are only processed if the module named module
name is included in Apache -- either compiled in or
dynamically loaded using The module name argument is the file name of the
module, at the time it was compiled. For example,
This directive allows inclusion of other configuration files
from within the server configuration files. Shell-style ( The file path specified may be an absolute path, or may be relative
to the Examples: Or, providing paths relative to your Running The Keep-Alive extension to HTTP/1.0 and the persistent
connection feature of HTTP/1.1 provide long-lived HTTP sessions
which allow multiple requests to be sent over the same TCP
connection. In some cases this has been shown to result in an
almost 50% speedup in latency times for HTML documents with
many images. To enable Keep-Alive connections, set
For HTTP/1.0 clients, Keep-Alive connections will only be
used if they are specifically requested by a client. In
addition, a Keep-Alive connection with an HTTP/1.0 client can
only be used when the length of the content is known in
advance. This implies that dynamic content such as CGI output,
SSI pages, and server-generated directory listings will
generally not use Keep-Alive connections to HTTP/1.0 clients.
For HTTP/1.1 clients, persistent connections are the default
unless otherwise specified. If the client requests it, chunked
encoding will be used in order to send content of unknown
length over persistent connections. The number of seconds Apache will wait for a subsequent
request before closing the connection. Once a request has been
received, the timeout value specified by the
Setting Access controls are normally effective for
all access methods, and this is the usual
desired behavior. In the general case, access control
directives should not be placed within a
The purpose of the The method names listed can be one or more of: For example: An internal redirect happens, for example, when using the The directive stores two different limits, which are evaluated on
per-request basis. The first number is the maximum number of
internal redirects, that may follow each other. The second number
determines, how deep subrequests may be nested. If you specify only one
number, it will be assigned to both limits. This directive specifies the number of bytes from 0
(meaning unlimited) to 2147483647 (2GB) that are allowed in a
request body. The This directive gives the server administrator greater
control over abnormal client request behavior, which may be
useful for avoiding some forms of denial-of-service
attacks. If, for example, you are permitting file upload to a particular
location, and wish to limit the size of the uploaded file to 100K,
you might use the following directive: Number is an integer from 0 (meaning unlimited) to
32767. The default value is defined by the compile-time
constant The This directive gives the server administrator greater
control over abnormal client request behavior, which may be
useful for avoiding some forms of denial-of-service attacks.
The value should be increased if normal clients see an error
response from the server that indicates too many fields were
sent in the request. For example: This directive specifies the number of bytes
that will be allowed in an HTTP request header. The This directive gives the server administrator greater
control over abnormal client request behavior, which may be
useful for avoiding some forms of denial-of-service attacks. For example: This directive sets the number of bytes from 0 to
the value of the compile-time constant
The This directive gives the server administrator greater
control over abnormal client request behavior, which may be
useful for avoiding some forms of denial-of-service attacks. For example: Limit (in bytes) on maximum size of an XML-based request
body. A value of Example: The Use For all origin (non-proxy) requests, the URL to be matched is a
URL-path of the form The URL may use wildcards. In a wild-card string, Extended regular
expressions can also be used, with the addition of the
would match URLs that contained the substring The The slash character has special meaning depending on where in a
URL it appears. People may be used to its behavior in the filesystem
where multiple adjacent slashes are frequently collapsed to a single
slash (i.e., For example, The would match URLs that contained the substring When a particular level is specified, messages from all
other levels of higher significance will be reported as well.
E.g., when Using a level of at least For example: When logging to a regular file messages of the level
The For example: The Although addr can be hostname it is recommended
that you always use an IP address, e.g. With the Note, that the "main server" and any Optionally you can specify a port number on which the
name-based virtual hosts should be used, e.g. IPv6 addresses must be enclosed in square brackets, as shown
in the following example: To receive requests on all interfaces, you can use an argument of
Note that the argument to the The option can be set to Even though the server follows the symlink it does not
change the pathname used to match against Note also, that this option gets ignored if set
inside a Normally, if multiple Mixing For example, without any then only then the options Using The default in the absence of any other settings is
This directive selects which authenticated users can access
a resource. The allowed syntaxes are: Access controls which are applied in this way are effective for
all methods. This is what is normally
desired. If you wish to apply access controls only to
specific methods, while leaving other methods unprotected, then
place the Takes 1 or 2 parameters. The first parameter sets the soft
resource limit for all processes and the second parameter sets
the maximum resource limit. Either parameter can be a number,
or This applies to processes forked off from Apache children
servicing requests, not the Apache children themselves. This
includes CGI scripts and SSI exec commands, but not any
processes forked off from the Apache parent such as piped
logs. CPU resource limits are expressed in seconds per
process. Takes 1 or 2 parameters. The first parameter sets the soft
resource limit for all processes and the second parameter sets
the maximum resource limit. Either parameter can be a number,
or This applies to processes forked off from Apache children
servicing requests, not the Apache children themselves. This
includes CGI scripts and SSI exec commands, but not any
processes forked off from the Apache parent such as piped
logs. Memory resource limits are expressed in bytes per
process. Takes 1 or 2 parameters. The first parameter sets the soft
resource limit for all processes and the second parameter sets
the maximum resource limit. Either parameter can be a number,
or This applies to processes forked off from Apache children
servicing requests, not the Apache children themselves. This
includes CGI scripts and SSI exec commands, but not any
processes forked off from the Apache parent such as piped
logs. Process limits control the number of processes per user. If CGI processes are not running
under user ids other than the web server user id, this directive
will limit the number of processes that the server itself can
create. Evidence of this situation will be indicated by
Access policy if both For example, if you wanted to let people on your network have
unrestricted access to a portion of your website, but require that
people outside of your network provide a password, you could use a
configuration similar to the following: Since version 2.0.51 This directive is used to control how Apache finds the
interpreter used to run CGI scripts. The default setting is
or, if Setting Be careful when using The option The It may be worth setting up a dedicated address for this, e.g. as users do not always mention that they are talking about the
server! The The If no If you are using name-based virtual hosts,
the See the description of the
The The The The After version 2.0.44, the details of the server version number
presented are controlled by the This directive controls whether This setting applies to the entire server, and cannot be
enabled or disabled on a virtualhost-by-virtualhost basis. After version 2.0.44, this directive also controls the
information presented by the When placed into an Another example: if you wanted to have the server display a
status report whenever a URL of
You can override an earlier defined The If more than one filter is specified, they must be separated
by semicolons in the order in which they should process the
content. The For example, the following configuration will process all files
in the If more than one filter is specified, they must be separated
by semicolons in the order in which they should process the
content. The We plan on making these separately configurable at some point
down the road. The timer used to default to 1200 before 1.2,
but has been lowered to 300 which is still far more than
necessary in most situations. It is not set any lower by
default because there may still be odd places in the code where
the timer is not reset when a packet is sent. This directive overrides the behavior of Finally, for testing and diagnostic purposes only, request
bodies may be allowed using the non-compliant In many situations Apache must construct a self-referential
URL -- that is, a URL that refers back to the same server. With
With An example where this may be useful is on an intranet server
where you have users connecting to the machine using short
names such as There is a third option, If CGIs make assumptions about the values of IPv6 addresses must be specified in square brackets because
the optional port number could not be determined otherwise. An
IPv6 example is shown below: Each Virtual Host must correspond to a different IP address,
different port number or a different host name for the server,
in the former case the server machine must be configured to
accept IP packets for multiple addresses. (If the machine does
not have multiple network interfaces, then this can be
accomplished with the The use of When using IP-based virtual hosting, the special name
You can specify a See the security tips
document for details on why your security could be compromised if the
directory where log files are stored is writable by anyone other
than the user that starts the server. Apache HTTP Server Version 2.0 이 문서는 아파치 설정
지시어를 설명하는데 사용한 용어들을 설명한다. 지시어의 목적에 대한 간단한 설명. 설정파일에서 사용할 지시어의 형식을 알려준다. 이 문법은
지시어마다 매우 다르며, 지시어를 정의할 때마다 자세히 설명한다.
일반적으로 지시어 이름 뒤에 공백으로 구분한 아규먼트들이
나온다. 아규먼트가 공백을 포함한다면 아규먼트를 쌍따옴표로
묶어야 한다. 선택적인 아규먼트는 중괄호로 묶는다. 아규먼트가
여러 값중 하나일 경우 값들을 수직막대 "|"로 구분한다.
문자그대로 사용할 부분은 기본 문자체로 쓰고, 대체할 아규먼트는
강조한다. 아규먼트 개수가 정해지지않은 지시어는
마지막 아규먼트가 반복됨을 나타내는 "..."으로 끝난다. 지시어는 매우 다양한 종류의 아규먼트를 받는다. 이중 자주
사용하는 것은 아래와 같다. 지시어에 기본값이 있다면 (예를 들어, 설정에서
지시어를 생략한 경우 아파치 웹서버는 이 값을 사용한다.)
이 항목에 나온다. 기본값이 없다면 이 항목은
"None"이어야 한다. 기본값이 서버에 포함된 기본
httpd.conf의 지시어 값과 다를 수 있음을 주의하라. 서버의 설정파일중 어느곳에서 지시어를 사용할 수 있는지
알려준다. 다음 값들을 쉼표로 구분한 목록이다: 지시어는 지정된 장소에서만 사용할 수 있다. 다른
곳에서 사용하면 설정오류가 발생하고 서버는 부분에 대한 요청을
올바로 처리하지 못하거나 작동이, 예를 들어 시작조차도,
안될 수 있다. 지시어를 사용할 수 있는 장소는 열거한 장소를 모두
불린(boolean) OR한 결과이다. 즉,
" 이 지시어를 Overrides는 지시어가 아파치 웹서버에 얼마나 긴밀히 묶여있는지를
나타낸다. 즉, 그 지시어나 기능을 사용하기위해 서버를
모듈과 같이 다시 컴파일할 필요가 있을 수도 있다.
가능한 값은 다음과 같다: 단순히 지시어를 정의한 소스 모듈명을 열거한다. 지시어가 원래 아파치 버전 2 배포본의 일부가 아니였다면,
지시어를 추가하기 시작한 버전이 여기 나온다. 또, 어떤
플래폼에서만 사용가능한 지시어도 여기 나온다. Apache HTTP Server Version 2.0
다음은 표준 아파치 배포본에서 사용가능한 지시어 목록이다.
이들을 동일한 형식으로 설명하였고, 설명에 사용한 용어
사전도 있다.
각 지시어를 요약하여 설명한 지시어 빠른참조도 있다.
A | B | C | D | E | F | G | H | I | K | L | M | N | O | P | R | S | T | U | V | W | X Apache HTTP Server Version 2.0
다음은 아파치 배포본에 포함된 모든 모듈 목록이다. 모든 아파치 지시어 목록도
참고하라.
A | C | D | E | F | H | I | L | M | N | P | R | S | U | V Apache HTTP Server Version 2.0 이 MPM은 실험적인 상태로, 기대한대로 동작하지않을 수 있다. 이 모듈은 표준 이 MPM은 쓰레드 동기를 위해 APR의 atomic compare-and-swap
명령을 사용한다. x86용으로 컴파일하지만 386을 지원할 필요가
없거나, SPARC용으로 컴파일하지만 UltraSPARC 칩 이전에서
실행하지 않는다면, Apache HTTP Server Version 2.0 The directives provided by Both host-based access restrictions and password-based
authentication may be implemented simultaneously. In that case,
the In general, access restriction directives apply to all
access methods ( The The first argument to this directive is always
Hosts whose names match, or end in, this string are allowed
access. Only complete components are matched, so the above
example will match An IP address of a host allowed access The first 1 to 3 bytes of an IP address, for subnet
restriction. A network a.b.c.d, and a netmask w.x.y.z. For more
fine-grained subnet restriction. Similar to the previous case, except the netmask consists of
nnn high-order 1 bits. Note that the last three examples above match exactly the
same set of hosts. IPv6 addresses and IPv6 subnets can be specified as shown
below: The third format of the arguments to the
In this case, browsers with a user-agent string beginning
with This directive allows access to the server to be restricted
based on hostname, IP address, or environment variables. The
arguments for the The Note that all Ordering is one of: Keywords may only be separated by a comma; no whitespace
is allowed between them. In the following example, all hosts in the apache.org domain
are allowed access; all other hosts are denied access. In the next example, all hosts in the apache.org domain are
allowed access, except for the hosts which are in the foo.apache.org
subdomain, who are denied access. All hosts not in the apache.org
domain are denied access because the default state is to On the other hand, if the The presence of an will The Apache HTTP Server Version 2.0 이 모듈에는 두가지 지시어가 있다. 이 지시어는 요청이 action-type이면
cgi-script를 실행하는 행동을 서버에 추가한다.
cgi-script는 첫번째 예에서 MIME content type이 두번째 예에서 확장자가 이 지시어는 파일을 method 메서드를 사용하여
요청하면 cgi-script를 실행하는 행동을 서버에
추가한다. cgi-script는 Script 명령어는 기본적인 행동만을 처리함을 주의하라.
CGI 스크립트가 불리거나, 요청한 메서드를 알아서 처리할 수
있는 리소스의 경우 그대로 처리한다. Apache HTTP Server Version 2.0 이 모듈이 제공하는 지시어들을 사용하여 서버가 요청을
받을때 URL을 수정하거나 조작할 수 있다. 서로 다른 사용장소에서 Alias와 Redirect를 사용하면 다른 지시어와
같이 표준 결합 방법에
따라 처리한다. 그러나 같은 사용장소에 (예를 들어, 같은 먼저 모든 Redirect를 처리한 후 Alias를 처리한다. 그래서
그래서 여러 지시어가 동일한 하위경로에 해당하는 경우 모든
지시어를 적용하기위해서는 가장 상세한 경로를 먼저 사용해야 한다.
예를 들어, 다음 설정은 의도한대로 동작한다: 그러나 위의 두 지시어 순서를 바꾸면 http://myserver/image/foo.gif를 요청하면 서버는
/ftp/pub/image/foo.gif 파일을 넘겨준다. url-path 끝에 /를 포함하면, URL 끝에 /를
사용해야만 영향이 있음을 주의하라. 즉, 대응의 대상을 포함하는 여러 특히 이 지시어는 Redirect 지시어는 이전 URL을 새로운 URL로 대응한다.
클라이언트에게 새로운 URL을 보내고, 클라이언트는 새로운
주소로 다시 한번 접속한다. (%로 인코딩된) URL-path로
시작하는 요청을 받으면 (%로 인코딩된) URL로 시작하는
새로운 URL로 리다이렉션 오류를 보낸다. 클라이언트가 http://myserver/service/foo.txt를 요청하면
대신 http://foo2.bar.com/service/foo.txt에 접근하라는 응답을
받는다. Redirect 지시어는 설정파일에서
나오는 순서와 관계없이 Alias와 ScriptAlias 지시어보다 우선순위가
높다. 또, .htaccess 파일이나 status 아규먼트를 지정하지않으면, "임시
(temporary)" (HTTP 상태 302) 리다이렉션을 보낸다. 즉,
클라이언트에게 자원을 임시로 옮겼다고 알린다. status
아규먼트를 사용하여 다른 HTTP 상태코드를 반환할 수 있다: status에 숫자 상태코드를 사용하여 다른 상태코드도
반환할 수 있다. 상태가 300과 399 사이라면 URL
아규먼트를 사용해야 하고, 아니라면 생략해야 한다. 단, 아파치
코드에 상태가 정의되있어야 한다 (http_protocol.c의
이 지시어는 이 지시어는 클라이언트에게 리다이렉션이 영구적임을 (상태
301) 알린다. 이 지시어는 클라이언트에게 리다이렉션이 임시적임을 (상태
302) 알린다. 이 지시어는 Apache HTTP Server Version 2.0 이 모듈은 아파치가 일반적인 HTTP 헤더의 대부분을 추가하지않고
문서를 보내도록 만드는 그래서 서버는 cgi 스크립트나 nph 스크립트를 사용하지않고도
리다이렉션과 다른 특별한 HTTP 응답 등 어떤 자료도 보낼 수
있다. 과거에 이 모듈은 mime type이 서버 설정파일에서 파일과 아파치는 다음은 내용 그대로 클라이언트에게 파일이
리다이력션되었다고 알리는 파일의 예이다. 서버는 자료를 클라이언트에게 보낼때 항상 Apache HTTP Server Version 2.0 This module allows the use of HTTP Basic Authentication to
restrict access by looking up users in plain text password and
group files. Similar functionality and greater scalability is
provided by Setting the So if a userID appears in the database of more than one module;
or if a valid A common use for this is in conjunction with one of the
database modules; such as By default control is not passed on and an unknown userID or
rule will result in an "Authentication Required" reply. Not setting
it thus keeps the system secure and forces an NCSA compliant
behaviour. Do consider the implications of allowing a user to allow
fall-through in his .htaccess file; and verify that this is really
what you want; Generally it is easier to just secure a single
.htpasswd file, than it is to secure a database such as mSQL.
Make sure that the The Each line of the group file contains a groupname followed by a
colon, followed by the member usernames separated by spaces. Note that searching large text files is very
inefficient; Make sure that the The Each line of the user file contains a username followed by
a colon, followed by the encrypted password. If the same user
ID is defined multiple times, The utility Create a password file Add or modify Note that searching large text files is very
inefficient; Make sure that the Apache HTTP Server Version 2.0 This module does access control in a manner similar to
anonymous-ftp sites; i.e. have a 'magic' user id
'anonymous' and the email address as a password. These email
addresses can be logged. Combined with other (database) access control methods, this
allows for effective user tracking and customization according
to a user profile while still keeping the site open for
'unregistered' users. One advantage of using Auth-based user
tracking is that, unlike magic-cookies and funny URL
pre/postfixes, it is completely browser independent and it
allows users to share URLs. The example below (when combined with the Auth directives of a
htpasswd-file based (or GDM, mSQL etc.) base access
control system allows users in as 'guests' with the following
properties: A list of one or more 'magic' userIDs which are allowed
access without password verification. The userIDs are space
separated. It is possible to use the ' and " quotes to allow a
space in a userID as well as the \ escape character. Please note that the comparison is
case-IN-sensitive. This would allow the user to enter without password
verification by using the userIDs "anonymous",
"AnonyMous", "Not Registered" and "I Don't Know". When set Be sure you know what you are doing when you decide to
switch it on. And remember that the order in which the Authentication
modules are queried is defined in the modules.c files at compile
time. When set Specifies whether the user must specify an email address as
the password. This prohibits blank passwords. When set When set Apache HTTP Server Version 2.0 This module provides for HTTP Basic Authentication, where
the usernames and passwords are stored in DBM type database
files. It is an alternative to the plain text password files
provided by Setting the So if a userID appears in the database of more than one module;
or if a valid A common use for this is in conjunction with one of the
basic auth modules; such as By default, control is not passed on and an unknown userID
or rule will result in an "Authentication Required" reply. Not
setting it thus keeps the system secure and forces an NCSA
compliant behaviour. Do consider the implications of allowing a user to allow
fall-through in his The The group file is keyed on the username. The value for a
user is a comma-separated list of the groups to which the users
belongs. There must be no whitespace within the value, and it
must never contain any colons. Security: make sure that the
Combining Group and Password DBM files: In some cases it is
easier to manage a single database which contains both the
password and group details for each user. This simplifies any
support programs that need to be written: they now only have to
deal with writing to and locking a single DBM file. This can be
accomplished by first setting the group and password files to
point to the same DBM: The key for the single DBM is the username. The value consists
of The password section contains the encrypted password as before.
This is followed by a colon and the comma separated list of groups.
Other data may optionally be left in the DBM file after another colon;
it is ignored by the authentication module. This is what
www.telescope.org uses for its combined password and group database. Sets the type of database file that is used to store the passwords.
The default database type is determined at compile time. The
availability of other types of database files also depends on
compile-time settings. It is crucial that whatever program you use to create your password
files is configured to use the same type of database. The The user file is keyed on the username. The value for a user is
the encrypted password, optionally followed by a colon and arbitrary
data. The colon and the data following it will be ignored by the
server. Make sure that the Important compatibility note: The implementation of
"dbmopen" in the apache modules reads the string length of the
hashed values from the DBM data structures, rather than relying
upon the string being NULL-appended. Some applications, such as
the Netscape web server, rely upon the string being
NULL-appended, so if you are having trouble using DBM files
interchangeably between applications this may be a part of the
problem. A perl script called
Apache HTTP Server Version 2.0 이 모듈은 HTTP Digest Authentication을 구현한다.
그러나 많은 테스트를 거치지 않은 실험적인 모듈이다. MD5 Digest authentication은 매우 쉽게 사용할 수 있다.
모든 htdigest 도구를
사용하여 사용자 (문자)파일을 만들 수 있다. Digest authentication은 Basic authentication보다 더
안전한 암호시스템을 제공하지만, 브라우저가 지원해야 한다.
2002년 11월 현재 digest authentication을 지원하는 브라우저에는
Opera, (질의문자열과
함께 사용하면 안되지만 - 해결방법은 아래 "MS Internet Explorer 문제 해결하기"를 참고) MS Internet
Explorer, Amaya, Mozilla, 버전 7 이후의
Netscape 등이 있다. digest authentication이 basic
authentication 만큼 널리 구현되지 않았기때문에 주의해서
사용해야 한다. 현재 Internet Explorer는 Digest authentication
사용시 질의문자열이 있는
첫번째는 프로그램에 자료를 넘겨주기위해 또, 아파치 2.0.51부터 선택적인 환경변수 설정에 대한 자세한 내용은 이 지시어는 항상 지정해야 하며, 최소한 영역들의
기본 URI(들)를 포함해야 한다. 생략하면 클라이언트는
이 서버로 보내는 모든 요청에 Authorization 헤더를
포함한다. 그러면 요청의 크기가 커지며, 다른 서버의 URI를 지정하면, (이를 이해하는) 클라이언트는
여러 서버마다 매번 사용자에게 묻지않고 같은 사용자명/암호를
사용할 수 있다. 이 파일 내용은 특별한 형식이 있다. 아파치 배포본의
그룹파일은 그룹명 뒤에 콜론, 그뒤에 그룹에 속한 사용자명들을
공백으로 구분하여 한 줄로 기록한다. 예를 들어 다음과 같다. 큰 문자파일을 검색하는 것이 매우 비효율적임을
명심하라. size는 보통 바이트 단위이지만, 뒤에
Apache HTTP Server Version 2.0 There are two phases in granting access to a user. The first
phase is authentication, in which During the authentication phase, The following directives are used during the search/bind
phase During the authorization phase, Apache's If this directive exists, The Because of the way that If the This directive specifies an LDAP group whose members are
allowed access. It takes the distinguished name of the LDAP
group. Note: Do not surround the group name with quotes.
For example, assume that the following entry existed in
the LDAP directory: The following directive would grant access to both Fred and
Barbara: Behavior of this directive is modified by the The The following directive would grant access to a specific
DN: Behavior of this directive is modified by the The The following directive would grant access to anyone with
the attribute employeeType = active Multiple attribute/value pairs can be specified on the same line
separated by spaces or they can be specified in multiple
The following directive would grant access to anyone with
the city attribute equal to "San Jose" or status equal to "Active" The next example demonstrates the power of using filters
to accomplish complicated administrative requirements.
Without filters, it would have been necessary to create a
new LDAP group and ensure that the group's members remain
synchronized with the pager users. This becomes trivial
with filters. The goal is to grant access to anyone who has
a filter, plus grant access to Joe Manager, who doesn't
have a pager, but does need to access the same
resource: This last may look confusing at first, so it helps to
evaluate what the search filter will look like based on who
connects, as shown below. The text in blue is the part that
is filled in using the attribute specified in the URL. The
text in red is the part that is filled in using the filter
specified in the URL. The text in green is filled in using
the information that is retrieved from the HTTP client. If
Fred User connects as The above search will only succeed if fuser has a
pager. When Joe Manager connects as jmanager, the
filter looks like The above search will succeed whether jmanager
has a pager or not. To use TLS, see the To use SSL, see the To specify a secure LDAP server, use ldaps:// in the
Normally, FrontPage uses FrontPage-web-specific user/group
files (i.e., the Once a FrontPage web has been created, adding LDAP
authentication to it is a matter of adding the following
directives to every FrontPage restricts access to a web by adding the Once directives have been added as specified above,
FrontPage users will be able to perform all management
operations from the FrontPage client. Set to An optional DN used to bind to the server when searching for
entries. If not provided, A bind password to use in conjunction with the bind DN. Note
that the bind password is probably sensitive data, and should be
properly protected. You should only use the The The file contains lines in the following format: The case of the extension does not matter. Blank lines, and lines
beginning with a hash character ( When set, This directive specifies when Set to See the section on using Microsoft
FrontPage with This directive specifies which LDAP attributes are used to
check for group membership. Multiple attributes can be used by
specifying this directive multiple times. If not specified,
then When set If this directive is set to on, the value of the
An RFC 2255 URL which specifies the LDAP search parameters
to use. The syntax of the URL is The name/port of the ldap server (defaults to
Once a connection has been made to a server, that
connection remains active for the life of the
If the LDAP server goes down and breaks an existing
connection, When doing searches, the attribute, filter and username passed
by the HTTP client are combined to create a search filter that
looks like
For example, consider an URL of
See above for examples of Apache HTTP Server Version 2.0 디렉토리 목록은 얻는 방법은 두가지다: 이 두 기능은 서로 별개로, 원한다면 자동 목록 생성을 완전히
제외할 (혹은 대체할) 수 있다. 자동 목록 생성은 "Size(크기)" 순으로 볼때 출력되는 값 순서가 아니라 실제
파일크기 순서임을 주의하라. 즉, 1010 바이트 파일과 1011
바이트 파일은 둘다 "1K"로 보이더라도 항상 1010 바이트 파일이
앞에 나온다. 아파치 2.0.23는 열순서에 대한 요청 아규먼트를 정리하고,
새로운 옵션들을 추가했다. 출력을 클라이언트가 조절할 수
없도록 만드는 열순서 이름은 아래 나온 순서 요청 옵션을 더한 자기참조
링크다. 아래 옵션은 디렉토리 자원에 대한 어떤 요청에도
사용할 수 있다. 'P'attern 아규먼트는 일반적인 header.html 파일에 사용할 수 있는 아래 간단한 예제는
이 옵션들을 설명한다. submit 버턴의 알 수 없는 "X" 아규먼트는
mod_autoindex가 X=Go 전까지 모든 아규먼트를 읽어들임을
확인하기위해 마지막에 사용했다. 이 지시어는 전형적인 기본 설명 필드폭은 23 바이트다. 이 필드의 폭를 바꾸거나 설명의 길이를 무한대로 만드려면
DescriptionWidth 이 지시어는 Name에는 디렉토리를 나타내는 가능하면 이 지시어는 MIME-encoding는 content-encoding에 해당하는
와일드카드 표현이다. 이 지시어는 MIME-type은 mime type에 해당하는 와일드카드
표현이다. 현재 HeaderName과 Filename에는 major content type이 수가 0으로 시작하면, 그 수를 분수로 취급한다: 아파치 1.3.3에서 다음과 같다 키워드 앞에 '+'나 '-'가 붙을때마다 해당 키워드가 현재
(상위 디렉토리에서 상속되었을) 앞에 아무것도 없는 특정 디렉토리에 대해 무조건적인
이 지시어와 이 동작을 자세히 설명한 Apache HTTP Server Version 2.0 내용을 URI를 토대로 만든 키로 캐쉬에 저장하고 가져온다.
접근보호가 된 내용은 캐쉬하지않는다. (아래 예와 같이) URL 공간이 다른
보통 응답을 캐쉬하고 클라이언트로 보내는 도중에 요청이
취소되면 응답 처리를 중단되고 캐쉬 항목을 지운다.
정도는 백분율로 나타내며 보통 no-cache나 no-store 헤더값을 가진 문서는 캐쉬에
저장하지않는다. 보통 최근수정일이 없는 문서는 캐쉬하지 않는다. 어떤 경우
최근수정일을 (예를 들어 문서에 만기시간은 없지만 최근수정일이 있는 경우 최근수정일
이후 지난 시간으로 만기시간을 계산한다.
Apache HTTP Server Version 2.0 CERN 웹서버 메타파일을 흉내낸다. 메타파일은 접근하는
파일에 대해 일반적인 헤더외에 추가로 출력할 HTTP 헤더를
담고있다. 아파치 .asis 파일과 비슷하고, Expires: 헤더를
수정하거나 다른 신기한 일들을 할 수 있다. 메타 정보를 다루는
방법은 다양하지만, 이미 이 모듈을 사용하는 많은 CERN 사용자들을
위해 이 방법을 선택했다. 더 자세한 정보는 CERN metafile semantics를 참고하라. 아파치가 메타정보 파일을 찾을 디렉토리명을 지정한다.
디렉토리는 보통 접근할 파일이 있는 디렉토리의 '감춰진'
하위디렉토리다. " 아니면 파일이 있는 하위디렉토리를 지정한다: 디렉토리별로 메타파일 처리여부를 결정한다. 메타정보를 저장하는 파일의 접미사를 지정한다. 예를 들어,
두 지시어의 기본값을 사용할 경우
Apache HTTP Server Version 2.0 서버는 mime type이 서버는 CGI 스크립트를 부를때 아파치에서 CGI 스크립트를 사용하는 방법에 대한 소개는
CGI로 동적 페이지 생성 투토리얼을
참고하라. 유닉스에서 다중쓰레드 MPM을 사용한다면 이 모듈대신
서버는 다음과 같은 방법으로 CGI 표준이 설명하는
CGI 환경변수를 설정한다: 어디에서 잘못 실행되는지 스크립트의 출력을 (표준출력과
표준오류) 볼 수 없기때문에 CGI 스크립트는 전통적으로 디버깅하기
어려웠다. 아파치 1.2 이후에 추가된 지시어를 사용하면 발생한
오류를 자세히 로그에 남길 수 있다. CGI 오류로그는 정상적으로 실행하지 못한 CGI를 기록한다.
오류가 발생한 CGI 스크립트는 로그에 여러 줄의 정보를 남긴다.
첫번째 두 줄은 항상 아래와 같은 형식이다: CGI 스크립트를 실행할 수 없는 오류인 경우 로그파일에
추가로 두 줄을 더 기록한다: 스크립트가 (보통 스크립트의 버그때문에) 잘못된 헤더
정보를 반환하는 경우, 다음 내용을 로그에 기록한다: (스크립트가 표준출력이나 표준오류에 아무 내용도 출력하지
않았다면 %stdout과 %stderr 부분은 생략될 수 있다). 자식 프로세스를 실행하는 사용자, 즉 스크립트 로그는 CGI 스크립트를 작성할때 디버깅을 위한
용도이지 서버를 실행하는 동안 계속 사용하기위함이 아님을
주의하라. 속도와 효율성면에서 최적화가 안되있고, 설계한
목적이외의 방법으로 사용하면 보안상 문제가 될 수 있다. 큰 내용을 받아서 로그파일이 너무 빨리 커지는 현상을 막기위해
파일에 기록할 PUT 혹은 POST 내용의 크기를 제한한다. 기본적으로
1024 바이트까지 로그에 기록하지만, 이 지시어를 사용하여
수정할 수 있다. Apache HTTP Server Version 2.0 아래에서 설명하는 추가된 어떤 유닉스 운영체제의 경우 다중쓰레드 서버에서 프로세스를
포크(fork)하면 새로운 프로세스가 부모 프로세스의 모든 쓰레드를
복제해야 하므로 부담이 된다. CGI 실행마다 이런 부담을 주지
않기위해 컴파일할때 다중쓰레드 MPM을 선택하면 기본적으로
이 지시어는 CGI 데몬과 통신을 위해 사용할 소켓의 이름을
지정한다. 아파치를 시작한 사용자 (보통 root) 권한으로 소켓을
연다. CGI 스크립트와 통신의 보안을 위해 다른 사용자가 소켓이
있는 디렉토리에 쓰기권한을 가지지않는 것이 중요하다. Apache HTTP Server Version 2.0 이 모듈은 실험적인 모듈이고, 주의있게
사용해야 한다. 원하는 동작을 하는지
이 모듈은 러시아판 아파치의 변환규칙이 상황에 맞지않으면 다음과 같은 여러 방식으로
변환이 실패할 수 있다: charset 아규먼트에는 APR이 지원하는 문자집합
이름을 사용해야 한다. 일반적으로 iconv가 지원하는 문자집합을
의미한다. charset 아규먼트에는 APR이 지원하는 문자집합
이름을 사용해야 한다. 일반적으로 iconv가 지원하는 문자집합을
의미한다. Solaris 8의 iconv가 이 예제의 문자집합을 지원한다. Apache HTTP Server Version 2.0 이 모듈은 아파치에 WebDAV
('Web-based Distributed Authoring and Versioning') class 1과
class 2 기능을 추가한다. WebDAV는 원격 웹서버의 자원과
콜렉션(collection)을 (역주; 콜렉션은 파일시스템의 디렉토리와
같은 개념이다) 만들고, 옮기고, 복사하고, 지울
수 있도록 HTTP 프로토콜을 확장한 것이다. 그러면 또, DAV 잠금(lock) 데이터베이스의 위치를 아파치를 실행하는 DAV를 사용하는 위치에 접근을 제한하기위해 DAV를 사용하면 원격 클라이언트가 서버의 파일을 조작할
수 있기때문에, 서버에서 DAV가 가능한 위치는 인증으로 보호해야 한다.
HTTP Basic Authentication는 추천하지 않는다. 최소한
일반적인 질문중 하나는 (PHP 스크립트, CGI 스크립트 등)
동적파일 작업을 위해 이 설정에서 지정한 위치에서 WebDAV HTTP 메써드를 사용하려면
클라이언트가 DAV 자원에 잠금(lock)을 요청할때 서버가
알아서 잠금을 제거할 수 있는 시간을 같이 알려줄 수 있다. 이 값은
단지 요청일뿐이며, 서버는 클라이언트가 요청한 값을 무시하고
클라이언트에게 임의의 시간을 알려줄 수 있다. Apache HTTP Server Version 2.0 이 모듈은 아파치를 실행하는 Apache HTTP Server Version 2.0 급한 사람을 위한 견본 설정이다. 아래 설정은 요약하였지만 그래도 복잡하다. 설정을 완전히
이해한 후 사용하라. 모든 내용을 압축하면 처리하지 못하는 브라우저가 있기때문에
html 파일만을 압축하기위해 (아래 참고)
보통 특별한 MIME type만 압축하려면 압축한 파일을 처리하지 못하는 브라우저에게는 압축하지않고
보내길위해 먼저 세번째 요청에 요청 내용을 직접 살펴본다면, 예를 들어, 요청 헤더외의 다른 정보에 (예를 들어, HTTP 버전)
따라 압축 여부가 결정된다면, (가장 덜 압축) 1과 (가장 많이 압축) 9 사이의 값을 지정한다. 로그에서 더 정확한 값을 추출하려면 type 아규먼트로
기록할 자료를 선택한다. type는 다음중 하나이다: 그래서 이렇게 로그에 기록할 수 있다: Apache HTTP Server Version 2.0 디렉토리의 index는 다음 둘중 한가지 방법으로 제공된다: 두 기능은 서로 별개로 원한다면 자동 index 생성을 완전히
없앨 (혹은 교체할) 수 있다. 이 경우 문서가 반드시 디렉토리에 상대적일 필요는 없다. 이 경우 디렉토리에 사용자가 마지막 슬래쉬없이 디렉토리에 해당하는 자원을
요청하면, 그런데 이 기능을 원하지 않거나 위에 든 이유가
당신에게 알맞지 않다면 다음과 같이 리다이렉션을 하지 않을
수 있다. 마지막 슬래쉬 리다이렉션을 끄면 정보가 유출될 수 있다.
( Apache HTTP Server Version 2.0 내용을 URI를 토대로 만든 키로 캐쉬에 저장하고 가져온다.
접근보호가 된 내용은 캐쉬하지않는다. 함수가 구현되면 더 자세한 내용이 여기 나온다. 함수가 구현되면 더 자세한 내용이 여기 나온다. 함수가 구현되면 더 자세한 내용이 여기 나온다. 함수가 구현되면 더 자세한 내용이 여기 나온다. 함수가 구현되면 더 자세한 내용이 여기 나온다. 함수가 구현되면 더 자세한 내용이 여기 나온다. Apache HTTP Server Version 2.0 The data logging is done right after SSL decoding (for
input) and right before SSL encoding (for output). As can
be expected, this can produce extreme volumes of data,
and should only be used when debugging problems. To enable the module, it should be compiled and
loaded in to your running Apache configuration. Logging
can then be enabled or disabled via the below directives. In order for dumping to work Enable dumping of all input. Enable dumping of all output. Apache HTTP Server Version 2.0 이 모듈은 프로토콜 모듈의 개념을 설명하기위한 예제이다.
이 모듈은 간단한 echo 서버를 구현한다. 이 서버로 telnet하여
무언가를 입력하면, 서버는 입력한 내용이 그대로 반환한다. Apache HTTP Server Version 2.0 이 모듈은 CGI 스크립트나 SSI 페이지에 전달할 환경변수를
조절한다. 웹서버를 시작한 쉘에서 환경변수를 가져올 수 있다.
아니면 설정과정중에 환경변수를 설정하고 제거할 수 있다. 웹서버를 실행한 쉘의 특정 환경변수를 CGI 스크립트나
SSI 페이지로 전달한다. CGI 스크립트나 SSI 페이지에 전달할 환경변수를 설정한다. Apache HTTP Server Version 2.0 아파치 배포본 example 모듈은 실제로 동작하는 모듈이다. 이 모듈을 서버에
연결하고 특정 위치에 "example-handler" 핸들러를 할당하여
그곳을 브라우징하면 example 모듈의 여러 콜백을 확인할 수
있다. 서버에 example 모듈을 포함하려면 다음 과정을 거친다: 자신이 만든 모듈을 추가하려면: example 모듈을 사용하려면 아니면 서버를 재시작한 후 이 위치를 브라우징하면 앞에서 말한
내용을 보게될 것이다. Apache HTTP Server Version 2.0 이 모듈은 서버 응답의 이 HTTP 헤더들은 클라이언트에게 문서의
유효성과 지속성을 알려준다. 이 시간이 아직 지나지않았다면,
문서를 캐쉬에서 가져와도 된다. 만기일이 지났다면 캐쉬된
것을 "만료되고" 유효하지 않다고 간주하여, 소스에서 문서를
새로 얻어와야 한다. <base>는 다음중 하나이다: 예를 들어, 다음 모두는 문서가 기본적으로 접속된지 1달후에
만기된다고 설정한다: '<num> <type>' 구문을 반복해서 사용하여
만기시간을 자세히 설정할 수 있다: 만약 수정시간(modification)을 기준으로 만기시간을 설정하는
경우 내용을 디스크에 있는 파일에서 가져오지 않는다면 Expires
헤더를 붙이지 않는다. 이 경우 내용에 수정시간이
없기 때문이다. 이 지시어는 해당 영역에 대해 (즉, 이 지시어가 이 지시어는 특정 종류의 (에를 들어,
기준 시간은 파일의 최근 수정시간 혹은 클라이언트가 문서에
접근한 시간이다. 이떤 것을 사용할지는
차이는 미묘하다. 이 지시어는 앞에서 설명한 다른 문법을 사용하여
만기시간을 계산할 수도 있다. 이 지시어는 해당 영역에 있는 모든 문서의 만기시간을
계산하는 기본 알고리즘을 지정한다. Apache HTTP Server Version 2.0 실제 사용하기에는 성능이 떨어지지만,
Note: 아래 gzip 예제는 단지 설명을 예로 든 것이다.
실제 서비스에 사용하려면 filtername은 정의할 필터 이름을 지정한다.
이 이름을 SetOutputFilter 지시어에서 사용한다. 등록한 모든
필터들간에 이름이 겹치면 안된다. 현재 필터등록 API는
오류를 보고하지 않는다. 그래서 사용자는 이름이 겹치는 문제를
알지 못한다. 실행할 외부 명령어와 다른 성질을 정의하는 나머지 아규먼트는
어떤 순서로 나와도 가능하다. 단, 주의: 필터 로그를 기록하려면 core 지시어 위의 설정을 사용하면 필터가 표준오류로 출력하는 문구를
아파치 오류로그에 기록하고, Apache HTTP Server Version 2.0 거의 변하지 않고 자주 요청되는 파일을 캐쉬에
저장하여 서버 부하를 줄일 수 있다. 주의: 이 방법은 CGI 프로그램이나 특별한 내용핸들러를
통해 서비스하는 파일의 서비스 속도를 높일 수 없다. 이 방법은
보통 아파치 core 내용핸들러가 서비스하는 일반파일에만
적용된다. 이 모듈은 아파치 1.3에 있는 모든 플래폼이 두 지시어를 모두 지원하는 것은 아니다.
예를 들어, 윈도우즈용 아파치는 현재 서버는 시작할때와 재시작할때만 서버는 시작할때와 재시작할때만 파일 핸들을 캐쉬한다.
그래서 파일시스템에서 캐쉬한 파일중 하나라도 변경되면
서버를 재시작해야 한다 (중단과 재시작 문서 참고).
다시 말해서 파일이 변경되었는데 서버를 재시작하지 않으면
완전히 이상하게 요청을 서비스할지도 모른다. 이전 파일을
지우고(unlink) 그 자리에 새로운 파일을 만드는 방식으로
파일을 수정해야 한다. 디렉토리의 모든 파일을 재귀적으로 캐쉬에 저장하는 지시어는
없다. 대신 다음과 같이 해보라... file-path 아규먼트를 조심해라. 아규먼트는
아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
정확히 일치해야 한다. 한번 더 불필요한 file-path 아규먼트를 조심해라. 아규먼트는
아파치의 URL-파일명 변환 핸들러가 만든 파일시스템 경로와
정확히 일치해야 한다. 한번 더 불필요한 Apache HTTP Server Version 2.0 이 모듈은 HTTP 요청 헤더와 응답 헤더를 조절하고 수정하는
지시어들을 제공한다. 헤더를 합치거나 대체, 제거할 수 있다. 지시어는 아래 순서대로 처리된다. 순서는 중요하다.
다음 두 지시어를 반대로 적으면 효과가 달라진다. 위와 같이 적으면 응답에 다음과 같은 헤더가 생긴다. 응답에 다음과 같은 헤더가 생긴다. HTTP 요청에 이 지시어는 HTTP 응답 헤더를 합치거나 대체, 제거한다.
내용 핸들러와 출력 필터가 실행한 직후에 헤더를 수정하기때문에
보낼 헤더를 수정할 수 있다. condition은 선택적으로 사용하며, 값으로
두번째 아규먼트에 따라 기능이 다르다. 두번째 아규먼트로
아래 값중 하나를 사용할 수 있다. 아규먼트 뒤에 header 이름이 나온다. 헤더명
뒤에 콜론을 적을 수 있지만, 없어도 된다. 응답을 네트웍으로
보내기 직전에 이 지시어는 HTTP 요청 헤더를 합치거나 대체, 제거한다.
내용 핸들러가 실행하기 직전에 헤더를 수정하기때문에 받은
헤더를 수정할 수 있다. 첫번째 아규먼트에 따라 기능이 다르다.
첫번째 아규먼트로 아래 값중 하나를 사용할 수 있다. 아규먼트 뒤에 헤더명이 나온다. 헤더명 뒤에 콜론을 적을
수 있지만, 없어도 된다. 대소문자는 무시한다. fixup 단계에서
요청에 해당하는 핸들러를 실행하기 직전에
Apache HTTP Server Version 2.0 이 모듈은 아래 지시어는 아직도 아래와 같은 설정을 지원한다. 그러나 우리는 점차 "서버에게 특별한 의미가 있는 MIME
type"을 제거하려고 하기때문에 이 방법은 없어질 것이다. 이미지맵 모듈에는 이전 이미지맵 프로그램에는 없는 몇가지
새로운 기능이 있다. 이미지맵 파일은 아래와 같은 형식으로 작성한다. directive는 이미지맵 파일에서 6가지 지시어를 사용할 수 있다. 지시어는
특별한 순서없이 사용할 수 있지만, 이미지맵 파일에 나온
순서대로 처리한다. 지시어에 아래 value를 사용할 수 있다. 상대 URL이나 절대 URL을 사용할 수 있다. 상대 URL에
'..'을 사용할 수 있으며, value 뒤나 좌표 뒤에 쌍따옴표로 묶은 문구를 적을
수도 있다. 이 문자열은 메뉴를 만들때 링크 제목으로 사용한다. 따옴표로 묶은 문구가 없다면 다음과 같이 링크를 링크
제목으로 사용한다. 문구에 쌍따옴표를 쓰려면 Apache HTTP Server Version 2.0 This module provides a filter which will process files
before they are sent to the client. The processing is
controlled by specially formatted SGML comments, referred to as
elements. These elements allow conditional text, the
inclusion of other files or programs, as well as the setting and
printing of environment variables. Server Side Includes are implemented by the
The following directive must be given for the directories
containing the shtml files (typically in a
For backwards compatibility, the For more information, see our Tutorial on Server Side Includes. Files processed for server-side includes no longer accept
requests with The document is parsed as an HTML document, with special
commands embedded as SGML comments. A command has the syntax: The value will often be enclosed in double quotes, but single
quotes ( The allowed elements are listed in the following table: SSI elements may be defined by modules other than
This command controls various aspects of the parsing. The
valid attributes are: This command prints one of the include
variables, defined below. If the variable is unset, the result is
determined by the Attributes: Specifies how Apache should encode special characters
contained in the variable before outputting them. If set
to The The The value specifies a (%-encoded) URL-path to
the CGI script. If the path does not begin with a slash (/),
then it is taken to be relative to the current
document. The document referenced by this path is
invoked as a CGI script, even if the server would not
normally recognize it as such. However, the directory
containing the script must be enabled for CGI scripts
(with The CGI script is given the If the script returns a The The server will execute the given string using
The use of In addition, on some platforms, like Win32, and on unix when
using suexec, you cannot pass arguments
to a command in an This command prints the size of the specified file, subject
to the This command prints the last modification date of the
specified file, subject to the This command inserts the text of another document or file
into the parsed file. Any included file is subject to the
usual access control. If the directory containing the
parsed file has Options
An attribute defines the location of the document; the
inclusion is done for each attribute given to the include
command. The valid attributes are: The value is a (%-encoded) URL-path. The URL cannot contain a
scheme or hostname, only a path and an optional query string. If it
does not begin with a slash (/) then it is taken to be relative to the
current document. A URL is constructed from the attribute, and the output the
server would return if the URL were accessed by the client is
included in the parsed output. Thus included files can be nested. If the specified URL is a CGI program, the program will be
executed and its output inserted in place of the directive in the
parsed file. You may include a query string in a CGI url: This prints out a listing of all existing variables and
their values. Special characters are entity encoded (see the This sets the value of a variable. Attributes: In addition to the variables in the standard CGI environment,
these are available for the Variable substitution is done within quoted strings in most
cases where they may reasonably occur as an argument to an SSI
directive. This includes the If a variable reference needs to be substituted in the
middle of a character sequence that might otherwise be
considered a valid identifier in its own right, it can be
disambiguated by enclosing the reference in braces,
a la shell substitution: This will result in the The below example will print "in foo" if the
The basic flow control elements are: The The The test_condition is one of the following: Compare string1 with string2. If
string2 has the form If you are matching positive ( " The boolean operators Anything that's not recognized as a variable or an operator
is treated as a string. Strings can also be quoted:
This directive changes the string that The This directive has the same effect as the This directive changes the string that You may want to use this option if you have 2 servers parsing the
output of a file each processing different commands (possibly at
different times). The example given above, which also specifies a matching
This directive changes the format in which date strings are displayed
when echoing This directive has the same effect as the The above directive would cause times to be displayed in the
format "22:26, June 14, 2002". This directive changes the string that The You would not want to use the full option, unless you assure the
group-execute bit is unset for every SSI script which might Apache HTTP Server Version 2.0 서버 설정 정보를 아무나 볼 수 없도록 이렇게 설정하면
서버에 특히 이 모듈은 시스템 경로, 사용자명/암호, 데이터베이스
이름과 같이 여러 아파치 모듈의 설정지시어에 기록한 민감한
정보를 유출할 수 있다. 모듈이 동작하는 방식상 이를 막을
방법이 없다. 그래서 이 모듈은 항상 주의해야 하며 통제된
환경에서만 사용해야 한다. module-name 모듈에 대한 추가 정보로
string의 내용을 HTML로 보여준다. 예를 들어, Apache HTTP Server Version 2.0 이 모듈은 Internet Server extension API를 구현한다. 그래서
제약은 있지만 Windows용 아파치에서 Internet Server extension을
(즉, ISAPI .dll 모듈) 사용할 수 있다. ISAPI extension 모듈(.dll 파일)은 제삼자가 작성한다.
Apache Group이 이들 모듈을 만들지 않았으며, 지원도 하지
않는다. ISAPI extension 사용에 관한 문제는 ISAPI 제작자에게
직접 연락하길 바란다. 제발 이런 문제를 아파치
메일링리스트나 버그보고 페이지에 올리지 마라. 서버설정파일에서 아파치 서버는 요청한 모듈을 메모리에 계속 둘 수 없다.
그러나 httpd.conf에서 다음과 같은 설정으로 특정 모듈을 미리
읽어들일 수는 있다. ISAPI extension을 미리 읽어들이던지 미리 읽어들이지 않던지
관계없이 ISAPI extension은 CGI 스크립트와 동일한 권한과
제약을 따른다. 즉, ISAPI .dll 파일이 있는 디렉토리에 아파치 ISAPI 구현은 비동기 입출력에 대한 "마이크로소프트
특유의" 확장기능을 제외한 ISAPI 2.0 규약을 모두 만족한다.
아파치의 입출력 구조로는 ISAPI가 사용할 수 있는 방식으로
비동기 입출력을 할 수 없다. ISA가 비동기 입출력과 같이 지원하지
않는 기능을 사용하려 한다면, 디버깅에 도움을 주기위해 오류
로그에 기록을 남긴다. 로그가 매우 커질 수 있기때문에
Microsoft IIS와 같은 서버는 ISAPI extension을 메모리로
읽어들여서 메모리 사용량이 매우 많지 않거나 특별히 설정하지
않는한 그대로 메모리에 둔다. 아파치는 현재 또, 아파치는 ISAPI Extension을 지원하지만, ISAPI
Filter를 지원하지 않음을 기억하라. 나중에 필터를
지원할 수 있지만, 현재는 계획이 없다. 아파치 2.0 최근 문서를 보면 Microsoft가 두 첫번째로 나온 지원하지 않는 아파치 2.0 ISAPI exntension의 ISAPI exntension의 아파치 서버가 시작할때 메모리로 읽어들여서 서버를 종료할때까지
메모리에 남아있을 파일명을 공백으로 구분하여 지정한다. 이
지시어는 ISAPI .dll 파일별로 여러번 사용할 수 있다. 파일의
전체 경로를 적는다. 절대 경로가 아니면 on으로 설정하면 비동기 ISAPI 콜백 지원을 흉내낸다. ISAPI extension이 지원하지 않는 기능을 요청하면 서버
오류 로그에 기록한다. 나중에 관리자가 문제를 추적하는데
도움이 된다. 원하는 모든 ISAPI 모듈이 정상적으로 동작하면
다시 off로 되돌려야 한다. ISAPI extension을 처음 호출할때 미리읽기버퍼의 최대 크기를
지정한다. (이 크기보다 큰) 나머지 자료는 Apache HTTP Server Version 2.0 This module was created to improve the performance of
websites relying on backend connections to LDAP servers. In
addition to the functions provided by the standard LDAP
libraries, this module adds an LDAP connection pool and an LDAP
shared memory cache. To enable this module, LDAP support must be compiled into
apr-util. This is achieved by adding the SSL support requires that The following is an example configuration that uses
LDAP connections are pooled from request to request. This
allows the LDAP server to remain connected and bound ready for
the next request, without the need to unbind/connect/rebind.
The performance advantages are similar to the effect of HTTP
keepalives. On a busy server it is possible that many requests will try
and access the same LDAP server connection simultaneously.
Where an LDAP connection is in use, Apache will create a new
connection alongside the original one. This ensures that the
connection pool does not become a bottleneck. There is no need to manually enable connection pooling in
the Apache configuration. Any module using this module for
access to LDAP services will share the connection pool. For improved performance, The process of doing a search and then a bind is the
most time-consuming aspect of LDAP operation, especially if
the directory is large. The search/bind cache is used to
cache all searches that resulted in successful binds.
Negative results (i.e., unsuccessful searches, or searches
that did not result in a successful bind) are not cached.
The rationale behind this decision is that connections with
invalid credentials are only a tiny percentage of the total
number of connections, so by not caching invalid
credentials, the size of the cache is reduced. The search and bind cache is controlled with the During attribute and distinguished name comparison
functions, The behavior of both of these caches is controlled with
the By fetching the URL The ability to create an SSL connections to an LDAP server
is defined by the directives If Specifies the maximum size of the primary LDAP cache. This
cache contains successful search/binds. Set it to 0 to turn off
search/bind caching. The default size is 1024 cached
searches. Specifies the time (in seconds) that an item in the
search/bind cache remains valid. The default is 600 seconds (10
minutes). Specifies the timeout value (in seconds) in which the module will
attempt to connect to the LDAP server. If a connection is not
successful with the timeout period, either an error will be
returned or the module will attempt to connect to a secondary LDAP
server if one is specified. The default is 10 seconds. This specifies the number of entries Specifies the time (in seconds) that entries in the
operation cache remain valid. The default is 600 seconds. Specifies the directory path and file name of the shared memory
cache file. If not set, anonymous shared memory will be used if the
platform supports it. Specifies the number of bytes to allocate for the shared
memory cache. The default is 100kb. If set to 0, shared memory
caching will not be used. It specifies the directory path and file name of the trusted CA
The following types are supported: Apache HTTP Server Version 2.0 이 모듈은 클라이언트의 요청을 로그에 자유롭게 기록한다.
자신이 원하는 형식으로 로그를 기록할 수 있고, 파일이나 외부
프로그램에 직접 로그를 보낼 수도 있다. 조건적 로그를 사용하면
요청의 성격에 따라 요청을 로그에 추가하거나 제외할 수 있다. 이 모듈은 세가지 지시어를 제공한다. 요청의 특징은 형식 문자열에 " (아파치 1.3 후반 버전에서 이 지시어는
"..."에는 (예를 들어,
수정자 "<"와 ">"는 내부 리다이렉션된 요청에서 각각
처음 요청을 말할지 마지막 요청을 말할지 선택한다. 기본적으로
2.0.46 이전의 httpd 2.0 버전은 보안상 이유로 2.0.46부터 출력할 수 없는 문자나 다른 특수문자를
일반적으로 많이 사용하는 로그 형식은 다음과 같다. 요청을 서비스하는 서버의 정규 서버가 요청을 로그에 남길때 로그를 기록할 장소를 지정하는 첫번째 아규먼트에는 다음
둘중 하나를 사용한다. 프로그램을 사용한다면 프로그램은 웹서버를 시작한 사용자
권한으로 실행된다. 서버를 root로 시작한다면 프로그램도
root로 실행하므로 프로그램이 안전한지 확인하라. 유닉스가 아닌 플래폼에서 파일경로를 입력할때 플래폼이
백슬래쉬를 사용하더라도 반드시 슬래쉬를 사용해야 한다.
일반적으로 설정파일에서는 항상 슬래쉬를 사용하는 것이
좋다. 두번째 아규먼트는 로그파일에 기록할 내용을 지정한다.
전에 예를 들어, 다음 두 지시어는 똑같은 일을 한다. 세번째 아규먼트는 없어도 되며, 특정 서버 환경변수 유무에
따라 요청을 로그에 기록할지 여부를 결정한다. 요청에 지정한
환경변수가 정의되있다면 (혹은
' 이 지시어는 접근 로그파일의 형식을 지정한다. 이 지시어는 Apache HTTP Server Version 2.0 This module provides for forensic logging of client
requests. Logging is done before and after processing a request, so the
forensic log contains two log lines for each request.
The forensic logger is very strict, which means: The Each request is logged two times. The first time is before it's
processed further (that is, after receiving the headers). The second log
entry is written after the request processing at the same time
where normal logging occurs. In order to identify each request, a unique request ID is assigned.
This forensic ID can be cross logged in the normal transfer log using the
The first line logs the forensic ID, the request line and all received
headers, separated by pipe characters ( The plus character at the beginning indicates that this is the first log
line of this request. The second line just contains a minus character and
the ID again: The See the security tips
document for details on why your security could be compromised
if the directory where logfiles are stored is writable by
anyone other than the user that starts the server. The The argument, which specifies the location to which
the logs will be written, can take one of the following two
types of values: If a program is used, then it will be run as the user who
started When entering a file path on non-Unix platforms, care should be taken
to make sure that only forward slashed are used even though the platform
may allow the use of back slashes. In general it is a good idea to always
use forward slashes throughout the configuration files. Apache HTTP Server Version 2.0 이 모듈은 요청당 입출력 바이트수를 기록한다. 숫자는
네트웍에서 실제로 주고받은 바이트수를 나타내며, 요청과 응답의
헤더와 내용을 포함한다. 개수는 입력의 경우 SSL/TLS 이전에,
출력의 경우 SSL/TLS 이후에 세기때문에 암호화의 결과도
올바로 반영된다. 이 모듈을 사용하려면 이 모듈은 두가지 새로운 로그지시어를 추가한다. 요청자체의
특성은 형식문자열에 " 보통 다음과 같이 사용한다: Apache HTTP Server Version 2.0 이 모듈을 사용하려면 내용은 URI를 키로 사용하여 캐쉬에 저장하고 가져온다.
접근을 제어하는 내용은 캐쉬에 저장하지 않는다. Apache HTTP Server Version 2.0 This module is used to associate various bits of "meta
information" with files by their filename extensions. This
information relates the filename of the document to it's
mime-type, language, character set and encoding. This
information is sent to the browser, and participates in content
negotiation, so the user's preferences are respected when
choosing one of several possible files to serve. See
The directives In addition, While Note that changing the meta-information for a file does not
change the value of the Files can have more than one extension, and the order of the
extensions is normally irrelevant. For example, if the
file Languages and content encodings are treated accumulative, because one can assign
more than one language or encoding to a particular resource. For example,
the file Care should be taken when a file with multiple extensions
gets associated with both a MIME-type and a handler. This will
usually result in the request being by the module associated
with the handler. For example, if the A file of a particular MIME type can additionally be encoded a
particular way to simplify transmission over the Internet.
While this usually will refer to compression, such as
The HTTP/1.1
RFC, section 14.11 puts it this way: The Content-Encoding entity-header field is used as a modifier to
the media-type. When present, its value indicates what additional
content codings have been applied to the entity-body, and thus what
decoding mechanisms must be applied in order to obtain the media-type
referenced by the Content-Type header field. Content-Encoding is
primarily used to allow a document to be compressed without losing
the identity of its underlying media type. By using more than one file extension (see section above about multiple file
extensions), you can indicate that a file is of a
particular type, and also has a particular
encoding. For example, you may have a file which is a Microsoft Word
document, which is pkzipped to reduce its size. If the
Apache sends a In addition to file type and the file encoding,
another important piece of information is what language a
particular document is in, and in what character set the file
should be displayed. For example, the document might be written
in the Vietnamese alphabet, or in Cyrillic, and should be
displayed as such. This information, also, is transmitted in
HTTP headers. The character set, language, encoding and mime type are all
used in the process of content negotiation (See
To convey this further information, Apache optionally sends
a The language specification is the two-letter abbreviation
for the language. The The Then the document The extension argument is case-insensitive, and can
be specified with or without a leading dot. The This will cause filenames containing the Old clients expect The extension argument is case-insensitive, and can
be specified with or without a leading dot. Files having the name extension will be served by the
specified handler-name. This
mapping is added to any already in force, overriding any mappings that
already exist for the same extension. For example, to
activate CGI scripts with the file extension Once that has been put into your httpd.conf file, any file containing
the The extension argument is case-insensitive, and can
be specified with or without a leading dot. If more than one filter is specified, they must be separated
by semicolons in the order in which they should process the
content. Both the filter and extension arguments are
case-insensitive, and the extension may be specified with or
without a leading dot. The Then the document If multiple language assignments are made for the same
extension, the last one encountered is the one that is used.
That is, for the case of: documents with the extension The extension argument is case-insensitive, and can
be specified with or without a leading dot. The For example, the following configuration will process all
If more than one filter is specified, they must be separated
by semicolons in the order in which they should process the
content. Both the filter and extension arguments
are case-insensitive, and the extension may be specified with or
without a leading dot. The The extension argument is case-insensitive, and can
be specified with or without a leading dot. The If no The This directive is recommended when you have a virtual filesystem. If you have a request for The To include extensions associated with Handlers and/or Filters,
set the You may finally allow For example, the following configuration will allow handlers
and filters to participate in Multviews, but will exclude unknown
files: The The extension argument is case-insensitive, and can
be specified with or without a leading dot. The This will cause The extension argument is case-insensitive, and can
be specified with or without a leading dot. The This has the effect of returning The extension argument is case-insensitive, and can
be specified with or without a leading dot. The The extension argument is case-insensitive, and can
be specified with or without a leading dot. The The extension argument is case-insensitive, and can
be specified with or without a leading dot. The The extension argument is case-insensitive, and can
be specified with or without a leading dot. The This will remove any special handling of The extension argument is case-insensitive, and can
be specified with or without a leading dot. The The file contains lines in the format of the arguments to
an The case of the extension does not matter. Blank lines, and lines
beginning with a hash character ( Apache HTTP Server Version 2.0 This module determines the MIME type of files in the same
way the Unix This module is derived from a free version of the
The contents of the file are plain ASCII text in 4-5
columns. Blank lines are allowed but ignored. Commented lines
use a hash mark ( type of data to match For example, the following magic file lines would recognize
some audio formats: Or these would recognize the difference between An optional MIME encoding can be included as a fifth column.
For example, this can recognize gzipped files and set the
encoding for them. This module is not for every system. If your system is barely
keeping up with its load or if you're performing a web server
benchmark, you may not want to enable this because the
processing is not free. However, an effort was made to improve the performance of
the original The following notes apply to the mod_mime_magic: MIME type lookup via file magic numbers This software was submitted by Cisco Systems to the Apache Group
in July 1997. Future revisions and derivatives of this source code
must acknowledge Cisco Systems as the original contributor of this
module. All other licensing and usage conditions are those of the
Apache Group. Some of this code is derived from the free version of the file
command originally posted to comp.sources.unix. Copyright info for
that program is included below as required. - Copyright (c) Ian F. Darwin, 1987. Written by Ian F. Darwin. This software is not subject to any license of the American
Telephone and Telegraph Company or of the Regents of the University
of California. Permission is granted to anyone to use this software for any
purpose on any computer system, and to alter it and redistribute it
freely, subject to the following restrictions: For compliance with Mr Darwin's terms: this has been very
significantly modified from the free "file" command. The Apache HTTP Server Version 2.0 Content negotiation, or more accurately content selection, is
the selection of the document that best matches the clients
capabilities, from one of several available documents. There
are two implementations of this. A type map has a format similar to RFC822 mail headers. It
contains document descriptions separated by blank lines, with
lines beginning with a hash character ('#') treated as
comments. A document description consists of several header
records; records may be continued on multiple lines if the
continuation lines start with spaces. The leading space will be
deleted and the lines concatenated. A header record consists of
a keyword name, which always ends in a colon, followed by a
value. Whitespace is allowed between the header name and value,
and between the tokens of value. The headers allowed are: A MultiViews search is enabled by the The If set, this directive allows content-negotiated documents
to be cached by proxy servers. This could mean that clients
behind those proxys could retrieve versions of the documents
that are not the best match for their abilities, but it will
make caching more efficient. This directive only applies to requests which come from
HTTP/1.0 browsers. HTTP/1.1 provides much better control over
the caching of negotiated documents, and this directive has no
effect in responses to HTTP/1.1 requests. Prior to version 2.0,
The Both options, The For a request for Note that this directive only has an effect if a 'best'
language cannot be determined by any other means or the Apache HTTP Server Version 2.0 This module enables SSL encryption for a specified port. It
takes advantage of the SSL encryption functionality that is
built into the NetWare operating system. Specifies a list of client certificate files (DER format)
that are used when creating a proxied SSL connection. Each
client certificate used by a server must be listed separately
in its own Allow a connection that was created on the specified address
and/or port to be upgraded to an SSL connection upon request from
the client. The address and/or port must have already be defined
previously with a Specifies the port and the eDirectory based certificate name
that will be used to enable SSL encryption. An optional third
parameter also enables mutual authentication. Apache HTTP Server Version 2.0 Do not enable proxying with This module implements a proxy/gateway for Apache. It implements
proxying capability for Apache's proxy features are divided into several modules in
addition to In addition, extended features are provided by other modules.
Caching is provided by Apache can be configured in both a forward and
reverse proxy mode. An ordinary forward proxy is an intermediate
server that sits between the client and the origin
server. In order to get content from the origin server,
the client sends a request to the proxy naming the origin server
as the target and the proxy then requests the content from the
origin server and returns it to the client. The client must be
specially configured to use the forward proxy to access other
sites. A typical usage of a forward proxy is to provide Internet
access to internal clients that are otherwise restricted by a
firewall. The forward proxy can also use caching (as provided
by The forward proxy is activated using the A reverse proxy, by contrast, appears to the
client just like an ordinary web server. No special
configuration on the client is necessary. The client makes
ordinary requests for content in the name-space of the reverse
proxy. The reverse proxy then decides where to send those
requests, and returns the content as if it was itself the
origin. A typical usage of a reverse proxy is to provide Internet
users access to a server that is behind a firewall. Reverse
proxies can also be used to balance load among several back-end
servers, or to provide caching for a slower back-end server.
In addition, reverse proxies can be used simply to bring
several servers into the same URL space. A reverse proxy is activated using the The examples below are only a very basic idea to help you
get started. Please read the documentation on the individual
directives. In addition, if you wish to have caching enabled, consult
the documentation from You can control who can access your proxy via the For more information on access control directives, see
Strictly limiting access is essential if you are using a
forward proxy (using the You probably don't have that particular file type defined as
In the rare situation where you must download a specific file using the
FTP An FTP URI is interpreted relative to the home directory of the user
who is logging in. Alas, to reach higher directory levels you cannot
use /../, as the dots are interpreted by the browser and not actually
sent to the FTP server. To address this problem, the so called Squid
%2f hack was implemented in the Apache FTP proxy; it is a
solution which is also used by other popular proxy servers like the Squid Proxy Cache. By
prepending To log in to an FTP server by username and password, Apache uses
different strategies. In absense of a user name and password in the URL
altogether, Apache sends an anonymous login to the FTP server,
i.e., This works for all popular FTP servers which are configured for
anonymous access. For a personal login with a specific username, you can embed the user
name into the URL, like in: If the FTP server asks for a password when given this username (which
it should), then Apache will reply with a in the first place). The password which is transmitted in such a way is not encrypted on
its way. It travels between your browser and the Apache proxy server in
a base64-encoded cleartext string, and between the Apache proxy and the
FTP server as plaintext. You should therefore think twice before
accessing your FTP server via HTTP (or before accessing your personal
files via FTP at all!) When using unsecure channels, an eavesdropper
might intercept your password on its way. If you're using the An Apache proxy server situated in an intranet needs to forward
external requests through the company's firewall (for this, configure
the Users within an intranet tend to omit the local domain name from their
WWW requests, thus requesting "http://somehost/" instead of
For circumstances where you have a application server which doesn't
implement keepalives or HTTP/1.1 properly, there are 2 environment
variables which when set send a HTTP/1.0 with no keepalive. These are set
via the These are the The By default, only the default https port ( Note that you'll need to have This directive is only useful for Apache proxy servers within
intranets. The The host arguments to the A Domain is a partially qualified DNS domain name, preceded
by a period. It represents a list of hosts which logically belong to the
same DNS domain or zone (i.e., the suffixes of the hostnames are
all ending in Domain). To distinguish Domains from Hostnames (both syntactically and semantically; a DNS domain can
have a DNS A record, too!), Domains are always written with a
leading period. Domain name comparisons are done without regard to the case, and
Domains are always assumed to be anchored in the root of the
DNS tree, therefore two domains A SubNet is a partially qualified internet address in
numeric (dotted quad) form, optionally followed by a slash and the netmask,
specified as the number of significant bits in the SubNet. It is
used to represent a subnet of hosts which can be reached over a common
network interface. In the absence of the explicit net mask it is assumed
that omitted (or zero valued) trailing digits specify the mask. (In this
case, the netmask can only be multiples of 8 bits wide.) Examples: As a degenerate case, a SubNet with 32 valid bits is the
equivalent to an IPAddr, while a SubNet with zero
valid bits (e.g., 0.0.0.0/0) is the same as the constant
_Default_, matching any IP address. A IPAddr represents a fully qualified internet address in
numeric (dotted quad) form. Usually, this address represents a host, but
there need not necessarily be a DNS domain name connected with the
address. An IPAddr does not need to be resolved by the DNS system, so
it can result in more effective apache performance. A Hostname is a fully qualified DNS domain name which can
be resolved to one or more IPAddrs via the
DNS domain name service. It represents a logical host (in contrast to
Domains, see above) and must be resolvable
to at least one IPAddr (or often to a list
of hosts with different IPAddrs). In many situations, it is more effective to specify an IPAddr in place of a Hostname since a
DNS lookup can be avoided. Name resolution in Apache can take a remarkable
deal of time when the connection to the name server uses a slow PPP
link. Hostname comparisons are done without regard to the case,
and Hostnames are always assumed to be anchored in the root
of the DNS tree, therefore two hosts Directives placed in For example, the following will allow only hosts in
The following example will process all files in the The The Note that Note also that blocks connections to all sites. This directive is only useful for Apache proxy servers within
intranets. The This directive is useful for reverse-proxy setups, where you want to
have a common look and feel on the error pages seen by the end user.
This also allows for included files (via mod_include's SSI) to get
the error code and act accordingly (default behavior would display
the error page of the proxied server, turning this on shows the SSI
Error message). The The In almost every case there's no reason to change that value. The The This directive allows remote servers to be mapped into the space of
the local server; the local server does not act as a proxy in the
conventional sense, but appears to be a mirror of the remote
server. path is the name of a local virtual path; url
is a partial URL for the remote server and cannot include a query
string. Suppose the local server has address will cause a local request for
The will proxy all requests to Order is important. you need to put the exclusions before the
general proxypass directive. When used inside a If you require a more flexible reverse-proxy configuration, see the
This directive lets Apache adjust the URL in the Only the HTTP response headers specifically mentioned above
will be rewritten. Apache will not rewrite other response
headers, nor will it rewrite URL references inside HTML pages.
This means that if the proxied content contains absolute URL
references, they will by-pass the proxy. A third-party module
that will look inside the HTML and rewrite URL references is Nick
Kew's mod_proxy_html. path is the name of a local virtual path. url is a
partial URL for the remote server - the same way they are used for the
For example, suppose the local server has address
will not only cause a local request for the
Note that this When used inside a When enabled, this option will pass the Host: line from the incoming
request to the proxied host, instead of the hostname specified in the
proxypass line. This option should normally be turned The This defines remote proxies to this proxy. match is either the
name of a URL-scheme that the remote server supports, or a partial URL
for which the remote server should be used, or scheme is effectively the protocol that should be used to
communicate with the remote server; only In the last example, the proxy will forward FTP requests, encapsulated
as yet another HTTP proxy request, to another proxy which can handle
them. This option also supports reverse proxy configuration - a backend
webserver can be embedded within a virtualhost URL space even if that
server is hidden by another forward proxy. The This allows or prevents Apache from functioning as a forward proxy
server. (Setting ProxyRequests to In a typical reverse proxy configuration, this option should be set to
In order to get the functionality of proxying HTTP or FTP sites, you
need also Do not enable proxying with This directive allows a user to specifiy a timeout on proxy requests.
This is useful when you have a slow/buggy appserver which hangs, and you
would rather just return a timeout and fail gracefully instead of waiting
however long it takes the server to return. This directive controls the use of the Apache HTTP Server Version 2.0 This module requires the service of Thus, in order to get the ability of handling Do not enable proxying until you have secured your server. Open proxy
servers are dangerous both to your network and to the Internet at
large. Apache HTTP Server Version 2.0 This module requires the service of Thus, in order to get the ability of handling FTP proxy requests,
Do not enable proxying until you have secured your server. Open proxy
servers are dangerous both to your network and to the Internet at
large. Apache HTTP Server Version 2.0 This module requires the service of Thus, in order to get the ability of handling HTTP proxy requests,
Do not enable proxying until you have secured your server. Open proxy
servers are dangerous both to your network and to the Internet at
large. Apache HTTP Server Version 2.0 This module uses a rule-based rewriting engine (based on a
regular-expression parser) to rewrite requested URLs on the
fly. It supports an unlimited number of rules and an
unlimited number of attached rule conditions for each rule, to
provide a really flexible and powerful URL manipulation
mechanism. The URL manipulations can depend on various tests,
of server variables, environment variables, HTTP
headers, or time stamps. Even external database lookups in
various formats can be used to achieve highly granular URL
matching. This module operates on the full URLs (including the
path-info part) both in per-server context
( Further details, discussion, and examples, are provided in the
detailed mod_rewrite documentation. Apache processes a HTTP request in several phases.
A hook for each of these
phases is provided by the Apache API. Once a request comes in, and Apache has determined the
appropriate server (or virtual server), the rewrite engine
starts the URL-to-filename translation,
processing the mod_rewrite directives from the
per-server configuration. A few
steps later, when the final data directories are found, the
per-directory configuration directives of mod_rewrite are
triggered in the Fixup phase. When mod_rewrite is triggered during these two API phases, it
reads the relevant rulesets from its configuration
structure (which was either created on startup, for
per-server context, or during the directory traversal
for per-directory context). The URL rewriting
engine is started with the appropriate ruleset (one or more
rules together with their conditions), and its operation
is exactly the same for both
configuration contexts. Only the final result processing is
different. The order of rules in the ruleset is important because the
rewrite engine processes them in a particular (not always
obvious) order, as follows: The rewrite engine loops
through the rulesets (each ruleset being made up of
As above, first the URL is matched against the
Pattern of a rule. If it does not match, If Using parentheses in Pattern or in one of the
CondPatterns causes back-references to be internally
created.
These can later be referenced using the strings
As of Apache 1.3.20, special characters in
TestString and Substitution strings can be
escaped (that is, treated as normal characters without their
usual special meaning) by prefixing them with a slash ('\')
character. In other words, you can include an actual
dollar-sign character in a Substitution string by
using ' This module keeps track of two additional (non-standard)
CGI/SSI environment variables named Notice: These variables hold the URI/URL as they were
initially requested, that is, before any
rewriting. This is important to note because the rewriting process is
primarily used to rewrite logical URLs to physical
pathnames. For numerous examples of common, and not-so-common, uses for
mod_rewrite, see the Rewrite
Guide, and the Advanced Rewrite
Guide documents. The When a substitution occurs for a new URL, this module has
to re-inject the URL into the server processing. To be able
to do this it needs to know what the corresponding URL-prefix
or URL-base is. By default this prefix is the corresponding
filepath itself. However, for most websites, URLs are NOT
directly related to physical filename paths, so this
assumption will often be wrong! Therefore, you can
use the For example, assume the following per-directory config file: In the above example, a request to
The following list gives detailed information about
the internal processing steps: This seems very complicated, but is in fact
correct Apache internal processing. Because the
per-directory rewriting comes late in the
process, the rewritten request
has to be re-injected into the Apache kernel.
This is not the serious overhead it may seem to be -
this re-injection is completely internal to the
Apache server (and the same procedure is used by
many other operations within Apache). The TestString is a string which can contain the
following expanded constructs in addition to plain text: These variables all
correspond to the similarly named HTTP
MIME-headers, C variables of the Apache server or
Other things you should be aware of: For instance, to rewrite according to the
On the other hand, because mod_rewrite implements
its per-directory context ( CondPattern is the condition pattern,
a regular expression which is applied to the
current instance of the TestString.
TestString is first evaluated, before being matched against
CondPattern. Remember: CondPattern is a
perl compatible regular expression with some
additions: Example: To rewrite the Homepage of a site according to the
`` Explanation: If you use a browser which identifies itself
as 'Mozilla' (including Netscape Navigator, Mozilla etc), then you
get the max homepage (which could include frames, or other special
features).
If you use the Lynx browser (which is terminal-based), then
you get the min homepage (which could be a version designed for
easy, text-only browsing).
If neither of these conditions apply (you use any other browser,
or your browser identifies itself as something non-standard), you get
the std (standard) homepage. The Use this directive to disable the module instead of
commenting out all the Note that, by default, rewrite configurations are not
inherited. This means that you need to have a
This directive sets the filename for a synchronization
lockfile which mod_rewrite needs to communicate with The The To disable the logging of rewriting actions simply set
Level to 0. This disables all rewrite action
logs. The The MapName is
the name of the map and will be used to specify a
mapping-function for the substitution strings of a rewriting
rule via one of the following constructs:
When such a construct occurs, the map MapName is
consulted and the key LookupKey is looked-up. If the
key is found, the map-function construct is substituted by
SubstValue. If the key is not found then it is
substituted by DefaultValue or by the empty string
if no DefaultValue was specified. For example, you might define a
You would then be able to use this map in a
The following combinations for MapType and
MapSource can be used: This is the standard rewriting map feature where the
MapSource is a plain ASCII file containing
either blank lines, comment lines (starting with a '#'
character) or pairs like the following - one per
line.
MatchingKey
SubstValue
This is identical to the Standard Plain Text variant
above but with a special post-processing feature: After
looking up a value it is parsed according to contained
`` Example: Here the source is a binary format DBM file containing
the same contents as a Plain Text format file, but
in a special representation which is optimized for really
fast lookups. The type can be sdbm, gdbm, ndbm, or
db depending on compile-time
settings. If the type is ommitted, the
compile-time default will be chosen. You can create such a
file with any DBM tool or with the following Perl
script. Be sure to adjust it to create the appropriate
type of DBM. The example creates an NDBM file. Here, the source is an internal Apache function.
Currently you cannot create your own, but the following
functions already exist: Here the source is a program, not a map file. To
create it you can use a language of your choice, but
the result has to be an executable program (either
object-code or a script with the magic cookie trick
' This program is started once, when the Apache server
is started, and then communicates with the rewriting engine
via its But be very careful: The The The Pattern is
a perl compatible regular
expression, which is applied to the current URL.
``Current'' means the value of the URL when this rule is
applied. This may not be the originally requested URL,
which may already have matched a previous rule, and have
been altered. Some hints on the syntax of regular expressions: For more information about regular expressions, have a look at the
perl regular expression manpage ("perldoc
perlre"). If you are interested in more detailed
information about regular expressions and their variants
(POSIX regex etc.) the following book is dedicated to this topic:
Mastering Regular Expressions, 2nd Edition In mod_rewrite, the NOT character
(' The substitution of a
rewrite rule is the string which is substituted for (or
replaces) the original URL which Pattern
matched. In addition to plain text, it can include Back-references are identifiers of the form
As already mentioned, all rewrite rules are
applied to the Substitution (in the order in which
they are defined
in the config file). The URL is completely
replaced by the Substitution and the
rewriting process continues until all rules have been applied,
or it is explicitly terminated by a
There is a special substitution string named
' Additionally you can set special flags for Substitution by
appending Note: Note: You must use this flag if you want to
mix directives from different modules which allow
URL-to-filename translators. The typical example
is the use of When the substitution string begins with a string
resembling "/~user" (via explicit text or backreferences), mod_rewrite performs
home directory expansion independent of the presence or configuration
of This expansion does not occur when the PT
flag is used on the There is one exception: If a substitution string
starts with `` When you prefix a substitution field with
Remember: An unconditional external
redirect to your own server will not work with the prefix
The Pattern will not be matched against the query string.
Instead, you must use a Here are all possible substitution combinations and their
meanings: Inside per-server configuration
( Inside per-directory configuration for
Apache HTTP Server Version 2.0 설정파일에 나오는 순서대로 지시어를 처리한다. 그래서
브라우저가 MSIE가 아니라 mozilla인 경우 추가 예제: 두번째 아규먼트는 (regex) Perl 호환 정규표현식이다.
이는 POSIX.2 egrep의 정규표현식과 비슷하다. regex가
attribute에 대응하면 나머지 아규먼트를 처리한다. 나머지 아규먼트는 설정할 변수명과 (선택적인) 설정값들이다.
다음과 같은 형식이다 첫번째 형태는 값으로 "1"을 사용한다. 두번째 형태는 변수가
이미 정의된 경우 변수를 제거하고, 세번째는 변수의 값으로
처음 세 줄은 이미지 파일을 요청한 경우 환경변수
마지막 예는 요청에 이름에 "TS"로 시작하고 값이 [a-z]
중 하나로 시작하는 헤더가 있는 경우 환경변수
이 경우 HTTP 요청 헤더 Apache HTTP Server Version 2.0 몇몇 운영체제에서 아파치는 동적공유객체
(DSO) 기술을 사용하여 서버를 다시 컴파일하지 않고도 실행중에
모듈을 읽어들일 수 있다. 읽어들일 코드는, 유닉스에서는 ( 아파치 1.3 모듈을 아파치 2.0에서 사용할 수 없다.
아파치 2.0이 동적으로 읽어들이거나 아파치와 같이 컴파일하려면
모듈을 수정해야 한다. 윈도우즈의 모듈명 형식은 아파치 1.3.15와 2.0에서 변경되었다.
모듈명은 이제 mod_foo.so식이다. mod_so는 아직도 ApacheModuleFoo.dll 식의 모듈을 읽어들일
수 있지만, 새로운 이름 규칙을 선호한다. 모듈을 2.0에 맞게
수정한다면 이름을 2.0 규칙에 알맞게 고치길 바란다. 아파치 모듈 API는 유닉스 버전이거나 윈도우즈 버전이거나
같다. 몇몇 API는 윈도우즈에 없는 유닉스 구조에 의존하기때문에
사용할 수 없지만, 유닉스에서 실행되는 많은 모듈을 수정없이
혹은 조금 수정하여 윈도우즈에서 사용할 수 있다. 모듈은 두가지 방법으로 서버에 추가할 수 있다. 유닉스에서는
모듈을 서버와 같이 컴파일할 수 있다. 윈도우즈용 아파치는
유닉스와 달리 두번째 방법은 모듈을 서버가
모듈 DLL을 만들기위해서는 모듈의 소스파일을 조금 수정해야
한다. DLL은 module record를 export해야 한다. (아래 참고)
이를 위해 모듈의 module record 정의에 (아파치 헤더파일에
정의된) 다음과 같이 수정한다: 이 부분은 윈도우즈에서만 사용하기때문에 변경하여도 유닉스에서
소스를 그대로 사용할 수 있다. 또, 이제 모듈을 포함한 DLL을 만든다. 이를 공유라이브러리
libhttpd.dll을 컴파일할때 만든 libhttpd.lib export 라이브러리와
링크한다. 아파치 헤더파일을 올바로 찾도록 컴파일러 설정을
수정해야 할지도 모른다. 서버의 modules 디렉토리에서 이
라이브러리를 찾을 수 있다. 컴파일환경을 올바로 설정하기위해
기존 모듈의 .dsp 파일을 가져다 쓰거나 직접 만든 .dsp와
컴파일러/링커 옵션을 비교하는 것이 좋다. 이제 모듈을 DLL로 만든다. 이것을 서버의
LoadFile 지시어는 서버가 시작하거나 재시작할때 지정한
목적파일이나 라이브러리를 읽어들인다(link in). 이 지시어는
어떤 모듈이 동작하기위해 필요한 코드를 추가로 읽어들일때
사용한다. Filename은 절대경로이거나 ServerRoot에 대한 상대경로이다. 예를 들어: LoadModule 지시어는 목적파일 혹은 라이브러리 filename을
읽어들이고, 사용가능한 모듈 목록에 module이라는
모듈 구조체를 추가한다. Module은 파일의
ServerRoot의 modules 하위디렉토리에서 지정한 모듈을 읽어들인다. Apache HTTP Server Version 2.0 종종 맞춤법이 틀리거나 대소문자를 잘못 사용하여 아파치가
문서 요청을 서비스할 수 없는 경우가 있다. 이 모듈은 다른
모든 모듈들이 포기한 요청에 해당하는 문서를 찾는다. 모듈은
요청한 디렉토리 안에 있는 모든 문서를 요청한 문서이름과
대소문자 구별없이 (문자 첨가 / 생략 / 교체
혹은 잘못된 문자 ) 맞춤법이 한번까지 틀려도
봐주며 비교한다. 이런 방법으로 문서목록을 만든다. 디렉토리를 살펴본 후에, 이 지시어는 맞춤법 모듈의 사용여부를 결정한다. 사용한다면
다음을 주의하라 Apache HTTP Server Version 2.0 This module provides SSL v2/v3 and TLS v1 support for the Apache
HTTP Server. It was contributed by Ralf S. Engeschall based on his
mod_ssl project and originally derived from work by Ben Laurie. This module relies on OpenSSL
to provide the cryptography engine. Further details, discussion, and examples are provided in the
SSL documentation. This module provides a lot of SSL information as additional environment
variables to the SSI and CGI namespace. The generated variables are listed in
the table below. For backward compatibility the information can
be made available under different names, too. Look in the Compatibility chapter for details on the
compatibility variables. [ where x509 is a component of a X.509 DN:
When
For backward compatibility there is additionally a special
``
Example:
This directive sets the all-in-one file where you can assemble the
Certificates of Certification Authorities (CA) whose clients you deal
with. These are used for Client Authentication. Such a file is simply the
concatenation of the various PEM-encoded Certificate files, in order of
preference. This can be used alternatively and/or additionally to
This directive sets the directory where you keep the Certificates of
Certification Authorities (CAs) whose clients you deal with. These are used to
verify the client certificate on Client Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you can't just place the Certificate files
there: you also have to create symbolic links named
hash-value
This directive sets the all-in-one file where you can
assemble the Certificate Revocation Lists (CRL) of Certification
Authorities (CA) whose clients you deal with. These are used
for Client Authentication. Such a file is simply the concatenation of
the various PEM-encoded CRL files, in order of preference. This can be
used alternatively and/or additionally to
This directive sets the directory where you keep the Certificate Revocation
Lists (CRL) of Certification Authorities (CAs) whose clients you deal with.
These are used to revoke the client certificate on Client Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you have not only to place the CRL files there.
Additionally you have to create symbolic links named
hash-value
This directive sets the optional all-in-one file where you can
assemble the certificates of Certification Authorities (CA) which form the
certificate chain of the server certificate. This starts with the issuing CA
certificate of of the server certificate and can range up to the root CA
certificate. Such a file is simply the concatenation of the various
PEM-encoded CA Certificate files, usually in certificate chain order.
This should be used alternatively and/or additionally to
But be careful: Providing the certificate chain works only if you are using a
single (either RSA or DSA) based server certificate. If you are
using a coupled RSA+DSA certificate pair, this will work only if actually both
certificates use the same certificate chain. Else the browsers will be
confused in this situation.
This directive points to the PEM-encoded Certificate file for the server and
optionally also to the corresponding RSA or DSA Private Key file for it
(contained in the same file). If the contained Private Key is encrypted the
Pass Phrase dialog is forced at startup time. This directive can be used up to
two times (referencing different filenames) when both a RSA and a DSA based
server certificate is used in parallel.
This directive points to the PEM-encoded Private Key file for the
server. If the Private Key is not combined with the Certificate in the
This complex directive uses a colon-separated cipher-spec string
consisting of OpenSSL cipher specifications to configure the Cipher Suite the
client is permitted to negotiate in the SSL handshake phase. Notice that this
directive can be used both in per-server and per-directory context. In
per-server context it applies to the standard SSL handshake when a connection
is established. In per-directory context it forces a SSL renegotation with the
reconfigured Cipher Suite after the HTTP request was read but before the HTTP
response is sent.
An SSL cipher specification in cipher-spec is composed of 4 major
attributes plus a few extra minor ones: An SSL cipher can also be an export cipher and is either a SSLv2 or SSLv3/TLSv1
cipher (here TLSv1 is equivalent to SSLv3). To specify which ciphers to use,
one can either specify all the Ciphers, one at a time, or use aliases to
specify the preference and order for the ciphers (see Table
1).
Now where this becomes interesting is that these can be put together
to specify the order and ciphers you wish to use. To speed this up
there are also aliases ( A simpler way to look at all of this is to use the `` The complete list of particular RSA & DH ciphers for SSL is given in Table 2.
This directive toggles the usage of the SSL/TLS Protocol Engine. This
is usually used inside a
This configures the SSL engine's semaphore (aka. lock) which is used for mutual
exclusion of operations which have to be done in a synchronized way between the
pre-forked Apache server processes. This directive can only be used in the
global server context because it's only useful to have one global mutex.
This directive is designed to closely match the
AcceptMutex directive
The following Mutex types are available:
This is the default where no Mutex is used at all. Use it at your own
risk. But because currently the Mutex is mainly used for synchronizing
write access to the SSL Session Cache you can live without it as long
as you accept a sometimes garbled Session Cache. So it's not recommended
to leave this the default. Instead configure a real Mutex.
This is an elegant Mutex variant where a Posix Semaphore is used when possible.
It is only available when the underlying platform
and APR supports it.
This is a somewhat elegant Mutex variant where a SystemV IPC Semaphore is used when
possible. It is possible to "leak" SysV semaphores if processes crash before
the semaphore is removed. It is only available when the underlying platform
and APR supports it.
This directive tells the SSL Module to pick the "best" semaphore implementation
available to it, choosing between Posix and SystemV IPC, in that order. It is only
available when the underlying platform and APR supports at least one of the 2.
This directive tells the SSL Module to use Posix thread mutexes. It is only available
if the underlying platform and APR supports it.
This is a portable Mutex variant where a physical (lock-)file and the
This is similar to the
This directive tells the SSL Module to pick the "best" file locking implementation
available to it, choosing between
This directive tells the SSL Module to pick the default locking implementation
as determined by the platform and APR.
This directive can be used to control various run-time options on a
per-directory basis. Normally, if multiple
The available options are:
When this option is enabled, the standard set of SSL related CGI/SSI
environment variables are created. This per default is disabled for
performance reasons, because the information extraction step is a
rather expensive operation. So one usually enables this option for
CGI and SSI requests only.
When this option is enabled, additional CGI/SSI environment variables are
created for backward compatibility to other Apache SSL solutions. Look in
the Compatibility chapter for details
on the particular variables generated.
When this option is enabled, additional CGI/SSI environment variables are
created:
When this option is enabled, the Subject Distinguished Name (DN) of the
Client X509 Certificate is translated into a HTTP Basic Authorization
username. This means that the standard Apache authentication methods can
be used for access control. The user name is just the Subject of the
Client's X509 Certificate (can be determined by running OpenSSL's
This forces forbidden access when
This enables optimized SSL connection renegotiation handling when SSL
directives are used in per-directory context. By default a strict
scheme is enabled where every per-directory reconfiguration of
SSL parameters causes a full SSL renegotiation handshake. When this
option is used mod_ssl tries to avoid unnecessary handshakes by doing more
granular (but still safe) parameter checks. Nevertheless these granular
checks sometimes maybe not what the user expects, so enable this on a
per-directory basis only, please.
When Apache starts up it has to read the various Certificate (see
This is the default where an interactive terminal dialog occurs at startup
time just before Apache detaches from the terminal. Here the administrator
has to manually enter the Pass Phrase for each encrypted Private Key file.
Because a lot of SSL-enabled virtual hosts can be configured, the
following reuse-scheme is used to minimize the dialog: When a Private Key
file is encrypted, all known Pass Phrases (at the beginning there are
none, of course) are tried. If one of those known Pass Phrases succeeds no
dialog pops up for this particular Private Key file. If none succeeded,
another Pass Phrase is queried on the terminal and remembered for the next
round (where it perhaps can be reused).
This scheme allows mod_ssl to be maximally flexible (because for N encrypted
Private Key files you can use N different Pass Phrases - but then
you have to enter all of them, of course) while minimizing the terminal
dialog (i.e. when you use a single Pass Phrase for all N Private Key files
this Pass Phrase is queried only once).
Here an external program is configured which is called at startup for each
encrypted Private Key file. It is called with two arguments (the first is
of the form ``
Both these security checks, and the way the Pass Phrase is determined, can
be as complex as you like. Mod_ssl just defines the interface: an
executable program which provides the Pass Phrase on
The reuse-algorithm above is used here, too. In other words: The external
program is called only once per unique Pass Phrase.
Example:
This directive can be used to control the SSL protocol flavors mod_ssl should
use when establishing its server environment. Clients then can only connect
with one of the provided protocols.
The available (case-insensitive) protocols are:
This is the Secure Sockets Layer (SSL) protocol, version 2.0. It is the
original SSL protocol as designed by Netscape Corporation.
This is the Secure Sockets Layer (SSL) protocol, version 3.0. It is the
successor to SSLv2 and the currently (as of February 1999) de-facto
standardized SSL protocol from Netscape Corporation. It's supported by
almost all popular browsers.
This is the Transport Layer Security (TLS) protocol, version 1.0. It is the
successor to SSLv3 and currently (as of February 1999) still under
construction by the Internet Engineering Task Force (IETF). It's still
not supported by any popular browsers.
This is a shortcut for ``
This directive sets the all-in-one file where you can assemble the
Certificates of Certification Authorities (CA) whose remote servers you deal
with. These are used for Remote Server Authentication. Such a file is simply the
concatenation of the various PEM-encoded Certificate files, in order of
preference. This can be used alternatively and/or additionally to
This directive sets the directory where you keep the Certificates of
Certification Authorities (CAs) whose remote servers you deal with. These are used to
verify the remote server certificate on Remote Server Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you can't just place the Certificate files
there: you also have to create symbolic links named
hash-value
This directive sets the all-in-one file where you can
assemble the Certificate Revocation Lists (CRL) of Certification
Authorities (CA) whose remote servers you deal with. These are used
for Remote Server Authentication. Such a file is simply the concatenation of
the various PEM-encoded CRL files, in order of preference. This can be
used alternatively and/or additionally to
This directive sets the directory where you keep the Certificate Revocation
Lists (CRL) of Certification Authorities (CAs) whose remote servers you deal with.
These are used to revoke the remote server certificate on Remote Server Authentication.
The files in this directory have to be PEM-encoded and are accessed through
hash filenames. So usually you have not only to place the CRL files there.
Additionally you have to create symbolic links named
hash-value Equivalent to
This directive toggles the usage of the SSL/TLS Protocol Engine for proxy. This
is usually used inside a
This directive sets the all-in-one file where you keep the certificates and
keys used for authentication of the proxy server to remote servers.
This referenced file is simply the concatenation of the various PEM-encoded
certificate files, in order of preference. Use this directive alternatively
or additionally to Currently there is no support for encrypted private keys
Example:
This directive sets the directory where you keep the certificates and
keys used for authentication of the proxy server to remote servers.
The files in this directory must be PEM-encoded and are accessed through
hash filenames. Additionally, you must create symbolic links named
Currently there is no support for encrypted private keys
Example:
This directive can be used to control the SSL protocol flavors mod_ssl should
use when establishing its server environment for proxy . It will only connect
to servers using one of the provided protocols. Please refer to
This directive sets the Certificate verification level for the remote server
Authentication. Notice that this directive can be used both in per-server and
per-directory context. In per-server context it applies to the remote server
authentication process used in the standard SSL handshake when a connection is
established. In per-directory context it forces a SSL renegotation with the
reconfigured remote server verification level after the HTTP request was read but
before the HTTP response is sent.
The following levels are available for level: In practice only levels none and
require are really interesting, because level
optional doesn't work with all servers and level
optional_no_ca is actually against the idea of
authentication (but can be used to establish SSL test pages, etc.)
This directive sets how deeply mod_ssl should verify before deciding that the
remote server does not have a valid certificate. Notice that this directive can be
used both in per-server and per-directory context. In per-server context it
applies to the client authentication process used in the standard SSL
handshake when a connection is established. In per-directory context it forces
a SSL renegotation with the reconfigured remote server verification depth after the
HTTP request was read but before the HTTP response is sent.
The depth actually is the maximum number of intermediate certificate issuers,
i.e. the number of CA certificates which are max allowed to be followed while
verifying the remote server certificate. A depth of 0 means that self-signed
remote server certificates are accepted only, the default depth of 1 means
the remote server certificate can be self-signed or has to be signed by a CA
which is directly known to the server (i.e. the CA's certificate is under
This configures one or more sources for seeding the Pseudo Random Number
Generator (PRNG) in OpenSSL at startup time (context is
The following source variants are available: This is the always available builtin seeding source. It's usage
consumes minimum CPU cycles under runtime and hence can be always used
without drawbacks. The source used for seeding the PRNG contains of the
current time, the current process id and (when applicable) a randomly
choosen 1KB extract of the inter-process scoreboard structure of Apache.
The drawback is that this is not really a strong source and at startup
time (where the scoreboard is still not available) this source just
produces a few bytes of entropy. So you should always, at least for the
startup, use an additional seeding source.
This variant uses an external file
But be careful: Usually
On some platforms like FreeBSD one can even control how the entropy is
actually generated, i.e. by which system interrupts. More details one can
find under rndcontrol(8) on those platforms. Alternatively, when
your system lacks such a random device, you can use tool
like EGD
(Entropy Gathering Daemon) and run it's client program with the
This variant uses an external executable
This variant uses the Unix domain socket of the
external Entropy Gathering Daemon (EGD) (see http://www.lothar.com/tech
/crypto/) to seed the PRNG. Use this if no random device exists
on your platform.
This directive specifies a general access requirement which has to be
fulfilled in order to allow access. It's a very powerful directive because the
requirement specification is an arbitrarily complex boolean expression
containing any number of access checks.
The expression must match the following syntax (given as a BNF
grammar notation): while for
This function takes one string argument and expands to the contents of the
file. This is especially useful for matching this contents against a
regular expression, etc. Notice that expression is first parsed into an internal machine
representation and then evaluated in a second step. Actually, in Global and
Per-Server Class context expression is parsed at startup time and
at runtime only the machine representation is executed. For Per-Directory
context this is different: here expression has to be parsed and
immediately executed for every request. Standard CGI/1.0 and Apache variables: SSL-related variables:
This directive forbids access unless HTTP over SSL (i.e. HTTPS) is enabled for
the current connection. This is very handy inside the SSL-enabled virtual
host or directories for defending against configuration errors that expose
stuff that should be protected. When this directive is present all requests
are denied which are not using SSL.
This configures the storage type of the global/inter-process SSL Session
Cache. This cache is an optional facility which speeds up parallel request
processing. For requests to the same server process (via HTTP keep-alive),
OpenSSL already caches the SSL session information locally. But because modern
clients request inlined images and other data via parallel requests (usually
up to four parallel requests are common) those requests are served by
different pre-forked server processes. Here an inter-process cache
helps to avoid unneccessary session handshakes.
The following two storage types are currently supported:
This is the default and just disables the global/inter-process Session
Cache. There is no drawback in functionality, but a noticeable speed
penalty can be observed.
This makes use of a DBM hashfile on the local disk to synchronize the
local OpenSSL memory caches of the server processes. The slight increase
in I/O on the server results in a visible request speedup for your
clients, so this type of storage is generally recommended.
This makes use of a high-performance hash table (approx. size bytes
in size) inside a shared memory segment in RAM (established via
This directive sets the timeout in seconds for the information stored in the
global/inter-process SSL Session Cache and the OpenSSL internal memory cache.
It can be set as low as 15 for testing, but should be set to higher
values like 300 in real life.
This directive sets the "user" field in the Apache request object.
This is used by lower modules to identify the user with a character
string. In particular, this may cause the environment variable
This directive sets the Certificate verification level for the Client
Authentication. Notice that this directive can be used both in per-server and
per-directory context. In per-server context it applies to the client
authentication process used in the standard SSL handshake when a connection is
established. In per-directory context it forces a SSL renegotation with the
reconfigured client verification level after the HTTP request was read but
before the HTTP response is sent.
The following levels are available for level: In practice only levels none and
require are really interesting, because level
optional doesn't work with all browsers and level
optional_no_ca is actually against the idea of
authentication (but can be used to establish SSL test pages, etc.)
This directive sets how deeply mod_ssl should verify before deciding that the
clients don't have a valid certificate. Notice that this directive can be
used both in per-server and per-directory context. In per-server context it
applies to the client authentication process used in the standard SSL
handshake when a connection is established. In per-directory context it forces
a SSL renegotation with the reconfigured client verification depth after the
HTTP request was read but before the HTTP response is sent.
The depth actually is the maximum number of intermediate certificate issuers,
i.e. the number of CA certificates which are max allowed to be followed while
verifying the client certificate. A depth of 0 means that self-signed client
certificates are accepted only, the default depth of 1 means the client
certificate can be self-signed or has to be signed by a CA which is directly
known to the server (i.e. the CA's certificate is under
Apache HTTP Server Version 2.0 Status 모듈은 서버 관리자에게 서버의 상태를 보여준다.
쉽게 읽을 수 있는 HTML 페이지로 현재 서버통계를 보여준다.
필요하다면 (표준을 따르는 브라우저에서) 페이지를 자동으로
갱신할 수 있다. 현재 서버 상태를 컴퓨터가 읽을 수 있는
간단한 목록으로 보여줄 수도 있다. 알려주는 정보는: 표준 아파치에는 "(*)"로 표시한 통계를 얻을 수 없다.
이 정보를 보려면 컴파일시 옵션을 사용해야 한다. foo.com 도메인에서 접근한 브라우저에게만 상태를 보여주려면
이제 웹브라우저로
브라우저가 "재갱신"을 지원한다면 status 페이지를 자동으로
갱신할 수 있다. N 초마다 갱신하려면
Apache HTTP Server Version 2.0 이 모듈은 suexec 지원
프로그램을 사용하여 CGI 스크립트를 특정 사용자와 그룹
권한으로 실행한다. Apache HTTP Server Version 2.0 이 모듈은 어떤 특별한 상황에서도 "모든" 요청중에서
유일하도록 보장된 식별자(identifier)를 모든 요청에 제공한다.
심지어 이 식별자는 특별하게 구성한 클러스터의 여러 컴퓨터들
중에서도 유일하다. 각 요청마다 환경변수
먼저 유닉스 시스템에서 아파치 서버가 어떻게 동작하는지
간략히 살펴보자. Windows NT는 현재 이 기능을 지원하지 않는다.
유닉스에서 아파치는 여러 자식을 만들고, 자식 프로세스는
한번에 한 요청씩 처리한다. 자식은 실행중에 여러 요청을
처리한다. 여기서 중요한 것은 자식들이 서로 자료를
공유하지 않는다는 점이다. 앞으로 자식을 httpd 프로세스라고
한다. 여러 컴퓨터로 웹사이트를 서비스한다면 클러스터(cluster)라고
부른다. 각 컴퓨터는 여러 아파치를 실행할 수 있다. 이들 모두를
"우주"로 보면, 클러스터에 있는 컴퓨터들간에 많은 통신없이
각 요청마다 우주에서 유일한 식별자를 만들 수 있다. 클러스터에 있는 컴퓨터는 다음 요구사항을 만족해야 한다.
(컴퓨터를 한대만 사용하더라도 컴퓨터 시간을 NTP와 동기해야
한다.) 운영체제에서 pid (프로세스 id)가 32비트에 들어간다고
가정한다. 운영체제가 pid로 32비트 이상을 사용한다면 간단하지만
코드를 수정해야 한다. 이런 가정하에 우리는 어떤 시점에서 클러스터의 어떤 컴퓨터에
있는 어떤 httpd 프로세스를 다른 모든 httpd 프로세스들과
구별할 수 있다. 컴퓨터의 IP 주소와 httpd 프로세스의 pid만으로도
충분히 구별할 수 있다. 그래서 요청에 대해 유일한 구별자를
만드려면 시간차를 구별할 수만 있으면 된다. 시간을 구별하기위해 유닉스 시간(timestamp, 세계 표준시로
1970년 1월 1일 이후 지난 초)과 16비트 카운터를 사용한다.
유닉스 시간은 초단위이고, 카운터는 일 초동안 65536까지
증가한다. ( ip_addr, pid, time_stamp, counter )
묶음은 어떤 httpd 프로세스에서 일 초동안 65536 요청을 구별할
수 있다. 그러나 카운터는 pid를 재사용하는 문제를 해결해야
한다. httpd 자식을 만들면 카운터는 ( 현재 밀리초 나누기 10 )을
65536으로 나눈 나머지가 된다. (몇몇 시스템의 밀리초 시간에서
하위 비트가 일치하지않는 문제때문에 이 공식을 만들었다.)
유일한 식별자를 만들때 사용하는 시간은 웹서버가 요청을 받은
시간이다. 카운터는 식별자를 만들때마다 증가한다 (그리고
다시 시작한다). 커널은 프로세스를 포크할때(fork) 각 프로세스에 pid를
할당하고, pid는 다시 시작할 수 있다. (pid는 많은 유닉스에서
16비트이지만, 최근 시스템은 32비트로 확장했다.) 그래서 시간이
지나면 같은 pid를 재사용할 수 있다. 그러나 같은 시간에 pid를
재사용하지 않는다면 위의 묶음은 유일하다. 즉, 우리는 시스템이
일초동안 프로세스를 65536개 이상 만들지 않는다고 가정한다.
(어떤 유닉스에서는 32768개 이상 프로세스를 만들면 pid 재사용
문제가 발생할 수 있지만, 이것조차도 일어날 것같지 않다.) 시간이 어떤 이유에서건 반복된다고 가정해보자. 즉, 시스템
시계가 꼬여서 시간이 과거로 돌아가는 (혹은 시계가 너무 앞서가서
올바로 재설정한후 미래에 같은 시간이 되는) 경우다. 이 경우
pid와 시간을 모두 재사용할 수 있다. 카운터의 초기화 공식은
이 문제를 해결하려고 고안되었다. 우리는 실제 무작위 숫자로
카운터를 초기화하길 원하지만, 많은 시스템에서 이런 수를
쉽게 얻을 수 없다. (예를 들어, seed가 필요하기때문에
rand()를 사용할 수 없고, 시간은 최소한 일초 단위이기때문에
시간으로 seed로 사용할 수 없다.) 즉 완벽한 해결책이 없다. 그럼 이 방법은 얼마나 괜찮을까? 컴퓨터중 하나가 요청을
초당 최대 500개 (시스템은 일반적으로 정적인 파일을 전송하는
것 이상의 작업을 하므로 이 글을 쓰는 시점에서 상당히 높은
값이다.) 서비스한다고 가정하자. 동시에 얼마만큼의 클라이언트를
처리하는가에 따라 자식의 개수가 결정된다. 그러나 우리는
비관적으로 한 자식이 요청을 초당 500개 처리할 수 있다고
가정한다. 재사용한 pid를 가진 자식의 500개 요청과 이전 자식의
500개 요청의 카운터값이 겹칠 수 있는 카운터 시작값 경우수는
1000개이다. 그래서 (초단위에서) 자식이 카운터값을 반복하여
유일성이 깨질 확률은 1.5%이다. 이것은 매우 비관적인 가정이며,
실제 이럴 경우는 상당히 더 낮다. 그래도 시스템에서 이런
일이 발생할 것 같다면 (소스를 수정하여) 카운터를 32비트로
만들어라. 섬머타임때문에 시계가 "뒤로 가는" 것을 걱정할지도 모른다.
그러나 여기서 사용하는 시간은 국제 표준시(UTC), 즉 시간이
"항상" 앞으로 가므로 문제가 없다. x86기반 유닉스에서는
적절한 설정이 필요하다. 메인보드 시계가 UTC를 사용하도록
설정해야 한다. 그러나 NTP를 사용한다면 재시작후 조금 지나면
UTC 시간에 올바로 맞춘다. 환경변수 순서는 앞으로 기존의 우리는 이 방법이 이 문제에 대하여 상대적으로 포팅가능한
해결책이라고 믿는다. 이 방법은 Windows NT와 같은 멀티쓰레드
시스템으로 확장할 수 있고, 앞으로 용도에 따라 확장할 수
있다. 미래에 필요한만큼 더 긴 식별자를 만들 수 있기때문에
생성한 식별자는 기본적으로 영원한 수명을 가진다. 기본적으로
클러스터의 컴퓨터들 사이에 통신이 필요없고 (부하가 작은
NTP 동기만 필요하다), httpd 프로세스 사이에 통신도 필요없다
(커널이 부여하는 pid값이 암묵적인 통신이다). 매우 특이한
상황이라면 인식자 크기를 줄일 수 있지만 더 많은 정보를
가정해야 한다. (예를 들어, 어떤 사이트에서 32비트 IP 주소
구분은 불필요하게 크지만, 이를 줄이는 방법은 상황에 따라
다르다.) Apache HTTP Server Version 2.0 이 모듈을 사용하면 다음 지시어는 클라이언트에게 리다이렉션을 보낸다: 추가 예제: 몇몇 사용자에게만 대부분의 사용자에게 다른 사용자 디렉토리를 지정할 수도 있다.
다음과 같은 명령어를 사용한다면: http://www.foo.com/~bob/one/two.html 요청을 하면,
먼저 ~bob/public_html/one/two.html 페이지를 찾고,
/usr/web/bob/one/two.html을 찾은 후, 마지막으로
http://www.foo.com/bob/one/two.html으로 리다이렉션을 보낸다. 리다이렉션을 사용한다면 목록의 마지막에 두어야 한다.
아파치는 리다이렉션이 성공했는지 알 수 없기때문에, 리다이렉션을
목록 앞에 두면 항상 리다이렉션을 사용하게 된다. Apache HTTP Server Version 2.0 Previous releases of Apache have included a module which
generates a 'clickstream' log of user activity on a site using
cookies. This was called the "cookies" module, mod_cookies. In
Apache 1.2 and later this module has been renamed the "user
tracking" module, mod_usertrack. This module has been
simplified and new directives added. Previously, the cookies module (now the user tracking
module) did its own logging, using the For backward compatibility the configurable log module
implements the old (the following is from message
<022701bda43d$9d32bbb0$1201a8c0@christian.office.sane.com>
in the new-httpd archives) This directive controls the setting of the domain to which
the tracking cookie applies. If not present, no domain is
included in the cookie header field. The domain string must begin with a dot, and
must include at least one embedded dot. That is,
When used, this directive sets an expiry time on the cookie
generated by the usertrack module. The expiry-period
can be given either as a number of seconds, or in the format
such as "2 weeks 3 days 7 hours". Valid denominations are:
years, months, weeks, days, hours, minutes and seconds. If the expiry
time is in any format other than one number indicating the
number of seconds, it must be enclosed by double quotes. If this directive is not used, cookies last only for the
current browser session. This directive allows you to change the name of the cookie
this module uses for its tracking purposes. By default the
cookie is named " You must specify a valid cookie name; results are
unpredictable if you use a name containing unusual characters.
Valid characters include A-Z, a-z, 0-9, "_", and "-". This directive controls the format of the cookie header
field. The three formats allowed are: Not all clients can understand all of these formats. but you
should use the newest one that is generally acceptable to your
users' browsers. At the time of writing, most browsers only fully
support When Apache HTTP Server Version 2.0 여러 다른 웹서버 버전과 구성을 다루어야 할 큰 네트웍과
테스트용으로 사용하기위해 이 모듈을 만들었다. 이 모듈은
숫자 비교나 정규표현식을 사용하여 자유로운 버전 검사가 가능한
다른 사용법은 아래를 참고한다. 숫자 비교외에도 정규표현식을 사용하여 웹서버 버전을 지정할
수 있다. 여기에는 두가지 방법이 있다. 연산자 앞에 느낌표( operator를 생략하면 Apache HTTP Server Version 2.0 This module creates dynamically configured virtual hosts, by
allowing the IP address and/or the If All the directives in this module interpolate a string into
a pathname. The interpolated string (henceforth called the
"name") may be either the server name (see the If For simple name-based virtual hosts you might use the
following directives in your server configuration file: A request for
For a very large number of virtual hosts it is a good idea
to arrange the files to reduce the size of the
A request for
A more even spread of files can be achieved by hashing from the
end of the name, for example: The example request would come from
Alternatively you might use: The example request would come from
For IP-based virtual hosting you might use the following in
your configuration file: A request for
If you want to include the A request for
The The The The The Apache HTTP Server Version 2.0 이 문서는 아파치 모듈을 설명하기위해
사용한 용어를 설명한다. 모듈 목적에 대한 간단한 설명. 모듈이 아파치 웹서버와 얼마나 밀접히 연관되있는지 나타낸다.
즉, 특정 모듈과 모듈의 기능을 사용하기위해서 서버를 다시
컴파일해야 할 경우가 있다. 이 속성의 값은: 간단하게 말해서 모듈 소스코드가 있는 소스파일명이다.
모듈을 지칭하는 문자열로, 모듈을 동적으로 읽어들이는
모듈이 원래 아파치 버전 2 배포본에 포함되지 않았다면,
모듈을 처음 소개한 버전을 알려준다. 또, 모듈이 특정
플래폼용이라면 상세히 설명한다. Apache HTTP Server Version 2.0 The If this directive is set to If you want to find out the compile time chosen default
for your system, you may set your The Only one This controls the directory to which Apache attempts to
switch before dumping core. The default is in the
If Apache starts as root and switches to another user, the
Linux kernel disables core dumps even if the directory is
writable for the process. Apache (2.0.46 and later) reenables core dumps
on Linux 2.4 and beyond, but only if you explicitly configure a For safety reasons this directive is only available if the server was
configured with the There are already two modules, The It is recommended that you set up a new group specifically for
running the server. Some admins use user Don't set Special note: Use of this directive in The The Multiple For example, to make the server accept connections on both
port 80 and port 8000, use: To make the server accept connections on two specified
interfaces and port numbers, use IPv6 addresses must be surrounded in square brackets, as in the
following example: The maximum length of the queue of pending connections.
Generally no tuning is needed or desired, however on some
systems it is desirable to increase this when under a TCP SYN
flood attack. See the backlog parameter to the
This will often be limited to a smaller number by the
operating system. This varies from OS to OS. Also note that
many OSes do not use exactly what is specified as the backlog,
but use a number based on (but normally larger than) what is
set. The It is best to avoid putting this file in a world writable
directory such as The For non-threaded servers (i.e., For threaded and hybrid servers (e.g. The The The default value for Setting For Maximum number of idle threads. Different MPMs deal with this
directive differently. For For For The range of the Minimum number of idle threads to handle request spikes.
Different MPMs deal with this directive
differently. The It is often useful to be able to send the server a signal,
so that it closes and then re-opens its The As of Apache 2 it is recommended to use only the The server will set the TCP receive buffer size to the number of
bytes specified. If set to the value of Apache uses a scoreboard to communicate between its parent
and child processes. Some architectures require a file to facilitate
this communication. If the file is left unspecified, Apache first
attempts to create the scoreboard entirely in memory (using anonymous
shared memory) and, failing that, will attempt to create the file on
disk (using file-based shared memory). Specifying this directive causes
Apache to always create the file on the disk. File-based shared memory is useful for third-party applications
that require direct access to the scoreboard. If you use a The server will set the TCP send buffer size to the number of bytes
specified. Very useful to increase past standard OS defaults on
high speed high latency (i.e., 100ms or so, such as
transcontinental fast pipes). If set to the value of For the Special care must be taken when using this directive. If
With the With With the There is a hard limit of The The default value differs from MPM to MPM. For
Number of threads created on startup. As the
number of threads is dynamically controlled depending on the
load, there is usually little reason to adjust this
parameter. For For For This directive sets the maximum configured value for Special care must be taken when using this directive. If
The default value for There is a hard limit of This directive sets the number of threads created by each
child process. The child creates these threads at startup and
never creates more. If using an MPM like The default value for The The user should have no privileges that result in it being
able to access files that are not intended to be visible to the
outside world, and similarly, the user should not be able to
execute code that is not meant for HTTP requests. It is
recommended that you set up a new user and group specifically for
running the server. Some admins use user Don't set With the Special note: Use of this directive in Apache HTTP Server Version 2.0 This Multi-Processing Module (MPM) implements an exclusively
threaded web server that has been optimized for Novell
NetWare. The main thread is responsible for launching child
worker threads which listen for connections and serve them when they
arrive. Apache always tries to maintain several spare
or idle worker threads, which stand ready to serve incoming
requests. In this way, clients do not need to wait for a new
child threads to be spawned before their requests can be
served. The The This directive tells the server what stack size to use for
each of the running threads. If you ever get a stack overflow
you will need to bump this number to a higher setting. Apache HTTP Server Version 2.0 This Multi-Processing Module (MPM) is the default for the
Windows NT operating systems. It uses a single control process
which launches a single child process which in turn creates
threads to handle requests you should use this directive to disable the use of
Apache HTTP Server Version 2.0 The Server consists of a main, parent process and a small, static
number of child processes. The parent process's job is to manage the child processes. This
involves spawning children as required to ensure there are always
Each child process consists of a a pool of worker threads and a
main thread that accepts connections and passes them to the workers via
a work queue. The worker thread pool is dynamic, managed by a
maintenance thread so that the number of idle threads is kept between
Apache HTTP Server Version 2.0 This Multi-Processing Module (MPM) implements a hybrid
multi-process, multi-threaded web server. A fixed number of
processes create threads to handle requests. Fluctuations in
load are handled by increasing or decreasing the number of
threads in each process. A single control process launches the number of child processes
indicated by the Apache always tries to maintain a pool of spare or
idle server threads, which stand ready to serve incoming
requests. In this way, clients do not need to wait for new
threads to be created. For each child process, Apache assesses
the number of idle threads and creates or destroys threads to
keep this number within the boundaries specified by
While the parent process is usually started as root under
Unix in order to bind to port 80, the child processes and
threads are launched by Apache as a less-privileged user. The
The The following example runs 7 child processes. Two of them are run
under Using unbalanced numbers of processes as above is useful, if the
particular virtual hosts produce different load. The assignment to
the virtual hosts is easily done as in the example below. In
conclusion with the example above the following assumes, that
Tie a virtual host to a specific user/group combination. Requests
addressed to the virtual host where this directive appears will be
served by a process running with the specified user and group ID. The user and group ID has to be assigned to a number of children
in the global server config using the Specify a user ID and group ID for a number of child processes.
The third argument, num-children, is the number of child
processes to start with the specified user and group. It does
not represent a specific child number. In order to use this
directive, the server must be run initially as If the total number of child processes, found by totaling all of the
third arguments to all
install.html 100644 0 0 40141 11074463123 10562 0 ustar 0 0
Apache HTTP Server Version 2.0 문서
invoking.html 100644 0 0 16170 11074463123 10745 0 ustar 0 0
컴파일과 설치
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
libtool과 autoconf를
사용한다.
성미 급한 사람을 위한 개요
다운로드
$ lynx http://httpd.apache.org/download.cgi
압축 풀기
$ gzip -d httpd-2_0_NN.tar.gz
$ tar xvf httpd-2_0_NN.tar
구성
$ ./configure --prefix=PREFIX
컴파일
$ make
설치
$ make install
설정
$ vi PREFIX/conf/httpd.conf
검사
$ PREFIX/bin/apachectl start
/usr/local/apache2를
사용한다.
요구사항
PATH 환경변수는 make와
같은 기본적인 컴파일 도구를 포함해야 한다.ntpdate나 xntpd를 사용한다.
NTP 소프트웨어와 공개 시간 서버에 대한 정보는 뉴스그룹
comp.protocols.time.ntp와
NTP 홈페이지를
참고하라.configure' 스크립트가
이 인터프리터를 찾지 못해도 문제없이 아파치 2.0을
컴파일하고 설치할 수 있다. 다만 지원 스크립트를 사용하지
못할 뿐이다. 여러 Perl 인터프리터가 설치되있다면 (아마도
살때 포함된 Perl 4와 직접 컴파일한 Perl 5)
./configure가 올바른 것을 찾기위해
--with-perl 옵션을 (아래 참고) 사용하길 바란다.
다운로드
INSTALL.bindist 파일의 지시를 따르라.
압축 풀기
$ gzip -d httpd-2_0_NN.tar.gz
$ tar xvf httpd-2_0_NN.tar
cd해야 한다.
소스 트리 구성하기
configure
스크립트를 사용한다. (아파치
소스 트리의 CVS 버전을 다운로드한 개발자는 이미
autoconf와 libtool가 설치되있고,
다음 과정으로 넘어가기 전에 buildconf를 실행해야
한다. 이는 정식 버전에서는 필요없다.)./configure를 입력하면된다. 기본 옵션을 수정하려면
./configure에 여러 변수와 명령행 옵션을 사용한다.--prefix다. 다른 configure
옵션들을 사용하여 파일의 위치를 더 자세히 설정할 수도
있다.--enable-module 옵션을 사용하여
포함한다. 여기서 module은 모듈 이름에서
mod_를 빼고 밑줄을 빼기기호로 변경한 결과다.
--enable-module=shared 옵션을 사용하면
모듈을 실행중에 포함하거나 뺄 수 있는 공유객체(shared object, DSO)로 컴파일한다.
또, --disable-module 옵션을 사용하여
Base 모듈을 뺄 수 있다. 지정한 모듈이 없어도
configure가 경고하지않고 그냥 무시하기때문에
모듈 이름을 정확히 입력하라.configure 스크립트에게 컴파일러,
라이브러리, 헤더파일 등의 위치를 알려줘야 할 경우가 있다.
이 정보는 환경변수나 configure의 명령행 옵션을
사용하여 전달한다. 자세한 내용은 configure manpage를
참고하라.mod_rewrite와
mod_speling을 추가하여
/sw/pkg/apache에 설치할 아파치를 컴파일하는
전형적인 예이다:
$ CC="pgcc" CFLAGS="-O2" \
./configure --prefix=/sw/pkg/apache \
--enable-rewrite=shared \
--enable-speling=shared
configure를 실행하면 몇분간 시스템의 기능을
검사하여 나중에 서버를 컴파일할때 사용할 Makefile들을
만든다.configure 옵션들에 대한 자세한 설명은 configure manpage에 있다.
컴파일
$ make
설치
--prefix
옵션 참고) 지정한 설치 위치 PREFIX에 설치한다:$ make install
설정
PREFIX/conf/에 있는
설정파일을 편집하여 아파치
웹서버를 설정한다.$ vi PREFIX/conf/httpd.conf
검사
$ PREFIX/bin/apachectl starthttp://localhost/로 첫 문서를
요청한다. 보게될 웹페이지는 아마도
PREFIX/htdocs/일 DocumentRoot 아래에 있다. 그리고
다음 명령어로 다시 서버를 중단한다:$ PREFIX/bin/apachectl stop
업그레이드
CHANGES
파일을 읽는다. (예를 들어, 1.3에서 2.0이나 2.0에서 2.2와
같은) 큰 버전이 변한 경우 컴파일 옵션과 설정을 직접 수정해야할
정도의 큰 변화가 있을 것이다. 모든 모듈도 모듈 API의 변화에
알맞게 업그레이드해야 한다.make install 작업은
기존의 문서, 로그파일, 설정파일을 수정하지 않는다. 또,
개발자는 작은 버전간에 configure 옵션, 설정,
모듈 API의 호환성없는 변화를 최대한 막는다. 대부분의 경우
동일한 configure 명령행, 동일한 설정파일을
사용할 수 있고, 모듈들도 모두 계속 동작할 것이다. (이 말은
2.0.41이후 버전에만 해당한다. 이전 버전들에는 호환성없는
변화가 있다.)config.nice
파일에는 소스를 구성할 때 사용했던 configure
명령행 옵션이 그대로 있다. 그래서 다음 버전으로 업그레이드한다면
새로운 버전 소스로 config.nice 파일을 복사하고,
원한다면 조금 수정을 한 후, 다음과 같이 실행한다:
$ ./config.nice
$ make
$ make install
$ PREFIX/bin/apachectl stop
$ PREFIX/bin/apachectl start
새로운 버전을 사용하기 전에 항상 검사해봐야
한다. 예를 들어, 업그레이드를 마치기 전에 호환성 문제가
있는지 알아보기위해 다른
--prefix와 (Listen 지시어로) 다른 포트를
사용하여 새로운 버전을 설치한후 이전 버전과 같이 실행해볼
수 있다.
license.html 100644 0 0 32120 11074463123 10534 0 ustar 0 0
아파치 시작
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
httpd를 시작하는 방법을
설명한다.
어떻게 아파치가 시작하나
Listen이 기본값인 80(혹은
1024이하의 다른 포트)이라면 이 특권 포트에 연결하기위해
root 권한이 필요하다. 서버는 시작하여 로그파일을 여는 등의
몇몇 기초적인 작업을 마친후, 클라이언트의 요청을 기다리고
응답하는 자식(child) 프로세스를 여러개 띄운다.
주 httpd 프로세스는 계속 root 사용자로 실행되지만,
자식 프로세스들은 더 권한이 작은 사용자로 실행된다. 이는
선택한 다중처리 모듈로 조정한다.httpd 실행파일을 시작하길
권장한다. 이 스크립트는 httpd가 몇몇
운영체제에서 정상적으로 동작하기위해 필요한 환경변수들을
설정하고 httpd 실행파일을 시작한다.
apachectl은 명령행 아규먼트를 그대로 넘기기때문에,
httpd의 어떤 옵션이라도 apachectl에
사용가능하다. 또, apachectl 스크립트의 앞부분에
나오는 HTTPD 변수를 httpd 실행파일이
있는 위치와 항상 사용할 명령행 아규먼트로 직접
수정할 수 있다.httpd를 실행하면 먼저 설정파일 httpd.conf를
찾아서 읽는다. 이 파일의 위치는 컴파일 중에 지정하나, 실행시
다음과 같이 -f 명령행 옵션으로 지정할 수도 있다./usr/local/apache2/bin/apachectl -f
/usr/local/apache2/conf/httpd.confDocumentRoot 디렉토리에 있는
테스트 페이지와 그 페이지에 링크된 (로컬카피) 설명서를 볼
수 있다.
시작중 오류
ErrorLog에 쓴다. 가장 흔한 오류문 중
하나는 "Unable to bind to Port ..."이다.
이 메세지는 보통 다음 두 경우에 발생한다:
부팅할때 시작하기
rc.local이나 rc.N
디렉토리에 있는 파일)에 apachectl을 추가해야
한다. 이 경우 아파치는 root로 시작된다. 이전에 서버의 보안이나
접근 제한(파일권한)이 올바로 설정되었는지 확인하라.apachectl은 표준 SysV init 스크립트와 비슷하게
동작하도록 만들어졌다. 스크립트는 아규먼트로 start,
restart, stop을 받으면 각각 적절한
시그널을 httpd에 보낸다. 그래서 보통은
apachectl을 적절한 init 디렉토리로 링크를 걸면된다.
그러나 사용하는 시스템의 정확한 요구사항을 확인하라.
logs.html 100644 0 0 63433 11074463123 10071 0 ustar 0 0
The Apache License, Version 2.0
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
misc/custom_errordocs.html 100644 0 0 60202 11074463123 13443 0 ustar 0 0
로그파일
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
보안 경고
오류 로그 (Error Log)
관련된 모듈 관련된 지시어 ErrorLog 지시어는
가장 중요한 로그파일인 서버 오류 로그의 이름과 위치를 지정한다.
아파치 웹서버는 이 파일에 진단정보와 요청을 처리하는 도중
발생한 오류를 기록한다. 서버가 시작하거나 동작하는데 문제가
있다면 무엇이 잘못되었고 때때로 어떻게 고치는지를 알려주는
이곳을 가장 먼저 살펴봐야 한다.error_log, 윈도우즈와 OS/2에서는
error.log) 파일에 기록된다. 유닉스 시스템에서
서버는 오류를 syslog나 파이프를
사용하여 다른 프로그램으로 보낼 수도 있다.
[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1]
client denied by server configuration:
/export/home/live/ap/htdocs/test
LogLevel 지시어로 오류 로그에
기록되는 오류의 심각성을 제한할 수 있다. 세번째 항목은
오류를 발생한 클라이언트의 IP 주소이다. 이 다음부터 오류문이
나오며, 이 경우 서버가 클라이언트의 접근을 거부하도록
설정되었다고 나와있다. 요청한 문서의 (웹 경로가 아닌)
파일시스템 경로도 보인다.stderr에 쓴
정보는 그대로 오류 로그로 복사된다.
tail -f error_log
접근 로그 (Access Log)
관련된 모듈 관련된 지시어 CustomLog
지시어는 접근 로그의 위치와 내용을 지정한다. LogFormat 지시어를
사용하여 로그에 포함할 내용을 쉽게 선택할 수 있다. 이 절은
서버가 접근 로그에 쓸 내용을 설정하는 방법을 설명한다.CustomLog
같은 모듈과 지시어를 사용하여 접근 로그를 다루었다. 지금은
CustomLog
지시어가 오래된 지시어들의 모든 기능을 이어받았다.mod_log_config 형식문자열을
참고하라.Common 로그 형식
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
common으로 정의한다. 형식문자열은 퍼센트
지시어들로 구성되며, 각각은 어떤 정보를 기록할지 알린다.
형식문자열에 일반 문자를 적으면 그대로 로그에 출력된다.
따옴표 문자(")를 출력하고 싶다면 백슬래쉬를
앞에 붙여서 형식문자열의 끝이 아님을 표시한다. 형식문자열에
줄바꿈 "\n", 탭 "\t"와 같은
특수 조절문자를 사용할 수 있다.CustomLog
지시어는 정의한 별명을 사용하는 새로운 로그파일을
만든다. 접근 로그의 파일명이 슬래쉬로 시작하지않으면
ServerRoot의 상대경로이다.
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
/apache_pb.gif HTTP/1.0" 200 2326
127.0.0.1 (%h)HostnameLookups가
On이라면 호스트명을 찾아서 IP 주소 자리에
대신 쓴다. 그러나 이 설정은 서버를 매우 느리게 할 수
있으므로 추천하지 않는다. 호스트명을 알려면 대신 나중에
logresolve와
같은 로그를 처리하는 프로그램을 사용하는 것이 좋다.
여기에 나온 IP 주소는 사용자가 사용하는 컴퓨터 주소가
아닐 수 있다. 프록시 서버가 사용자와 서버사이에 존재한다면,
원래 컴퓨터 주소가 아니라 프록시의 주소가 기록될 것이다.- (%l)identd가 제공할 클라이언트의 RFC 1413
신원이다. 이 정보는 매우 믿을 수 없기때문에, 긴밀히
관리되는 내부 네트웍이 아니라면 절대로 이 정보를 사용하면
안된다. IdentityCheck가
On이 아니라면 아파치 웹서버는 이 정보를
알아보려고 시도하지도 않는다.frank (%u)REMOTE_USER 환경변수로 넘겨진다. 요청의
상태코드가 401이라면 (아래 참고) 사용자가 아직 인증을
거치지 않았으므로 이 값을 믿으면 안된다. 문서를 암호로
보호하지 않는다면 이 항목은 이전 항목과 같이
"-"이다.[10/Oct/2000:13:55:36 -0700]
(%t)[day/month/year:hour:minute:second zone]
day = 숫자 2개
month = 숫자 3개
year = 숫자 4개
hour = 숫자 2개
minute = 숫자 2개
second = 숫자 2개
zone = (`+' | `-') 숫자 4개%{format}t를 사용하여
다른 형식으로 시간을 출력할 수 있다. format은
C 표준 라이브러리의 strftime(3)과 같다.
"GET /apache_pb.gif HTTP/1.0"
(\"%r\")GET이다. 둘째, 클라이언트는 자원
/apache_pb.gif를 요청한다. 세번째, 클라이언트는
HTTP/1.0 프로토콜을 사용한다. 요청줄의
여러 부분을 따로 로그할 수도 있다. 예를 들어, 형식문자열
"%m %U%q %H"은 "%r"과 똑같이
메써드, 경로, 질의문자열, 프로토콜을 로그한다.200 (%>s)2326 (%b)-"이다. 내용이
없는 경우 "0"을 로그하려면 대신
%B를 사용한다.Combined 로그 형식
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-agent}i\"" combined
CustomLog log/access_log combined
%{header}i를 사용한다. 여기서
header 자리에 HTTP 요청 헤더 이름이 나올 수
있다. 이 형식의 접근 로그는 다음과 같다:
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET
/apache_pb.gif HTTP/1.0" 200 2326
"http://www.example.com/start.html" "Mozilla/4.08 [en]
(Win98; I ;Nav)"
"http://www.example.com/start.html"
(\"%{Referer}i\")/apache_pb.gif를 링크하였거나 포함한
사이트이다.)"Mozilla/4.08 [en] (Win98; I ;Nav)"
(\"%{User-agent}i\")여러 접근 로그
CustomLog 지시어를
사용하면 접근 로그가 여러개 만들어진다. 예를 들어, 다음
설정은 세가지 접근 로그를 만든다. 첫번째는 기본 CLF 정보를
기록하고, 두번째와 세번째는 referer와 브라우저 정보를
기록한다. 마지막 두 CustomLog 줄은 어떻게
이전 ReferLog와 AgentLog 지시어의
기능을 흉내낼 수 있는지 보여준다.
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
CustomLog logs/referer_log "%{Referer}i -> %U"
CustomLog logs/agent_log "%{User-agent}i"
LogFormat으로 반드시
별명을 정의할 필요는 없음을 보여준다. 대신 CustomLog 지시어에
직접 로그 형식을 지정할 수 있다.조건부 로그
SetEnvIf를 사용한다.
그리고 CustomLog
지시어에 env=을 사용하여 환경변수 유무에
따라 요청을 집어넣거나 뺀다. 예를 들면:
# loop-back 인터페이스에서 요청을 표시한다
SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
# robots.txt 파일에 대한 요청을 표시한다
SetEnvIf Request_URI "^/robots\.txt$" dontlog
# 나머지를 로그에 남긴다
CustomLog logs/access_log common env=!dontlog
SetEnvIf Accept-Language "en" english
CustomLog logs/english_log common env=english
CustomLog logs/non_english_log common env=!english
로그 순환 (Log Rotation)
mv access_log access_log.old
mv error_log error_log.old
apachectl graceful
sleep 600
gzip access_log.old error_log.old
로그를 파이프로 보내기
|"와 뒤에 표준입력으로
로그 항목을 읽을 실행파일명을 적으면 된다. 아파치는 서버가
시작할때 파이프로 연결할 로그 프로세스를 시작하고, 서버가
실행되는 동안 프로세스가 죽으면 다시 시작한다. (이 마지막
기능때문에 우리는 이 방법을 "믿을 수 있는 파이프 로그"라고
부른다.)
CustomLog "|/usr/local/apache/bin/rotatelogs
/var/log/access_log 86400" common
가상호스트
<VirtualHost> 섹션이
아닌 주서버 설정에 로그 지시어를 두면 모든 요청이 같은 접근
로그와 오류 로그로 기록된다. 이 방법은 가상호스트별로 쉽게
통계처리를 할 수 없다.<VirtualHost>
섹션 안에 CustomLog나
ErrorLog 지시어를
사용하면 해당 가상호스트에 대한 요청과 오류만이 지정된
파일에 기록된다. 로그 지시어가 없는 다른 가상호스트는 계속
주서버 로그에 로그를 기록한다. 이 방법은 가상호스트 개수가
적을 경우 매우 유용하지만, 호스트 수가 많다면 관리하기
힘들어진다. 또, 파일기술자가
부족한 문제가 자주 발생한다.
LogFormat "%v %l %u %t \"%r\" %>s %b"
comonvhost
CustomLog logs/access_log comonvhost
%v는 요청을 서비스하는 가상호스트 이름을
기록한다. 나중에 split-logfile
같은 프로그램으로 접근 로그를 가상호스별로 나눌 수 있다.
다른 로그파일
관련된 모듈 관련된 지시어 PID 파일
logs/httpd.pid
파일에 부모 httpd 프로세스의 process id를 저장한다. 이
파일명은 PidFile
지시어로 변경할 수 있다. process-id는 관리자가 부모 프로세스에
시그널을 보내 서버를 재시작하거나 죽일때 사용한다.
윈도우즈에서는 대신 -k 명령행옵션을 사용한다. 더 자세한
정보는 중단과 재시작 페이지를
참고하라.스크립트 로그
ScriptLog 지시어를 사용하여
CGI 스크립트의 입력과 출력을 기록할 수 있다. 이 지시어는
오직 테스트용으로만 사용해야 한다. 실제 사용하는 서버에서
사용하면 안된다. 더 자세한 정보는 mod_cgi 문서를 참고하라.재작성 로그
RewriteLog를 사용할 필요가
있다. 이 로그파일은 재작성 엔진이 어떻게 요청을 변환하는지에
대해 자세히 알려준다. 자세한 정도는 RewriteLogLevel 지시어로
조절한다.
misc/descriptors.html 100644 0 0 27306 11074463123 12420 0 ustar 0 0
International Customized Server Error Messages
Warning:
mod_include to return
error messages generated by the server in the client's native
language.
Introduction
ErrorDocument messages
can share a homogenous and consistent style and layout, and
maintenance work (changing images, changing links) is kept to a
minimum because all layout information can be kept in a single
file.
![[Needs graphics capability to display]](../images/custom_errordocs.gif)
Creating an ErrorDocument directory
Options, we
enable the language selection of the most appropriate
language alternative (content negotiation).LanguagePriority
directive we define a set of default fallback languages in
the situation where the client's browser did not express any
preference at all.mod_include
(and disallowing execution of cgi scripts for
security reasons), we allow the server to include building
blocks of the error message, and to substitute the value of
certain environment variables into the generated document
(dynamic HTML) or even to conditionally include or omit parts
of the text.AddHandler and AddType directives
are useful for automatically SSI-expanding all files with a
.shtml suffix to text/html.Alias directive, we
keep the error document directory outside of the document
tree because it can be regarded more as a server part than
part of the document tree.<Directory> block
restricts these "special" settings to the error document
directory and avoids an impact on any of the settings for the
regular document tree.src/main/http_protocol.c if you wish to see
apache's standard messages), an ErrorDocument in
the aliased /errordocs directory is defined.
Note that we only define the basename of the document here
because the MultiViews option will select the best candidate
based on the language suffixes and the client's preferences.
Any error situation with an error code not handled
by a custom document will be dealt with by the server in the
standard way (i.e., a plain error message in
english).AllowOverride directive tells
apache that it is not necessary to look for a .htaccess file
in the /errordocs directory: a minor speed optimization.httpd.conf configuration would then
look similar to this:Note
Note that you can define your own
error messages using this method for only part of the document
tree, e.g., a /~user/ subtree. In this case, the configuration
could as well be put into the .htaccess file at the root of the
subtree, and the <Directory> and </Directory>
directives -but not the contained directives- must be
omitted.
LanguagePriority en fr de
Alias /errordocs /usr/local/apache/errordocs
<Directory /usr/local/apache/errordocs>
AllowOverride none
Options MultiViews IncludesNoExec FollowSymLinks
AddType text/html .shtml
<FilesMatch "\.shtml[.$]">
SetOutputFilter INCLUDES
</FilesMatch>
</Directory>
# "400 Bad Request",
ErrorDocument 400 /errordocs/400
# "401 Authorization Required",
ErrorDocument 401 /errordocs/401
# "403 Forbidden",
ErrorDocument 403 /errordocs/403
# "404 Not Found",
ErrorDocument 404 /errordocs/404
# "500 Internal Server Error",
ErrorDocument 500 /errordocs/500
/usr/local/apache/errordocs/) must then be created
with the appropriate permissions (readable and executable by
the server uid or gid, only writable for the administrator).Naming the Individual Error Document files
MultiViews option, the server was
told to automatically scan the directory for matching variants
(looking at language and content type suffixes) when a
requested document was not found. In the configuration, we
defined the names for the error documents to be just their
error number (without any suffix).
errordocs/403.shtml.lang is created and
filled with the error text in that language (see below).errordocs/403.shtml is created, usually by
creating a symlink to the default language variant (see below).The Common Header and Footer Files
title.head.shtml because it contains server-parsed
content but no language specific information. The footer file
exists once for each language translation, plus a symlink for
the default language.
for English, French and German versions (default english)
foot.shtml.en,
foot.shtml.fr,
foot.shtml.de,
foot.shtml symlink to
foot.shtml.en
<!--#include virtual="head" -->
and <!--#include virtual="foot" -->
respectively: the rest of the magic occurs in mod_negotiation
and in mod_include.Creating ErrorDocuments in Different Languages
<!--#set var="title" value="error description title" -->
<!--#include virtual="head" -->
explanatory error text
<!--#include virtual="foot" -->
The Fallback Language
for f in *.shtml.en
do
ln -s $f `basename $f .en`
done
Customizing Proxy Error Messages
ErrorDocument mechanism for proxy error messages
as well (previous versions always returned fixed predefined
error messages).ERROR_NOTES CGI
environment variable: if invoked for a proxy error, this
variable will contain the actual proxy error message text in
HTML form.ERROR_NOTES variable within an error document:
<!--#if expr="$REDIRECT_ERROR_NOTES = ''" -->
<p>
The server encountered an unexpected condition
which prevented it from fulfilling the request.
</p>
<p>
<a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
SUBJECT="Error message [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> for <!--#echo var="REQUEST_URI" -->">
Please forward this error screen to <!--#echo var="SERVER_NAME" -->'s
WebMaster</a>; it includes useful debugging information about
the Request which caused the error.
<pre><!--#printenv --></pre>
</p>
<!--#else -->
<!--#echo var="REDIRECT_ERROR_NOTES" -->
<!--#endif -->
HTML Listing of the Discussed Example
400.shtml.en document. You will notice that it
contains almost nothing but the error text (with conditional
additions). Starting with this example, you will find it easy
to add more error documents, or to translate the error
documents to different languages.
<!--#set var="title" value="Bad Request"-->
<!--#include virtual="head" -->
<p>
Your browser sent a request that this server could not understand:
<blockquote>
<strong><!--#echo var="REQUEST_URI" --></strong>
</blockquote>
The request could not be understood by the server due to malformed
syntax. The client should not repeat the request without
modifications.
</p>
<p>
<!--#if expr="$HTTP_REFERER != ''" -->
Please inform the owner of
<a href="<!--#echo var="HTTP_REFERER" -->">the referring page</a> about
the malformed link.
<!--#else -->
Please check your request for typing errors and retry.
<!--#endif -->
</p>
<!--#include virtual="foot" -->
head.shtml.en file (the funny
line breaks avoid empty lines in the document after SSI
processing). Note the configuration section at top. That's
where you configure the images and logos as well as the apache
documentation directory. Look how this file displays two
different logos depending on the content of the virtual host
name ($SERVER_NAME), and that an animated apache logo is shown
if the browser appears to support it (the latter requires
server configuration lines of the form BrowserMatch "^Mozilla/[2-4]" anigif
<!--#if expr="$SERVER_NAME = /.*\.mycompany\.com/" -->
<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" -->
<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
<!--#else -->
<!--#set var="IMG_CorpLogo" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" -->
<!--#set var="ALT_CorpLogo" value="Powered by Linux!" -->
<!--#endif-->
<!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" -->
<!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" -->
<!--#if expr="$anigif" -->
<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" -->
<!--#else-->
<!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" -->
<!--#endif-->
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>
[<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" -->
</title>
</head>
<body bgcolor="white" background="<!--#echo var="IMG_BgImage" -->">
<h1 align="center">
[<!--#echo var="REDIRECT_STATUS" -->]
<!--#echo var="title" -->
<img src="<!--#echo var="IMG_CorpLogo" -->"
alt="<!--#echo var="ALT_CorpLogo" -->" align="right">
</h1>
<hr />
<!-- ======================================================== -->
<div>
foot.shtml.en file:
</div>
<hr />
<div align="right">
<small>Local Server time:
<!--#echo var="DATE_LOCAL" --></small>
</div>
<div align="center">
<a href="<!--#echo var="DOC_Apache" -->">
<img src="<!--#echo var="IMG_Apache" -->" border="0" align="bottom"
alt="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></a>
<br />
<small><!--#set var="var" value="Powered by $SERVER_SOFTWARE --
File last modified on $LAST_MODIFIED" -->
<!--#echo var="var" --></small>
</div>
<p>If the indicated error looks like a misconfiguration, please inform
<a href="mailto:<!--#echo var="SERVER_ADMIN" -->"
subject="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" -->]
<!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->">
<!--#echo var="SERVER_NAME" -->'s WebMaster</a>.
</p>
</body>
</html>
misc/fin_wait_2.html 100644 0 0 47302 11074463123 12076 0 ustar 0 0
Descriptors and Apache
Warning:
stdin, stdout, and
stderr which are descriptors 0, 1, and 2
respectively. Apache needs a descriptor for each log file, plus
one for each network socket that it listens on, plus a handful
of others. Libraries that Apache uses may also require
descriptors. Normal programs don't open up many descriptors at
all, and so there are some latent problems that you may
experience should you start running Apache with many
descriptors (i.e., with many virtual hosts).
#open files <= soft limit <= hard limit <= kernel limit
limit (csh) or ulimit (sh)
directives. See the respective man pages for more information.
For example you can probably use ulimit -n
unlimited to raise your soft limit up to the hard limit.
You should include this command in a shell script which starts
your webserver.
BSDI 2.0
-DFD_SETSIZE=nnn to
EXTRA_CFLAGS (where nnn is the number of
descriptors you wish to support, keep it less than the hard
limit). But it will run into trouble if more than
approximately 240 Listen directives are used. This may be
cured by rebuilding your kernel with a higher
FD_SETSIZE.
FreeBSD 2.2, BSDI 2.1+
FD_SETSIZE and rebuild. But the extra Listen
limitation doesn't exist.
Linux
Solaris through 2.5.1
-DHIGH_SLACK_LINE=256 added to
EXTRA_CFLAGS. You will be limited to
approximately 240 error logs if you do this.
AIX
SCO OpenServer
/etc/conf/cf.d/stune file or use
/etc/conf/cf.d/configure choice 7 (User and
Group configuration) and modify the NOFILES
kernel parameter to a suitably higher value. SCO recommends a
number between 60 and 11000, the default is 110. Relink and
reboot, and the new number of descriptors will be
available.
Compaq Tru64 UNIX/Digital UNIX/OSF
open_max_soft and
open_max_hard to 4096 in the proc subsystem.
Do a man on sysconfig, sysconfigdb, and
sysconfigtab.max-vnodes to a large number which
is greater than the number of apache processes * 4096
(Setting it to 250,000 should be good for most people).
Do a man on sysconfig, sysconfigdb, and
sysconfigtab.NO_SLACK to work around a bug in the OS.
CFLAGS="-DNO_SLACK" ./configure
Others
LOW_SLACK_LINE and there's a tiny bit of
documentation in the header file httpd.h.-DNO_SLACK
to EXTRA_CFLAGS and rebuild. But please report it
to our Bug
Report Page so that we can investigate.
misc/index.html 100644 0 0 11470 11074463123 11161 0 ustar 0 0
Connections in the FIN_WAIT_2 state and Apache
Warning:
netstat) than they saw using older
versions. When the server closes a TCP connection, it sends
a packet with the FIN bit set to the client, which then
responds with a packet with the ACK bit set. The client
then sends a packet with the FIN bit set to the server,
which responds with an ACK and the connection is closed.
The state that the connection is in during the period
between when the server gets the ACK from the client and
the server gets the FIN from the client is known as
FIN_WAIT_2. See the TCP RFC for
the technical details of the state transitions.
Why Does It Happen?
Buggy Clients and Persistent
Connections
KeepAliveTimeout),
the client is programmed so that the client does not send
back a FIN and ACK to the server. This means that the
connection stays in the FIN_WAIT_2 state until one of the
following happens:
A necessary bit of code
introduced in 1.2
lingering_close() which was
added between 1.1 and 1.2. This function is necessary for
the proper handling of persistent connections and any
request which includes content in the message body
(e.g., PUTs and POSTs). What it does is read any
data sent by the client for a certain time after the server
closes the connection. The exact reasons for doing this are
somewhat complicated, but involve what happens if the
client is making a request at the same time the server
sends a response and closes the connection. Without
lingering, the client might be forced to reset its TCP
input buffer before it has a chance to read the server's
response, and thus understand why the connection has
closed. See the appendix for more
details.lingering_close() appears to
cause problems for a number of factors, including the
change in traffic patterns that it causes. The code has
been thoroughly reviewed and we are not aware of any bugs
in it. It is possible that there is some problem in the BSD
TCP stack, aside from the lack of a timeout for the
FIN_WAIT_2 state, exposed by the
lingering_close code that causes the observed
problems.
What Can I Do About it?
Add a timeout for FIN_WAIT_2
ndd to modify
tcp_fin_wait_2_flush_interval, but the
default should be appropriate for most servers and
improper tuning can have negative impacts.SO_LINGER socket option which is enabled by
Apache. This parameter can be adjusted by using
nettune to modify parameters such as
tcp_keepstart and tcp_keepstop.
In later revisions, there is an explicit timer for
connections in FIN_WAIT_2 that can be modified; contact
HP support for details.
Compile without using
lingering_close()lingering_close() function. This will result
in that section of code being similar to that which was in
1.1. If you do this, be aware that it can cause problems
with PUTs, POSTs and persistent connections, especially if
the client uses pipelining. That said, it is no worse than
on 1.1, and we understand that keeping your server running
is quite important.lingering_close()
function, add -DNO_LINGCLOSE to the end of the
EXTRA_CFLAGS line in your
Configuration file, rerun
Configure and rebuild the server.Use
SO_LINGER as
an alternative to lingering_close()SO_LINGER that can be set with
setsockopt(2). It does something very similar
to lingering_close(), except that it is broken
on many systems so that it causes far more problems than
lingering_close. On some systems, it could
possibly work better so it may be worth a try if you have
no other alternatives.-DUSE_SO_LINGER
-DNO_LINGCLOSE to the end of the
EXTRA_CFLAGS line in your
Configuration file, rerun
Configure and rebuild the server.NOTE
Attempting to use
SO_LINGER and lingering_close()
at the same time is very likely to do very bad things, so
don't.Increase the amount of memory
used for storing connection state
NMBCLUSTERS="n", where
n is the number of mbuf clusters you want
to your kernel config file and rebuilding your
kernel.Disable KeepAlive
Appendix
Why the lingering close
functionality is necessary with HTTP
misc/known_client_problems.html 100644 0 0 50431 11074463123 14447 0 ustar 0 0
Apache Miscellaneous Documentation
Warning
FIN_WAIT_2FIN_WAIT_2 state, and what you can do
about it.mod_rewrite
reference documentation.
It describes how one can use Apache's mod_rewrite
to solve typical URL-based problems webmasters are usually confronted
with in practice.
misc/perf-tuning.html 100644 0 0 126701 11074463123 12334 0 ustar 0 0
Known Problems in Clients
Warning:
mod_browser. Unless
otherwise noted all of these workarounds exist in versions 1.2
and later.
Trailing CRLF on POSTs Broken KeepAlive Incorrect interpretation of
HTTP/1.1 in response Requests use HTTP/1.1 but
responses must be in HTTP/1.0 Boundary problems with
header parsing Multipart responses and
Quoted Boundary Strings Byterange Requests Set-Cookie header is
unmergeable Expires headers
and GIF89A animations POST without
Content-Length JDK 1.2 betas lose
parts of responses. Content-Type
change is not noticed after reload MSIE Cookie
problem with expiry date in the year 2000 Lynx incorrectly asking for
transparent content negotiation MSIE 4.0 mishandles Vary
response header
Trailing CRLF on POSTs
POST data to have an extra CRLF
following it. Thus many clients send an extra CRLF
that is not included in the Content-Length of the
request. Apache works around this problem by eating any empty
lines which appear before a request.
Broken KeepAlive
BrowserMatch Mozilla/2 nokeepalive
nokeepalive code prior to 1.2.2 would not work
with HTTP/1.1 clients. You must apply
this patch to version 1.2.1. Then add this to your
config:
BrowserMatch "MSIE 4\.0b2;" nokeepalive
Incorrect interpretation of
HTTP/1.1 in response
HTTP uses a "<MAJOR>.<MINOR>" numbering scheme to
indicate versions of the protocol. The protocol versioning
policy is intended to allow the sender to indicate the format
of a message and its capacity for understanding further HTTP
communication, rather than the features obtained via that
communication.
force-response-1.0 environment variable was added
to Apache. When present Apache will indicate "HTTP/1.0" in
response to an HTTP/1.0 client, but will not in any other way
change the response.
BrowserMatch Java/1.0 force-response-1.0
BrowserMatch JDK/1.0 force-response-1.0
User-Agent
as version 4.0. The workaround is still:
BrowserMatch "RealPlayer 4.0" force-response-1.0
Requests use HTTP/1.1 but
responses must be in HTTP/1.0
BrowserMatch "MSIE 4\.0b2;" downgrade-1.0
force-response-1.0
Boundary problems with
header parsing
Multipart responses and
Quoted Boundary Strings
Byterange Requests
Request-Range, and a response type
multipart/x-byteranges. The HTTP/1.1 standard
includes this draft with a few fixes, and it defines the header
Range and type
multipart/byteranges.Range
and Request-Range headers (with the same value),
but does not accept a multipart/byteranges
response. The response must be
multipart/x-byteranges. As a workaround, if Apache
receives a Request-Range header it considers it
"higher priority" than a Range header and in
response uses multipart/x-byteranges.multipart/x-byterange response. Unfortunately
there is no clue that it is the plugin making the request. If
the plugin is used with Navigator, the above workaround works
fine. But if the plugin is used with MSIE 3 (on Windows) the
workaround won't work because MSIE 3 doesn't give the
Range-Request clue that Navigator does. To
workaround this, Apache special cases "MSIE 3" in the
User-Agent and serves
multipart/x-byteranges. Note that the necessity
for this with MSIE 3 is actually due to the Acrobat plugin, not
due to the browser.Request-Range header. When an Acrobat plugin prior
to version 3.01 is used with it, it will not properly
understand byteranges. The user must upgrade their Acrobat
reader to 3.01.
Set-Cookie header is
unmergeableSet-Cookie header is sent
separately. When parsing the headers returned by a CGI, Apache
will explicitly avoid merging any Set-Cookie
headers.
Expires headers
and GIF89A animationsExpires header. This happens
regardless of how far in the future the expiry time is set.
There is no workaround supplied with Apache, however there are
hacks for
1.2 and for
1.3.
POST without
Content-Length
JDK 1.2 betas lose
parts of responses.
BrowserMatch "Java1\.2beta[23]" nokeepalive
Content-Type
change is not noticed after reloadcontent-type for an object "forever". Using reload
or shift-reload will not cause Navigator to notice a
content-type change. The only work-around is for
the user to flush their caches (memory and disk). By way of an
example, some folks may be using an old mime.types
file which does not map .htm to
text/html, in this case Apache will default to
sending text/plain. If the user requests the page
and it is served as text/plain. After the admin
fixes the server, the user will have to flush their caches
before the object will be shown with the correct
text/html type.
MSIE Cookie
problem with expiry date in the year 2000
Lynx incorrectly asking for
transparent content negotiation
MSIE 4.0 mishandles Vary
response header
BrowserMatch "MSIE 4\.0" force-no-vary
misc/relevant_standards.html 100644 0 0 17537 11074463123 13747 0 ustar 0 0
아파치 성능향상
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
하드웨어와 운영체제에 대해서
MaxClients 지시어를 조절하여
웹서버가 스왑을 할 정도로 많은 자식을 만들지않도록 해야
한다. 방법은 간단하다: top과 같은 도구에서
프로세스 목록을 보고 아파치 프로세스의 평균 메모리 사용량을
알아낸후, 전체 사용가능한 메모리에서 다른 프로세스들이 사용할
공간을 뺀 값에서 나눈다.
sendfile(2) 시스템호출을
지원한다면, 이를 사용하기위한 버전이나 패치를 설치하였는지
확인한다. (예를 들어, 리눅스라면 2.4 이상 버전을 뜻한다.
Solaris 8 초기 버전은 패치가 필요하다.) 지원하는 시스템이라면
아파치 2는 sendfile을 사용하여 CPU를 덜
사용하며 정적 파일을 더 빨리 전송할 수 잇다.
실행시 설정에 대해서
관련된 모듈 관련된 지시어 HostnameLookups와 DNS에 대해 고려할 점들
HostnameLookups의 기본값은
On이였다. 요청을 마치기전에 DNS 검색이 끝나야
하므로 요청마다 지연이 생겼다. 아파치 1.3에서 이 설정의
기본값이 Off로 변경되었다. 로그파일의 주소를
호스트명으로 변환하려면 여러 로그처리 프로그램중 하나인,
아파치에 포함된 logresolve
프로그램을 사용하라.Allow
from domainDeny from domain<Location /server-status> 섹션 등으로
지시어의 적용범위를 제한할 수 있음을 기억하라. 이 경우
조건에 맞는 요청에만 DNS 조회를 한다. 다음은
.html과 .cgi 파일만 DNS 검색을
하는 예제다:
HostnameLookups off
<Files ~ "\.(html|cgi)$">
HostnameLookups on
</Files>
gethostbyname 호출을 하도록 고려해볼
수 있다.FollowSymLinks와 SymLinksIfOwnerMatch
Options FollowSymLinks를
사용하지않고 Options SymLinksIfOwnerMatch를
사용하면 아파치는 심볼링크를 검사하기위해 시스템호출을
한번 더 해야 한다. 파일명의 각 부분마다 한번씩 더 호출을
한다. 예를 들어, 설정이 다음과 같고:
DocumentRoot /www/htdocs
<Directory />
Options SymLinksIfOwnerMatch
</Directory>
/index.html URI에 대한 요청이 있다고 가정하자.
그러면 아파치는 /www, /www/htdocs,
/www/htdocs/index.html 각각에 대해
lstat(2)를 호출한다. lstats
결과를 캐싱하지 않기때문에 요청이 들어올 때마다 매번 같은
작업을 한다. 진짜 심볼링크 보안 검사를 원한다면 다음과
같이 할 수 있다:
DocumentRoot /www/htdocs
<Directory />
Options FollowSymLinks
</Directory>
<Directory /www/htdocs>
Options -FollowSymLinks +SymLinksIfOwnerMatch
</Directory>
DocumentRoot 경로는 검사하지
않는다. DocumentRoot 밖에 있는 경로로 Alias나 RewriteRule을 사용한
경우에도 위와 비슷한 섹션이 필요하다. 심볼링크 보안을
고려하지 않고 최고의 성능을 얻으려면,
FollowSymLinks를 설정하고,
SymLinksIfOwnerMatch는 절대로 안된다.AllowOverride
.htaccess 파일) 아파치는 파일명의 각 부분마다
.htaccess를 열길 시도한다. 예를 들어,
DocumentRoot /www/htdocs
<Directory />
AllowOverride all
</Directory>
/index.html URI에 대한 요청이 있다고 가정하자.
아파치는 /.htaccess, /www/.htaccess,
/www/htdocs/.htaccess를 열려고 시도한다.
해결책은 앞의 Options FollowSymLinks 경우와
비슷하다. 최고의 성능을 얻으려면 파일시스템에 대해서 항상
AllowOverride None을 사용한다.내용협상
DirectoryIndex index
DirectoryIndex index.cgi index.pl index.shtml index.html
MultiViews
보다는, 한 파일만 읽으면 필요한 정보를 얻을 수 있는
type-map 파일을 직접 만드는 것이 더 빠름을
명심하라.Options
MultiViews 지시어를 사용하기보다 type-map
파일을 고려하라. 협상방법에 대한 자세한 설명과
type-map 파일을 만드는 방법은 내용협상 문서를 참고하라.메모리대응 (memory-mapping)
mmap(2)
등을 지원한다면 파일을 메모리대응한다.
mmap은 CPU 개수가
많아질때 read(2) 만큼 확장성이 좋지 않다.
예를 들어, 다중프로세서 Solaris 서버에서 아파치 2.0은
종종 mmap을 사용하지 않을때 서버가 처리한
파일을 더 빨리 전송한다.EnableMMAP off를 사용해야 한다. (주의:
이 지시어는 디렉토리별로 변경할 수 있다.)Sendfile
sendfile(2)을 지원하면
커널 sendfile을 사용하여 -- 예를 들어, 정적 파일을 서비스할때
-- 전송할 파일을 직접 읽지않을 수 있다.
EnableSendfile off를 사용해야 한다. (주의:
이 지시어는 디렉토리별로 변경할 수 있다.)프로세스 생성
MinSpareServers, MaxSpareServers, StartServers 설정이 모두
벤치마크 결과에 큰 영향을 미쳤다. 특히 아파치는 작업을
서비스하기위해 충분한 자식수에 다다를 때까지 "도달" 기간이
필요했다. 처음 StartServers개 자식을
만든후, MinSpareServers
설정값까지 초당 자식을 하나씩 만들었다. 그래서 StartServers 기본값이
5인 서버에 클라이언트 100개가 동시에 접속하면
부하를 처리하기에 충분한 자식을 만들기까지 95초가 걸렸다.
자주 재시작하지 않는 실제 서버에서는 잘 동작하지만, 10분간만
실행하는 벤치마크 결과는 매우 나쁘게 나온다.MinSpareServers 설정에 다다르면
증가를 중단한다.MinSpareServers, MaxSpareServers, StartServers를 거의 설정할 필요가 없다. 일초에
자식을 4개 이상 생성하면 ErrorLog에 기록한다. 이런 오류문이
많이 보이면 이 설정들을 조절하길 바란다.
mod_status 결과가 도움이 될 것이다.MaxRequestsPerChild 설정은
프로세스를 종료한다. 기본값은 자식당 처리할 요청수에 제한이
없다는 0이다. 현재 설정이 30과
같이 매우 작은 값으로 설정되있다면, 값을 상당히 높힐 필요가
있다. SunOS나 오래된 Solaris 버전을 사용한다면, 메모리유출때문에
이 값을 10000 정도로 설정하라.KeepAliveTimeout의
기본값 15 초는 이런 현상을 최소화한다. 네트웍
대역폭과 서버 자원 간의 균형이 맞게 설정한다.
연결유지의 대부분의 이점이 사라지기때문에 어떤 경우에도
이 값을 60 초 이상으로 올리지 마라.
컴파일시 설정에 대해서
MPM 선택
beos,
mpm_netware, mpmt_os2,
mpm_winnt와 같이 특정 플래폼에서만 사용할
수 있는 MPM도 있다. 일반적인 유닉스류 시스템은 여러 MPM
중에 하나를 선택할 수 있다. 웹서버의 속도와
확장성(scalability)은 어떤 MPM을 선택했냐에 달렸다:
worker MPM은 여러 자식 프로세스가
각각 여러 쓰레드를 사용한다. 각 쓰레드는 한번에 한 연결을
담당한다. 일반적으로 worker는 prefork MPM 보다 적은
메모리를 사용하므로 통신량이 많은 서버에 적절하다.prefork MPM은 쓰레드가 한개인 자식
프로세스를 여러개 사용한다. 각 프로세스는 한번에 한
연결을 담당한다. 여러 시스템에서 prefork의 속도는 worker와
비슷하지만, 더 많은 메모리를 사용한다. 다음과 같은 상황에서
쓰레드를 사용하지 않는 prefork 방식이 worker에 비해
이점을 가진다: 쓰레드에 안전하지 (thread-safe) 않은
제삼자가 만든 모듈을 사용할 수 있고, 쓰레드 디버깅 지원이
빈약한 플래폼에서 쉽게 디버깅할 수 있다.모듈
LoadModule 지시어를 주석처리하면
된다. 그래서 모듈을 제거하고 실행하여 사이트가 모듈없이도
정상적으로 동작하는지 살펴볼 수 있다.mod_mime,
mod_dir, mod_log_config
모듈은 사용할 것이다. 물론 웹사이트에 로그파일이 필요없다면
mod_log_config는 없어도 된다. 그러나 추천하지
않는다.Atomic 명령
mod_cache 같은 모듈과 최근 개발중인
worker MPM은 APR의 atomic API를 사용한다. 이 API는 경량급
쓰레드 동기화를 위할 atomic 명령을 제공한다.--enable-nonportable-atomics
옵션을 사용하여 더 빠른 atomic 구현을 선택할 수 있다:
./buildconf
./configure --with-mpm=worker --enable-nonportable-atomics=yes
--enable-nonportable-atomics 옵션은 다음과
같은 플래폼에 영향이 있다:
기본적으로 APR은 Solaris/SPARC에서 mutex기반 atomic을
사용한다. 그러나 구성할때
--enable-nonportable-atomics를 사용하면
APR은 빠른 하드웨어 compare-and-swap을 위한 SPARC
v8plus 명령어를 사용한다. 이 옵션을 사용하면 atomic
명령이 더 효율적이지만 (CPU를 덜 사용하고 더 높은
동기화가 가능하다), 컴파일한 실행파일은 UltraSPARC
칩에서만 실행할 수 있다.
기본적으로 APR은 리눅스에서 mutex기반 atomic을
사용한다. 그러나 구성할때
--enable-nonportable-atomics를 사용하면
APR은 빠른 하드웨어 compare-and-swap을 위한 486
명령어를 사용한다. 더 효율적인 atomic 명령이 가능하지만,
컴파일한 실행파일은 486 이상 칩에서만 (386은 안된다)
실행할 수 있다.
mod_status와 ExtendedStatus On
mod_status를 포함하고
실행할때 ExtendedStatus On을 설정하면 아파치는
요청을 받을때마다 gettimeofday(2)(혹은 운영체제에
따라 times(2))를 두번 호출하고 (1.3 이전에는)
time(2)도 추가로 여러번 호출한다. 상태 보고서에
동작시간이 필요하기 때문이다. 최상의 성능을 얻으려면
(기본값인) ExtendedStatus off를 설정한다.accept 직렬화 - 여러 소켓
주의:
Listen을 사용한다고 가정하자.
연결이 가능한지 각 소켓을 검사하기위해 아파치는
select(2)를 사용한다. select(2)는
소켓에 기다리고 있는 연결이 없는지 혹은 최소한
한개 있는지 알려준다. 아파치에는 여러 자식이 있고,
쉬고 있는 모든 자식은 동시에 새로운 연결을 검사한다. 원래
구현은 다음과 비슷하다 (이 예는 코드에서 가져오지 않았다.
단지 설명하기위한 용도로 만들었다.):
for (;;) {
for (;;) {
fd_set accept_fds;
FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
FD_SET (i, &accept_fds);
}
rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
}
if (new_connection != -1) break;
}
process the new_connection;
}
select에서 멈춘다. 이때
어떤 소켓에 요청이 하나라도 들어오면 모든 자식이 깨어난다
(깨어나는 자식의 개수는 운영체제와 타이밍에 따라 다르다).
이들은 모두 연결을 accept하길 시도한다. 그러나
(아직도 한 연결만 대기중이라면) 한 자식만 성공하고, 나머지는
accept에서 멈춘다. 그러면 이 자식들은
한 소켓의 요청만을 서비스하도록 묶여서, 그 소켓으로 새로운
요청이 충분히 들어와서 모든 자식을 깨울때까지 정지해있다.
이런 고갈 문제는 PR#467에
처음 보고되었다. 최소한 두가지 해결책이 있다.accept를 해도 멈추지
않고, 즉시 진행할 수 있다. 그러나 CPU 시간을 낭비한다.
select에서 쉬는 자식이 10개 있고, 새로 연결이
한개 들어왔다고 가정하자. 그러면 이 자식중 9개는 깨어나서
연결을 accept하길 시도하고 실패하면 아무
일도 하지 않고 다시 select를 반복한다. 다시
select로 돌아올 때까지 어떤 자식도 다른 소켓에
들어온 요청을 서비스하지 않는다. (다중프로세서 컴퓨터에서)
쉬는 자식 개수만큼 CPU 개수가 있는 드문 경우가 아니라면
이 해결책은 별로 좋아보이지 않는다.
for (;;) {
accept_mutex_on ();
for (;;) {
fd_set accept_fds;
FD_ZERO (&accept_fds);
for (i = first_socket; i <= last_socket; ++i) {
FD_SET (i, &accept_fds);
}
rc = select (last_socket+1, &accept_fds, NULL, NULL, NULL);
if (rc < 1) continue;
new_connection = -1;
for (i = first_socket; i <= last_socket; ++i) {
if (FD_ISSET (i, &accept_fds)) {
new_connection = accept (i, NULL, NULL);
if (new_connection != -1) break;
}
}
if (new_connection != -1) break;
}
accept_mutex_off ();
process the new_connection;
}
accept_mutex_on과 accept_mutex_off
함수는 mutex 세마포어를
구현한다. 한번에 오직 한 자식만이 mutex를 가질 수 있다.
mutex를 구현하는 방법은 여러가지이다. 구현 방법은 (1.3
이전) src/conf.h나 (1.3과 그 이후)
src/include/ap_config.h에 정의되있다. 어떤
아키텍쳐는 잠금(locking) 방법을 선택하지 않기때문에, 이런
아키텍쳐에서 여러 Listen 지시어를 사용하면
위험하다.AcceptMutex 지시어를 사용하여
mutex 구현을 변경할 수 있다.
AcceptMutex flockflock(2)
시스템호출을 사용한다 (잠금파일 위치는 LockFile 지시어로 지정).AcceptMutex fcntlfcntl(2)
시스템호출을 사용한다 (잠금파일 위치는 LockFile 지시어로 지정).AcceptMutex sysvsemipcs(8) manpage
참고). 다른 하나는 웹서버와 동일한 uid로 실행하는
CGI가 (즉, suexec나
cgiwrapper를 사용하지않는 한 모든 CGI)
세마포어 API를 사용하여 서비스거부공격을 할 수 있는
점이다. 이런 이유때문에 IRIX를 제외한 아키텍쳐에서
이 방법을 사용하지 않는다 (대부분의 IRIX 컴퓨터에서
앞의 두 방법은 지나치게 버겁다).AcceptMutex pthreadAcceptMutex posixsemListen 문을 사용하지 않는
것이 이상적이다. 그러나 계속 설명한다.accept 직렬화 - 소켓 한개
accept(2)에서 멈춰있기때문에 이론상 같은
문제가 발생하지 않고, 고갈 문제도 없다. 그러나 실제로는
앞에서 말한 대기하지 않는 (non-blocking) 방법에서 발생하는
"공회전(spinning)" 현상을 감추고 있다. 대부분의 TCP 스택은
연결이 도착하면 커널이 accept에서 멈춰있는
모든 자식을 깨우도록 구현되있다. 프로세스중 한개가 연결을
얻고 사용자영역으로 돌아가고, 나머지는 커널에서 공회전하여
연결이 없음을 발견하면 다시 잠을 잔다. 사용자영역 코드에서는
이런 공회전을 알 수 없지만, 분명히 존재한다. 그래서 다중소켓의
대기하지 않는 방법과 동일하게 부하를 높이는 불필요한 행동이
일어난다.SINGLE_LISTEN_UNSERIALIZED_ACCEPT를
정의한다.Close 지연(lingering)
FIN_WAIT_2에 타임아웃이 있다고 정하지 않았지만,
금지하지도 않았다. 타임아웃이 없는 시스템에서 아파치 1.2는
많은 소켓을 영원히 FIN_WAIT_2 상태로 만들었다.
많은 경우 이 문제는 제작사가 제공하는 최신 TCP/IP 패치를
적용하여 해결할 수 있다. 그러나 제작사가 패치를 발표하지
않는 경우가 (즉, SunOS4 -- 소스 라이선스가 있는
사람은 직접 패치할 수 있지만) 있기때문에 이 기능을 사용하지
않기로 결정했다.SO_LINGER를
사용하는 방법이다. 그러나 불행히도 대부분의 TCP/IP 스택은
이 옵션을 올바로 구현하지 않았다. 올바로 구현한 스택에서
조차도 (즉, 리눅스 2.0.31) 이 방법은 다음 방법보다
더 cpu를 잡아먹는다.http_main.c에 있는)
lingering_close라는 함수를 사용한다. 이 함수는
대충 다음과 같다:
void lingering_close (int s)
{
char junk_buffer[2048];
/* shutdown the sending side */
shutdown (s, 1);
signal (SIGALRM, lingering_death);
alarm (30);
for (;;) {
select (s for reading, 2 second timeout);
if (error) break;
if (s is ready for reading) {
if (read (s, junk_buffer, sizeof (junk_buffer)) <= 0) {
break;
}
/* just toss away whatever is here */
}
}
close (s);
}
NO_LINGCLOSE를 정의하여 이 기능을 사용하지
않을 수 있지만, 절대로 권하지 않는다. 특히 HTTP/1.1
파이프라인 (역주; 연결유지 상태에서 응답을 기다리지
않고 여러 요청을 보내는 기술) 연결유지에는
lingering_close가 필수적이다 (그리고
파이프라인 연결이 더 빠르기때문에 사용하길 바랄 것이다).Scoreboard 파일
src/main/conf.h 파일에서 사용하는 아키텍쳐를
찾아서 USE_MMAP_SCOREBOARD 혹은
USE_SHMGET_SCOREBOARD인지 확인한다. 둘중
하나를 (각각 함께 사용할 HAVE_MMAP이나
HAVE_SHMGET도 같이) 정의하면 공유메모리 코드를
사용한다. 시스템이 다른 종류의 공유메모리를 사용한다면
src/main/http_main.c 파일을 수정하여 아파치에서
공유메모리를 사용할 수 있도록 훅(hook)을 추가하라. (또한
패치를 우리에게 보내주길 바란다.)역사적 설명: 아파치의 리눅스 버전은 아파치 1.2 버전부터
공유메모리를 사용하기 시작했다. 리눅스에서 초기 아파치
버전이 느리고 신뢰도가 떨어졌기 때문이다.
DYNAMIC_MODULE_LIMIT
-DDYNAMIC_MODULE_LIMIT=0을 추가한다. 그러면
모듈을 동적으로 읽어들이기위해 할당하는 메모리를 절약한다.
부록: 시스템호출 기록을 자세히 분석하기
truss -l -p httpd_child_pid.
-l 옵션을 사용하면 truss는 시스템호출을
하는 LWP (lightweight process, 경량급 프로세스--Solaris의
커널수준 쓰레드) ID를 같이 기록한다.strace, ktrace,
par 같은 시스템호출 추적 도구가 있다. 결과는
비슷하다./67: accept(3, 0x00200BEC, 0x00200C0C, 1) (sleeping...)
/67: accept(3, 0x00200BEC, 0x00200C0C, 1) = 9
accept(2) 직렬화를 사용하지 않음을 주목하라.
여러 포트를 기다리지않는 경우 이 플래폼의 worker MPM은
기본적으로 직렬화하지 않은 accept를 사용한다./65: lwp_park(0x00000000, 0) = 0
/67: lwp_unpark(65, 1) = 0
/65: getsockname(9, 0x00200BA4, 0x00200BC4, 1) = 0
Listen
지시어에 와일드카드 주소를 사용하지 않은 경우 등) 많은 경우
이 호출을 없앨 수 있다. 그러나 아직 이런 최적화 작업이
안되있다. /65: brk(0x002170E8) = 0
/65: brk(0x002190E8) = 0
brk(2) 호출은 힙(heap)에서 메모리를 할당한다.
웹서버는 대부분의 요청 처리시 자체 메모리
할당자(apr_pool과 apr_bucket_alloc)를
사용하기때문에 시스템호출 기록에서 이 시스템호출을 보기가
드물다. 이 기록에서 웹서버는 시작하자마자 자체 메모리 할당자가
사용할 메모리블록을 얻기위해 malloc(3)을 호출한다./65: fcntl(9, F_GETFL, 0x00000000) = 2
/65: fstat64(9, 0xFAF7B818) = 0
/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B910, 2190656) = 0
/65: fstat64(9, 0xFAF7B818) = 0
/65: getsockopt(9, 65535, 8192, 0xFAF7B918, 0xFAF7B914, 2190656) = 0
/65: setsockopt(9, 65535, 8192, 0xFAF7B918, 4, 2190656) = 0
/65: fcntl(9, F_SETFL, 0x00000082) = 0
setsockopt(2)와
getsockopt(2) 호출은 Solaris의 libc가 소켓에
대한 fcntl(2)을 어떻게 처리하는지 보여준다./65: read(9, " G E T / 1 0 k . h t m".., 8000) = 97
/65: stat("/var/httpd/apache/httpd-8999/htdocs/10k.html", 0xFAF7B978) = 0
/65: open("/var/httpd/apache/httpd-8999/htdocs/10k.html", O_RDONLY) = 10Options FollowSymLinks와
AllowOverride None이다. 그래서 요청한 파일경로의
각 디렉토리에 대해 lstat(2)하거나
.htaccess 파일을 검사할 필요가 없다. 파일을
검사하기위해, 1) 파일이 있는지, 2) 디렉토리가 아닌 일반파일인지,
stat(2) 호출만 하면 된다./65: sendfilev(0, 9, 0x00200F90, 2, 0xFAF7B53C) = 10269
sendfilev(2) 시스템호출로
HTTP 응답헤더와 요청한 파일을 전송할 수 있다. Sendfile 지원여부는
운영체제마다 다르다. 다른 시스템이라면 sendfile(2)을
호출하기 전에 헤더를 보내기위해 write(2)나
writev(2) 호출을 한다./65: write(4, " 1 2 7 . 0 . 0 . 1 - ".., 78) = 78
write(2) 호출은 접근로그(access log)에 요청을
기록한다. 이 기록에 time(2) 호출이 없음을 주목하라.
아파치 1.3과 달리 아파치 2.0은 시간을 알기위해
gettimeofday(3)를 사용한다.
gettimeofday를 최적화한 리눅스와 Solaris 같은
몇몇 운영체제에서는 일반적인 시스템호출 부담이 없다./65: shutdown(9, 1, 1) = 0
/65: poll(0xFAF7B980, 1, 2000) = 1
/65: read(9, 0xFAF7BC20, 512) = 0
/65: close(9) = 0
/65: close(10) = 0
/65: lwp_park(0x00000000, 0) (sleeping...)
/67: accept(3, 0x001FEB74, 0x001FEB94, 1) (sleeping...)
accept(2)가 (요청이 매우
많은 경우 항상) 일어날 수 있다.
misc/rewriteguide.html 100644 0 0 174341 11074463123 12600 0 ustar 0 0
관련 표준
주의
HTTP 권고
HTML 권고
인증
언어/국가 코드
misc/security_tips.html 100644 0 0 36312 11074463123 12762 0 ustar 0 0
URL 재작성 지침서
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
Ralf S. Engelschall <rse@apache.org>
1997년 12월mod_rewrite 참조 문서를 보충한다.
이 문서는 웹관리자가 실제 작업에서 부딪치게되는 전형적인
URL관련 문제를 해결하기위해서 어떻게 아파치
mod_rewrite를 사용하는지 설명한다. URL
재작성 규칙을 설정하여 문제를 해결하는 방법을 자세히 설명한다.
mod_rewrite 소개mod_rewrite 모듈은 굉장하다.
즉, URL을 조작할 수 있는 강력하고 실로 정교한 모듈이다.
상상해왔던 거의 모든 종류의 URL 조작이 가능하다. 그러나
그 대가로 사용하기 복잡하다. mod_rewrite의
최대 단점은 초보자가 이해하고 사용하기 쉽지 않다는 점이다.
심지어 아파치 전문가도 종종 mod_rewrite의
새로운 용도를 발견한다.mod_rewrite에 대해 당신은
처음에 겁을 먹고 절대로 다시 사용하지 않거나, 강력함에 매료되어
앞으로 삶 동안 사랑에 빠질 것이다. 이 글은 첫번째 경우를
막기위해 이미 알려진 몇가지 성공사례를 소개하려고 한다.
실용적인 해결책
주의: 서버 설정에 따라 상황에 맞게
예제를 조금 수정해야 할 경우가 있다. 예를 들어, 추가로
mod_alias, mod_userdir
등을 사용한다면 [PT] 플래그를 추가한다. 혹은
주서버설정/가상호스트 사용장소가 아닌 .htaccess
사용장소에 알맞게 규칙을 수정할 수도 있다. 사용하기 전에
항상 규칙이 어떤 기능을 하는지 이해하도록 해라. 그러면 문제를
피할 수 있다.
URL 구조
기준이 되는 URL
/~user를 기준이 되는 /u/user로
대체하고, /u/user 마지막에 슬래쉬가 없다면
추가한다.
RewriteRule ^/~([^/]+)/?(.*) /u/$1/$2 [R]
RewriteRule ^/([uge])/([^/]+)$ /$1/$2/ [R]
기준이 되는 호스트명
# 80번이 아닌 포트에서 실행하는 사이트용
RewriteCond %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteCond %{SERVER_PORT} !^80$
RewriteRule ^/(.*) http://fully.qualified.domain.name:%{SERVER_PORT}/$1 [L,R]
# 그리고, 80번 포트에서 실행하는 사이트용
RewriteCond %{HTTP_HOST} !^fully\.qualified\.domain\.name [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/(.*) http://fully.qualified.domain.name/$1 [L,R]
DocumentRoot를 옮긴 경우
DocumentRoot는 보통 URL
"/"과 직접 관련있다. 그러나 이곳에 모든
자료가 있지 않고, 자료가 다른 여러 곳에 흩어져있는
경우가 있다. 예를 들어 인트라넷 사이트에 (외부를 위한
홈페이지) /e/www/와 (인트라넷을 위한
홈페이지) /e/sww/가 있다고 하자. 이제
DocumentRoot가
/e/www/이기때문에, 요청에서 페이지에
포함된 그림 등을 이곳에서 가져와야 한다./를 /e/www/로
리다이렉션만 하면 된다. 사소해 보이지만 실제로
mod_rewrite를 사용해서만 가능하다.
(mod_alias 등이 제공하는) URL
Alias 같은 전형적인 방법은 앞부분만
찾는다. DocumentRoot가
모든 URL의 앞부분이기때문에 이 방법을 사용하여 리다이렉션을
할 수 없다. mod_rewrite를 사용하면
진짜 간단하다:
RewriteEngine on
RewriteRule ^/$ /e/www/ [R]
마지막 슬래쉬 문제
/~quux/foo/ 대신 /~quux/foo를
사용하면 서버가 foo라는 파일을
찾기때문에 오류가 발생한다. 파일이 디렉토리이기때문에
받아들이지 않는다. 대부분의 경우 보통 서버가 자동으로
URL을 고치지만, 가끔 직접 해줘야 할 경우가 있다. 예를
들어, CGI 스크립트 등으로 복잡한 URL 재작성을 한 후에
그러하다./~quux/foo/index.html에서
image.gif를 요청하면
/~quux/image.gif를 요청하게 된다!
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo$ foo/ [R]
.htaccess 파일에
다음과 같이 설정할 수도 있다. 그러나 처리하는데 부담이
된다.
RewriteEngine on
RewriteBase /~quux/
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.+[^/])$ $1/ [R]
일관된 URL 구조로 만든 웹클러스터
user1 server_of_user1
user2 server_of_user2
: :
map.xxx-to-host
파일에 저장했다. 다음으로 모든 서버에서 URL이 서버에
없다면 다음과 같은 URL을,
/u/user/anypath
/g/group/anypath
/e/entity/anypath
http://physical-host/u/user/anypath
http://physical-host/g/group/anypath
http://physical-host/e/entity/anypath
RewriteEngine on
RewriteMap user-to-host txt:/path/to/map.user-to-host
RewriteMap group-to-host txt:/path/to/map.group-to-host
RewriteMap entity-to-host txt:/path/to/map.entity-to-host
RewriteRule ^/u/([^/]+)/?(.*) http://${user-to-host:$1|server0}/u/$1/$2
RewriteRule ^/g/([^/]+)/?(.*) http://${group-to-host:$1|server0}/g/$1/$2
RewriteRule ^/e/([^/]+)/?(.*) http://${entity-to-host:$1|server0}/e/$1/$2
RewriteRule ^/([uge])/([^/]+)/?$ /$1/$2/.www/
RewriteRule ^/([uge])/([^/]+)/([^.]+.+) /$1/$2/.www/$3\
홈디렉토리를 다른 웹서버로 이전
mod_rewrite를 사용하면 간단하다.
이전 웹서버는 모든 /~user/anypath URL을
http://newserver/~user/anypath로
리다이렉션하면 된다.
RewriteEngine on
RewriteRule ^/~(.+) http://newserver/~$1 [R,L]
홈디렉토리 구조 만들기
/~foo/anypath는
/home/f/foo/.www/anypath이고,
/~bar/anypath는
/home/b/bar/.www/anypath이다.
RewriteEngine on
RewriteRule ^/~(([a-z])[a-z0-9]+)(.*) /home/$2/$1/.www$3
파일시스템 재구성
RewriteRules를 매우 많이 사용하여 자료
자체는 그대로 둔체로 웹에 자료를 자연스럽게 브라우징하도록
한다. 배경: 나는 1992년 부터 자유롭게 사용할 수 있는
유닉스 소프트웨어들을 net.sw에
모아두고 있었다. 이는 내가 컴퓨터과학을 공부하면서
여러해동안 여가시간에 시스템 관리자와 네트웍 관리자를
해왔기때문에 내 취미이자 일이다. 매주마다 새로 소프트웨어가
추가될 때마다 디렉토리를 깊게 만들어왔다:
drwxrwxr-x 2 netsw users 512 Aug 3 18:39 Audio/
drwxrwxr-x 2 netsw users 512 Jul 9 14:37 Benchmark/
drwxrwxr-x 12 netsw users 512 Jul 9 00:34 Crypto/
drwxrwxr-x 5 netsw users 512 Jul 9 00:41 Database/
drwxrwxr-x 4 netsw users 512 Jul 30 19:25 Dicts/
drwxrwxr-x 10 netsw users 512 Jul 9 01:54 Graphic/
drwxrwxr-x 5 netsw users 512 Jul 9 01:58 Hackers/
drwxrwxr-x 8 netsw users 512 Jul 9 03:19 InfoSys/
drwxrwxr-x 3 netsw users 512 Jul 9 03:21 Math/
drwxrwxr-x 3 netsw users 512 Jul 9 03:24 Misc/
drwxrwxr-x 9 netsw users 512 Aug 1 16:33 Network/
drwxrwxr-x 2 netsw users 512 Jul 9 05:53 Office/
drwxrwxr-x 7 netsw users 512 Jul 9 09:24 SoftEng/
drwxrwxr-x 7 netsw users 512 Jul 9 12:17 System/
drwxrwxr-x 12 netsw users 512 Aug 3 20:15 Typesetting/
drwxrwxr-x 10 netsw users 512 Jul 9 14:08 X11/
/e/netsw/.www/에 두었다:
-rw-r--r-- 1 netsw users 1318 Aug 1 18:10 .wwwacl
drwxr-xr-x 18 netsw users 512 Aug 5 15:51 DATA/
-rw-rw-rw- 1 netsw users 372982 Aug 5 16:35 LOGFILE
-rw-r--r-- 1 netsw users 659 Aug 4 09:27 TODO
-rw-r--r-- 1 netsw users 5697 Aug 1 18:01 netsw-about.html
-rwxr-xr-x 1 netsw users 579 Aug 2 10:33 netsw-access.pl
-rwxr-xr-x 1 netsw users 1532 Aug 1 17:35 netsw-changes.cgi
-rwxr-xr-x 1 netsw users 2866 Aug 5 14:49 netsw-home.cgi
drwxr-xr-x 2 netsw users 512 Jul 8 23:47 netsw-img/
-rwxr-xr-x 1 netsw users 24050 Aug 5 15:49 netsw-lsdir.cgi
-rwxr-xr-x 1 netsw users 1589 Aug 3 18:43 netsw-search.cgi
-rwxr-xr-x 1 netsw users 1885 Aug 1 17:41 netsw-tree.cgi
-rw-r--r-- 1 netsw users 234 Jul 30 16:35 netsw-unlimit.lst
DATA/ 하위디렉토리에 위에서 말한 저장소가
있다. 실제 net.sw의 내용은 보통
rdist를 사용하여 자동으로 가져온다. 두번째
부분이 남았다: 어떻게 이 두 구조를 하나의 자연스러운
URL 구조로 연결하는가? 사용자에게 DATA/
디렉토리를 감추고, URL마다 적절한 CGI 스크립트를 실행하고
싶다. 해결책은 다음과 같다: 먼저 서버의 DocumentRoot에서 공개된
URL /net.sw/를 내부 경로 /e/netsw로
재작성하기위해 디렉토리별 설정파일에 다음과 같이 설정한다:
RewriteRule ^net.sw$ net.sw/ [R]
RewriteRule ^net.sw/(.*)$ e/netsw/$1
/e/netsw/.www/.wwwacl에 결정적인
설정이 나온다:
Options ExecCGI FollowSymLinks Includes MultiViews
RewriteEngine on
# 앞 부분이 /net.sw/ 로 접근한다
RewriteBase /net.sw/
# 먼저 최상위 디렉토리를
# cgi 스크립트로 재작성한다
RewriteRule ^$ netsw-home.cgi [L]
RewriteRule ^index\.html$ netsw-home.cgi [L]
# 브라우저가 디렉토리별 페이지를 요청한 경우
# 하위디렉토리를 추출한다
RewriteRule ^.+/(netsw-[^/]+/.+)$ $1 [L]
# 이제 재작성을 마친다
RewriteRule ^netsw-home\.cgi.* - [L]
RewriteRule ^netsw-changes\.cgi.* - [L]
RewriteRule ^netsw-search\.cgi.* - [L]
RewriteRule ^netsw-tree\.cgi$ - [L]
RewriteRule ^netsw-about\.html$ - [L]
RewriteRule ^netsw-img/.*$ - [L]
# 다른 cgi 스크립트가 처리할
# 하위디렉토리가 남았다
RewriteRule !^netsw-lsdir\.cgi.* - [C]
RewriteRule (.*) netsw-lsdir.cgi/$1
-')가
없고 L (last) 플래그가 있음을 주목하라!
(not) 문자와 C (chain) 플래그를 주목하라NCSA imagemap을 아파치
mod_imap으로
imagemap 프로그램을 사용한 페이지를 현대적인
아파치 mod_imap로 처리하길 바란다.
문제는 imagemap 프로그램을
/cgi-bin/imagemap/path/to/page.map과
같이 참조하는 하이퍼링크가 많다는 것이다. 아파치는
/path/to/page.map과 같은 요청을 받아야
한다.
RewriteEngine on
RewriteRule ^/cgi-bin/imagemap(.*) $1 [PT]
여러 디렉토리에서 페이지 검색
RewriteEngine on
# 먼저 custom/에서 찾길 시도하고...
# ...찾으면 끝!
RewriteCond /your/docroot/dir1/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir1/$1 [L]
# 두번째로 pub/에서 찾길 시도한다...
# ...찾으면 끝!
RewriteCond /your/docroot/dir2/%{REQUEST_FILENAME} -f
RewriteRule ^(.+) /your/docroot/dir2/$1 [L]
# 못찾으면 다른 Alias나 ScriptAlias 지시어 등으로 진행한다.
RewriteRule ^(.+) - [PT]
URL에 따라 환경변수를 설정한다
/foo/S=java/bar/는
/foo/bar/로 변환되고 STATUS라는
환경변수 값을 "java"로 설정한다.
RewriteEngine on
RewriteRule ^(.*)/S=([^/]+)/(.*) $1/$3 [E=STATUS:$2]
가상 사용자 호스트
www.username.host.domain.com을
사용자의 홈페이지로 제공하고 싶다.http://www.username.host.com/anypath를
/home/username/anypath로 재작성할 수
있다:
RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.[^.]+\.host\.com$
RewriteRule ^(.+) %{HTTP_HOST}$1 [C]
RewriteRule ^www\.([^.]+)\.host\.com(.*) /home/$1$2
홈디렉토리를 외부 서버로 리다이렉션
ourdomain.com 밖에서 요청이
들어오면 홈디렉토리 URL을 다른 웹서버
www.somewhere.com으로 리다리렉션하길
바란다. 종종 가상호스트 사용장소에서 사용한다.
RewriteEngine on
RewriteCond %{REMOTE_HOST} !^.+\.ourdomain\.com$
RewriteRule ^(/~.+) http://www.somewhere.com/$1 [R,L]
실패한 URL을 다른 웹서버로 리다이렉션
ErrorDocument CGI 스크립트를
사용하지만, mod_rewrite를 사용하는
방법도 있다. 그러나 성능은 ErrorDocument CGI 스크립트보다
떨어짐을 명심하라!
RewriteEngine on
RewriteCond /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule ^(.+) http://webserverB.dom/$1
DocumentRoot 안에 있는 페이지만
가능하다는 점이다. (예를 들어 홈디렉토리 등을 위해)
조건을 추가할 수 있지만, 더 좋은 방법이 있다:
RewriteEngine on
RewriteCond %{REQUEST_URI} !-U
RewriteRule ^(.+) http://webserverB.dom/$1
mod_rewrite의 URL 전방참조(look-ahead)를
사용한다. 그래서 모든 URL에 동작하고 안전하다. 그러나
모든 요청마다 내부 하위요청을 한번 더 하기때문에 웹서버
성능에 악영향을 준다. 그래서 강력한 CPU에서 웹서버를
실행한다면 사용하라. 컴퓨터가 느리다면 첫번째 방법이나
더 나은 ErrorDocument
CGI 스크립트를 사용하라.확장 리다이렉션
url#anchor"
같은 URL의 anchor도 escape한다. 아파치의
uri_escape() 함수는 우물정자(#)도 같이
escape하므로 사용할 수 없다. 그러면 어떻게 이런 URL로
리다이렉션할 수 있나?xredirect:를 도입한다:
RewriteRule ^xredirect:(.+) /path/to/nph-xredirect.cgi/$1 \
[T=application/x-httpd-cgi,L]
xredirect:로 시작하는 모든 URL은
nph-xredirect.cgi 프로그램을 통하게 된다.
프로그램은 다음과 같다:
#!/path/to/perl
##
## nph-xredirect.cgi -- NPH/CGI script for extended redirects
## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##
$| = 1;
$url = $ENV{'PATH_INFO'};
print "HTTP/1.0 302 Moved Temporarily\n";
print "Server: $ENV{'SERVER_SOFTWARE'}\n";
print "Location: $url\n";
print "Content-type: text/html\n";
print "\n";
print "<html>\n";
print "<head>\n";
print "<title>302 Moved Temporarily (EXTENDED)</title>\n";
print "</head>\n";
print "<body>\n";
print "<h1>Moved Temporarily (EXTENDED)</h1>\n";
print "The document has moved <a HREF=\"$url\">here</a>.<p>\n";
print "</body>\n";
print "</html>\n";
##EOF##
mod_rewrite가 직접 받지못하는
모든 URL scheme으로 리다이렉션할 수 있다. 예를 들어,
다음과 같이 news:newsgroup으로 리다이렉션할
수 있다
RewriteRule ^anyurl xredirect:news:newsgroup
주의: 위의 특별한 "통과" 규칙을 사용하여
xredirect:를 마지막에 확장해야 하기때문에
규칙에 [R]이나 [R,L]을 사용하면
안된다.저장소 접근 중계(multiplexer)
mod_rewrite를 사용하여
비슷하게 만들 수 있을까?mod_rewrite 3.0.0 버전부터
리다이렉션에 "ftp:" scheme을 사용할 수
있다. 다음으로 클라이언트의 최상위 도메인을 RewriteMap과 같이
사용하여 위치를 추정할 수 있다. 복잡히 엮인 규칙에서
최상위 도메인을 중계맵의 키로 사용한다.
RewriteEngine on
RewriteMap multiplex txt:/path/to/map.cxan
RewriteRule ^/CxAN/(.*) %{REMOTE_HOST}::$1 [C]
RewriteRule ^.+\.([a-zA-Z]+)::(.*)$ ${multiplex:$1|ftp.default.dom}$2 [R,L]
##
## map.cxan -- Multiplexing Map for CxAN
##
de ftp://ftp.cxan.de/CxAN/
uk ftp://ftp.cxan.uk/CxAN/
com ftp://ftp.cxan.com/CxAN/
:
##EOF##
시간에 따른 재작성
mod_rewrite로는 어떻게
할 수 있는가?TIME_xxx
변수가 있다. 변수와 특별한 사전순서 비교
<STRING, >STRING,
=STRING을 사용하여 시간에 따라 리다이렉션할
수 있다:
RewriteEngine on
RewriteCond %{TIME_HOUR}%{TIME_MIN} >0700
RewriteCond %{TIME_HOUR}%{TIME_MIN} <1900
RewriteRule ^foo\.html$ foo.day.html
RewriteRule ^foo\.html$ foo.night.html
foo.html을 요청하면
07:00-19:00 동안 foo.day.html
내용을 서비스하고, 나머지 시간 동안
foo.night.html 내용을 서비스한다. 홈페이지에서
사용하기 좋은 기능이다...YYYY를 XXXX로 이전한 경우 역호환
.html 파일을 .phtml로
변환하는 등 document.YYYY를
document.XXXX로 이전한후 역호환(backward
compatibility) URL을 (가상적으로 존재하게) 만들 수
있나?
# 문서.html 이 없고
# 문서.phtml 만 있는 경우
# 문서.html 을 문서.phtml 로
# 재작성하는 역호환 규칙
RewriteEngine on
RewriteBase /~quux/
# 기본이름을 찾고, 찾았다는 사실을 기억한다
RewriteRule ^(.*)\.html$ $1 [C,E=WasHTML:yes]
# 파일이 있다면 문서.phtml 로 재작성한다
RewriteCond %{REQUEST_FILENAME}.phtml -f
RewriteRule ^(.*)$ $1.phtml [S=1]
# 아니면 앞에서 찾은 기본이름을 되돌린다
RewriteCond %{ENV:WasHTML} ^yes$
RewriteRule ^(.*)$ $1.html
컨텐츠 다루기
새로 이전 (감추기)
foo.html을 bar.html로
변경하고 역호환성을 위해 이전 URL을 계속 제공하고
싶다고 가정하자. 사용자는 이전 URL이 변경되었다는
사실을 눈치채지 못한다.
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.html$ bar.html
새로 이전 (알리기)
foo.html을 bar.html로
변경하고 역호환성을 위해 이전 URL을 계속 제공하고
싶다고 가정하자. 그러나 이제는 이전 URL을 사용하면
사용자에게 새로운 URL을 힌트로 알려준다. 즉, 브라우저
주소창이 변한다.
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.html$ bar.html [R]
브라우저에 따른 내용
foo.html 페이지를 foo.NS.html로
재작성하고 재작성을 중단한다. 브라우저가 "Lynx"나
"Mozilla" 버전 1 혹은 2라면 URL은
foo.20.html이 된다. 나머지 브라우저는
foo.32.html 페이지를 받는다. 아래 규칙이
이 작업을 한다:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/3.*
RewriteRule ^foo\.html$ foo.NS.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx/.* [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/[12].*
RewriteRule ^foo\.html$ foo.20.html [L]
RewriteRule ^foo\.html$ foo.32.html [L]
동적 미러
mirror 프로그램을
사용할 수 있고, 웹서버라면 HTTP로 비슷한 작업을 하는
webcopy 프로그램을 사용할 수 있다. 그러나
두 방법 모두 단점이 있다: 복사본은 가끔씩 프로그램을
실행해줄 때만 최신판으로 유지된다. 직접 구성해야하는
정적인 미러가 아니라면 좋겠다. 대신 (외부 호스트에서
자료가 갱신되면) 필요할때 자동으로 자료를 갱신하는
동적 미러가 필요하다.[P]) 사용하여 외부 웹페이지 혹은 외부
웹공간 전체를 우리 이름공간으로 대응한다:
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^hotsheet/(.*)$ http://www.tstimpreso.com/hotsheet/$1 [P]
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^usa-news\.html$ http://www.quux-corp.com/news/index.html [P]
동적 역미러
RewriteEngine on
RewriteCond /mirror/of/remotesite/$1 -U
RewriteRule ^http://www\.remotesite\.com/(.*)$ /mirror/of/remotesite/$1
없는 자료를 인트라넷에서 가져오기
www2.quux-corp.dom) 저장하면서, 기업의
(외부) 인터넷 웹서버를 (www.quux-corp.dom)
실행하는 것처럼 보이게 한다. 외부 웹서버는 요청한
자료를 내부 웹서버에서 가져온다.
ALLOW Host www.quux-corp.dom Port >1024 --> Host www2.quux-corp.dom Port 80
DENY Host * Port * --> Host www2.quux-corp.dom Port 80
mod_rewrite 규칙을 작성한다:
RewriteRule ^/~([^/]+)/?(.*) /home/$1/.www/$2
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^/home/([^/]+)/.www/?(.*) http://www2.quux-corp.dom/~$1/pub/$2 [P]
로드밸런싱 (부하 분산하기)
www.foo.com의 통신량을
www[0-5].foo.com (총 서버 6대)으로 분산하고
싶다. 어떻게 하는가?mod_rewrite를 사용하는 경우를 살펴보자:
BIND의
DNS round-robin 방식을 사용하는 것이다. 다음과
같이 DNS A(address) 레코드에
www[0-9].foo.com을 설정한다.
www0 IN A 1.2.3.1
www1 IN A 1.2.3.2
www2 IN A 1.2.3.3
www3 IN A 1.2.3.4
www4 IN A 1.2.3.5
www5 IN A 1.2.3.6
www IN CNAME www0.foo.com.
IN CNAME www1.foo.com.
IN CNAME www2.foo.com.
IN CNAME www3.foo.com.
IN CNAME www4.foo.com.
IN CNAME www5.foo.com.
IN CNAME www6.foo.com.
BIND의
의도된 기능이다. 이제 www.foo.com을
찾으면, BIND는 매번 순서를 조금씩
바꿔가며 www0-www6을 반환한다. 그래서
클라이언트들을 여러 서버로 분산한다. 그러나 DNS
검색 결과가 네트웍의 다른 네임서버에 캐쉬되여
www.foo.com을 찾은 결과가 특정
wwwN.foo.com이면 클라이언트의 다음
요청들도 같은 wwwN.foo.com으로
보내지기때문에 완벽한 로드밸런싱 기법이 아님을
주의하라. 그러나 크게 보면 요청이 여러 웹서버에
분산되므로 효과가 좋다.lbnamed 프로그램을 사용하여
정교한 DNS기반 로드밸런싱을 할 수 있다. DNS가
실제 로드밸런싱을 하도록 만드는 여러 도구와 Perl
5 프로그램이다.mod_rewrite와 proxy
throughput 기능을 사용한다. 먼저 DNS에 다음 항목을
사용하여 www0.foo.com이 실제
www.foo.com을 전담하게 한다
www IN CNAME www0.foo.com.
www0.foo.com을 프록시전용
서버로 변경한다. 즉, URL을 받으면 서버는 내부
프록시를 통해 다른 5대 서버중 (www1-www5)
한대로 보내기만 한다. 이를 위해 먼저 모든 URL을
로드밸런싱 스크립트 lb.pl로 보내는
규칙을 만든다.
RewriteEngine on
RewriteMap lb prg:/path/to/lb.pl
RewriteRule ^/(.+)$ ${lb:$1} [P,L]
lb.pl을 작성한다:
#!/path/to/perl
##
## lb.pl -- 로드밸런싱 스크립트
##
$| = 1;
$name = "www"; # 기본 호스트명
$first = 1; # 첫번째 서버 (자신이 0이기 때문에, 0을 사용하지 않는다)
$last = 5; # round-robin에서 마지막 서버
$domain = "foo.dom"; # 도메인명
$cnt = 0;
while (<STDIN>) {
$cnt = (($cnt+1) % ($last+1-$first));
$server = sprintf("%s%d.%s", $name, $cnt+$first, $domain);
print "http://$server/$_";
}
##EOF##
마지막 주의: 왜 이 방법이 유용한가?
www0.foo.com에 부담이 가지않는가?
물론, 부담이 된다. 그러나 단순한 proxy throughput
요청만 하기때문에 괜찮다! 모든 SSI, CGI, ePerl
등은 전적으로 다른 서버가 처리한다. 이것이 핵심이다.새로운 MIME-type, 새로운 서비스
PATH_INFO와
QUERY_STRINGS) 프로그램의 입력으로 사용하지
않을 때만 적절하다. 먼저, 확장자가 (secure CGI를 줄여)
.scgi인 파일을 유명한 cgiwrap
프로그램으로 처리하기위해 새로운 type을 설정한다.
문제는 (위에서 본) 일관된 URL 구조를 사용하는 경우
사용자 홈디렉토리가 /u/user/foo/bar.scgi같은
URL인 점이다. cgiwrap는
/~user/foo/bar.scgi/ 형식의 URL을
원하기때문이다. 다음 규칙이 문제를 해결한다:
RewriteRule ^/[uge]/([^/]+)/\.www/(.+)\.scgi(.*) ...
... /internal/cgi/user/cgiwrap/~$1/$2.scgi$3 [NS,T=application/x-http-cgi]
access.log를 출력하는) wwwlog와
(URL 하위트리에 Glimpse를 실행하는) wwwidx가
있다고 가정하자. 우리는 프로그램에게 작업할 대상인
URL 영역을 알려줘야 한다. 그러나 요청할때마다 항상
적어줘야 하기때문에 깔끔하지 않다. 즉, 보통
/u/user/foo/에 대해 swwidx
프로그램을 실행한다면 다음과 같은 링크를 사용한다
/internal/cgi/user/swwidx?i=/u/user/foo/
RewriteRule ^/([uge])/([^/]+)(/?.*)/\* /internal/cgi/user/wwwidx?i=/$1/$2$3/
RewriteRule ^/([uge])/([^/]+)(/?.*):log /internal/cgi/user/wwwlog?f=/$1/$2$3
/u/user/foo/을 검색하는 링크는
다음과 같다
HREF="*"
/u/user/foo/* (???)
/internal/cgi/user/wwwidx?i=/u/user/foo/
:log를 사용하여
접근 로그 CGI 프로그램을 실행할 수 있다.정적에서 동적으로
foo.html을 동적인 foo.cgi로
변경할 수 있나./~quux/foo.html를 요청하면 내부적으로
/~quux/foo.cgi를 실행하게 된다.
RewriteEngine on
RewriteBase /~quux/
RewriteRule ^foo\.html$ foo.cgi [T=application/x-httpd-cgi]
즉석 컨텐츠 재생성
RewriteCond %{REQUEST_FILENAME} !-s
RewriteRule ^page\.html$ page.cgi [T=application/x-httpd-cgi,L]
page.html를 요청할때
page.html이 없거나 파일크기가 0인 경우
내부적으로 page.cgi를 실행한다. 여기서
비결은 page.cgi가 일반적인 CGI 스크립트와
같이 STDOUT에 출력하고, 추가로 출력을
page.html 파일에 적는다. 한번 실행한후
서버는 page.html의 정보를 보낸다. 웹관리자가
강재로 내용을 갱신하고 싶다면, (보통 cron 작업이)
page.html을 지우기만 하면 된다.자동으로 새로 고침하는 문서
mod_rewrite의 URL 조작 능력을 결합하면
된다. 먼저, 새로운 URL 기능을 만든다: URL에
:refresh를 추가하기만 하면 파일시스템에서
수정될 때마다 새로 고침한다.
RewriteRule ^(/[uge]/[^/]+/?.*):refresh /internal/cgi/apache/nph-refresh?f=$1
/u/foo/bar/page.html:refresh
/internal/cgi/apache/nph-refresh?f=/u/foo/bar/page.html
#!/sw/bin/perl
##
## nph-refresh -- NPH/CGI script for auto refreshing pages
## Copyright (c) 1997 Ralf S. Engelschall, All Rights Reserved.
##
$| = 1;
# split the QUERY_STRING variable
@pairs = split(/&/, $ENV{'QUERY_STRING'});
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair);
$name =~ tr/A-Z/a-z/;
$name = 'QS_' . $name;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
eval "\$$name = \"$value\"";
}
$QS_s = 1 if ($QS_s eq '');
$QS_n = 3600 if ($QS_n eq '');
if ($QS_f eq '') {
print "HTTP/1.0 200 OK\n";
print "Content-type: text/html\n\n";
print "<b>ERROR</b>: No file given\n";
exit(0);
}
if (! -f $QS_f) {
print "HTTP/1.0 200 OK\n";
print "Content-type: text/html\n\n";
print "<b>ERROR</b>: File $QS_f not found\n";
exit(0);
}
sub print_http_headers_multipart_begin {
print "HTTP/1.0 200 OK\n";
$bound = "ThisRandomString12345";
print "Content-type: multipart/x-mixed-replace;boundary=$bound\n";
&print_http_headers_multipart_next;
}
sub print_http_headers_multipart_next {
print "\n--$bound\n";
}
sub print_http_headers_multipart_end {
print "\n--$bound--\n";
}
sub displayhtml {
local($buffer) = @_;
$len = length($buffer);
print "Content-type: text/html\n";
print "Content-length: $len\n\n";
print $buffer;
}
sub readfile {
local($file) = @_;
local(*FP, $size, $buffer, $bytes);
($x, $x, $x, $x, $x, $x, $x, $size) = stat($file);
$size = sprintf("%d", $size);
open(FP, "<$file");
$bytes = sysread(FP, $buffer, $size);
close(FP);
return $buffer;
}
$buffer = &readfile($QS_f);
&print_http_headers_multipart_begin;
&displayhtml($buffer);
sub mystat {
local($file) = $_[0];
local($time);
($x, $x, $x, $x, $x, $x, $x, $x, $x, $mtime) = stat($file);
return $mtime;
}
$mtimeL = &mystat($QS_f);
$mtime = $mtime;
for ($n = 0; $n < $QS_n; $n++) {
while (1) {
$mtime = &mystat($QS_f);
if ($mtime ne $mtimeL) {
$mtimeL = $mtime;
sleep(2);
$buffer = &readfile($QS_f);
&print_http_headers_multipart_next;
&displayhtml($buffer);
sleep(5);
$mtimeL = &mystat($QS_f);
last;
}
sleep($QS_s);
}
}
&print_http_headers_multipart_end;
exit(0);
##EOF##
대량의 가상호스트
<VirtualHost>
기능이 잘 동작한다. 그러나 가상호스트가 수백개 있는
ISP라면 이 기능이 최선은 아니다.[P]) 사용하여 외부 웹페이지
혹은 전체 외부 웹영역을 우리의 이름공간에 대응한다:
##
## vhost.map
##
www.vhost1.dom:80 /path/to/docroot/vhost1
www.vhost2.dom:80 /path/to/docroot/vhost2
:
www.vhostN.dom:80 /path/to/docroot/vhostN
##
## httpd.conf
##
:
# 리다이렉트할때 정규 호스트명을 사용한다.
UseCanonicalName on
:
# 가상호스트를 CLF 형식 앞에 추가한다
CustomLog /path/to/access_log "%{VHOST}e %h %l %u %t \"%r\" %>s %b"
:
# 주서버에서 재작성 엔진을 사용한다
RewriteEngine on
# 두 맵을 정의한다: 하나는 URL을 고치고,
# 다른 하나는 가상호스트별 DocumentRoot를
# 정의한다.
RewriteMap lowercase int:tolower
RewriteMap vhost txt:/path/to/vhost.map
# 이제 크고 복잡한 규칙 한개를 사용하여
# 가상호스트로 대응한다.
#
# 1. 가상호스트들이 같이 사용하는 위치는 대응하지 않는다
RewriteCond %{REQUEST_URI} !^/commonurl1/.*
RewriteCond %{REQUEST_URI} !^/commonurl2/.*
:
RewriteCond %{REQUEST_URI} !^/commonurlN/.*
#
# 2. 우리가 현재 사용하는 방법이 Host 헤더를
# 가상호스트를 지원하므로
# Host 헤더가 있는지 확인한다
RewriteCond %{HTTP_HOST} !^$
#
# 3. 호스트명을 소문자로 만든다
RewriteCond ${lowercase:%{HTTP_HOST}|NONE} ^(.+)$
#
# 4. vhost.map에서 호스트명을 찾고
# 경로일때만 기억한다
# (위에서 "NONE"은 아니다)
RewriteCond ${vhost:%1} ^(/.*)$
#
# 5. 마지막으로 URL을 문서 위치로 대응하고
# 로그에 남기기위해 가상호스트를 기억해 둔다
RewriteRule ^/(.*)$ %1/$1 [E=VHOST:${lowercase:%{HTTP_HOST}}]
:
접근 제한
로봇 막기
/robots.txt 파일은 보통 이런 로봇을
막는데 충분하지 않다./~quux/foo/arc/에
있는 URL들을 거부하는 규칙을 사용한다. 우리는 특정
로봇의 접근을 막아야 한다. 즉, 로봇을 실행하는 호스트를
막는 것으로는 불충분하며, 그 호스트의 사용자도 막아버리게
된다. User-Agent HTTP 헤더 정보도 비교한다.
RewriteCond %{HTTP_USER_AGENT} ^NameOfBadRobot.*
RewriteCond %{REMOTE_ADDR} ^123\.45\.67\.[8-9]$
RewriteRule ^/~quux/foo/arc/.+ - [F]
그림 퍼가기 방지
http://www.quux-corp.de/~quux/에 있는
페이지들이 GIF 그림을 포함한다고 가정하자. 이 그림이
멋있어서, 다른 사람들이 자신의 페이지에 직접 링크를
건다. 서버에 불필요한 부담이 되므로 막고 싶다.
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://www.quux-corp.de/~quux/.*$ [NC]
RewriteRule .*\.gif$ - [F]
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !.*/foo-with-gif\.html$
RewriteRule ^inlined-in-foo\.gif$ - [F]
호스트 거부
RewriteEngine on
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteCond ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND} !=NOT-FOUND [OR]
RewriteCond ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^/.* - [F]
RewriteEngine on
RewriteMap hosts-deny txt:/path/to/hosts.deny
RewriteRule ^/(.*)$ ${hosts-deny:%{REMOTE_HOST}|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ ${hosts-deny:%{REMOTE_ADDR}|NOT-FOUND}/$1
RewriteRule !^NOT-FOUND/.* - [F]
RewriteRule ^NOT-FOUND/(.*)$ /$1
##
## hosts.deny
##
## 주의! 이것은 목록처럼 보이지만 목록이 아니라 맵이다.
## mod_rewrite는 이 정보를 키/값 쌍으로 해석하기때문에,
## 각 항목의 값 자리에 최소한 "-"가 필요하다.
##
193.102.180.41 -
bsdti1.sdm.de -
192.76.162.40 -
프록시 거부
mod_rewrite가 mod_proxy
아래에(!) 있어야 한다. 그러면 mod_rewrite는
mod_proxy 이전에 불린다.
이제 다음과 같이 특정 호스트를 거부하도록 설정한다...
RewriteCond %{REMOTE_HOST} ^badhost\.mydomain\.com$
RewriteRule !^http://[^/.]\.mydomain.com.* - [F]
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} ^badguy@badhost\.mydomain\.com$
RewriteRule !^http://[^/.]\.mydomain.com.* - [F]
특별한 인증 방식
mod_auth의 Basic Auth를 사용한
경우와 달리) 별다른 물음없이 접근을 허용한다.
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend1@client1.quux-corp\.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend2@client2.quux-corp\.com$
RewriteCond %{REMOTE_IDENT}@%{REMOTE_HOST} !^friend3@client3.quux-corp\.com$
RewriteRule ^/~quux/only-for-friends/ - [F]
Referer기반 변환기(deflector)
RewriteMap deflector txt:/path/to/deflector.map
RewriteCond %{HTTP_REFERER} !=""
RewriteCond ${deflector:%{HTTP_REFERER}} ^-$
RewriteRule ^.* %{HTTP_REFERER} [R,L]
RewriteCond %{HTTP_REFERER} !=""
RewriteCond ${deflector:%{HTTP_REFERER}|NOT-FOUND} !=NOT-FOUND
RewriteRule ^.* ${deflector:%{HTTP_REFERER}} [R,L]
##
## deflector.map
##
http://www.badguys.com/bad/index.html -
http://www.badguys.com/bad/index2.html -
http://www.badguys.com/bad/index3.html http://somewhere.com/
-"를
사용한 경우) 참조페이지나 (URL이 맵에 있는 경우 두번째
아규먼트로) 특정 URL로 리다이렉션한다.
기타
외부 재작성 엔진
mod_rewrite로는 해결책이 안보인다...RewriteMap을 사용하라.
즉, 프로그램이 RewriteMap 역할을
한다. 프로그램은 아파치가 시작할때 시작하여
STDIN에서 요청한 URL을 받고, (같은 순서로!)
결과 (보통 재작성된) URL을 STDOUT에 출력한다.
RewriteEngine on
RewriteMap quux-map prg:/path/to/map.quux.pl
RewriteRule ^/~quux/(.*)$ /~quux/${quux-map:$1}
#!/path/to/perl
# 아파치 서버가 멈추지 않도록
# 입출력 버퍼를 사용하지 않는다
$| = 1;
# stdin에서 한줄씩 URL을 읽고
# stdout에 변환한 URL을 출력한다
while (<>) {
s|^foo/|bar/|;
print $_;
}
/~quux/foo/... URL을
/~quux/bar/...로 재작성하는 스크립트를
예로 들었다. 실제로 마음대로 프로그래밍할 수 있다.
그러나 일반 사용자가 이런 맵을 사용할
수 있다고 하더라고, 오직 시스템 관리자만이 맵을
정의해야 함을 주의하라.
misc/tutorials.html 100644 0 0 23462 11074463123 12104 0 ustar 0 0
보안 팁
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
최신판으로 유지하기
ServerRoot 디렉토리 권한
User 지시어로
지정한 사용자로 변환한다. root가 실행하는 명령어가 있다면,
root 이외의 사용자가 수정하지 못하도록 주의해야 한다. 이
파일들을 root만 쓸 수 있어야 하고, 디렉토리와 모든 상위디렉토리도
마찬가지다. 예를 들어, ServerRoot로 /usr/local/apache를
사용한다면 root 사용자가 다음과 같이 디렉토리를 만들길
제안한다:
mkdir /usr/local/apache
cd /usr/local/apache
mkdir bin conf logs
chown 0 . bin conf logs
chgrp 0 . bin conf logs
chmod 755 . bin conf logs
cp httpd /usr/local/apache/bin
chown 0 /usr/local/apache/bin/httpd
chgrp 0 /usr/local/apache/bin/httpd
chmod 511 /usr/local/apache/bin/httpd
Server Side Includes
Options 지시어에서 Includes
대신 IncludesNOEXEC를 사용한다. 그래도 스크립트가
ScriptAlias 지시어로
지정한 디렉토리에 있다면 <--#include virtual="..." -->를
사용하여 CGI 스크립트를 실행할 수 있음을 주의하라.
일반적인 CGI
ScriptAlias하지 않은 CGI
ScriptAlias한 CGI
동적 내용을 생성하는 다른 방법
User 지시어 참고) 실행되기때문에,
스크립트 엔진이 실행하는 스크립트는 잠재적으로 서버 사용자가
접근할 수 있는 모든 것에 접근할 수 있다. 어떤 스크립트 엔진은
어느정도 제한을 하지만, 안전하다고 가정하지 않는 것이 좋다.
시스템 설정 보호하기
.htaccess 파일을 사용하여 당신이 설정한 보안기능을
변경하길 바라지 않을 것이다. 그러기위해 다음과 같은 방법이
있다.
<Directory />
AllowOverride None
</Directory>
.htaccess 파일을 사용할 수 없다.
기본적으로 서버에 있는 파일 보호하기
# cd /; ln -s / public_html
http://localhost/~root/ 에 접근한다
<Directory />
Order Deny,Allow
Deny from all
</Directory>
Directory 블록을 추가한다.
<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>
Location과 Directory 지시어를 같이 사용하는
경우 특별히 주의를 기울여라. 예를 들어, <Directory
/>가 접근을 거부하더라도 <Location
/> 지시어가 이를 무시할 수 있다UserDir 지시어를
사용하는 경우에도 주의하라. 지시어를 "./" 같이 설정하면
root 사용자에 대해 바로 위의 경우와 같은 문제가 발생한다.
아파치 1.3 이상을 사용한다면 서버 설정파일에 아래 줄을 추가하길
강력히 권한다:
UserDir disabled root
로그 살펴보기
grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log
grep "client denied" error_log | tail -n 10
[Thu Jul 11 17:18:39 2002] [error] [client foo.bar.com] client denied
by server configuration: /usr/local/apache/htdocs/.htpasswd
.htpasswd 파일에 접근할
수 있었다면 접근 로그에
다음과 같은 기록이 남을 것이다:
foo.bar.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"
<Files ~ "^\.ht">
Order allow,deny
Deny from all
<Files>
mod/beos.html 100644 0 0 13461 11074463123 10630 0 ustar 0 0
Apache Tutorials
Warning:
Installation & Getting Started
Basic Configuration
Security
Logging
CGI and SSI
Other Features
mod/core.html 100644 0 0 532576 11074463123 10665 0 ustar 0 0
아파치 MPM beos
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: BeOS에 최적화된 다중처리 모듈. 상태: MPM 모듈명: mpm_beos_module 소스파일: beos.c 요약
지시어들
CoreDumpDirectory Group Listen ListenBacklog MaxClients MaxMemFree MaxRequestsPerThread MaxSpareThreads MinSpareThreads PidFile ScoreBoardFile SendBufferSize StartThreads User참고
MaxRequestsPerThread 지시어
설명: 한 쓰레드가 실행하는 동안 처리할 요청개수 한계 문법: MaxRequestsPerThread number기본값: MaxRequestsPerThread 0사용장소: 주서버설정 상태: MPM 모듈: beos MaxRequestsPerThread 지시어는
한 서버 쓰레드가 처리할 요청개수를 제한한다.
MaxRequestsPerThread개 요청을 처리한후
쓰레드는 죽는다. MaxRequestsPerThread가
0이면 절대로 쓰레드를 죽이지 않는다.MaxRequestsPerThread를 0이 아닌
값으로 설정하면 두가지 장점이 있다:
주의:
KeepAlive 요청의
경우 오직 첫번째 요청만을 센다. 그래서 이 지시어는 쓰레드당
연결 개수를 제한하게 된다.
mod/directive-dict.html 100644 0 0 27421 11074463123 12600 0 ustar 0 0
Apache Core Features
Description: Core Apache HTTP Server features that are always
available Status: Core Directives
AcceptPathInfo AccessFileName AddDefaultCharset AddOutputFilterByType AllowEncodedSlashes AllowOverride AuthName AuthType CGIMapExtension ContentDigest DefaultType <Directory> <DirectoryMatch> DocumentRoot EnableMMAP EnableSendfile ErrorDocument ErrorLog FileETag <Files> <FilesMatch> ForceType HostnameLookups IdentityCheck <IfDefine> <IfModule> Include KeepAlive KeepAliveTimeout <Limit> <LimitExcept> LimitInternalRecursion LimitRequestBody LimitRequestFields LimitRequestFieldSize LimitRequestLine LimitXMLRequestBody <Location> <LocationMatch> LogLevel MaxKeepAliveRequests NameVirtualHost Options Require RLimitCPU RLimitMEM RLimitNPROC Satisfy ScriptInterpreterSource ServerAdmin ServerAlias ServerName ServerPath ServerRoot ServerSignature ServerTokens SetHandler SetInputFilter SetOutputFilter TimeOut TraceEnable UseCanonicalName <VirtualHost>AcceptPathInfo Directive
Description: Resources accept trailing pathname information Syntax: AcceptPathInfo On|Off|DefaultDefault: AcceptPathInfo DefaultContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: Available in Apache 2.0.30 and later PATH_INFO environment
variable./test/ points to
a directory that contains only the single file
here.html. Then requests for
/test/here.html/more and
/test/nothere.html/more both collect
/more as PATH_INFO.AcceptPathInfo directive are:
Off/test/here.html/more in the above example will return
a 404 NOT FOUND error.On/test/here.html/more will be accepted if
/test/here.html maps to a valid file.DefaultPATH_INFO requests. Handlers that serve scripts, such as cgi-script and isapi-handler, generally accept
PATH_INFO by default.AcceptPathInfo
directive is to allow you to override the handler's choice of
accepting or rejecting PATH_INFO. This override is required,
for example, when you use a filter, such
as INCLUDES, to generate content
based on PATH_INFO. The core handler would usually reject
the request, so you can use the following configuration to enable
such a script:
<Files "mypaths.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo On
</Files>
AccessFileName Directive
Description: Name of the distributed configuration file Syntax: AccessFileName filename [filename] ...Default: AccessFileName .htaccessContext: server config, virtual host Status: Core Module: core
AccessFileName .acl
/usr/local/web/index.html, the server will read
/.acl, /usr/.acl,
/usr/local/.acl and /usr/local/web/.acl
for directives, unless they have been disabled with
<Directory />
AllowOverride None
</Directory>
See also
AddDefaultCharset Directive
Description: Default charset parameter to be added when a response
content-type is text/plain or text/htmlSyntax: AddDefaultCharset On|Off|charsetDefault: AddDefaultCharset OffContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core text/plain or text/html. This should override
any charset specified in the body of the response via a META
element, though the exact behavior is often dependent on the user's client
configuration. A setting of AddDefaultCharset Off
disables this functionality. AddDefaultCharset On enables
a default charset of iso-8859-1. Any other value is assumed
to be the charset to be used, which should be one of the
IANA registered
charset values for use in MIME media types.
For example:
AddDefaultCharset utf-8
AddDefaultCharset should only be used when all
of the text resources to which it applies are known to be in that
character encoding and it is too inconvenient to label their charset
individually. One such example is to add the charset parameter
to resources containing generated content, such as legacy CGI
scripts, that might be vulnerable to cross-site scripting attacks
due to user-provided data being included in the output. Note, however,
that a better solution is to just fix (or delete) those scripts, since
setting a default charset does not protect users that have enabled
the "auto-detect character encoding" feature on their browser.See also
AddOutputFilterByType Directive
Description: assigns an output filter to a particular MIME-type Syntax: AddOutputFilterByType filter[;filter...]
MIME-type [MIME-type] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: Available in Apache 2.0.33 and later DEFLATE filter, which
is provided by mod_deflate. It will compress all
output (either static or dynamic) which is labeled as
text/html or text/plain before it is sent
to the client.
AddOutputFilterByType DEFLATE text/html text/plain
AddOutputFilterByType directive for each of
these filters.text/html to be processed at first by the
INCLUDES filter and then by the DEFLATE
filter.
<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
</Location>
Note
AddOutputFilterByType
may fail partially or completely in some cases. For example, no
filters are applied if the MIME-type could not be determined and falls
back to the DefaultType setting,
even if the DefaultType is the
same.AddType or
ForceType. Setting the
content type within a (non-nph) CGI script is also safe.See also
AllowEncodedSlashes Directive
Description: Determines whether encoded path separators in URLs are allowed to
be passed through Syntax: AllowEncodedSlashes On|OffDefault: AllowEncodedSlashes OffContext: server config, virtual host Status: Core Module: core Compatibility: Available in Apache 2.0.46 and later AllowEncodedSlashes directive allows URLs
which contain encoded path separators (%2F for /
and additionally %5C for \ on according systems)
to be used. Normally such URLs are refused with a 404 (Not found) error.AllowEncodedSlashes On is
mostly useful when used in conjunction with PATH_INFO.Note
%2F or %5C (only on
according systems) will be left as such in the otherwise decoded URL
string.See also
AllowOverride Directive
Description: Types of directives that are allowed in
.htaccess filesSyntax: AllowOverride All|None|directive-type
[directive-type] ...Default: AllowOverride AllContext: directory Status: Core Module: core .htaccess file (as
specified by AccessFileName)
it needs to know which directives declared in that file can override
earlier configuration directives.Only available in <Directory> sections
AllowOverride is valid only in
<Directory>
sections specified without regular expressions, not in <Location>, <DirectoryMatch> or
<Files> sections.
None, then
.htaccess files are completely ignored.
In this case, the server will not even attempt to read
.htaccess files in the filesystem.All, then any
directive which has the .htaccess Context is allowed in
.htaccess files.
AuthDBMGroupFile,
AuthDBMUserFile,
AuthGroupFile,
AuthName,
AuthType, AuthUserFile, Require, etc.).DefaultType, ErrorDocument, ForceType, LanguagePriority,
SetHandler, SetInputFilter, SetOutputFilter, and
mod_mime Add* and Remove*
directives, etc.).AddDescription,
AddIcon, AddIconByEncoding,
AddIconByType,
DefaultIcon, DirectoryIndex, FancyIndexing, HeaderName, IndexIgnore, IndexOptions, ReadmeName,
etc.).Allow, Deny and Order).Options and
XBitHack).
AllowOverride AuthConfig Indexes
AuthConfig nor Indexes cause an internal
server error.See also
AuthName Directive
Description: Authorization realm for use in HTTP
authentication Syntax: AuthName auth-domainContext: directory, .htaccess Override: AuthConfig Status: Core Module: core AuthName takes a single argument; if the
realm name contains spaces, it must be enclosed in quotation
marks. It must be accompanied by AuthType and Require directives, and directives such
as AuthUserFile and
AuthGroupFile to
work.
AuthName "Top Secret"
AuthName is what will
appear in the password dialog provided by most browsers.See also
AuthType Directive
Description: Type of user authentication Syntax: AuthType Basic|DigestContext: directory, .htaccess Override: AuthConfig Status: Core Module: core Basic and Digest are
currently implemented.
It must be accompanied by AuthName and Require directives, and directives such
as AuthUserFile and
AuthGroupFile to
work.See also
CGIMapExtension Directive
Description: Technique for locating the interpreter for CGI
scripts Syntax: CGIMapExtension cgi-path .extensionContext: directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: NetWare only CGIMapExtension sys:\foo.nlm .foo will
cause all CGI script files with a .foo extension to
be passed to the FOO interpreter.ContentDigest Directive
Description: Enables the generation of Content-MD5 HTTP Response
headersSyntax: ContentDigest On|OffDefault: ContentDigest OffContext: server config, virtual host, directory, .htaccess Override: Options Status: Core Module: core Content-MD5 headers as defined in RFC1864
respectively RFC2068.Content-MD5 header provides an end-to-end
message integrity check (MIC) of the entity-body. A proxy or
client may check this header for detecting accidental
modification of the entity-body in transit. Example header:
Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
Content-MD5 is only sent for documents served
by the core, and not by any module. For example,
SSI documents, output from CGI scripts, and byte range responses
do not have this header.DefaultType Directive
Description: MIME content-type that will be sent if the
server cannot determine a type in any other way Syntax: DefaultType MIME-typeDefault: DefaultType text/plainContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core DefaultType. For example:
DefaultType image/gif
.gif extension.ForceType, this directive only
provides the default mime-type. All other mime-type definitions,
including filename extensions, that might identify the media type
will override this default.<Directory> Directive
Description: Enclose a group of directives that apply only to the
named file-system directory and sub-directories Syntax: <Directory directory-path>
... </Directory>Context: server config, virtual host Status: Core Module: core <Directory> and
</Directory> are used to enclose a group of
directives that will apply only to the named directory and
sub-directories of that directory. Any directive that is allowed
in a directory context may be used. Directory-path is
either the full path to a directory, or a wild-card string using
Unix shell-style matching. In a wild-card string, ? matches
any single character, and * matches any sequences of
characters. You may also use [] character ranges. None
of the wildcards match a `/' character, so <Directory
/*/public_html> will not match
/home/user/public_html, but <Directory
/home/*/public_html> will match. Example:
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
<Directory> will not apply to files accessed from
that same directory via a different path, such as via different symbolic
links.~ character. For example:
<Directory ~ "^/www/.*/[0-9]{3}">
/www/ that consisted of
three numbers.<Directory> sections
match the directory (or one of its parents) containing a document,
then the directives are applied in the order of shortest match
first, interspersed with the directives from the .htaccess files. For example,
with
<Directory />
AllowOverride None
</Directory>
<Directory /home/>
AllowOverride FileInfo
</Directory>
/home/web/dir/doc.html
the steps are:
AllowOverride None
(disabling .htaccess files).AllowOverride FileInfo (for
directory /home).FileInfo directives in
/home/.htaccess, /home/web/.htaccess and
/home/web/dir/.htaccess in that order.
<Directory ~ abc$>
# ... directives here ...
</Directory>
<Directory>s and
.htaccess files have been applied. Then the regular
expression will match on /home/abc/public_html/abc and
the corresponding <Directory> will
be applied.<Directory /> is Allow from All.
This means that Apache will serve any file mapped from an URL. It is
recommended that you change this with a block such
as
<Directory />
Order Deny,Allow
Deny from All
</Directory>
httpd.conf file.
<Directory> directives
cannot nest, and cannot appear in a <Limit> or <LimitExcept> section.See also
<DirectoryMatch> Directive
Description: Enclose directives that apply to
file-system directories matching a regular expression and their
subdirectories Syntax: <DirectoryMatch regex>
... </DirectoryMatch>Context: server config, virtual host Status: Core Module: core <DirectoryMatch> and
</DirectoryMatch> are used to enclose a group
of directives which will apply only to the named directory and
sub-directories of that directory, the same as <Directory>. However, it
takes as an argument a regular expression. For example:
<DirectoryMatch "^/www/(.+/)?[0-9]{3}">
/www/ that consisted of three
numbers.See also
<Directory> for
a description of how regular expressions are mixed in with normal
<Directory>sDocumentRoot Directive
Description: Directory that forms the main document tree visible
from the web Syntax: DocumentRoot directory-pathDefault: DocumentRoot /usr/local/apache/htdocsContext: server config, virtual host Status: Core Module: core httpd
will serve files. Unless matched by a directive like Alias, the server appends the
path from the requested URL to the document root to make the
path to the document. Example:
DocumentRoot /usr/web
http://www.my.host.com/index.html refers to
/usr/web/index.html.DocumentRoot should be specified without
a trailing slash.See also
EnableMMAP Directive
Description: Use memory-mapping to read files during delivery Syntax: EnableMMAP On|OffDefault: EnableMMAP OnContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core httpd may use
memory-mapping if it needs to read the contents of a file during
delivery. By default, when the handling of a request requires
access to the data within a file -- for example, when delivering a
server-parsed file using mod_include -- Apache
memory-maps the file if the OS supports it.
httpd.DocumentRoot,
the httpd may crash due to a segmentation fault if a file
is deleted or truncated while the httpd has it
memory-mapped.
EnableMMAP Off
<Directory "/path-to-nfs-files">
EnableMMAP Off
</Directory>
EnableSendfile Directive
Description: Use the kernel sendfile support to deliver files to the client Syntax: EnableSendfile On|OffDefault: EnableSendfile OnContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: Available in version 2.0.44 and later httpd may use the
sendfile support from the kernel to transmit file contents to the client.
By default, when the handling of a request requires no access
to the data within a file -- for example, when delivering a
static file -- Apache uses sendfile to deliver the file contents
without ever reading the file if the OS supports it.
DocumentRoot (e.g., NFS or SMB),
the kernel may be unable to serve the network file through
its own cache.
EnableSendfile Off
<Directory "/path-to-nfs-files">
EnableSendfile Off
</Directory>
ErrorDocument Directive
Description: What the server will return to the client
in case of an error Syntax: ErrorDocument error-code documentContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: Quoting syntax for text messages is different in Apache
2.0
ErrorDocument
directive, which is followed by the HTTP response code and a URL
or a message. Apache will sometimes offer additional information
regarding the problem/error.DocumentRoot), or be a
full URL which the client can resolve. Alternatively, a message
can be provided to be displayed by the browser. Examples:
ErrorDocument 500 http://foo.example.com/cgi-bin/tester
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Sorry can't allow you access today"
default can be used
to specify Apache's simple hardcoded message. While not required
under normal circumstances, default will restore
Apache's simple hardcoded message for configurations that would
otherwise inherit an existing ErrorDocument.
ErrorDocument 404 /cgi-bin/bad_urls.pl
<Directory /web/docs>
ErrorDocument 404 default
</Directory>
ErrorDocument
that points to a remote URL (ie. anything with a method such as
http in front of it), Apache will send a redirect to the
client to tell it where to find the document, even if the
document ends up being on the same server. This has several
implications, the most important being that the client will not
receive the original error status code, but instead will
receive a redirect status code. This in turn can confuse web
robots and other clients which try to determine if a URL is
valid using the status code. In addition, if you use a remote
URL in an ErrorDocument 401, the client will not
know to prompt the user for a password since it will not
receive the 401 status code. Therefore, if you use an
ErrorDocument 401 directive then it must refer to a local
document.ErrorDocument. In
particular, if a malformed request is detected, normal request processing
will be immediately halted and the internal error message returned.
This is necessary to guard against security problems caused by
bad requests.See also
ErrorLog Directive
Description: Location where the server will log errors Syntax: ErrorLog file-path|syslog[:facility]Default: ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows and OS/2)Context: server config, virtual host Status: Core Module: core ErrorLog directive sets the name of
the file to which the server will log any errors it encounters. If
the file-path is not absolute then it is assumed to be
relative to the ServerRoot.Example
ErrorLog /var/log/httpd/error_log
Example
ErrorLog "|/usr/local/bin/httpd_errors"
syslog instead of a filename enables logging
via syslogd(8) if the system supports it. The default is to use
syslog facility local7, but you can override this by
using the syslog:facility syntax where
facility can be one of the names usually documented in
syslog(1).Example
ErrorLog syslog:user
Note
See also
FileETag Directive
Description: File attributes used to create the ETag
HTTP response header Syntax: FileETag component ...Default: FileETag INode MTime SizeContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core FileETag directive configures the file
attributes that are used to create the ETag (entity
tag) response header field when the document is based on a file.
(The ETag value is used in cache management to save
network bandwidth.) In Apache 1.3.22 and earlier, the
ETag value was always formed
from the file's inode, size, and last-modified time (mtime). The
FileETag directive allows you to choose
which of these -- if any -- should be used. The recognized keywords are:
FileETag INode MTime SizeETag field will be
included in the responseINode, MTime, and Size
keywords may be prefixed with either + or -,
which allow changes to be made to the default setting inherited
from a broader scope. Any keyword appearing without such a prefix
immediately and completely cancels the inherited setting.FileETag INode MTime Size, and a
subdirectory's includes FileETag -INode,
the setting for that subdirectory (which will be inherited by
any sub-subdirectories that don't override it) will be equivalent to
FileETag MTime Size.<Files> Directive
Description: Contains directives that apply to matched
filenames Syntax: <Files filename> ... </Files>Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core <Files> directive
limits the scope of the enclosed directives by filename. It is comparable
to the <Directory>
and <Location>
directives. It should be matched with a </Files>
directive. The directives given within this section will be applied to
any object with a basename (last component of filename) matching the
specified filename. <Files>
sections are processed in the order they appear in the
configuration file, after the <Directory> sections and
.htaccess files are read, but before <Location> sections. Note
that <Files> can be nested
inside <Directory> sections to restrict the
portion of the filesystem they apply to.? matches any single character,
and * matches any sequences of characters. Extended regular
expressions can also be used, with the addition of the
~ character. For example:
<Files ~ "\.(gif|jpe?g|png)$">
<FilesMatch> is preferred,
however.<Directory> and <Location> sections, <Files> sections can be used inside
.htaccess files. This allows users to control access to
their own files, at a file-by-file level.See also
<FilesMatch> Directive
Description: Contains directives that apply to regular-expression matched
filenames Syntax: <FilesMatch regex> ... </FilesMatch>Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core <FilesMatch> directive
limits the scope of the enclosed directives by filename, just as the
<Files> directive
does. However, it accepts a regular expression. For example:
<FilesMatch "\.(gif|jpe?g|png)$">
See also
ForceType Directive
Description: Forces all matching files to be served with the specified
MIME content-type Syntax: ForceType MIME-type|NoneContext: directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: Moved to the core in Apache 2.0 .htaccess file or a
<Directory>, or
<Location> or
<Files>
section, this directive forces all matching files to be served
with the content type identification given by
MIME-type. For example, if you had a directory full of
GIF files, but did not want to label them all with .gif,
you might want to use:
ForceType image/gif
DefaultType,
this directive overrides all mime-type associations, including
filename extensions, that might identify the media type.ForceType setting
by using the value of None:
# force all files to be image/gif:
<Location /images>
ForceType image/gif
</Location>
# but normal mime-type associations here:
<Location /images/mixed>
ForceType None
</Location>
HostnameLookups Directive
Description: Enables DNS lookups on client IP addresses Syntax: HostnameLookups On|Off|DoubleDefault: HostnameLookups OffContext: server config, virtual host, directory Status: Core Module: core REMOTE_HOST).
The value Double refers to doing double-reverse
DNS lookup. That is, after a reverse lookup is performed, a forward
lookup is then performed on that result. At least one of the IP
addresses in the forward lookup must match the original
address. (In "tcpwrappers" terminology this is called
PARANOID.)mod_access is
used for controlling access by hostname, a double reverse lookup
will be performed. This is necessary for security. Note that the
result of this double-reverse isn't generally available unless you
set HostnameLookups Double. For example, if only
HostnameLookups On and a request is made to an object
that is protected by hostname restrictions, regardless of whether
the double-reverse fails or not, CGIs will still be passed the
single-reverse result in REMOTE_HOST.Off in order to save the network
traffic for those sites that don't truly need the reverse
lookups done. It is also better for the end users because they
don't have to suffer the extra latency that a lookup entails.
Heavily loaded sites should leave this directive
Off, since DNS lookups can take considerable
amounts of time. The utility logresolve, compiled by
default to the bin subdirectory of your installation
directory, can be used to look up host names from logged IP addresses
offline.IdentityCheck Directive
Description: Enables logging of the RFC1413 identity of the remote
user Syntax: IdentityCheck On|OffDefault: IdentityCheck OffContext: server config, virtual host, directory Status: Core Module: core <IfDefine> Directive
Description: Encloses directives that will be processed only
if a test is true at startup Syntax: <IfDefine [!]parameter-name> ...
</IfDefine>Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core <IfDefine test>...</IfDefine>
section is used to mark directives that are conditional. The
directives within an <IfDefine>
section are only processed if the test is true. If
test is false, everything between the start and end markers is
ignored.<IfDefine> section directive can be one of two forms:
!parameter-namehttpd command line via -Dparameter-
, at the time the server was started.<IfDefine> sections are
nest-able, which can be used to implement simple
multiple-parameter tests. Example:
httpd -DReverseProxy ...
# httpd.conf
<IfDefine ReverseProxy>
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/libproxy.so
</IfDefine>
<IfModule> Directive
Description: Encloses directives that are processed conditional on the
presence or absence of a specific module Syntax: <IfModule [!]module-name> ...
</IfModule>Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core <IfModule test>...</IfModule>
section is used to mark directives that are conditional on the presence of
a specific module. The directives within an <IfModule> section are only processed if the test
is true. If test is false, everything between the start and
end markers is ignored.<IfModule> section directive can be one of two forms:
LoadModule. The second format reverses the test,
and only processes the directives if module name is
not included.mod_rewrite.c. If a module consists of several
source files, use the name of the file containing the string
STANDARD20_MODULE_STUFF.<IfModule> sections are
nest-able, which can be used to implement simple multiple-module
tests.This section should only be used if you need to have one
configuration file that works whether or not a specific module
is available. In normal operation, directives need not be
placed in
<IfModule>
sections.Include Directive
Description: Includes other configuration files from within
the server configuration files Syntax: Include file-path|directory-pathContext: server config, virtual host, directory Status: Core Module: core Compatibility: Wildcard matching available in 2.0.41 and later fnmatch()) wildcard characters can be used to
include several files at once, in alphabetical order. In
addition, if Include points to a directory,
rather than a file, Apache will read all files in that directory
and any subdirectory. But including entire directories is not
recommended, because it is easy to accidentally leave temporary
files in a directory that can cause httpd to
fail.ServerRoot directory.
Include /usr/local/apache2/conf/ssl.conf
Include /usr/local/apache2/conf/vhosts/*.conf
ServerRoot directory:
Include conf/ssl.conf
Include conf/vhosts/*.conf
apachectl configtest will give you a list
of the files that are being processed during the configuration
check:
root@host# apachectl configtest
Processing config file: /usr/local/apache2/conf/ssl.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost1.conf
Processing config file: /usr/local/apache2/conf/vhosts/vhost2.conf
Syntax OK
See also
KeepAlive Directive
Description: Enables HTTP persistent connections Syntax: KeepAlive On|OffDefault: KeepAlive OnContext: server config, virtual host Status: Core Module: core KeepAlive On.See also
KeepAliveTimeout Directive
Description: Amount of time the server will wait for subsequent
requests on a persistent connection Syntax: KeepAliveTimeout secondsDefault: KeepAliveTimeout 15Context: server config, virtual host Status: Core Module: core Timeout directive applies.KeepAliveTimeout to a high value
may cause performance problems in heavily loaded servers. The
higher the timeout, the more server processes will be kept
occupied waiting on connections with idle clients.<Limit> Directive
Description: Restrict enclosed access controls to only certain HTTP
methods Syntax: <Limit method [method] ... > ...
</Limit>Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core <Limit> section.<Limit>
directive is to restrict the effect of the access controls to the
nominated HTTP methods. For all other methods, the access
restrictions that are enclosed in the <Limit> bracket will have no
effect. The following example applies the access control
only to the methods POST, PUT, and
DELETE, leaving all other methods unprotected:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
GET,
POST, PUT, DELETE,
CONNECT, OPTIONS,
PATCH, PROPFIND, PROPPATCH,
MKCOL, COPY, MOVE,
LOCK, and UNLOCK. The method name is
case-sensitive. If GET is used it will also
restrict HEAD requests. The TRACE method
cannot be limited.A
<LimitExcept> section should always be
used in preference to a <Limit> section when restricting access,
since a <LimitExcept> section provides protection
against arbitrary methods.<LimitExcept> Directive
Description: Restrict access controls to all HTTP methods
except the named ones Syntax: <LimitExcept method [method] ... > ...
</LimitExcept>Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core <LimitExcept> and
</LimitExcept> are used to enclose
a group of access control directives which will then apply to any
HTTP access method not listed in the arguments;
i.e., it is the opposite of a <Limit> section and can be used to control
both standard and nonstandard/unrecognized methods. See the
documentation for <Limit> for more details.
<LimitExcept POST GET>
Require valid-user
</LimitExcept>
LimitInternalRecursion Directive
Description: Determine maximum number of internal redirects and nested
subrequests Syntax: LimitInternalRecursion number [number]Default: LimitInternalRecursion 10Context: server config, virtual host Status: Core Module: core Compatibility: Available in Apache 2.0.47 and later Action directive, which internally
redirects the original request to a CGI script. A subrequest is Apache's
mechanism to find out what would happen for some URI if it were requested.
For example, mod_dir uses subrequests to look for the
files listed in the DirectoryIndex
directive.LimitInternalRecursion prevents the server
from crashing when entering an infinite loop of internal redirects or
subrequests. Such loops are usually caused by misconfigurations.Example
LimitInternalRecursion 5
LimitRequestBody Directive
Description: Restricts the total size of the HTTP request body sent
from the client Syntax: LimitRequestBody bytesDefault: LimitRequestBody 0Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core LimitRequestBody directive allows
the user to set a limit on the allowed size of an HTTP request
message body within the context in which the directive is given
(server, per-directory, per-file or per-location). If the client
request exceeds that limit, the server will return an error
response instead of servicing the request. The size of a normal
request message body will vary greatly depending on the nature of
the resource and the methods allowed on that resource. CGI scripts
typically use the message body for retrieving form information.
Implementations of the PUT method will require
a value at least as large as any representation that the server
wishes to accept for that resource.
LimitRequestBody 102400
LimitRequestFields Directive
Description: Limits the number of HTTP request header fields that
will be accepted from the client Syntax: LimitRequestFields numberDefault: LimitRequestFields 100Context: server config Status: Core Module: core DEFAULT_LIMIT_REQUEST_FIELDS (100 as
distributed).LimitRequestFields directive allows
the server administrator to modify the limit on the number of
request header fields allowed in an HTTP request. A server needs
this value to be larger than the number of fields that a normal
client request might include. The number of request header fields
used by a client rarely exceeds 20, but this may vary among
different client implementations, often depending upon the extent
to which a user has configured their browser to support detailed
content negotiation. Optional HTTP extensions are often expressed
using request header fields.
LimitRequestFields 50
LimitRequestFieldSize Directive
Description: Limits the size of the HTTP request header allowed from the
client Syntax: LimitRequestFieldsize bytesDefault: LimitRequestFieldsize 8190Context: server config Status: Core Module: core LimitRequestFieldSize directive
allows the server administrator to reduce or increase the limit
on the allowed size of an HTTP request header field. A server
needs this value to be large enough to hold any one header field
from a normal client request. The size of a normal request header
field will vary greatly among different client implementations,
often depending upon the extent to which a user has configured
their browser to support detailed content negotiation. SPNEGO
authentication headers can be up to 12392 bytes.
LimitRequestFieldSize 4094
Under normal conditions, the value should not be changed from
the default.
Apache 2.0.53 or higher is required for increasing the
limit above the compiled-in value of DEFAULT_LIMIT_REQUEST_FIELDSIZE
(8190 as distributed).
LimitRequestLine Directive
Description: Limit the size of the HTTP request line that will be accepted
from the client Syntax: LimitRequestLine bytesDefault: LimitRequestLine 8190Context: server config Status: Core Module: core DEFAULT_LIMIT_REQUEST_LINE (8190 as distributed)
that will be allowed on the HTTP request-line.LimitRequestLine directive allows
the server administrator to reduce the limit on the allowed size
of a client's HTTP request-line below the normal input buffer size
compiled with the server. Since the request-line consists of the
HTTP method, URI, and protocol version, the
LimitRequestLine directive places a
restriction on the length of a request-URI allowed for a request
on the server. A server needs this value to be large enough to
hold any of its resource names, including any information that
might be passed in the query part of a GET request.
LimitRequestLine 4094
Under normal conditions, the value should not be changed from
the default.
LimitXMLRequestBody Directive
Description: Limits the size of an XML-based request body Syntax: LimitXMLRequestBody bytesDefault: LimitXMLRequestBody 1000000Context: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core 0 will disable any checking.
LimitXMLRequestBody 0
<Location> Directive
Description: Applies the enclosed directives only to matching
URLs Syntax: <Location
URL-path|URL> ... </Location>Context: server config, virtual host Status: Core Module: core <Location> directive
limits the scope of the enclosed directives by URL. It is similar to the
<Directory>
directive, and starts a subsection which is terminated with a
</Location> directive. <Location> sections are processed in the
order they appear in the configuration file, after the <Directory> sections and
.htaccess files are read, and after the <Files> sections.<Location> sections operate
completely outside the filesystem. This has several consequences.
Most importantly, <Location>
directives should not be used to control access to filesystem
locations. Since several different URLs may map to the same
filesystem location, such access controls may by circumvented.When to use
<Location><Location> to apply
directives to content that lives outside the filesystem. For
content that lives in the filesystem, use <Directory> and <Files>. An exception is
<Location />, which is an easy way to
apply a configuration to the entire server./path/. No scheme, hostname,
port, or query string may be included. For proxy requests, the
URL to be matched is of the form
scheme://servername/path, and you must include the
prefix.? matches
any single character, and * matches any sequences of
characters.~ character. For example:
<Location ~ "/(extra|special)/data">
/extra/data
or /special/data. The directive <LocationMatch> behaves
identical to the regex version of <Location>.<Location>
functionality is especially useful when combined with the
SetHandler
directive. For example, to enable status requests, but allow them
only from browsers at foo.com, you might use:
<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
Note about / (slash)
/home///foo is the same as
/home/foo). In URL-space this is not necessarily true.
The <LocationMatch>
directive and the regex version of <Location> require you to explicitly specify multiple
slashes if that is your intention.<LocationMatch ^/abc> would match
the request URL /abc but not the request URL
//abc. The (non-regex) <Location> directive behaves similarly when used for
proxy requests. But when (non-regex) <Location> is used for non-proxy requests it will
implicitly match multiple slashes with a single slash. For example,
if you specify <Location /abc/def> and the
request is to /abc//def then it will match.See also
<LocationMatch> Directive
Description: Applies the enclosed directives only to regular-expression
matching URLs Syntax: <LocationMatch
regex> ... </LocationMatch>Context: server config, virtual host Status: Core Module: core <LocationMatch> directive
limits the scope of the enclosed directives by URL, in an identical manner
to <Location>. However,
it takes a regular expression as an argument instead of a simple
string. For example:
<LocationMatch "/(extra|special)/data">
/extra/data
or /special/data.See also
LogLevel Directive
Description: Controls the verbosity of the ErrorLog Syntax: LogLevel levelDefault: LogLevel warnContext: server config, virtual host Status: Core Module: core LogLevel adjusts the verbosity of the
messages recorded in the error logs (see ErrorLog directive). The following
levels are available, in order of decreasing
significance:
Level
Description
Example
emerg Emergencies - system is unusable.
"Child cannot open lock file. Exiting"
alert Action must be taken immediately.
"getpwuid: couldn't determine user name from uid"
crit Critical Conditions.
"socket: Failed to get a socket, exiting child"
error Error conditions.
"Premature end of script headers"
warn Warning conditions.
"child process 1234 did not exit, sending another
SIGHUP"
notice Normal but significant condition.
"httpd: caught SIGBUS, attempting to dump core in
..."
info Informational.
"Server seems busy, (you may need to increase
StartServers, or Min/MaxSpareServers)..."
debug Debug-level messages
"Opening config file ..."
LogLevel info is specified,
then messages with log levels of notice and
warn will also be posted.crit is
recommended.
LogLevel notice
Note
notice cannot be suppressed and thus are always
logged. However, this doesn't apply when logging is done
using syslog.MaxKeepAliveRequests Directive
Description: Number of requests allowed on a persistent
connection Syntax: MaxKeepAliveRequests numberDefault: MaxKeepAliveRequests 100Context: server config, virtual host Status: Core Module: core MaxKeepAliveRequests directive
limits the number of requests allowed per connection when
KeepAlive is on. If it is
set to 0, unlimited requests will be allowed. We
recommend that this setting be kept to a high value for maximum
server performance.
MaxKeepAliveRequests 500
NameVirtualHost Directive
Description: Designates an IP address for name-virtual
hosting Syntax: NameVirtualHost addr[:port]Context: server config Status: Core Module: core NameVirtualHost directive is a
required directive if you want to configure name-based virtual hosts.
NameVirtualHost 111.22.33.44
NameVirtualHost directive you
specify the IP address on which the server will receive requests
for the name-based virtual hosts. This will usually be the address
to which your name-based virtual host names resolve. In cases
where a firewall or other proxy receives the requests and forwards
them on a different IP address to the server, you must specify the
IP address of the physical interface on the machine which will be
servicing the requests. If you have multiple name-based hosts on
multiple addresses, repeat the directive for each address.Note
_default_ servers
will never be served for a request to a
NameVirtualHost IP address (unless for some
reason you specify NameVirtualHost but then
don't define any VirtualHosts for that
address).
NameVirtualHost 111.22.33.44:8080
NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080
*
NameVirtualHost *
Argument to
<VirtualHost>
directive<VirtualHost> directive must
exactly match the argument to the NameVirtualHost directive.
NameVirtualHost 1.2.3.4
<VirtualHost 1.2.3.4>
# ...
</VirtualHost>
See also
Options Directive
Description: Configures what features are available in a particular
directory Syntax: Options
[+|-]option [[+|-]option] ...Default: Options AllContext: server config, virtual host, directory, .htaccess Override: Options Status: Core Module: core Options directive controls which
server features are available in a particular directory.None, in which
case none of the extra features are enabled, or one or more of
the following:
AllMultiViews. This is the default
setting.ExecCGImod_cgi
is permitted.FollowSymLinks
<Directory> sections.<Location>
section.Includesmod_include
are permitted.IncludesNOEXEC#exec
cmd and #exec cgi are disabled. It is still
possible to #include virtual CGI scripts from
ScriptAliased
directories.IndexesDirectoryIndex
(e.g., index.html) in that directory, then
mod_autoindex will return a formatted listing
of the directory.MultiViewsmod_negotiation.SymLinksIfOwnerMatchNote
This option gets ignored if
set inside a <Location> section.Options could
apply to a directory, then the most specific one is used and
others are ignored; the options are not merged. (See how sections are merged.)
However if all the options on the
Options directive are preceded by a
+ or - symbol, the options are
merged. Any options preceded by a + are added to the
options currently in force, and any options preceded by a
- are removed from the options currently in
force. Warning
Options with a + or
- with those without is not valid syntax, and is likely
to cause unexpected results.+ and - symbols:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>
Includes will be set for the
/web/docs/spec directory. However if the second
Options directive uses the + and
- symbols:
<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>
FollowSymLinks and
Includes are set for the /web/docs/spec
directory.Note
-IncludesNOEXEC or
-Includes disables server-side includes completely
regardless of the previous setting.All.Require Directive
Description: Selects which authenticated users can access
a resource Syntax: Require entity-name [entity-name] ...Context: directory, .htaccess Override: AuthConfig Status: Core Module: core
Require user userid [userid]
...Require group group-name [group-name]
...Require valid-userRequire must be accompanied by
AuthName and AuthType directives, and directives such
as AuthUserFile
and AuthGroupFile (to
define users and groups) in order to work correctly. Example:
AuthType Basic
AuthName "Restricted Resource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin
Require statement into a
<Limit>
section.See also
RLimitCPU Directive
Description: Limits the CPU consumption of processes launched
by Apache children Syntax: RLimitCPU seconds|max [seconds|max]Default: Unset; uses operating system defaultsContext: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core max to indicate to the server that the limit should
be set to the maximum allowed by the operating system
configuration. Raising the maximum resource limit requires that
the server is running as root, or in the initial startup
phase.See also
RLimitMEM Directive
Description: Limits the memory consumption of processes launched
by Apache children Syntax: RLimitMEM bytes|max [bytes|max]Default: Unset; uses operating system defaultsContext: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core max to indicate to the server that the limit should
be set to the maximum allowed by the operating system
configuration. Raising the maximum resource limit requires that
the server is running as root, or in the initial startup
phase.See also
RLimitNPROC Directive
Description: Limits the number of processes that can be launched by
processes launched by Apache children Syntax: RLimitNPROC number|max [number|max]Default: Unset; uses operating system defaultsContext: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core max to indicate to the server that the limit
should be set to the maximum allowed by the operating system
configuration. Raising the maximum resource limit requires that
the server is running as root, or in the initial startup
phase.Note
cannot fork messages in the
error_log.See also
Satisfy Directive
Description: Interaction between host-level access control and
user authentication Syntax: Satisfy Any|AllDefault: Satisfy AllContext: directory, .htaccess Override: AuthConfig Status: Core Module: core Compatibility: Influenced by <Limit> and <LimitExcept> in version 2.0.51 and
laterAllow and Require used. The parameter can be
either All or Any. This directive is only
useful if access to a particular area is being restricted by both
username/password and client host address. In this case
the default behavior (All) is to require that the client
passes the address access restriction and enters a valid
username and password. With the Any option the client will be
granted access if they either pass the host restriction or enter a
valid username and password. This can be used to password restrict
an area, but to let clients from particular addresses in without
prompting for a password.
Require valid-user
Allow from 192.168.1
Satisfy Any
Satisfy directives can
be restricted to particular methods by <Limit> and <LimitExcept> sections.See also
ScriptInterpreterSource Directive
Description: Technique for locating the interpreter for CGI
scripts Syntax: ScriptInterpreterSource Registry|Registry-Strict|ScriptDefault: ScriptInterpreterSource ScriptContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: Win32 only;
option Registry-Strict is available in Apache 2.0 and
laterScript. This causes Apache to use the interpreter pointed to
by the shebang line (first line, starting with #!) in the
script. On Win32 systems this line usually looks like:
#!C:/Perl/bin/perl.exe
perl is in the PATH, simply:
#!perl
ScriptInterpreterSource Registry will
cause the Windows Registry tree HKEY_CLASSES_ROOT to be
searched using the script file extension (e.g., .pl) as a
search key. The command defined by the registry subkey
Shell\ExecCGI\Command or, if it does not exist, by the subkey
Shell\Open\Command is used to open the script file. If the
registry keys cannot be found, Apache falls back to the behavior of the
Script option.Security
ScriptInterpreterSource
Registry with ScriptAlias'ed directories, because
Apache will try to execute every file within this
directory. The Registry setting may cause undesired
program calls on files which are typically not executed. For
example, the default open command on .htm files on
most Windows systems will execute Microsoft Internet Explorer, so
any HTTP request for an .htm file existing within the
script directory would start the browser in the background on the
server. This is a good way to crash your system within a minute or
so.Registry-Strict which is new in Apache
2.0 does the same thing as Registry but uses only the
subkey Shell\ExecCGI\Command. The
ExecCGI key is not a common one. It must be
configured manually in the windows registry and hence prevents
accidental program calls on your system.ServerAdmin Directive
Description: Email address that the server includes in error
messages sent to the client Syntax: ServerAdmin email-addressContext: server config, virtual host Status: Core Module: core ServerAdmin sets the e-mail address
that the server includes in any error messages it returns to the
client.
ServerAdmin www-admin@foo.example.com
ServerAlias Directive
Description: Alternate names for a host used when matching requests
to name-virtual hosts Syntax: ServerAlias hostname [hostname] ...Context: virtual host Status: Core Module: core ServerAlias directive sets the
alternate names for a host, for use with name-based virtual hosts.
<VirtualHost *>
ServerName server.domain.com
ServerAlias server server2.domain.com server2
# ...
</VirtualHost>
See also
ServerName Directive
Description: Hostname and port that the server uses to identify
itself Syntax: ServerName fully-qualified-domain-name[:port]Context: server config, virtual host Status: Core Module: core Compatibility: In version 2.0, this
directive supersedes the functionality of the Port
directive from version 1.3.ServerName directive sets the hostname and
port that the server uses to identify itself. This is used when
creating redirection URLs. For example, if the name of the
machine hosting the web server is simple.example.com,
but the machine also has the DNS alias www.example.com
and you wish the web server to be so identified, the following
directive should be used:
ServerName www.example.com:80
ServerName is specified, then the
server attempts to deduce the hostname by performing a reverse
lookup on the IP address. If no port is specified in the
ServerName, then the server will use the port
from the incoming
request. For optimal reliability and predictability, you should
specify an explicit hostname and port using the
ServerName directive.ServerName inside a
<VirtualHost>
section specifies what hostname must appear in the request's
Host: header to match this virtual host.UseCanonicalName directive for
settings which determine whether self-referential URL's (e.g., by the
mod_dir module) will refer to the
specified port, or to the port number given in the client's request.
See also
ServerPath Directive
Description: Legacy URL pathname for a name-based virtual host that
is accessed by an incompatible browser Syntax: ServerPath URL-pathContext: virtual host Status: Core Module: core ServerPath directive sets the legacy
URL pathname for a host, for use with name-based virtual hosts.See also
ServerRoot Directive
Description: Base directory for the server installation Syntax: ServerRoot directory-pathDefault: ServerRoot /usr/local/apacheContext: server config Status: Core Module: core ServerRoot directive sets the
directory in which the server lives. Typically it will contain the
subdirectories conf/ and logs/. Relative
paths in other configuration directives (such as Include or LoadModule, for example) are taken as
relative to this directory.Example
ServerRoot /home/httpd
See also
-d
option to httpdServerRootServerSignature Directive
Description: Configures the footer on server-generated documents Syntax: ServerSignature On|Off|EMailDefault: ServerSignature OffContext: server config, virtual host, directory, .htaccess Override: All Status: Core Module: core ServerSignature directive allows the
configuration of a trailing footer line under server-generated
documents (error messages, mod_proxy ftp directory
listings, mod_info output, ...). The reason why you
would want to enable such a footer line is that in a chain of proxies,
the user often has no possibility to tell which of the chained servers
actually produced a returned error message.Off
setting, which is the default, suppresses the footer line (and is
therefore compatible with the behavior of Apache-1.2 and
below). The On setting simply adds a line with the
server version number and ServerName of the serving virtual host,
and the EMail setting additionally creates a
"mailto:" reference to the ServerAdmin of the referenced
document.ServerTokens directive.See also
ServerTokens Directive
Description: Configures the Server HTTP response
headerSyntax: ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|FullDefault: ServerTokens FullContext: server config Status: Core Module: core Server response
header field which is sent back to clients includes a
description of the generic OS-type of the server as well as
information about compiled-in modules.
ServerTokens Prod[uctOnly]Server:
ApacheServerTokens MajorServer:
Apache/2ServerTokens MinorServer:
Apache/2.0ServerTokens Min[imal]Server:
Apache/2.0.41ServerTokens OSServer: Apache/2.0.41
(Unix)ServerTokens Full (or not specified)Server: Apache/2.0.41
(Unix) PHP/4.2.2 MyMod/1.2ServerSignature directive.See also
SetHandler Directive
Description: Forces all matching files to be processed by a
handler Syntax: SetHandler handler-name|NoneContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core Compatibility: Moved into the core in Apache 2.0 .htaccess file or a
<Directory> or
<Location>
section, this directive forces all matching files to be parsed
through the handler given by
handler-name. For example, if you had a directory you
wanted to be parsed entirely as imagemap rule files, regardless
of extension, you might put the following into an
.htaccess file in that directory:
SetHandler imap-file
http://servername/status was called, you might put
the following into httpd.conf:
<Location /status>
SetHandler server-status
</Location>
SetHandler
directive by using the value None.See also
SetInputFilter Directive
Description: Sets the filters that will process client requests and POST
input Syntax: SetInputFilter filter[;filter...]Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core SetInputFilter directive sets the
filter or filters which will process client requests and POST
input when they are received by the server. This is in addition to
any filters defined elsewhere, including the
AddInputFilter
directive.See also
SetOutputFilter Directive
Description: Sets the filters that will process responses from the
server Syntax: SetOutputFilter filter[;filter...]Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Core Module: core SetOutputFilter directive sets the filters
which will process responses from the server before they are
sent to the client. This is in addition to any filters defined
elsewhere, including the
AddOutputFilter
directive./www/data/ directory for server-side
includes.
<Directory /www/data/>
SetOutputFilter INCLUDES
</Directory>
See also
TimeOut Directive
Description: Amount of time the server will wait for
certain events before failing a request Syntax: TimeOut secondsDefault: TimeOut 300Context: server config, virtual host Status: Core Module: core TimeOut directive currently defines
the amount of time Apache will wait for three things:
TraceEnable Directive
Description: Determines the behaviour on TRACE
requestsSyntax: TraceEnable [on|off|extended]Default: TraceEnable onContext: server config Status: Core Module: core Compatibility: Available in Apache 1.3.34, 2.0.55 and later TRACE for both
the core server and mod_proxy. The default
TraceEnable on permits TRACE requests per
RFC 2616, which disallows any request body to accompany the request.
TraceEnable off causes the core server and
mod_proxy to return a 405 (Method not
allowed) error to the client.TraceEnable
extended directive. The core (as an origin server) will
restrict the request body to 64k (plus 8k for chunk headers if
Transfer-Encoding: chunked is used). The core will
reflect the full headers and all chunk headers with the response
body. As a proxy server, the request body is not restricted to 64k.UseCanonicalName Directive
Description: Configures how the server determines its own name and
port Syntax: UseCanonicalName On|Off|DNSDefault: UseCanonicalName OnContext: server config, virtual host, directory Status: Core Module: core UseCanonicalName On Apache will use the hostname and port
specified in the ServerName
directive to construct the canonical name for the server. This name
is used in all self-referential URLs, and for the values of
SERVER_NAME and SERVER_PORT in CGIs.UseCanonicalName Off Apache will form
self-referential URLs using the hostname and port supplied by
the client if any are supplied (otherwise it will use the
canonical name, as defined above). These values are the same
that are used to implement name based virtual hosts,
and are available with the same clients. The CGI variables
SERVER_NAME and SERVER_PORT will be
constructed from the client supplied values as well.www. You'll notice that if the users
type a shortname, and a URL which is a directory, such as
http://www/splat, without the trailing
slash then Apache will redirect them to
http://www.domain.com/splat/. If you have
authentication enabled, this will cause the user to have to
authenticate twice (once for www and once again
for www.domain.com -- see the
FAQ on this subject for more information). But if
UseCanonicalName is set Off, then
Apache will redirect to http://www/splat/.UseCanonicalName DNS,
which is intended for use with mass IP-based virtual hosting to
support ancient clients that do not provide a
Host: header. With this option Apache does a
reverse DNS lookup on the server IP address that the client
connected to in order to work out self-referential URLs.Warning
SERVER_NAME
they may be broken by this option. The client is essentially free
to give whatever value they want as a hostname. But if the CGI is
only using SERVER_NAME to construct self-referential URLs
then it should be just fine.See also
<VirtualHost> Directive
Description: Contains directives that apply only to a specific
hostname or IP address Syntax: <VirtualHost
addr[:port] [addr[:port]]
...> ... </VirtualHost>Context: server config Status: Core Module: core <VirtualHost> and
</VirtualHost> are used to enclose a group of
directives that will apply only to a particular virtual host. Any
directive that is allowed in a virtual host context may be
used. When the server receives a request for a document on a
particular virtual host, it uses the configuration directives
enclosed in the <VirtualHost>
section. Addr can be:
*, which is used only in combination with
NameVirtualHost * to match all IP addresses; or_default_, which is used only
with IP virtual hosting to catch unmatched IP addresses.Example
<VirtualHost 10.1.2.3>
ServerAdmin webmaster@host.foo.com
DocumentRoot /www/docs/host.foo.com
ServerName host.foo.com
ErrorLog logs/host.foo.com-error_log
TransferLog logs/host.foo.com-access_log
</VirtualHost>
<VirtualHost [2001:db8::a00:20ff:fea7:ccea]>
ServerAdmin webmaster@host.example.com
DocumentRoot /www/docs/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
TransferLog logs/host.example.com-access_log
</VirtualHost>
ifconfig alias command -- if
your OS supports it).Note
<VirtualHost> does
not affect what addresses Apache listens on. You
may need to ensure that Apache is listening on the correct addresses
using Listen._default_ can be specified in
which case this virtual host will match any IP address that is
not explicitly listed in another virtual host. In the absence
of any _default_ virtual host the "main" server config,
consisting of all those definitions outside any VirtualHost
section, is used when no IP-match occurs. (But note that any IP
address that matches a NameVirtualHost directive will use neither
the "main" server config nor the _default_ virtual host.
See the name-based virtual hosting
documentation for further details.):port to change the port that is
matched. If unspecified then it defaults to the same port as the
most recent Listen
statement of the main server. You may also specify :*
to match all ports on that address. (This is recommended when used
with _default_.)Security
See also
mod/directives.html 100644 0 0 65637 11074463123 12055 0 ustar 0 0
지시어를 설명하는데 사용한 용어들
설명 (Description) 문법 (Syntax) 기본값 (Default) 사용장소 (Context) Override 옵션 (Override) 상태 (Status) 모듈 (Module) 지원 (Compatibility)참고
설명 (Description)
문법 (Syntax)
http://www.example.com/path/to/file.html과
같이 스킴(scheme), 호스트명, 선택적인 경로명을 포함한
완전한 Uniform Resource Locator/path/to/file.html과 같이 url에서
스킴과 호스트명 뒤에 나오는 부분. url-path는
파일시스템에서 본 시점이 아닌 웹에서 본 시점에서의 자료를
나타낸다./usr/local/apache/htdocs/path/to/file.html과
같이 root 디렉토리로 시작하는 파일시스템상의 파일 경로. 따로
언급하지않으면, 슬래쉬로 시작하지않은 file-path는
ServerRoot에 상대경로로
취급한다./usr/local/apache/htdocs/path/to/와 같이
root 디렉토리로 시작하는 파일시스템상의 디렉토리 경로.file.html과 같이 경로 정보가 없는 파일명.file.html.en은
.html과 .en이라는 두가지 확장자를
가진다. 아파치 지시어에서 extension에 지정한
값 앞에 마침표가 있어도 되고 없어도 된다. 또,
extension은 대소문자를 가리지않는다.text/html과 같이 슬래쉬로 major format
type과 minor format type를 구분하여 파일의 형식을 설명하는
방식.
기본값 (Default)
사용장소 (Context)
httpd.conf) 사용할 수 있으나, <VirtualHost>나
<Directory>에서
사용할 수 없음을 뜻한다. 이 지시어는
.htaccess 파일에서도 사용할 수 없다.<VirtualHost> 안에서 사용할 수
있음을 뜻한다.<Directory>, <Location>,
<Files>에서
사용할 수 있음을 뜻한다..htaccess
파일에서 사용할 수 있음을 뜻한다. 이 지시어는 현재 사용하는
overrides 값에 따라 무시될 수
있다.server config, .htaccess"에서 가능하다는
지시어는 httpd.conf 파일과 .htaccess
파일에서는 사용할 수 있지만, <Directory>나 <VirtualHost>에서는 사용할 수 없다.
Override 옵션 (Override)
.htaccess 파일에서 사용하려면
어떤 override 옵션을 사용해야 하는지를 나타낸다. 지시어의
사용장소가 지시어를 .htaccess
파일에서 사용할 수 없다고 한다면 어떤 사용장소도 나오지
않는다.AllowOverride 지시어로 지시하고,
(디렉토리 등의) 특정 범위와 하위 범위에서 다른 AllowOverride 지시어로 다른 값을
설정하지않았다면 하위 범위에도 그대로 적용된다. 지시어 설명에
사용가능한 override 이름들이 나온다.
상태 (Status)
모듈 (Module)
지원 (Compatibility)
지시어 목록
mod/index.html 100644 0 0 26612 11074463123 11011 0 ustar 0 0
mod/leader.html 100644 0 0 13106 11074463123 11130 0 ustar 0 0
모듈 목록
핵심 기능과 다중처리 모듈
worker MPM의 실험적인 변형worker MPM다른 모듈
ls 명령어나 Win32의
dir 쉘명령어와 유사한 디렉토리 목록을 만든다mod_dav을 위한 파일시스템 제공자Expires와
Cache-Control HTTP 헤더를 생성한다mod_proxy extension for
CONNECT request handlingmod_proxymod_proxy
mod/mod_access.html 100644 0 0 46267 11074463123 12012 0 ustar 0 0
아파치 MPM leader
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 표준 worker MPM의 실험적인 변형상태: MPM 모듈명: mpm_leader_module 소스파일: leader.c 요약
주의
worker MPM의 실험적인
변형이다. 이 모듈은 쓰레드간의 협동을 위해 Leader/Followers
디자인패턴을 사용한다. 더 자세한 정보는 http://deuce.doc.wustl.edu/doc/pspdfs/lf.pdf를 참고하라.leader MPM을 사용하려면,
httpd를 컴파일할때 configure
스크립트 아규먼트에 --with-mpm=leader를
사용한다.configure 스크립트 아규먼트에
--enable-nonportable-atomics=yes를 사용하라.
그러면 APR이 오래된 CPU에는 없는 더 효율적인 명령어를 사용하여
atomic 명령을 구현한다.
mod/mod_actions.html 100644 0 0 16421 11074463123 12176 0 ustar 0 0
Apache Module mod_access
Description: Provides access control based on client hostname, IP
address, or other characteristics of the client request. Status: Base Module쟅dentifier: access_module Source쟂ile: mod_access.c Compatibility: Available only in versions prior to 2.1 Summary
mod_access are used
in <Directory>,
<Files>, and
<Location> sections
as well as .htaccess
files to control access to particular parts of the server. Access
can be controlled based on the client hostname, IP address, or
other characteristics of the client request, as captured in environment variables. The Allow and Deny directives are used to
specify which clients are or are not allowed access to the server,
while the Order
directive sets the default access state, and configures how the
Allow and Deny directives interact with each
other.Satisfy directive is used
to determine how the two sets of restrictions interact.GET, PUT,
POST, etc). This is the desired behavior in most
cases. However, it is possible to restrict some methods, while
leaving other methods unrestricted, by enclosing the directives
in a <Limit> section.Allow Directive
Description: Controls which hosts can access an area of the
server Syntax: Allow from
all|host|env=env-variable
[host|env=env-variable] ...Context: directory, .htaccess Override: Limit Status: Base Module: mod_access Allow directive affects which hosts can
access an area of the server. Access can be controlled by
hostname, IP address, IP address range, or by other
characteristics of the client request captured in environment
variables.from. The subsequent arguments can take three
different forms. If Allow from all is specified, then
all hosts are allowed access, subject to the configuration of the
Deny and Order directives as discussed
below. To allow only particular hosts or groups of hosts to access
the server, the host can be specified in any of the
following formats:
Example:
Allow from apache.org
Allow from .net example.edu
foo.apache.org but it will not
match fooapache.org. This configuration will cause
Apache to perform a double reverse DNS lookup on the client IP
address, regardless of the setting of the HostnameLookups directive. It will do
a reverse DNS lookup on the IP address to find the associated
hostname, and then do a forward lookup on the hostname to assure
that it matches the original IP address. Only if the forward
and reverse DNS are consistent and the hostname matches will
access be allowed.Example:
Allow from 10.1.2.3
Allow from 192.168.1.104 192.168.1.205
Example:
Allow from 10.1
Allow from 10 172.20 192.168.2
Example:
Allow from 10.1.0.0/255.255.0.0
Example:
Allow from 10.1.0.0/16
Allow from 2001:db8::a00:20ff:fea7:ccea
Allow from 2001:db8::a00:20ff:fea7:ccea/10
Allow directive allows access to the server
to be controlled based on the existence of an environment variable. When Allow from
env=env-variable is specified, then the request is
allowed access if the environment variable env-variable
exists. The server provides the ability to set environment
variables in a flexible way based on characteristics of the client
request using the directives provided by
mod_setenvif. Therefore, this directive can be
used to allow access based on such factors as the clients
User-Agent (browser type), Referer, or
other HTTP request header fields.Example:
SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
<Directory /docroot>
Order Deny,Allow
Deny from all
Allow from env=let_me_in
</Directory>
KnockKnock/2.0 will be allowed access, and all
others will be denied.Deny Directive
Description: Controls which hosts are denied access to the
server Syntax: Deny from all|host|env=env-variable
[host|env=env-variable] ...Context: directory, .htaccess Override: Limit Status: Base Module: mod_access Deny directive are
identical to the arguments for the Allow directive.Order Directive
Description: Controls the default access state and the order in which
Allow and Deny are
evaluated.Syntax: Order orderingDefault: Order Deny,AllowContext: directory, .htaccess Override: Limit Status: Base Module: mod_access Order directive, along with the
Allow and Deny directives, controls a
three-pass access control system. The first pass processes either
all Allow or all
Deny directives, as
specified by the Order directive. The second
pass parses the rest of the directives (Deny or Allow). The third pass applies to
all requests which do not match either of the first two.Allow
and Deny directives are
processed, unlike a typical firewall, where only the first match is
used. The last match is effective (also unlike a typical firewall).
Additionally, the order in which lines appear in the configuration
files is not significant -- all Allow lines are processed as one
group, all Deny lines are
considered as another, and the default state is considered by
itself.
Allow,DenyAllow
directives are evaluated; at least one must match, or the request
is rejected. Next, all Deny directives are evaluated. If
any matches, the request is rejected. Last, any requests which do
not match an Allow or a
Deny directive are
denied by default.Deny,AllowDeny
directives are evaluated; if any match, the request is denied
unless it also matches an Allow directive. Any requests
which do not match any Allow or Deny directives are
permitted.Mutual-failureOrder
Allow,Deny and is deprecated in its favor.
Match
Allow,Deny result
Deny,Allow result
Match Allow only
Request allowed
Request allowed
Match Deny only
Request denied
Request denied
No match
Default to second directive: Denied
Default to second directive: Allowed
Match both Allow & Deny
Final match controls: Denied
Final match controls: Allowed
Order Deny,Allow
Deny from all
Allow from apache.org
Deny access to the server.
Order Allow,Deny
Allow from apache.org
Deny from foo.apache.org
Order in the
last example is changed to Deny,Allow, all hosts will
be allowed access. This happens because, regardless of the actual
ordering of the directives in the configuration file, the
Allow from apache.org will be evaluated last and will
override the Deny from foo.apache.org. All hosts not in
the apache.org domain will also be allowed access
because the default state is Allow.Order directive can
affect access to a part of the server even in the absence of
accompanying Allow and
Deny directives because
of its effect on the default access state. For example,
<Directory /www>
Order Allow,Deny
</Directory>
Deny all access
to the /www directory because the default access state
is set to Deny.Order directive controls the order of
access directive processing only within each phase of the server's
configuration processing. This implies, for example, that an
Allow or Deny directive occurring in a
<Location> section
will always be evaluated after an Allow or Deny directive occurring in a
<Directory>
section or .htaccess file, regardless of the setting of
the Order directive. For details on the
merging of configuration sections, see the documentation on How Directory, Location and Files sections
work.
mod/mod_alias.html 100644 0 0 45773 11074463123 11643 0 ustar 0 0
아파치 모듈 mod_actions
설명: 이 모듈은 미디어종류나 요청메서드에 따라 CGI
스크립트를 실행한다. 상태: Base 모듈명: actions_module 소스파일: mod_actions.c 요약
Action 지시어는 요청하는
파일의 종류에 따라 CGI 스크립트를 실행한다. Script 지시어는 요청이
특정 메서드를 사용할 경우 CGI 스크립트를 실행한다. 그래서
파일을 처리하는 스크립트를 매우 쉽게 실행할 수 있다.Action 지시어
설명: 특정 핸들러나 content-type에 대해 CGI 스크립트를
사용한다 문법: Action action-type cgi-script사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_actions ScriptAlias나 AddHandler를 사용하여 CGI
스크립트로 지정한 리소스의 URL경로이다.
action-type에는 핸들러나 MIME content type을
사용할 수 있다. 이 지시어는 PATH_INFO와 PATH_TRANSLATED
CGI 표준 환경변수로 요청한 문서의 URL과 파일경로를 전달한다.예제
# 특정 종류의 파일 요청:
Action image/gif /cgi-bin/images.cgi
# 특정한 확장자를 가진 파일
AddHandler my-file-type .xyz
Action my-file-type /cgi-bin/program.cgi
image/gif인
파일을 요청하면 지정한 cgi 스크립트 /cgi-bin/images.cgi가
대신 처리한다..xyz인 파일을 요청하면
지정한 cgi 스크립트 /cgi-bin/program.cgi가
대신 처리한다.참고
Script 지시어
설명: 특정 요청메서드에 대해 CGI 스크립트를
사용한다. 문법: Script method cgi-script사용장소: 주서버설정, 가상호스트, directory 상태: Base 모듈: mod_actions ScriptAlias나 AddHandler를 사용하여 CGI
스크립트로 지정한 리소스의 URL경로이다. 이 지시어는 PATH_INFO와
PATH_TRANSLATED CGI 표준 환경변수로 요청한 문서의 URL과
파일경로를 전달한다.
어떤 메서드 이름이라도 사용할 수 있다. 메서드 이름은
대소문자를 구별한다. 그래서
Script PUT과
Script put은 완전히 다르다.
GET
메서드의 Script는 질의아규먼트가 있을때만 (예,
foo.html?hi) 사용함을 주의하라. 질의아규먼트가 없다면
정상적으로 요청을 처리한다.예제
# <ISINDEX>식 검색을 위해
Script GET /cgi-bin/search
# CGI PUT 핸들러
Script PUT /~bob/put.cgi
mod/mod_asis.html 100644 0 0 11374 11074463123 11477 0 ustar 0 0
아파치 모듈 mod_alias
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 파일시스템의 다른 부분들을 문서 계층구조에 포함하고,
URL 리다이렉션을 제공한다 상태: Base 모듈명: alias_module 소스파일: mod_alias.c 요약
Alias와 ScriptAlias 지시어는 URL을
파일시스템 경로로 대응한다. 그래서 DocumentRoot 아래에 없는 내용을
웹으로 서비스할 수 있다. 또, ScriptAlias 지시어는 지정한
디렉토리에 CGI 스크립트밖에 없다고 알린다.Redirect 지시어는
클라이언트에게 다른 URL로 새로운 요청을 하도록 지시한다.
자원을 새로운 장소로 옮긴 경우 자주 사용한다.mod_alias는 간단한 URL 조작을 위해
설계되었다. 질의문자열 조작과 같은 복잡한 작업은
mod_rewrite가 제공하는 기능을 이용하라.지시어들
주제
참고
처리 순서
<VirtualHost> 섹션에)
Alias와 Redirect를 사용하면 아래 순서대로 처리한다.Redirect나 RedirectMatch에 해당하는 요청은
절대로 Alias하지 않는다. 그리고 Alias와 Redirect는 설정파일에서
첫번째로 나오는 것을 사용한다.
Alias /foo/bar /baz
Alias /foo /gaq
/foo/bar
Alias 이전에
/foo Alias를
적용하므로 항상 두번째 지시어를 무시한다.Alias 지시어
설명: URL을 특정 파일시스템 장소로 대응한다 문법: Alias URL-path
file-path|directory-path사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_alias Alias 지시어를 사용하면 파일시스템에서
DocumentRoot 밖에 있는
문서도 서비스할 수 있다. url-path로 시작하는
(%로 인코딩된) URL을 directory-path로 시작하는
파일에 대응한다.예제:
Alias /image /ftp/pub/image
Alias /icons/
/usr/local/apache/icons/ 설정은 url /icons와
관계가 없다.<Directory> 섹션이
필요할지도 모른다. 이 지시어는 <Directory> 섹션을 검사하기 전에
처리하므로, 대응의 대상만 섹션의 영향을 받는다. (그러나
<Location>
섹션은 이 지시어를 처리하기 전에 한번만 검사하므로 지정한
URL 이하 전체에 영향을 준다.)DocumentRoot
밖에 있는 디렉토리로 Alias를 만들었다면, 직접
대상 디렉토리의 접근을 허용해줘야 한다.예제:
Alias /image /ftp/pub/image
<Directory /ftp/pub/image>
Order allow,deny
Allow from all
</Directory>
AliasMatch 지시어
설명: 정규표현식을 사용하여 URL을 파일시스템 장소로
대응한다 문법: AliasMatch regex
file-path|directory-path사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_alias Alias와
같지만, 간단히 URL의 앞부분만 비교하는 대신 표준 정규표현식을
사용한다. 지정한 정규표현식을 URL 경로와 비교하여 맞다면,
서버는 괄호로 묶은 부분을 대체하여 파일명으로 사용한다.
예를 들어, 다음과 같이 /icons 디렉토리를 사용할
수 있다:
AliasMatch ^/icons(.*) /usr/local/apache/icons$1
Redirect 지시어
설명: 클라이언트가 다른 URL에 접속하도록 요청하는 외부
리다이렉션을 보낸다 문법: Redirect [status] URL-path
URL사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_alias 예제:
Redirect /service http://foo2.bar.com/service
주의
<Directory> 섹션에서 사용하더라도
URL-path에는 상대경로가 아니라 반드시 완전한 URL을
사용해야 한다.
send_error_response 함수 참고).예제:
Redirect permanent /one http://example.com/two
Redirect 303 /three http://example.com/other
RedirectMatch 지시어
설명: 현재 URL이 정규표현식에 해당하면 외부 리다이렉션을
보낸다 문법: RedirectMatch [status] regex
URL사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_alias Redirect와 같지만, 간단히
URL의 앞부분만 비교하는 대신 표준 정규표현식을 사용한다.
지정한 정규표현식을 URL 경로와 비교하여 맞다면, 서버는 괄호로
묶은 부분을 대체하여 파일명으로 사용한다. 예를 들어, 다음은
모든 GIF 파일 요청에 대해 다른 서버의 비슷한 이름을 가진
JPEG 파일로 리다이렉션을 보낸다:
RedirectMatch (.*)\.gif$ http://www.anotherserver.com$1.jpg
RedirectPermanent 지시어
설명: 클라이언트가 다른 URL에 접속하도록 요청하는 외부
영구 리다이렉션을 보낸다 문법: RedirectPermanent URL-path URL사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_alias Redirect permanent와 정확히 같다.RedirectTemp 지시어
설명: 클라이언트가 다른 URL에 접속하도록 요청하는 외부
임시 리다이렉션을 보낸다 문법: RedirectTemp URL-path URL사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_alias Redirect temp와 정확히 같다.ScriptAlias 지시어
설명: URL을 특정 파일시스템 장소로 대응하고 대상이 CGI
스크립트라고 알린다 문법: ScriptAlias URL-path
file-path|directory-path사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_alias ScriptAlias 지시어는 Alias 지시어와 비슷하지만,
추가로 대상 디렉토리에 mod_cgi의 cgi-script
핸들러가 처리할 CGI 스크립트가 있다고 알린다.
URL-path로 시작하는 (%로 인코딩된) URL을 파일시스템의
절대경로인 두번째 아규먼트로 시작하는 스크립트에 대응한다.예제:
ScriptAlias /cgi-bin/ /web/cgi-bin/
http://myserver/cgi-bin/foo를 요청하면 서버는
/web/cgi-bin/foo 스크립트를 실행한다.ScriptAliasMatch 지시어
설명: 정규표현식을 사용하여 URL을 특정 파일시스템 장소로
대응하고 대상이 CGI 스크립트라고 알린다 문법: ScriptAliasMatch regex
file-path|directory-path사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_alias ScriptAlias와 같지만, 간단히
URL의 앞부분만 비교하는 대신 표준 정규표현식을 사용한다.
지정한 정규표현식을 URL 경로와 비교하여 맞다면, 서버는 괄호로
묶은 부분을 대체하여 파일명으로 사용한다. 예를 들어, 다음과
같이 표준적인 /cgi-bin을 사용할 수 있다:
ScriptAliasMatch ^/cgi-bin(.*) /usr/local/apache/cgi-bin$1
mod/mod_auth.html 100644 0 0 30033 11074463123 11472 0 ustar 0 0
아파치 모듈 mod_asis
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: HTTP 헤더를 포함한 파일을 보낸다 상태: Base 모듈명: asis_module 소스파일: mod_asis.c 요약
send-as-is 핸들러를
제공한다.httpd/send-as-is인
파일도 처리했다.
사용법
send-as-is 핸들러를
예를 들어 다음과 같이 연결한다.AddHandler send-as-is asis.asis 확장자를 가진 파일의 내용을
거의 수정하지않고 클라이언트에게 보낸다. 클라이언트는 HTTP
헤더가 필요하므로 빼먹지마라. Status: 헤더도 필요하다. 이
헤더의 내용은 세자리 숫자인 HTTP 응답코드와 그 뒤의 문구이다.
Status: 301 Now where did I leave that URL
Location: http://xyz.abc.com/foo/bar.html
Content-type: text/html
<html>
<head>
<title>Lame excuses'R'us</title>
</head>
<body>
<h1>Fred's exceptionally wonderful page has moved to
<a href="http://xyz.abc.com/foo/bar.html">Joe's</a>
site.
</h1>
</body>
</html>
주의:
Date:와
Server: 헤더를 추가하므로, 파일에 이 헤더가
있으면 안된다. 서버는 Last-Modified 헤더를
추가하지 않는다. 그래서 아마도 이 헤더는 포함해야
한다.
mod/mod_auth_anon.html 100644 0 0 33522 11074463123 12513 0 ustar 0 0
Apache Module mod_auth
Description: User authentication using text files Status: Base Module쟅dentifier: auth_module Source쟂ile: mod_auth.c Compatibility: Available only in versions prior to 2.1 Summary
mod_auth_dbm. HTTP Digest
Authentication is provided by mod_auth_digest.AuthAuthoritative Directive
Description: Sets whether authorization and authentication are
passed to lower level modules Syntax: AuthAuthoritative On|OffDefault: AuthAuthoritative OnContext: directory, .htaccess Override: AuthConfig Status: Base Module: mod_auth AuthAuthoritative directive
explicitly to Off allows for both authentication and
authorization to be passed on to lower level modules (as defined in the
modules.c files) if there is no userID
or rule matching the supplied userID. If there is a
userID and/or rule specified; the usual password and access checks
will be applied and a failure will give an "Authentication Required"
reply.Require
directive applies to more than one module; then the first module
will verify the credentials; and no access is passed on;
regardless of the AuthAuthoritative setting.mod_auth_dbm,
mod_auth_msql, and mod_auth_anon.
These modules supply the bulk of the user credential checking; but
a few (administrator) related accesses fall through to a lower
level with a well protected AuthUserFile.Security
AuthUserFile and the AuthGroupFile are stored outside the document tree of
the web-server; do not put them in the directory that they
protect. Otherwise, clients will be able to download the AuthUserFile and the AuthGroupFile.AuthGroupFile Directive
Description: Sets the name of a text file containing the list
of user groups for authentication Syntax: AuthGroupFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Base Module: mod_auth AuthGroupFile directive sets the
name of a textual file containing the list of user groups for user
authentication. File-path is the path to the group
file. If it is not absolute, it is treated as relative to the ServerRoot.Example:
mygroup: bob joe anne
AuthDBMGroupFile provides a much better performance.Security
AuthGroupFile is
stored outside the document tree of the web-server; do not
put it in the directory that it protects. Otherwise, clients may
be able to download the AuthGroupFile.AuthUserFile Directive
Description: Sets the name of a text file containing the list of users and
passwords for authentication Syntax: AuthUserFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Base Module: mod_auth AuthUserFile directive sets the name
of a textual file containing the list of users and passwords for
user authentication. File-path is the path to the user
file. If it is not absolute (i.e., if it doesn't begin
with a slash), it is treated as relative to the ServerRoot.mod_auth will
use the first occurrence to verify the password.htpasswd
which is installed as part of the binary distribution, or which
can be found in src/support, is used to maintain
this password file. See the man
page for more details. In short:Filename with
username as the initial ID. It will prompt for the
password:
htpasswd -c Filename username
username2 in the password file
Filename:
htpasswd Filename username2
AuthDBMUserFile should be used
instead.Security
AuthUserFile is
stored outside the document tree of the web-server. Do
not put it in the directory that it protects.
Otherwise, clients may be able to download the
AuthUserFile.
mod/mod_auth_dbm.html 100644 0 0 32450 11074463123 12321 0 ustar 0 0
Apache Module mod_auth_anon
Description: Allows "anonymous" user access to authenticated
areas Status: Extension Module쟅dentifier: auth_anon_module Source쟂ile: mod_auth_anon.c Compatibility: Available only in versions prior to 2.1 Summary
Directives
Anonymous Anonymous_Authoritative Anonymous_LogEmail Anonymous_MustGiveEmail Anonymous_NoUserID Anonymous_VerifyEmailTopics
Example
Anonymous_NoUserID)Anonymous_MustGiveEmail)Anonymous_VerifyEmail)anonymous guest www test
welcome and comparison is not case
sensitive. (Anonymous)Anonymous_LogEmail)Excerpt of httpd.conf:
Anonymous_NoUserID off
Anonymous_MustGiveEmail on
Anonymous_VerifyEmail on
Anonymous_LogEmail on
Anonymous anonymous guest www test welcome
AuthName "Use 'anonymous' & Email address for guest entry"
AuthType basic
# An
AuthUserFile/AuthDBUserFile/AuthDBMUserFile
# directive must be specified, or use
# Anonymous_Authoritative for public access.
# In the .htaccess for the public directory, add:
<Files *>
Order Deny,Allow
Allow from all
Require valid-user
</Files>
Anonymous Directive
Description: Specifies userIDs that are allowed access without
password verification Syntax: Anonymous user [user] ...Context: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon
I strongly suggest that the magic username
'anonymous' is always one of the allowed
userIDs.Example:
Anonymous anonymous "Not Registered" "I don't know"
Anonymous_Authoritative Directive
Description: Configures if authorization will fall-through
to other methods Syntax: Anonymous_Authoritative On|OffDefault: Anonymous_Authoritative OffContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On, there is no fall-through to other
authentication methods. So if a userID does not match the values
specified in the Anonymous
directive, access is denied.Anonymous_LogEmail Directive
Description: Sets whether the password entered will be logged in the
error log Syntax: Anonymous_LogEmail On|OffDefault: Anonymous_LogEmail OnContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On, the default, the 'password' entered
(which hopefully contains a sensible email address) is logged in
the error log.Anonymous_MustGiveEmail Directive
Description: Specifies whether blank passwords are allowed Syntax: Anonymous_MustGiveEmail On|OffDefault: Anonymous_MustGiveEmail OnContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon Anonymous_NoUserID Directive
Description: Sets whether the userID field may be empty Syntax: Anonymous_NoUserID On|OffDefault: Anonymous_NoUserID OffContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On, users can leave the userID (and
perhaps the password field) empty. This can be very convenient for
MS-Explorer users who can just hit return or click directly on the
OK button; which seems a natural reaction.Anonymous_VerifyEmail Directive
Description: Sets whether to check the password field for a correctly
formatted email address Syntax: Anonymous_VerifyEmail On|OffDefault: Anonymous_VerifyEmail OffContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_anon On the 'password' entered is checked for
at least one '@' and a '.' to encourage users to enter valid email
addresses (see the above Anonymous_LogEmail).
mod/mod_auth_digest.html 100644 0 0 50456 11074463123 13044 0 ustar 0 0
Apache Module mod_auth_dbm
Description: Provides for user authentication using DBM
files Status: Extension Module쟅dentifier: auth_dbm_module Source쟂ile: mod_auth_dbm.c Compatibility: Available only in versions prior to 2.1 Summary
mod_auth.Directives
See also
AuthDBMAuthoritative Directive
Description: Sets whether authentication and authorization will be
passed on to lower level modules Syntax: AuthDBMAuthoritative On|OffDefault: AuthDBMAuthoritative OnContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm AuthDBMAuthoritative
directive explicitly to Off allows for both
authentication and authorization to be passed on to lower level
modules (as defined in the modules.c files) if there
is no userID or rule matching the
supplied userID. If there is a userID and/or rule specified; the
usual password and access checks will be applied and a failure will
give an "Authentication Required" reply.Require
directive applies to more than one module; then the first module
will verify the credentials; and no access is passed on;
regardless of the AuthDBMAuthoritative
setting.mod_auth. Whereas this
DBM module supplies the bulk of the user credential checking; a
few (administrator) related accesses fall through to a lower
level with a well protected .htpasswd file.Security:
.htaccess file; and verify that this
is really what you want; Generally it is easier to just secure
a single .htpasswd file, than it is to secure a
database which might have more access interfaces.AuthDBMGroupFile Directive
Description: Sets the name of the database file containing the list
of user groups for authentication Syntax: AuthDBMGroupFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm AuthDBMGroupFile directive sets the
name of a DBM file containing the list of user groups for user
authentication. File-path is the absolute path to the
group file.AuthDBMGroupFile is stored outside the
document tree of the web-server; do not put it in the
directory that it protects. Otherwise, clients will be able to
download the AuthDBMGroupFile unless
otherwise protected.
AuthDBMGroupFile /www/userbase
AuthDBMUserFile /www/userbase
Unix Crypt-ed Password:List of Groups[:(ignored)]
AuthDBMType Directive
Description: Sets the type of database file that is used to
store passwords Syntax: AuthDBMType default|SDBM|GDBM|NDBM|DBDefault: AuthDBMType defaultContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm Compatibility: Available in version 2.0.30 and later. AuthDBMUserFile Directive
Description: Sets thename of a database file containing the list of users and
passwords for authentication Syntax: AuthDBMUserFile file-pathContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_auth_dbm AuthDBMUserFile directive sets the
name of a DBM file containing the list of users and passwords for
user authentication. File-path is the absolute path to
the user file.Security:
AuthDBMUserFile is stored
outside the document tree of the web-server; do not put it in
the directory that it protects. Otherwise, clients will be able to
download the AuthDBMUserFile.dbmmanage is included with
Apache. This program can be used to create and update DBM
format password files for use with this module.
mod/mod_auth_ldap.html 100644 0 0 137753 11074463123 12533 0 ustar 0 0
아파치 모듈 mod_auth_digest
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: MD5 Digest Authentication을 사용한 사용자인증. 상태: Experimental 모듈명: auth_digest_module 소스파일: mod_auth_digest.c 요약
지시어들
AuthDigestAlgorithm AuthDigestDomain AuthDigestFile AuthDigestGroupFile AuthDigestNcCheck AuthDigestNonceFormat AuthDigestNonceLifetime AuthDigestQop AuthDigestShmemSize주제
참고
Digest Authentication 사용하기
AuthGroupFile을
AuthDigestGroupFile로
변경하고, AuthType Basic과 AuthUserFile 대신
AuthType Digest와 AuthDigestFile을
사용하여 간단히 인증을 설정할 수 있다. 그리고 최소한 보호하려는
영역의 기본 URI을 AuthDigestDomain 지시어에 사용한다.예제:
<Location /private/>
AuthType Digest
AuthName "private area"
AuthDigestDomain /private/ http://mirror.my.dom/private2/
AuthDigestFile /web/auth/.digest_pw
Require valid-user
</Location>
주의
MS Internet Explorer 문제 해결하기
GET 요청을 RFC와 다르게
처리하는 문제가 있다. 몇가지 방법으로 이 문제를 해결할 수
있다.GET
대신 POST 요청을 사용하는 방법이다. 이 방법이
가능하다면 가장 간단한 해결책이다.
AuthDigestEnableQueryStringHack
환경변수를 제공하여 문제를 해결한다. 요청에
AuthDigestEnableQueryStringHack을 설정하면
아파치는 MSIE 버그를 피해갈 조치를 취하고 요청 URI를 digest
비교에서 제외한다. 이 방법은 다음과 같이 사용한다.MSIE에서 Digest Authentication 사용하기:
BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On
BrowserMatch 지시어를
참고하라.AuthDigestAlgorithm 지시어
설명: digest authentication에서 challenge와 response
hash를 계산하는 알고리즘을 선택한다 문법: AuthDigestAlgorithm MD5|MD5-sess기본값: AuthDigestAlgorithm MD5사용장소: directory, .htaccess Override 옵션: AuthConfig 상태: Experimental 모듈: mod_auth_digest AuthDigestAlgorithm 지시어는
challenge와 response hash를 계산하는 알고리즘을 선택한다.
MD5-sess는 아직 완전히 구현되지 않았다.
AuthDigestDomain 지시어
설명: digest authentication에서 같은 보호영역에 속하는
URI들 문법: AuthDigestDomain URI [URI] ...사용장소: directory, .htaccess Override 옵션: AuthConfig 상태: Experimental 모듈: mod_auth_digest AuthDigestDomain 지시어는 같은
보호영역에 있는 (예를 들어 같은 영역과 사용자명/암호
정보를 사용하는) URI들을 지정한다. 지정한 URI는 접두사로
사용한다. 즉, 클라이언트는 URI "아래" 모두를
같은 사용자명/암호로 보호한다고 가정한다. URI는
(즉, 스킴(scheme), 호스트, 포트 등을 포함하는)
절대 URL이거나 상대 URI이다.AuthDigestNcCheck를
사용한다면 성능에 나쁜 영향을 줄 수 있다.AuthDigestFile 지시어
설명: digest authentication에 사용할 사용자명과 인코딩된
암호 목록을 저장한 문서파일 위치 문법: AuthDigestFile file-path사용장소: directory, .htaccess Override 옵션: AuthConfig 상태: Experimental 모듈: mod_auth_digest AuthDigestFile 지시어는 digest
authentication에 사용할 사용자명과 인코딩된 암호를 저장하는
문서파일명을 지정한다. File-path는 사용자정보
파일의 절대경로이다.support/ 하위디렉토리에 있는 htdigest 도구를 사용하여
이런 형식의 파일을 만들 수 있다.AuthDigestGroupFile 지시어
설명: digest authentication에 사용할 그룹 목록을 저장한
문서파일명 문법: AuthDigestGroupFile file-path사용장소: directory, .htaccess Override 옵션: AuthConfig 상태: Experimental 모듈: mod_auth_digest AuthDigestGroupFile 지시어는 그룹과
그룹의 구성원들(사용자명) 목록을 저장하는 문서파일명을 지정한다.
File-path는 그룹정보 파일의 절대경로이다.mygroup: bob joe anne보안:
AuthGroupFile을 웹서버 문서들 밖에
저장해야 한다. 그룹파일이 보호하는 디렉토리 안에 그룹파일을
두지 마라. 그렇지 않으면 클라이언트가
AuthGroupFile을 다운받을 수도 있다.AuthDigestNcCheck 지시어
설명: 서버가 보내는 nonce-count를 검사할지 여부 문법: AuthDigestNcCheck On|Off기본값: AuthDigestNcCheck Off사용장소: 주서버설정 상태: Experimental 모듈: mod_auth_digest
아직 구현되지 않았다.
AuthDigestNonceFormat 지시어
설명: nonce를 만드는 방법을 결정한다 문법: AuthDigestNonceFormat format사용장소: directory, .htaccess Override 옵션: AuthConfig 상태: Experimental 모듈: mod_auth_digest 아직 구현되지 않았다.
AuthDigestNonceLifetime 지시어
설명: 서버 nonce가 유효한 기간 문법: AuthDigestNonceLifetime seconds기본값: AuthDigestNonceLifetime 300사용장소: directory, .htaccess Override 옵션: AuthConfig 상태: Experimental 모듈: mod_auth_digest AuthDigestNonceLifetime 지시어는
서버 nonce가 유효한 기간을 조절한다. 클라이언트가 만기된
nonce를 가지고 서버에 접근하면 서버는 stale=true와
함께 401을 반환한다. seconds가 0보다 크면 nonce가
유효한 기간을 지정한다. 아마도 10 초보다 작게 설정하면 안된다.
seconds가 0보다 작으면 nonce는 영원히 만기되지
않는다.
AuthDigestQop 지시어
설명: digest authentication가 사용할
보호수준(quality-of-protection)을 지정한다. 문법: AuthDigestQop none|auth|auth-int [auth|auth-int]기본값: AuthDigestQop auth사용장소: directory, .htaccess Override 옵션: AuthConfig 상태: Experimental 모듈: mod_auth_digest AuthDigestQop 지시어는
보호수준(quality-of-protection)을 지정한다.
auth는 (사용자명/암호) 인증만 하고,
auth-int는 인증과 완결성 검사를 (MD5 해쉬도
계산하여 검사한다) 한다. none은 (완결성 검사를
하지않는) 오래된 RFC-2069 digest 알고리즘을 사용한다.
auth와 auth-int를 모두 지정할
수 있다. 이 경우 브라우저는 어떤 것을 사용할지 선택한다.
브라우저가 어던 이유에서건 challenge를 좋아하지 않는다면
none을 사용해야 한다.
auth-int는 아직 구현되지 않았다.
AuthDigestShmemSize 지시어
설명: 클라이언트를 추적하기위해 할당하는 공유메모리량 문법: AuthDigestShmemSize size기본값: AuthDigestShmemSize 1000사용장소: 주서버설정 상태: Experimental 모듈: mod_auth_digest AuthDigestShmemSize 지시어는
클라이언트를 추적하기위해 서버가 시작할때 할당하는
공유메모리량을 정의한다. 공유메모리는 최소한 하나의
클라이언트를 추적하기위해 필요한 공간보다 작을 수 없음을
주의하라. 이 값은 시스템에 따라 다르다. 정확한 값을 알려면
AuthDigestShmemSize를 0으로
설정하고 서버를 시작한후 오류문을 참고하라.K나 M을 사용하여 KBytes나 MBytes를
나타낼 수 있다. 예를 들어, 다음 지시어들은 모두 같다:
AuthDigestShmemSize 1048576
AuthDigestShmemSize 1024K
AuthDigestShmemSize 1M
mod/mod_autoindex.html 100644 0 0 125352 11074463123 12562 0 ustar 0 0
Apache Module mod_auth_ldap
Description: Allows an LDAP directory to be used to store the database
for HTTP Basic authentication. Status: Experimental Module쟅dentifier: auth_ldap_module Source쟂ile: mod_auth_ldap.c Compatibility: Available in version 2.0.41 and later Summary
mod_auth_ldap supports the following features:
Directives
AuthLDAPAuthoritative AuthLDAPBindDN AuthLDAPBindPassword AuthLDAPCharsetConfig AuthLDAPCompareDNOnServer AuthLDAPDereferenceAliases AuthLDAPEnabled AuthLDAPFrontPageHack AuthLDAPGroupAttribute AuthLDAPGroupAttributeIsDN AuthLDAPRemoteUserIsDN AuthLDAPUrlTopics
Contents Operation The Require Directives Examples Using TLS Using SSL Using Microsoft
FrontPage with mod_auth_ldapSee also
Operation
mod_auth_ldap
verifies that the user's credentials are valid. This also called
the search/bind phase. The second phase is
authorization, in which mod_auth_ldap determines
if the authenticated user is allowed access to the resource in
question. This is also known as the compare
phase.The Authentication
Phase
mod_auth_ldap
searches for an entry in the directory that matches the username
that the HTTP client passes. If a single unique match is found,
then mod_auth_ldap attempts to bind to the
directory server using the DN of the entry plus the password
provided by the HTTP client. Because it does a search, then a
bind, it is often referred to as the search/bind phase. Here are
the steps taken during the search/bind phase.
AuthLDAPURL directive with
the username passed by the HTTP client.
AuthLDAPURLSpecifies the LDAP server, the
base DN, the attribute to use in the search, as well as the
extra search filter to use.
AuthLDAPBindDNAn optional DN to bind with
during the search phase.
AuthLDAPBindPasswordAn optional password to bind
with during the search phase.
The Authorization
Phase
mod_auth_ldap
attempts to determine if the user is authorized to access the
resource. Many of these checks require
mod_auth_ldap to do a compare operation on the
LDAP server. This is why this phase is often referred to as the
compare phase. mod_auth_ldap accepts the
following Require
directives to determine if the credentials are acceptable:
Require
valid-user directive.Require user directive, and the
username in the directive matches the username passed by the
client.Require
dn directive, and the DN in the directive matches
the DN fetched from the LDAP directory.Require group directive, and
the DN fetched from the LDAP directory (or the username
passed by the client) occurs in the LDAP group.Require ldap-attribute
directive, and the attribute fetched from the LDAP directory
matches the given value.mod_auth_ldap uses the following directives during the
compare phase:
AuthLDAPURL The attribute specified in the
URL is used in compare operations for the
Require
user operation.
AuthLDAPCompareDNOnServerDetermines the behavior of the
Require dn directive.
AuthLDAPGroupAttributeDetermines the attribute to
use for comparisons in the
Require group
directive.
AuthLDAPGroupAttributeIsDNSpecifies whether to use the
user DN or the username when doing comparisons for the
Require group directive.
The Require Directives
Require
directives are used during the authorization phase to ensure that
a user is allowed to access a resource.Require
valid-user
mod_auth_ldap grants
access to any user that has successfully authenticated during the
search/bind phase.Require user
Require user directive specifies what
usernames can access the resource. Once
mod_auth_ldap has retrieved a unique DN from the
directory, it does an LDAP compare operation using the username
specified in the Require user to see if that username
is part of the just-fetched LDAP entry. Multiple users can be
granted access by putting multiple usernames on the line,
separated with spaces. If a username has a space in it, then it
must be surrounded with double quotes. Multiple users can also be
granted access by using multiple Require user
directives, with one user per line. For example, with a AuthLDAPURL of
ldap://ldap/o=Airius?cn (i.e., cn is
used for searches), the following Require directives could be used
to restrict access:
Require user "Barbara Jenson"
Require user "Fred User"
Require user "Joe Manager"
mod_auth_ldap handles this
directive, Barbara Jenson could sign on as Barbara
Jenson, Babs Jenson or any other cn that
she has in her LDAP entry. Only the single Require
user line is needed to support all values of the attribute
in the user's entry.uid attribute was used instead of the
cn attribute in the URL above, the above three lines
could be condensed toRequire user bjenson fuser jmanagerRequire group
dn: cn=Administrators, o=Airius
objectClass: groupOfUniqueNames
uniqueMember: cn=Barbara Jenson, o=Airius
uniqueMember: cn=Fred User, o=Airius
Require group cn=Administrators, o=AiriusAuthLDAPGroupAttribute and
AuthLDAPGroupAttributeIsDN
directives.Require dn
Require dn directive allows the administrator
to grant access based on distinguished names. It specifies a DN
that must match for access to be granted. If the distinguished
name that was retrieved from the directory server matches the
distinguished name in the Require dn, then
authorization is granted. Note: do not surround the distinguished
name with quotes.Require dn cn=Barbara Jenson, o=AiriusAuthLDAPCompareDNOnServer
directive.Require ldap-attribute
Require ldap-attribute directive allows the
administrator to grant access based on attributes of the authenticated
user in the LDAP directory. If the attribute in the directory
matches the value given in the configuration, access is granted.Require ldap-attribute employeeType=activeRequire ldap-attribute directives. The effect of listing
multiple attribute/values pairs is an OR operation. Access will be
granted if any of the listed attribute values match the value of a
corresponding attribute in the user object. If the value of the
attribute contains a space, only the value must be within double quotes.Require ldap-attribute city="San Jose" status=active
Examples
AuthLDAPURL ldap://ldap1.airius.com:389/ou=People, o=Airius?uid?sub?(objectClass=*)
Require valid-user
AuthLDAPURL ldap://ldap1.airius.com ldap2.airius.com/ou=People, o=Airius
Require valid-user
cn, because a search on cn
must return exactly one entry. That's why
this approach is not recommended: it's a better idea to
choose an attribute that is guaranteed unique in your
directory, such as uid.
AuthLDAPURL ldap://ldap.airius.com/ou=People, o=Airius?cn
Require valid-user
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid
Require group cn=Administrators, o=Airius
qpagePagerID. The example will grant access
only to people (authenticated via their UID) who have
alphanumeric pagers:
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(qpagePagerID=*)
Require valid-user
AuthLDAPURL ldap://ldap.airius.com/o=Airius?uid??(|(qpagePagerID=*)(uid=jmanager))
Require valid-user
fuser, the filter would look
like(&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))(&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))
Using TLS
mod_ldap directives LDAPTrustedCA and LDAPTrustedCAType.
Using SSL
mod_ldap directives LDAPTrustedCA and LDAPTrustedCAType.AuthLDAPURL
directive, instead of ldap://.
Using Microsoft
FrontPage with mod_auth_ldap
mod_auth module) to handle all
authentication. Unfortunately, it is not possible to just
change to LDAP authentication by adding the proper directives,
because it will break the Permissions forms in
the FrontPage client, which attempt to modify the standard
text-based authorization files..htaccess file
that gets created in the web
AuthLDAPURL "the url"
AuthLDAPAuthoritative off
AuthLDAPFrontPageHack on
AuthLDAPAuthoritative must be
off to allow mod_auth_ldap to decline group
authentication so that Apache will fall back to file
authentication for checking group membership. This allows the
FrontPage-managed group file to be used.How It Works
Require
valid-user directive to the .htaccess
files. If AuthLDAPFrontPageHack is not
on, the Require valid-user directive will succeed for
any user who is valid as far as LDAP is
concerned. This means that anybody who has an entry in
the LDAP directory is considered a valid user, whereas FrontPage
considers only those people in the local user file to be
valid. The purpose of the hack is to force Apache to consult the
local user file (which is managed by FrontPage) - instead of LDAP
- when handling the Require valid-user directive.Caveats
mod_auth user file.
The user ID is ideal for this.mod_auth in order to
use FrontPage support. This is because Apache will still use
the mod_auth group file for determine the extent of a
user's access to the FrontPage web..htaccess
files. Attempting to put them inside <Location> or <Directory> directives won't work. This
is because mod_auth_ldap has to be able to grab
the AuthUserFile
directive that is found in FrontPage .htaccess
files so that it knows where to look for the valid user list. If
the mod_auth_ldap directives aren't in the same
.htaccess file as the FrontPage directives, then
the hack won't work, because mod_auth_ldap will
never get a chance to process the .htaccess file,
and won't be able to find the FrontPage-managed user file.AuthLDAPAuthoritative Directive
Description: Prevent other authentication modules from
authenticating the user if this one fails Syntax: AuthLDAPAuthoritative on|offDefault: AuthLDAPAuthoritative onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap off if this module should let other
authentication modules attempt to authenticate the user, should
authentication with this module fail. Control is only passed on
to lower modules if there is no DN or rule that matches the
supplied user name (as passed by the client).AuthLDAPBindDN Directive
Description: Optional DN to use in binding to the LDAP server Syntax: AuthLDAPBindDN distinguished-nameContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap will use
an anonymous bind.AuthLDAPBindPassword Directive
Description: Password used in conjuction with the bind DN Syntax: AuthLDAPBindPassword passwordContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap AuthLDAPBindDN and AuthLDAPBindPassword if you
absolutely need them to search the directory.AuthLDAPCharsetConfig Directive
Description: Language to charset conversion configuration file Syntax: AuthLDAPCharsetConfig file-pathContext: server config Status: Experimental Module: mod_auth_ldap AuthLDAPCharsetConfig directive sets the location
of the language to charset conversion configuration file. File-path is relative
to the ServerRoot. This file specifies
the list of language extensions to character sets.
Most administrators use the provided charset.conv
file, which associates common language extensions to character sets.
Language-Extension charset [Language-String] ...
#) are ignored.AuthLDAPCompareDNOnServer Directive
Description: Use the LDAP server to compare the DNs Syntax: AuthLDAPCompareDNOnServer on|offDefault: AuthLDAPCompareDNOnServer onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap will use the LDAP
server to compare the DNs. This is the only foolproof way to
compare DNs. mod_auth_ldap will search the
directory for the DN specified with the Require dn directive, then,
retrieve the DN and compare it with the DN retrieved from the user
entry. If this directive is not set,
mod_auth_ldap simply does a string comparison. It
is possible to get false negatives with this approach, but it is
much faster. Note the mod_ldap cache can speed up
DN comparison in most situations.AuthLDAPDereferenceAliases Directive
Description: When will the module de-reference aliases Syntax: AuthLDAPDereferenceAliases never|searching|finding|alwaysDefault: AuthLDAPDereferenceAliases AlwaysContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap will
de-reference aliases during LDAP operations. The default is
always.AuthLDAPEnabled Directive
Description: Turn on or off LDAP authentication Syntax: AuthLDAPEnabled on|offDefault: AuthLDAPEnabled onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap off to disable
mod_auth_ldap in certain directories. This is
useful if you have mod_auth_ldap enabled at or
near the top of your tree, but want to disable it completely in
certain locations.AuthLDAPFrontPageHack Directive
Description: Allow LDAP authentication to work with MS FrontPage Syntax: AuthLDAPFrontPageHack on|offDefault: AuthLDAPFrontPageHack offContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap.AuthLDAPGroupAttribute Directive
Description: LDAP attributes used to check for group membership Syntax: AuthLDAPGroupAttribute attributeContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap mod_auth_ldap uses the member and
uniquemember attributes.AuthLDAPGroupAttributeIsDN Directive
Description: Use the DN of the client username when checking for
group membership Syntax: AuthLDAPGroupAttributeIsDN on|offDefault: AuthLDAPGroupAttributeIsDN onContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap on, this directive says to use the
distinguished name of the client username when checking for group
membership. Otherwise, the username will be used. For example,
assume that the client sent the username bjenson,
which corresponds to the LDAP DN cn=Babs Jenson,
o=Airius. If this directive is set,
mod_auth_ldap will check if the group has
cn=Babs Jenson, o=Airius as a member. If this
directive is not set, then mod_auth_ldap will
check if the group has bjenson as a member.AuthLDAPRemoteUserIsDN Directive
Description: Use the DN of the client username to set the REMOTE_USER
environment variable Syntax: AuthLDAPRemoteUserIsDN on|offDefault: AuthLDAPRemoteUserIsDN offContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap REMOTE_USER environment variable will be set to the full
distinguished name of the authenticated user, rather than just
the username that was passed by the client. It is turned off by
default.AuthLDAPUrl Directive
Description: URL specifying the LDAP search parameters Syntax: AuthLDAPUrl urlContext: directory, .htaccess Override: AuthConfig Status: Experimental Module: mod_auth_ldap ldap://host:port/basedn?attribute?scope?filter
ldap. For secure LDAP, use ldaps
instead. Secure LDAP is only available if Apache was linked
to an LDAP library with SSL support.localhost:389 for ldap, and
localhost:636 for ldaps). To
specify multiple, redundant LDAP servers, just list all
servers, separated by spaces. mod_auth_ldap
will try connecting to each server in turn, until it makes a
successful connection.httpd process, or until the LDAP server goes
down.mod_auth_ldap will attempt to
re-connect, starting with the primary server, and trying
each redundant server in turn. Note that this is different
than a true round-robin search.uid. It's a good
idea to choose an attribute that will be unique across all
entries in the subtree you will be using.one or
sub. Note that a scope of base is
also supported by RFC 2255, but is not supported by this
module. If the scope is not provided, or if base scope
is specified, the default is to use a scope of
sub.(objectClass=*), which
will search for all objects in the tree. Filters are
limited to approximately 8000 characters (the definition of
MAX_STRING_LEN in the Apache source code). This
should be than sufficient for any application.(&(filter)(attribute=username)).ldap://ldap.airius.com/o=Airius?cn?sub?(posixid=*). When
a client attempts to connect using a username of Babs
Jenson, the resulting search filter will be
(&(posixid=*)(cn=Babs Jenson)).AuthLDAPURL URLs.
mod/mod_cache.html 100644 0 0 51115 11074463123 11600 0 ustar 0 0
아파치 모듈 mod_autoindex
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 자동으로 유닉스의 ls 명령어나 Win32의
dir 쉘명령어와 유사한 디렉토리 목록을 만든다상태: Base 모듈명: autoindex_module 소스파일: mod_autoindex.c 요약
index.html이란 이름으로 사용자가
작성한 파일. 이 파일의 이름은 DirectoryIndex 지시어로
지정한다. 이 작업은 mod_dir이 한다.AddIcon, AddIconByEncoding,
AddIconByType은
여러 파일종류마다 보여줄 아이콘들을 지정한다. 각 파일에
대응하는 첫번째 아이콘을 보인다. 이 작업을
mod_autoindex가 한다.Options +Indexes로 가능하다.
자세한 내용은 Options
지시어를 참고하라.IndexOptions
지시어에 FancyIndexing 옵션을 주면, 열 이름을 출력할
순서를 바꾸는 링크로 만든다. 이름 링크를 선택하면 그 열의
값 순서로 목록을 다시 만든다. 같은 이름을 반복해서 선택하면
오름차순과 내림차순 사이를 오간다. IndexOptions 지시어의
SuppressColumnSorting 옵션은 이런 열 이름 링크를
만들지 않는다.지시어들
AddAlt AddAltByEncoding AddAltByType AddDescription AddIcon AddIconByEncoding AddIconByType DefaultIcon HeaderName IndexIgnore IndexOptions IndexOrderDefault ReadmeName주제
Autoindex 요청 아규먼트
IndexOptions
IgnoreClient 옵션이 추가되었다.
C=N은 파일명 순이다C=M은 최근 수정일 순, 그리고 파일명 순이다C=S는 크기 순, 그리고 파일명 순이다C=D는 설명 순, 그리고 파일명
순이다O=A는 오름차순으로 목록을 정렬한다O=D는 내림차순으로 목록을 정렬한다F=0은 (FancyIndexed가 아닌) 간단한 목록 형식이다F=1은 FancyIndexed 목록 형식이다F=2는 HTMLTable FancyIndexed 목록
형식이다V=0은 버전 순으로 정렬하지 않는다V=1은 버전 순으로 정렬한다P=pattern은 주어진 pattern에
해당하는 파일만을 목록으로 만든다IndexIgnore 지시어를 처리한 후에
검사하기때문에, 목록은 다른 autoindex 조건을 따름을 주의하라.
mod_autoindex의 요청 아규먼트를 읽어들일때
알 수 없는 옵션을 발견하면 더 이상 읽지않는다. 요청 아규먼트는
위의 표에 따라 만들어야 한다.
<form action="" method="get">
Show me a <select name="F">
<option value="0"> Plain list</option>
<option value="1" selected="selected"> Fancy list</option>
<option value="2"> Table list</option>
</select>
Sorted by <select name="C">
<option value="N" selected="selected"> Name</option>
<option value="M"> Date Modified</option>
<option value="S"> Size</option>
<option value="D"> Description</option>
</select>
<select name="O">
<option value="A" selected="selected"> Ascending</option>
<option value="D"> Descending</option>
</select>
<select name="V">
<option value="0" selected="selected"> in Normal order</option>
<option value="1"> in Version order</option>
</select>
Matching <input type="text" name="P" value="*" />
<input type="submit" name="X" value="Go" />
</form>
AddAlt 지시어
설명: 파일명으로 선택한 아이콘대신 사용할 파일 설명글 문법: AddAlt string file [file] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex AddAlt는 FancyIndexing에서
파일에 대한 아이콘대신 보일 글을 지정한다. File에는
설명할 파일의 파일 확장자, 파일명 일부, 와일드카드 표현,
전체 파일명을 사용할 수 있다. String에 공백이
들어간다면 따옴표(" 혹은 ')로
묶어야 한다. 클라이언트가 이미지를 볼 수 없거나, 이미지를
읽지않거나, 아이콘을 못 얻은 경우 이 추가 글이 보이게 된다.예제
AddAlt "PDF file" *.pdf
AddAlt Compressed *.gz *.zip *.Z
AddAltByEncoding 지시어
설명: MIME-encoding으로 선택한 아이콘대신 사용할 파일
설명글 문법: AddAltByEncoding string MIME-encoding
[MIME-encoding] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex AddAltByEncoding은 FancyIndexing에서
파일에 대한 아이콘대신 보일 글을 지정한다. MIME-encoding은
x-compress와 같은 유효한 content-encoding이다.
String에 공백이 들어간다면 따옴표("
혹은 ')로 묶어야 한다. 클라이언트가 이미지를
볼 수 없거나, 이미지를 읽지않거나, 아이콘을 못 얻은 경우
이 추가 글이 보이게 된다.예제
AddAltByEncoding gzip x-gzip
AddAltByType 지시어
설명: MIME content-type으로 선택한 아이콘대신 사용할 파일
설명글 문법: AddAltByType string MIME-type
[MIME-type] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex AddAltByType은 FancyIndexing에서
파일에 대한 아이콘대신 보일 글을 지정한다. MIME-type은
text/html과 같은 유효한 content-type이다.
String에 공백이 들어간다면 따옴표("
혹은 ')로 묶어야 한다. 클라이언트가 이미지를
볼 수 없거나, 이미지를 읽지않거나, 아이콘을 못 얻은 경우
이 추가 글이 보이게 된다.예제
AddAltByType 'plain text' text/plain
AddDescription 지시어
설명: 파일에 대한 설명 문법: AddDescription string file [file] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex FancyIndexing에서 파일에 대한 설명을 지정한다.
File에는 설명할 파일의 파일 확장자, 파일명 일부,
와일드카드 표현, 전체 파일명을 사용할 수 있다. String은
따옴표(")로 묶어야 한다.예제
AddDescription "The planet Mars" /web/pics/mars.gif
IndexOptions
SuppressIcon 옵션을 사용하면 기본폭에 6 바이트를
더 추가하고, IndexOptions SuppressSize 옵션은 7 바이트를,
IndexOptions SuppressLastModified 옵션은 19
바이트를 더 추가한다. 그러므로 가장 넓은 설명폭은 55 바이트다.IndexOptions 키워드를 참고하라.조심
AddDescription으로 지정한 설명글에
태그나 character entity(역주; <, & 등을
지칭)같은 HTML을 사용할 수 있다. 그러나 폭때문에
태그가 있는 부분이 짤리게되면 (예를 들어 굵은체 부분 끝이
짤리면) 나머지 디렉토리 목록에 영향을 줄 수 있다.AddIcon 지시어
설명: 이름으로 선택한 파일에 사용할 아이콘 문법: AddIcon icon name [name]
...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex FancyIndexing에서 name으로 끝나는
파일 옆에 보여줄 아이콘을 지정한다. Icon은
아이콘의 (%-escaped) 상대 URL 혹은
(alttext,url) 형식이다.
여기서 alttext는 그림을 보여줄 수 없는 브라우저가
아이콘대신 사용할 문구이다.^^DIRECTORY^^,
(목록 형식을 올바로 맞추기위해) 빈줄을 나타내는
^^BLANKICON^^, 파일 확장자, 와일드카드 표현,
파일명 일부 혹은 전체를 사용할 수 있다.예제
AddIcon (IMG,/icons/image.xbm) .gif .jpg .xbm
AddIcon /icons/dir.xbm ^^DIRECTORY^^
AddIcon /icons/backup.xbm *~
AddIcon보다는 AddIconByType을 사용해야 한다.AddIconByEncoding 지시어
설명: MIME content-encoding으로 선택한 파일에 사용할 아이콘 문법: AddIconByEncoding icon MIME-encoding
[MIME-encoding] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex FancyIndexing에서
파일 옆에 보여줄 아이콘을 지정한다. Icon은
아이콘의 (%-escaped) 상대 URL 혹은
(alttext,url) 형식이다.
여기서 alttext는 그림을 보여줄 수 없는 브라우저가
아이콘대신 사용할 문구이다.예제
AddIconByEncoding /icons/compress.xbm x-compress
AddIconByType 지시어
설명: MIME content-type으로 선택한 파일에 사용할 아이콘 문법: AddIconByType icon MIME-type
[MIME-type] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex FancyIndexing에서
MIME-type의 파일 옆에 보여줄 아이콘을 지정한다.
Icon은 아이콘의 (%-escaped) 상대 URL 혹은
(alttext,url) 형식이다.
여기서 alttext는 그림을 보여줄 수 없는 브라우저가
아이콘대신 사용할 문구이다.예제
AddIconByType (IMG,/icons/image.xbm) image/*
DefaultIcon 지시어
설명: 특정 아이콘을 설정하지않은 파일에 사용할 아이콘 문법: DefaultIcon url-path사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex DefaultIcon 지시어는 FancyIndexing에서
특정 아이콘을 설정하지않은 파일 옆에 나올 아이콘이다.
Icon은 아이콘의 (%-escaped) 상대 URL이다.예제
DefaultIcon /icon/unknown.xbm
HeaderName 지시어
설명: 파일목록 위에 삽입할 파일의 이름 문법: HeaderName filename사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex HeaderName 지시어는 파일목록 앞에
삽입할 파일의 이름을 지정한다. Filename은 삽입할
파일명이다.예제
HeaderName HEADER.html
ReadmeName 둘 모두
Filename을 접근하려는 디렉토리의 상대 URI 경로로
받아들인다. Filename이 슬래쉬로 시작하면 DocumentRoot에 상대적인 경로로
받아들인다.예제
HeaderName /include/HEADER.html
text/*인
(예를 들어, text/html, text/plain,
등) 문서를 사용해야 한다. 즉, 스크립트의 (출력이 아닌) 실제 파일
type을 다음과 같이 text/html로 지정한다면
filename으로 CGI 스크립트를 지정할 수도 있다:
AddType text/html .cgi
Options
MultiViews을 사용하면 내용협상을 한다.
filename이 (CGI 스크립트가 아닌) 고정된
text/html 문서이고 options Includes나
IncludesNOEXEC 중 하나를 사용한다면 파일을
server-side includes로 처리한다. (mod_include
문서 참고)HeaderName으로 지정한 파일에
(<html>, <head>, 등) HTML 문서 시작부분이 포함되있다면
IndexOptions
+SuppressHTMLPreamble을 사용하여 이 부분을 추가하지않는
것이 좋다.IndexIgnore 지시어
설명: 디렉토리 목록에서 숨길 파일목록을 추가한다 문법: IndexIgnore file [file] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex IndexIgnore 지시어는 디렉토리
목록에서 감출 파일목록을 추가한다. File에는 감출
(쉘에서 사용하는) 화일드카드 표현이나 전체 파일명을
사용할 수 있다. 여러 IndexIgnore 지시어를 사용하면 기존의
감출 파일목록을 대체하지않고 목록에 지정한 파일들을 추가한다.
기본적으로 목록은 .을 (현재 디렉토리) 포함한다.
IndexIgnore README .htaccess *.bak *~
IndexOptions 지시어
설명: 디렉토리 목록의 여러 설정들 문법: IndexOptions [+|-]option [[+|-]option]
...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex IndexOptions 지시어는 디렉토리
목록을 설정한다. Option은 다음 중 하나이다
DescriptionWidth 키워드를 사용하여 문자단위로
설명열의 폭을 지정할 수 있다.-DescriptionWidth를 지정하면 (혹은 아무것도
지정하지않으면) mod_autoindex가 최적의
폭을 계산한다.DescriptionWidth=n은 열의
폭을 n 바이트로 고정한다.DescriptionWidth=*은 열의 폭을 가장 긴
설명글을 담을 수 있는만큼 늘린다.AddDescription
절을 참고하라.FoldersFirst를
사용한다면 하위디렉토리 Zed가 하위디렉토리
Beta 앞에 나오고, 하위디렉토리 Beta는
일반 파일 Gamma와 Alpha 앞에
나온다. 이 옵션은 FancyIndexing을 함께 사용할때만 효과가
있다.img 태그에 height와 width
속성을 포함한다. 그러면 브라우저는 모든 이미지를 받지않은
상황에서도 페이지 구성을 미리 계산할 수 있다. 옵션에 값을
주지않으면 아파치가 제공하는 아이콘의 표준 높이를 사용한다.IconHeight와 같이 사용하면
서버는 파일 아이콘의 img 태그에
height와 width 속성을 포함한다.
그러면 브라우저는 모든 이미지를 박지않은 상황에서도 페이지
구성을 미리 계산할 수 있다. 옵션에 값을 주지않으면 아파치가
제공하는 아이콘의 표준 폭을 사용한다.mod_autoindex는
순서를 포함하여 클라이언트가 보내는 모든 질의변수를 무시한다.
(SuppressColumnSorting을 가정한다.)NameWidth 키워드는 바이트단위로 파일명
열의 폭을 지정한다.-NameWidth을 지정하면 (혹은 아무것도
지정하지않으면) mod_autoindex가 최적의
폭을 계산한다.NameWidth=n는 열의 폭을 n
바이트로 고정한다.NameWidth=*은 열의 폭을 필요한만큼 늘린다.AddDescription로
지정한 설명이 없다면 웹서버는 문서의 title
요소값을 읽어들인다. 이 작업은 CPU와 디스크를 많이 사용한다.AddDescription을 참고하라. 설명열의 크기를
지정하는 DescriptionWidth
옵션도 참고하라.HeaderName 지시어로
지정한 파일이 있는 경우 모듈은 보통 표준 HTML 시작부분
(<html>, <head>,
et cetera) 뒤에 파일 내용을 첨가한다. 그러나
SuppressHTMLPreamble 옵션을 사용하면 처음부터
header 파일 내용을 포함한다. 이 경우 header 파일에는 적절한
HTML 명령이 있어야 한다. header 파일이 없다면 일반적인
시작부분이 만들어진다.SuppressIcon과
SuppressRules를 같이 사용하면, (FancyIndexed
목록이 사용한) pre 안에 img와
hr 요소 사용을 금지한 마지막 표준인 HTML 3.2에
알맞은 출력이 된다.hr 요소)
사용하지 않는다. SuppressIcon과
SuppressRules를 같이 사용하면, (FancyIndexed
목록이 사용한) pre 안에 img와
hr 요소 사용을 금지한 마지막 표준인 HTML 3.2에
알맞은 출력이 된다.HEAD 요청을 사용하여 파일목록의 변화를 추적할
수 있다. 어떤 운영체제는 새로운 파일과 삭제한 파일을 올바로
추적하지만, 디렉토리에 있는 파일의 크기나 날짜 변화를
추적하지 못함을 주의하라. 모든 유닉스 플래폼에서
기존 파일의 크기나 날짜 변화시 Last-Modified 헤더가
바뀌지않는다. 이런 변화가 중요하다면 이 옵션을
사용하지 마라.VersionSort 키워드는 버전 번호를 포함한
파일명을 자연스럽게 정렬한다. 문자 부분은 정상적인 순서를
정렬하지만, 파일과 설명에 있는 숫자 부분은 숫자값으로
비교한다.
예제:
foo-1.7
foo-1.7.2
foo-1.7.12
foo-1.8.2
foo-1.8.2a
foo-1.12
foo-1.001
foo-1.002
foo-1.030
foo-1.04
XHTML 키워드를 사용하면
mod_autoindex는 HTML 3.2 대신 XHTML 1.0
코드를 생성한다.IndexOptions
지시어 처리방식이 크게 변화되었다. 특별히:
IndexOptions 지시어들을 서로 결합한다.
다음의 결과는:
<Directory /foo>
IndexOptions HTMLTable
IndexOptions SuppressColumnsorting
</Directory>
IndexOptions HTMLTable SuppressColumnsorting
+나
-를 붙이는) 점진적인 문법이 추가되었다.IndexOptions
설정에 반영된다. 그러나 앞에 아무것도 없는 키워드를 만나면
아직까지 상속되거나 점진적으로 변경된 설정을 모두 지운다.
다음 예제를 살펴보자:
IndexOptions +ScanHTMLTitles -IconsAreLinks FancyIndexing
IndexOptions +SuppressSize
FancyIndexing이 이전의
점진적인 설정을 지워버렸지만 설정이 다시 추가되여 결과는
IndexOptions FancyIndexing +SuppressSize와 같다.IndexOptions를 설정하려면 키워드
앞에 +나 -를 사용하지말고
상속된 설정을 지운다.IndexOrderDefault 지시어
설명: 디렉토리 목록의 기본 순서를 설정한다 문법: IndexOrderDefault Ascending|Descending
Name|Date|Size|Description기본값: IndexOrderDefault Ascending Name사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex IndexOrderDefault 지시어는 FancyIndexing
목록 옵션과 함께 사용한다. 기본적으로 fancyindexed 디렉토리
목록은 파일명 오름차순이다. IndexOrderDefault는
이 초기 순서를 변경할 수 있다.IndexOrderDefault는 두 아규먼트를
받는다. 첫번째는 순서의 방향을 지시하는 Ascending
(오른차순) 이나 Descending (내림차순) 중 하나다.
두번째 아규먼트는 일차 순서를 나타내는 키워드 Name,
Date, Size, Description
중 하나다. 이차 순서는 항상 파일명 오름차순이다.SuppressColumnSorting 목록 옵션을 같이 사용하면
특정 순서로만 디렉토리 목록을 만든다. 이 경우 클라이언트는
다른 순서로 디렉토리 목록을 요청하지 못한다.ReadmeName 지시어
설명: 파일목록 마지막에 삽입할 파일의 이름 문법: ReadmeName filename사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_autoindex ReadmeName 지시어는 파일목록 끝에
삽입할 파일의 이름을 지정한다. Filename은 포함할
파일명이고, 목록을 만들려는 위치의 상대경로로 받아들인다.
Filename이 슬래쉬로 시작하면 DocumentRoot에 상대경로로 받아들인다.
예제
ReadmeName FOOTER.html
예제 2
ReadmeName /include/FOOTER.html
HeaderName도 참고하라.
mod/mod_cern_meta.html 100644 0 0 15552 11074463123 12477 0 ustar 0 0
아파치 모듈 mod_cache
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: Content cache keyed to URIs. 상태: Experimental 모듈명: cache_module 소스파일: mod_cache.c 요약
이 모듈은 실험적인 상태이다. 문서는 아직 작업중이다...
mod_cache는 같은 컴퓨터에 있는 내용이나
프록시된 내용을 캐쉬할 수 있는 RFC 2616
호환 HTTP 내용캐쉬를 구현한다. mod_cache를
사용하려면 저장관리모듈(storage management module)이 필요하다.
기본 아파치 배포본에는 두가지 저장관리모듈이 있다:
mod_disk_cachemod_mem_cachemod_mem_cache는 파일기술자를 캐쉬하거나
힙(heap) 공간에 객체를 캐쉬하는 두가지 방식중 한가지 방법으로
동작하도록 설정할 수 있다. mod_mem_cache는
자신이 생성한 내용을 캐쉬하거나, (역프록시(reverse proxy)로
알려진) ProxyPass를
사용하여 mod_proxy를 위해 뒷단 서버내용을
캐쉬할 수 있다.지시어들
CacheDefaultExpire CacheDisable CacheEnable CacheForceCompletion CacheIgnoreCacheControl CacheIgnoreNoLastMod CacheLastModifiedFactor CacheMaxExpire주제
관련된 모듈과 지시어
관련된 모듈 관련된 지시어
설정예
Sample httpd.conf
#
# 예제 캐쉬 설정
#
LoadModule cache_module modules/mod_cache.so
<IfModule mod_cache.c>
#LoadModule disk_cache_module modules/mod_disk_cache.so
<IfModule mod_disk_cache.c>
CacheRoot c:/cacheroot
CacheSize 256
CacheEnable disk /
CacheDirLevels 5
CacheDirLength 3
</IfModule>
LoadModule mem_cache_module modules/mod_mem_cache.so
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 4096
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 2048
</IfModule>
</IfModule>
CacheDefaultExpire 지시어
설명: 만기시간을 지정하지않은 문서를 캐쉬할 기본 기간. 문법: CacheDefaultExpire seconds기본값: CacheDefaultExpire 3600 (one hour)사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_cache CacheDefaultExpire 지시어는 문서의
만기시간과 최근수정시간이 없는 경우 문서를 캐쉬할 초단위
기본 시간을 지정한다. CacheMaxExpire로
지정한 값이 이 설정을 무시하지 않는다.
CacheDefaultExpire 86400
CacheDisable 지시어
설명: 특정 URL을 캐쉬하지 않는다 문법: CacheDisable url-string사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_cache CacheDisable 지시어를 사용하면
mod_cache가 url-string 이하의
url들을 캐쉬하지 않는다.예제
CacheDisable /local_files
CacheEnable 지시어
설명: 지정한 저장관리자를 사용하여 지정한 URL을 캐쉬한다 문법: CacheEnable cache_type url-string사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_cache CacheEnable 지시어를 사용하면
mod_cache가 url-string 이하
url들을 캐쉬한다. 캐쉬 저장관리자는 cache_type
아규먼트로 지정한다. cache_type mem은
mod_mem_cache가 구현하는 메모리기반
저장관리자를 사용한다. cache_type disk는
mod_disk_cache가 구현하는 디스크기반
저장관리자를 사용한다. cache_type fd는
mod_mem_cache가 구현하는 파일기술자 캐쉬를
사용한다.CacheEnable 지시어와 겹치면 실제로
한 저장관리자가 요청을 처리할때까지 두 저장관리자를 모두
실행한다. 설정파일에서 CacheEnable
지시어의 순서대로 저장관리자가 실행된다.
CacheEnable mem /manual
CacheEnable fd /images
CacheEnable disk /
CacheForceCompletion 지시어
설명: 요청이 취소되더라도 서버가 파일을 계속 캐쉬하기위해
필요한 문서의 서비스률. 문법: CacheForceCompletion Percentage기본값: CacheForceCompletion 60사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_cache CacheForceCompletion 지시어는 요청이
취소되더라도 문서를 계속 캐쉬할 정도를 지정한다.1과 100
사이의 값이다. 0 값을 지정하면 기본값을 사용한다.
100은 내용을 모두 서비스한 문서만을 캐쉬한다.
60과 90 사이의 값을 추천한다.
CacheForceCompletion 80
주의:
이 기능은 현재 구현되지 않았다.
CacheIgnoreCacheControl 지시어
설명: 클라이언트가 캐쉬하지않는 내용을 요청함을 무시한다. 문법: CacheIgnoreCacheControl On|Off기본값: CacheIgnoreCacheControl Off사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_cache CacheIgnoreCacheControl
지시어는 이런 행동을 변경한다.
CacheIgnoreCacheControl On을 사용하면
서버는 문서에 no-cache나 no-store 헤더값이 있어도 문서를
캐쉬한다. 인증이 필요한 문서는 절대로 캐쉬하지
않는다.
CacheIgnoreCacheControl On
CacheIgnoreNoLastMod 지시어
설명: 응답에 Last Modified 헤더가 없다는 사실을 무시한다. 문법: CacheIgnoreNoLastMod On|Off기본값: CacheIgnoreNoLastMod Off사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_cache mod_include 처리중에)
빼거나 처음부터 없었을 수가 있다.
CacheIgnoreNoLastMod 지시어는 최근수정일이
없는 문서도 반드시 캐쉬하도록 만든다. 문서에 최근수정일과
만기시간이 없는 경우 CacheDefaultExpire
지시어로 지정한 값을 만기시간으로 사용한다.
CacheIgnoreNoLastMod On
CacheLastModifiedFactor 지시어
설명: LastModified 시간으로 만기시간을 계산하는데 사용하는
계수. 문법: CacheLastModifiedFactor float기본값: CacheLastModifiedFactor 0.1사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_cache CacheLastModifiedFactor 지시어는
만기시간을 계산하는 다음 공식에서 사용할 factor를
지정한다:
expiry-period = time-since-last-modified-date * factor
expiry-date = current-date + expiry-period
예를 들어, 문서가 10 시간 전에 마지막으로 수정되었고 factor가
0.1이라면 만기기간은 10*01 = 1 시간이 된다. 현재 시간이
3:00pm이라면 만기시간은 3:00pm + 1시간 = 4:00pm이다.
만기기간이 CacheMaxExpire 보다 길다면
CacheMaxExpire를 사용한다.
CacheLastModifiedFactor 0.5
mod/mod_cgi.html 100644 0 0 30753 11074463123 11304 0 ustar 0 0
아파치 모듈 mod_cern_meta
설명: CERN 웹서버 메타파일 지원 상태: Extension 모듈명: cern_meta_module 소스파일: mod_cern_meta.c 요약
MetaDir 지시어
설명: CERN 메타정보를 찾을 디렉토리 이름 문법: MetaDir directory기본값: MetaDir .web사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Extension 모듈: mod_cern_meta ."으로 지정하면 같은 디렉토리에서
파일을 찾는다:MetaDir .MetaDir .metaMetaFiles 지시어
설명: CERN 메타파일을 처리한다 문법: MetaFiles on|off기본값: MetaFiles off사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Extension 모듈: mod_cern_meta MetaSuffix 지시어
설명: CERN 메타정보를 저장하는 파일의 접미사 문법: MetaSuffix suffix기본값: MetaSuffix .meta사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Extension 모듈: mod_cern_meta DOCUMENT_ROOT/somedir/index.html을 요청하면
DOCUMENT_ROOT/somedir/.web/index.html.meta의
내용을 참고하여 MIME 헤더 정보를 추가한다.예제:
MetaSuffix .meta
mod/mod_cgid.html 100644 0 0 12662 11074463123 11447 0 ustar 0 0
아파치 모듈 mod_cgi
설명: CGI 스크립트 실행 상태: Base 모듈명: cgi_module 소스파일: mod_cgi.c 요약
application/x-httpd-cgi이거나
(아파치 1.1 이후) 핸들러가 cgi-script인 모든
파일을 CGI 스크립트로 인식하여, 실행하고, 그 결과를 클라이언트에게
보낸다. 파일이 AddType
지시어로 지정한 확장자를 가지거나, ScriptAlias 디렉토리 안에
있으면 CGI로 처리된다.DOCUMENT_ROOT라는
환경변수를 추가한다. 이 변수는 DocumentRoot 설정값을 가진다.mod_cgid 모듈을 사용해야 한다. 사용자
입장에서 이 두 모듈은 기본적으로 동일하다.지시어들
주제
참고
CGI 환경변수
AcceptPathInfo 지시어를 직접 off로
지정한 경우에만 설정한다. AcceptPathInfo가 없는 경우 서버는 기본적으로
경로 정보가 있는 요청에 대해 404 NOT FOUND 오류를 내지만,
mod_cgi는 경로 정보를 (URI에서 스크립트
파일명 뒤에 나오는 /more/path/info) 받는다.
AcceptPathInfo 지시어를 생략하면
mod_cgi 요청에 대해서 AcceptPathInfo를 On으로
설정한 것과 같다.HostnameLookups가 on이고 (기본값은
off), 접속한 호스트 주소를 역DNS 검색하여 실제 호스트명을
찾은 경우에만 설정한다.IdentityCheck가 on이고, 접속한
호스트가 ident 프로토콜을 지원하는 경우에만 설정한다.
쉽게 이 값을 속일 수 있기때문에 이 변수의 내용을 믿으면
안되고, 클라이언트와 서버 사이에 프록시가 있다면 변수
내용이 완전히 무의미함을 주의하라.
CGI 디버깅
CGI 로그파일 형식
%% [시간] 요청줄
%% HTTP-상태 CGI-스크립트-파일명
%%error
오류문
%request
받은 모든 HTTP 헤더
(있다면) POST나 PUT 내용
%response
CGI 스크립트 출력의 모든 헤더
%stdout
CGI 표준출력
%stderr
CGI 표준오류
ScriptLog 지시어
설명: CGI 스크립트 오류로그파일의 위치 문법: ScriptLog file-path사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_cgi, mod_cgidScriptLog 지시어는 CGI 스크립트
오류로그파일을 지정한다. ScriptLog를
사용하지않으면 오류로그를 만들지 않는다. 사용하면 아규먼트로
지정한 파일에 CGI 오류를 기록한다. 상대경로를 지정하면
ServerRoot에 상대경로로
받아들인다.
예제
ScriptLog logs/cgi_log
User 지시어로 지정한 사용자
권한으로 로그를 연다. 그래서 그 사용자가 스크립트 로그가
있는 디렉토리에 쓰기권한이 있던지, 직접 미리 파일을 만들어서
그 사용자에게 쓰기권한을 줘야 한다. 스크립트 로그를 주 로그
디렉토리에 둔다면 자식 프로세스를 실행하는 사용자에게 쓰기권한을
주기위해 디렉토리 권한을 변경하지 마라.ScriptLogBuffer 지시어
설명: 스크립트 로그에 기록할 PUT 혹은 POST 요청의 최대량 문법: ScriptLogBuffer bytes기본값: ScriptLogBuffer 1024사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_cgi, mod_cgidScriptLogLength 지시어
설명: CGI 스크립트 로그파일의 크기 제한 문법: ScriptLogLength bytes기본값: ScriptLogLength 10385760사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_cgi, mod_cgidScriptLogLength는 CGI 스크립트
로그파일의 크기를 제한한다. CGI 오류가 발생할때마다 (모든
요청 헤더, 모든 스크립트 출력 등) 많은 정보가 로그에
기록되기때문에 파일이 매우 커질 수 있다. 파일이 무한히 커지는
문제를 막기위해 이 지시어를 사용하여 CGI 로그파일의 최대
파일크기를 설정한다. 파일의 크기가 설정한 값을 넘으면 더
이상 정보를 기록하지않는다.
mod/mod_charset_lite.html 100644 0 0 25027 11074463123 13206 0 ustar 0 0
아파치 모듈 mod_cgid
설명: 외부 CGI 데몬을 사용하여 CGI 스크립트를 실행 상태: Base 모듈명: cgid_module 소스파일: mod_cgid.c 지원: 유닉스에서 쓰레드를 사용하는 MPMs 전용 요약
ScriptSock 지시어를 제외하고
mod_cgid는 mod_cgi와
비슷하게 동작한다. 아파치와 CGI에 대한 자세한 설명은
mod_cgi를 참고하라.mod_cgid는 CGI 스크립트를 실행하는
자식 프로세스를 포크하는 외부 데몬을 만든다. 주서버는 이
데몬과 유닉스소켓(unix domain socket)을 사용하여 통신한다.mod_cgi 대신 이 모듈을 사용한다. 사용자
입장에서 이 모듈의 설정과 동작은 mod_cgi와
동일하다. 유일한 차이점은 cgi 데몬과 통신을 위해 사용할
소켓의 이름을 설정하는 ScriptSock 지시어가
추가된 점이다.ScriptSock 지시어
설명: cgi 데몬과 통신을 위해 사용할 소켓의 이름 문법: ScriptSock file-path기본값: ScriptSock logs/cgisock사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_cgid 예제
ScriptSock /var/run/cgid.sock
mod/mod_dav.html 100644 0 0 33622 11074463123 11312 0 ustar 0 0
아파치 모듈 mod_charset_lite
설명: 문자집합 변환을 지정 상태: Experimental 모듈명: charset_lite_module 소스파일: mod_charset_lite.c 요약
mod_charset_lite 설정을 시험해봐라.mod_charset_lite를 사용하여 문서 원본의
문자집합과 문서를 클라이언트로 보내기 전에 변환할 문자집합을
지정할 수 있다. mod_charset_lite는 직접
자료를 변환하지않고 대신 아파치에게 변환하라고 요청한다.
mod_charset_lite는 EBCDIC과 ASCII 환경에서
사용할 수 있다. EBCDIC 환경에서 아파치는 보통 아파치 프로세스의
코드페이지에서 ISO-8859-1 문자집합으로 문서를 변환한다.
mod_charset_lite를 사용하여 다른 변환을
지시할 수 있다. ASCII 환경에서 아파치는 기본적으로 변환을
하지 않기때문에, 어떤 변환을 위해서는
mod_charset_lite가 필요하다.mod_charset이
제공하는 설정의 일부를 제공한다.
일반적인 문제점
잘못된 문자집합 이름
mod_charset_lite를 사용하는 시스템의
ARP 번역기능이 CharsetSourceEnc와
CharsetDefault의
파라미터인 문자집합 이름을 처리할 수 있어야 한다. 문자집합
이름은 표준화되지 않았고, http 헤더에 사용하는 값과 항상
같지는 않다. 현재 APR은 iconv(3)만을 사용하기때문에,
다음과 같이 iconv(1) 프로그램을 사용하여 특정 문자집합
이름을 사용할 수 있는지 쉽게 알 수 있다:
iconv -f charsetsourceenc-value -t charsetdefault-value
내용과 변환규칙의 문자집합이 서로 다름
CharsetDefault 지시어
설명: 변환할 문자집합 문법: CharsetDefault charset사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Experimental 모듈: mod_charset_lite CharsetDefault 지시어는 지시어를
사용한 위치에 있는 원본을 변환할 문자집합을 지정한다.예제
<Directory /export/home/trawick/apacheinst/htdocs/convert>
CharsetSourceEnc UTF-16BE
CharsetDefault ISO-8859-1
</Directory>
CharsetOptions 지시어
설명: 문자집합 변환 기능을 설정 문법: CharsetOptions option [option] ...기본값: CharsetOptions DebugLevel=0 NoImplicitAdd사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Experimental 모듈: mod_charset_lite CharsetOptions 지시어는
mod_charset_lite의 기능을 설정한다.
Option에는 아래 항목들을 사용할 수 있다
DebugLevel=nDebugLevel 키워드는
mod_charset_lite가 기록하는 디버그문구의
수준을 설정한다. 기본적으로 어떤 것도 기록하지 않는다.
이는 DebugLevel=0과 같다. 높은 숫자를 사용할수록
더 많은 디버그문구를 기록하게되어 서버 성능이 떨어진다.
숫자값의 실제 의미는 mod_charset_lite.c 앞부분의
DBGLVL_ 상수 정의를 참고하라.ImplicitAdd | NoImplicitAddImplicitAdd 키워드는 내용을 변환할
문자집합을 지정하면 자동으로 mod_charset_lite를
필터에 추가한다. AddOutputFilter 지시어로 필터순서를 직접
지정한다면, NoImplicitAdd를 사용하여
mod_charset_lite가 자동으로 필터에
추가되지않도록 해야 한다.CharsetSourceEnc 지시어
설명: 파일 원본의 문자집합 문법: CharsetSourceEnc charset사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Experimental 모듈: mod_charset_lite CharsetSourceEnc 지시어는 지시어를
사용한 위치에 있는 파일들 원본의 문자집합을 지정한다.예제
<Directory /export/home/trawick/apacheinst/htdocs/convert>
CharsetSourceEnc UTF-16BE
CharsetDefault ISO-8859-1
</Directory>
mod/mod_dav_fs.html 100644 0 0 12101 11074463123 11767 0 ustar 0 0
아파치 모듈 mod_dav
설명: Distributed Authoring and Versioning
(WebDAV) 기능 상태: Extension 모듈명: dav_module 소스파일: mod_dav.c 요약
지시어들
주제
참고
WebDAV 사용하기
mod_dav를 사용하려면 httpd.conf
파일에 아래과 같이 추가한다:Dav Onmod_dav_fs 모듈이 구현하는 DAV
파일시스템 제공자(provider)를 사용한다. 그러므로 이 모듈도
서버에 같이 컴파일되있거나 LoadModule 지시어로 실행중에
읽어들여야 한다.httpd.conf
파일의 전역 부분에 DavLockDB 지시어를 사용하여
지정해야 한다:
DavLockDB /usr/local/apache2/var/DavLock
User와 Group은 잠금 데이터베이스가
있는 디렉토리에 쓰기 권한을 가져야 한다.<Location> 지시어
안에 <Limit>
지시어를 사용할 수 있다. DAV 클라이언트가 한번의 요청에
보낼 수 있는 최대 바이트수를 제한하려면 LimitXMLRequestBody 지시어를 사용한다.
"일반적인" LimitRequestBody
지시어는 DAV 요청과 관계없다.전체 예제
DavLockDB /usr/local/apache2/var/DavLock
<Location /foo>
Dav On
AuthType Basic
AuthName DAV
AuthUserFile user.passwd
<LimitExcept GET OPTIONS>
require user admin
</LimitExcept>
</Location>
mod_dav는 Greg Stein이 만든 Apache 1.3용 mod_dav를
기반으로 만들었다. 모듈에 대한 더 자세한 정보는 그 사이트를
참고하라.
보안 문제
mod_dav를 사용하기 전에
서버가 안전한지 특별히 관심을 가져야 한다.mod_auth_digest 모듈이 제공하는 HTTP Digest
Authentication을 사용해야 한다. 거의 모든 WebDAV 클라이언트는
이 인증 방식을 지원한다. 아니면 SSL
연결에서 Basic Authentication을 사용할 수도 있다.mod_dav가 파일을 조작하려면, 아파치를
실행하는 User와
Group은 해당
디렉토리와 파일에 쓰기 권한을 가져야 한다. 또, 새로 생성한
파일은 User와
Group이 소유하게
된다. 그래서 아무나 이 계정에 접근할 수 없도록 하라. DAV
저장소는 아파치만 접근할 수 있다고 가정한다. 아파치를 통하지않고
(예를 들어 FTP나 파일시스템 도구를 사용하여) 파일을 수정함을
허용하면 안된다.mod_dav는 여러 서비스거부 공격의 대상이
될 수 있다. LimitXMLRequestBody 지시어를
사용하여 큰 DAV 요청을 읽을때 메모리량을 제한할 수 있다.
DavDepthInfinity
지시어를 사용하여 많은 메모리를 소모하기위한 매우 큰 저장소의
PROPFIND 요청을 막을 수 있다. 단순히 클라이언트가
여러 큰 파일들로 디스크공간을 채우는 서비스거부 공격도 가능하다.
아파치에서 이를 막을 직접적인 방법은 없다. 그러므로 신뢰하지않는
사용자에게 DAV 접근을 허용하지 않도록하라.
복잡한 설정
mod_dav를 사용하는
방법이다. 이는 GET 요청이 파일 내용을 다운로드하지
않고 항상 스크립트를 실행하므로 어렵다. 해결방법중 하나는
내용에 두개의 URL을 대응하는 것이다. 한 URL은 스크립트를
실행하고, 다른 URL로는 파일을 다운로드하여 DAV로 작업할
수 있다.
Alias /phparea /home/gstein/php_files
Alias /php-source /home/gstein/php_files
<Location /php-source>
DAV On
ForceType text/plain
</Location>
http://example.com/phparea는
PHP 스크립트의 결과를 보여주고,
http://example.com/php-source로는 DAV 클라이언트에서
스크립트를 수정할 수 있다.Dav 지시어
설명: WebDAV HTTP 메써드를 시작한다 문법: Dav On|Off|provider-name기본값: Dav Off사용장소: directory 상태: Extension 모듈: mod_dav Dav 지시어를 사용한다:
<Location /foo>
Dav On
</Location>
On 값은 실제로 mod_dav_fs
모듈이 제공하는 기본 제공자인 filesystem의
별칭이다. 어떤 위치에서 DAV를 시작하면 하위공간에서 DAV를
사용안하도록 설정할 수 없음을 주의하라. 완전한
설정예는 위의 절을 참고하라.
서버를 안전하게 구성할때까지 WebDAV을 사용하지 마라. 그렇지
않으면 누구라도 서버를 통해 파일을 분배할 수 있게 된다.
DavDepthInfinity 지시어
설명: PROPFIND의 Depth: Infinity 요청을 허가한다 문법: DavDepthInfinity on|off기본값: DavDepthInfinity off사용장소: 주서버설정, 가상호스트, directory 상태: Extension 모듈: mod_dav DavDepthInfinity 지시어를 사용하면
'Depth: Infinity' 헤더를 가진 PROPFIND 요청을
허가한다. 이런 요청을 사용하여 서비스거부 공격이 가능하기
때문에 기본적으로 허용하지 않는다.DavMinTimeout 지시어
설명: 서버가 DAV 자원에 대해 유지할 잠금의 최소시간 문법: DavMinTimeout seconds기본값: DavMinTimeout 0사용장소: 주서버설정, 가상호스트, directory 상태: Extension 모듈: mod_dav DavMinTimeout 지시어는 클라이언트에게
보낼 최소 잠금 시간을 (초단위) 지정한다. Microsoft Web Folders는
기본값으로 120 초를 사용한다. DavMinTimeout에
(600 초와 같이) 더 높은 값을 사용하면 클라이언트가 네트웍
지연때문에 잠금을 잃게되는 경우를 줄일 수 있다.예제
<Location /MSWord>
DavMinTimeout 600
</Location>
mod/mod_deflate.html 100644 0 0 42126 11074463123 12143 0 ustar 0 0
아파치 모듈 mod_dav_fs
설명: mod_dav을 위한 파일시스템 제공자상태: Extension 모듈명: dav_fs_module 소스파일: mod_dav_fs.c 요약
mod_dav 서비스에 필요하다.
mod_dav를 지원하는 모듈로 서버의 파일시스템에
있는 자원을 접근할 수 있도록 한다. 이 제공자(provider)의
정식명칭은 filesystem이다. Dav 지시어를 지정하여
mod_dav 뒷단 제공자를 사용한다:예제
Dav filesystem
filesystem이 mod_dav의
기본 제공자이므로 대신 On을 사용할 수 있다.DavLockDB 지시어
설명: DAV 잠금 데이터베이스 위치 문법: DavLockDB file-path사용장소: 주서버설정, 가상호스트 상태: Extension 모듈: mod_dav_fs DavLockDB 지시어는 잠금 데이터베이스의
전체 경로를 확장자를 제외하고 지정한다. 절대경로가 아니면
ServerRoot에 상대경로로
처리한다. mod_dav_fs는 잠금을 SDBM 데이터베이스에
기록한다.예제
DavLockDB var/DavLock
User와
Group은 잠금
데이터베이스가 있는 디렉토리에 쓰기 권한을 가져야 한다.
보안상 이유로 기존 디렉토리의 권한을 바꾸기보다는 잠금
데이터베이스용 디렉토리를 만들어야 한다. 위의 경우 아파치는
ServerRoot 아래
var/ 디렉토리에 서버가 선택한 확장명을 가진
DavLock 파일을 만든다.
mod/mod_dir.html 100644 0 0 21242 11074463123 11311 0 ustar 0 0
아파치 모듈 mod_deflate
설명: 내용을 클라이언트로 보내기 전에 압축한다 상태: Extension 모듈명: deflate_module 소스파일: mod_deflate.c 요약
mod_deflate 모듈은 서버의 출력을 네트웍으로
클라이언트에 보내기 전에 압축하는 DEFLATE 출력필터를
제공한다.지시어들
주제
참고
권장하는 설정
일부 type만 압축
AddOutputFilterByType DEFLATE text/html text/plain text/xml
이미지를 제외한 모든 것을 압축
<Location />
# 필터를 추가한다
SetOutputFilter DEFLATE
# Netscape 4.x에 문제가 있다...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08에 더 문제가 있다
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE은 Netscape라고 자신을 알리지만, 문제가 없다
# BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# 주의: 아파치 2.0.48까지 mod_setenvif의 버그때문에
# 위의 정규표현식은 동작하지 않는다. 원하는 효과를
# 얻기위해 다음과 같이 수정하여 사용한다:
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
# 이미지를 압축하지 않는다
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
# 프록시가 잘못된 내용을 전달하지않도록 한다
Header append Vary User-Agent env=!dont-vary
</Location>
압축하기
출력 압축
DEFLATE 필터가
압축을 한다. 다음 지시어는 지시어가 있는 위치의 문서를
압축한다:
SetOutputFilter DEFLATE
gzip-only-text/html을 1로 설정할지도
모른다. 이를 1이 아닌 값으로 설정하면
무시한다.AddOutputFilterByType 지시어를 사용한다.
다음 설정은 html 파일만을 압축한다:
<Directory "/your-server-root/manual">
AddOutputFilterByType DEFLATE text/html
</Directory>
BrowserMatch 지시어에 no-gzip을
설정한다. 최적의 결과를 얻기위해 no-gzip과
gzip-only-text/html을 같이 사용할 수 있다.
이 경우 전자가 후자를 무시한다. 위 절의 설정 예제 일부를 살펴보자:
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
User-Agent 문자열을 보고 Netscape
Navigator 버전 4.x인지 검사한다. 이 버전은 text/html이
아닌 type의 압축을 처리하지 못한다. 버전 4.06, 4.07, 4.08은
html 파일 압축을 처리하는대도 문제가 있다. 그래서 우리는
이 경우 deflate 필터를 완전히 사용하지않는다.BrowserMatch
지시어는 Microsoft Internet Explorer가 자신을 "Mozilla/4"로
알리지만 압축된 요청을 처리할 수 있기때문에 user agent
추측을 수정한다. User-Agent 헤더에서 "MSIE"
(\b는 "단어 경계"를 뜻한다) 문자열을 발견하면
앞에서 설정한 제약을 푼다.주의
DEFLATE 필터는 항상 PHP나 SSI와 같은 RESOURCE
필터 뒤에 들어간다. 또, 내부 하위요청(subrequest)에 영향을
주지 않는다.
입력 압축풀기
mod_deflate 모듈은 gzip으로 압축된 요청
내용을 푸는 필터도 제공한다. 이 기능을 사용하려면 다음과
같이 SetInputFilter나
AddInputFilter를
사용하여 입력필터순서에 DEFLATE 필터를
추가한다.
<Location /dav-area>
SetInputFilter DEFLATE
</Location>
Content-Encoding: gzip 헤더가 있다면
자동으로 압축된 내용을 푼다. gzip 요청을 할 수 있는
브라우저는 드물다. 그러나 어떤 WebDAV 클라이언트와 같은
특별한 프로그램은 요청 압축을 지원한다.Content-Length에 대한 주의
Content-Length
헤더를 믿지마라! Content-Length 헤더는 클라이언트가
보낸 내용의 길이이지, 압축을 푼 결과의 바이트수가
아니다.
프록시 서버 다루기
mod_deflate 모듈은 프록시가 자신이 캐쉬한
응답을 적절한 Accept-Encoding 요청 헤더를 보낸
클라이언트에게만 보내도록 Vary:
Accept-Encoding HTTP 응답 헤더를 추가한다. 그래서
압축된 내용을 이해할 수 없는 클라이언트에 압축된 내용을
보내지않도록 한다.User-Agent 헤더 등에 따라 특별히
필터 적용을 취소한다면, 프록시에게 이러한 제한을 알려주기위해
직접 Vary 헤더에 추가해야 한다. 예를 들어,
설정이 User-Agent에 따라 DEFLATE
필터를 추가한다면 다음을 사용한다:
Header append Vary User-Agent
Vary 헤더값을
*로 설정해야 한다. 그러면 표준을 따르는 프록시는
캐쉬를 하지 않게 된다.예제
Header set Vary *
DeflateBufferSize 지시어
설명: zlib이 한번에 압축할 크기 문법: DeflateBufferSize value기본값: DeflateBufferSize 8096사용장소: 주서버설정, 가상호스트 상태: Extension 모듈: mod_deflate DeflateBufferSize 지시어는 zlib이
한번에 압축할 바이트수를 지정한다.DeflateCompressionLevel 지시어
설명: 출력을 어느정도 압축하는가 문법: DeflateCompressionLevel value기본값: Zlib's default사용장소: 주서버설정, 가상호스트 상태: Extension 모듈: mod_deflate 지원: 아파치 2.0.45 부터 DeflateCompressionLevel 지시어는
사용할 압축수준을 선택한다. 값이 클수록 압축률이 증가하지만,
CPU를 더 많이 사용한다.DeflateFilterNote 지시어
설명: 압축률을 로그에 기록한다 문법: DeflateFilterNote [type] notename사용장소: 주서버설정, 가상호스트 상태: Extension 모듈: mod_deflate 지원: type은 아파치 2.0.45 부터 DeflateFilterNote 지시어는 요청의
압축률을 로그에 기록하는 기호를 지정한다. 기호 이름은 지시어로
지정한 값이다. 통계를 위해 접근
로그에서 기호를 사용할 수 있다.예제
DeflateFilterNote ratio
LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i"' deflate
CustomLog logs/deflate_log deflate
InputOutputRatiooutput/input * 100) 저장한다.
type 아규먼트를 생략하면 사용하는 기본값이다.정밀한 로그
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate
CustomLog logs/deflate_log deflate
참고
DeflateMemLevel 지시어
설명: zlib이 압축할때 사용하는 메모리량 문법: DeflateMemLevel value기본값: DeflateMemLevel 9사용장소: 주서버설정, 가상호스트 상태: Extension 모듈: mod_deflate DeflateMemLevel 지시어는 zlib이
압축할때 얼마만큼 메모리를 사용할지 결정한다. (1과 9 사이의
값)
mod/mod_disk_cache.html 100644 0 0 47777 11074463123 12635 0 ustar 0 0
아파치 모듈 mod_dir
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: "마지막 슬래쉬" 리다이렉션을 제공하고 디렉토리
index 파일을 서비스한다 상태: Base 모듈명: dir_module 소스파일: mod_dir.c 요약
index.html이라는
파일. DirectoryIndex
지시어는 이 파일의 이름을 지정한다. mod_dir가
이 지시어를 제공한다.mod_autoindex가
이 기능을 제공한다.dirname이 디렉토리라면 서버는 URL
http://servername/foo/dirname 요청을 받으면
"마지막 슬래쉬" 리다이렉션을 보낸다. 디렉토리에는 마지막
슬래쉬가 필요하다. 그래서 mod_dir은
http://servername/foo/dirname/로 리다이렉션을
보낸다.DirectoryIndex 지시어
설명: 클라이언트가 디렉토리를 요청할때 찾아볼 자원 목록 문법: DirectoryIndex
local-url [local-url] ...기본값: DirectoryIndex index.html사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_dir DirectoryIndex 지시어는 클라이언트가
디렉토리명 끝에 /를 붙여서 디렉토리의 index를 요청할때 찾아볼
자원 목록을 지정한다. Local-url은 요청한 디렉토리에
상대적인 문서의 (%로 인코딩된) URL이다. 보통은 디렉토리에
있는 파일명이다. 여러 URL을 지정할 수 있고, 이 경우 서버는
첫번째로 찾은 파일을 보낸다. 자원을 찾을 수 없고
Indexes 옵션을 설정하였다면 서버는 직접 디렉토리
목록을 만든다.예제
DirectoryIndex index.html
http://myserver/docs/를 요청할때
http://myserver/docs/index.html이 있으면 이를
보내고, 없다면 디렉토리 목록을 보낸다.
DirectoryIndex index.html index.txt /cgi-bin/index.pl
index.html이나
index.txt가 없으면 CGI 스크립트
/cgi-bin/index.pl을 실행한다.DirectorySlash 지시어
설명: 마지막 슬래쉬 리다이렉션을 키고 끈다 문법: DirectorySlash On|Off기본값: DirectorySlash On사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_dir 지원: 아파치 2.0.51 이후부터 DirectorySlash 지시어는
mod_dir가 디렉토리를 가리키는 URL을 수정할지
여부를 결정한다.mod_dir는 보통 다음과 같은 이유로
사용자를 마지막 슬래쉬를 붙인 동일한 자원으로
리다이렉션한다.
mod_autoindex가 올바로 동작한다. 이
기능이 없다면 이 모듈은 링크에 잘못된 경로를 쓰게 된다.DirectoryIndex는
마지막 슬래쉬가 있는 디렉토리 요청만을 처리한다.
# 아래 보안 경고 참고!
<Location /some/path>
DirectorySlash Off
SetHandler some-handler
</Location>
보안 경고
Options +Indexes) mod_autoindex를
사용하고 DirectoryIndex를
(index.html 같은) 유효한 자원으로 설정하였지만
해당 URL에 다른 특별한 핸들러가 없는 상황을 상상해보라.
이 경우 마지막 슬래쉬가 있는 요청은 index.html
파일을 보여준다. 그러나 마지막 슬래쉬가 없는 요청은
디렉토리 내용을 보여준다.
mod/mod_dumpio.html 100644 0 0 13534 11074463123 12035 0 ustar 0 0
아파치 모듈 mod_disk_cache
설명: Content cache storage manager keyed to URIs 상태: Experimental 모듈명: disk_cache_module 소스파일: mod_disk_cache.c 요약
이 모듈은 실험적인 상태이다. 문서는 아직 작업중이다...
mod_disk_cache는 디스크기반 저장관리자를
구현한다. 이 모듈은 기본적으로 mod_proxy와
같이 사용한다.주의:
mod_disk_cache는
mod_cache가 필요하다.지시어들
CacheDirLength 지시어
설명: 하위디렉토리명의 문자개수 문법: CacheDirLength length기본값: CacheDirLength 2사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache CacheDirLength 지시어는 캐쉬
계층구조에서 각 하위디렉토리명의 문자수를 지정한다.
CacheDirLevels와
CacheDirLength를 곱하여 20 보다
크면 안된다.
CacheDirLength 4
CacheDirLevels 지시어
설명: 캐쉬의 하위디렉토리 깊이. 문법: CacheDirLevels levels기본값: CacheDirLevels 3사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache CacheDirLevels 지시어는 캐쉬의
하위디렉토리 깊이를 지정한다. 캐쉬된 자료를 CacheRoot 디렉토리
아래 이 깊이까지 저장한다.
CacheDirLevels와 CacheDirLength를
곱하여 20 보다 크면 안된다.
CacheDirLevels 5
CacheExpiryCheck 지시어
설명: 캐쉬에서 파일을 찾을때 만기시간을 고려할지 여부 문법: CacheExpiryCheck On|Off기본값: CacheExpiryCheck On사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache
CacheExpiryCheck Off
CacheExpiryCheck 지시어는 현재
구현되지 않았다.
CacheGcClean 지시어
설명: URL에 해당하는 변하지않은 캐쉬파일을 유지할 시간 문법: CacheGcClean hours url-string기본값: CacheGcClean ?사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache
CacheGcClean 12 /daily_scripts
CacheGcClean 지시어는 현재 구현되지
않았다.
CacheGcDaily 지시어
설명: 매일 가비지컬랙터를 실행할 반복 시간 (24시 시계) 문법: CacheGcDaily time기본값: CacheGcDaily ?사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache
CacheGcDaily 23:59
CacheGcDaily 지시어는 현재 구현되지
않았다.
CacheGcInterval 지시어
설명: 가비지컬랙터를 실행하는 간격. 문법: CacheGcInterval hours사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache CacheGcInterval 지시어는 카비지컬랙터가
디스크공간을 비우는 시간 간격을 시간단위로 지정한다.
CacheGcInterval 24
CacheGcInterval 지시어는 현재 구현되지
않았다.
CacheGcMemUsage 지시어
설명: 가비지컬랙터가 사용할 최대 메모리량 (kilobyte 단위) 문법: CacheGcMemUsage KBytes기본값: CacheGcMemUsage ?사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache
CacheGcMemUsage 16
CacheGcMemUsage 지시어는 현재
구현되지 않았다.
CacheGcUnused 지시어
설명: URL에 해당하는 참조되지않은 캐쉬파일을 유지할 기간. 문법: CacheGcUnused hours url-string기본값: CacheGcUnused ?사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache
CacheGcUnused 12 /local_images
CacheGcUnused 지시어는 현재 구현되지
않았다.
CacheMaxFileSize 지시어
설명: 캐쉬에 저장할 문서의 최대크기 (바이트 단위) 문법: CacheMaxFileSize bytes기본값: CacheMaxFileSize 1000000사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache CacheMaxFileSize 지시어는 캐쉬에
저장할 문서의 최대크기를 바이트 단위로 지정한다.
CacheMaxFileSize 64000
CacheMinFileSize 지시어
설명: 캐쉬에 저장할 문서의 최소크기 (바이트 단위) 문법: CacheMinFileSize bytes기본값: CacheMinFileSize 1사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache CacheMinFileSize 지시어는 캐쉬에
저장할 문서의 최소크기를 바이트 단위로 지정한다.
CacheMinFileSize 64
CacheRoot 지시어
설명: 캐쉬 파일을 저장할 디렉토리 root 문법: CacheRoot directory사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache CacheRoot 지시어는 디스크에서
캐쉬 파일을 저장할 디렉토리를 지정한다. mod_disk_cache 모듈을 아파치 서버와 같이 컴파일하였거나
읽어들인 경우 반드시 이 지시어를 정의해야 한다.
CacheRoot에 값이 없으면 설정파일을
처리하지 않는다. CacheDirLevels와 CacheDirLength 지시어는
이 지시어로 지정한 root 디렉토리의 하위디렉토리 구조를 지시한다.
CacheRoot c:/cacheroot
CacheSize 지시어
설명: 캐쉬로 사용할 최대 디스크공간 (KByte 단위) 문법: CacheSize KBytes기본값: CacheSize 1000000사용장소: 주서버설정, 가상호스트 상태: Experimental 모듈: mod_disk_cache CacheSize 지시어는 캐쉬로 사용할
디스크공간 크기를 KByte (1024 바이트) 단위로 지정한다. 이
지시어는 캐쉬 크기를 제한하지 않는다. 가비지컬랙터가 캐쉬
사용량이 설정한 값보다 작게될때까지 파일을 지운다. 항상
사용가능한 디스크공간 보다 작은 값을 사용하라.
CacheSize 5000000
mod/mod_echo.html 100644 0 0 7254 11074463123 11440 0 ustar 0 0
Apache Module mod_dumpio
Description: Dumps all I/O to error log as desired. Status: Experimental Module쟅dentifier: dumpio_module Source쟂ile: mod_dumpio.c Summary
mod_dumpio allows for the logging of
all input received by Apache and/or all output sent by
Apache to be logged (dumped) to the error.log file.
Enabling dumpio Support
LogLevel must be set to debug.DumpIOInput Directive
Description: Dump all input data to the error log Syntax: DumpIOInput On|OffDefault: DumpIOInput OffContext: server config Status: Experimental Module: mod_dumpio Compatibility: DumpIOInput is only available in Apache 2.0.53 and
later. Example
DumpIOInput On
DumpIOOutput Directive
Description: Dump all output data to the error log Syntax: DumpIOOutput On|OffDefault: DumpIOOutput OffContext: server config Status: Experimental Module: mod_dumpio Compatibility: DumpIOOutput is only available in Apache 2.0.53 and
later. Example
DumpIOOutput On
mod/mod_env.html 100644 0 0 13747 11074463123 11336 0 ustar 0 0
아파치 모듈 mod_echo
설명: 프로토콜 모듈을 설명하기위한 간단한 echo 서버 상태: Experimental 모듈명: echo_module 소스파일: mod_echo.c 지원: Apache 2.0 이후부터 요약
지시어들
mod/mod_example.html 100644 0 0 14724 11074463123 12175 0 ustar 0 0
아파치 모듈 mod_env
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: CGI 스크립트나 SSI 페이지에 전달할 환경변수를
수정한다 상태: Base 모듈명: env_module 소스파일: mod_env.c 요약
PassEnv 지시어
설명: 쉘에서 환경변수를 가져온다 문법: PassEnv env-variable [env-variable]
...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_env 예제
PassEnv LD_LIBRARY_PATH
SetEnv 지시어
설명: 환경변수를 설정한다 문법: SetEnv env-variable value사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_env 예제
SetEnv SPECIAL_PATH /foo/bin
mod/mod_expires.html 100644 0 0 26253 11074463123 12221 0 ustar 0 0
아파치 모듈 mod_example
설명: 아파치 모듈 API를 설명한다 상태: Experimental 모듈명: example_module 소스파일: mod_example.c 요약
이 문서는 아파치 웹서버 2.0 버전에서 변경된 내용을 담고
있지 않다. 아직도 유효한 정보가 있지만, 주의해서 사용하길
바란다.
src/modules/example 디렉토리에
있는 파일들은 아파치 API를 사용하여 모듈을 작성하려는 사람들을
돕기위한 예제다.mod_example.c는 모든 콜백(callback) 구조와
호출 문법을 설명하는 파일이다. 당신은 모듈에 이 모든 콜백을
구현할 필요가 없다. 사실 정반대다!
example 모듈 컴파일하기
src/Configuration 파일 아래 부분에 있는
"AddModule modules/example/mod_example" 줄의 주석처리를
없앤다. 이런 줄이 없다면, 다음과 같은 줄을 추가한다.
AddModule modules/example/mod_example.o
src/Configure 스크립트를 실행한다
("cd src; ./Configure"). 그러면
서버 자체 Makefile을 만들고, 하위디렉토리에 있는 요청한
추가 모듈을 src/modules/Makefile에 추가한다.src 디렉토리에 있는
"make"를 실행한다).
mkdir src/modules/mymodulecp src/modules/example/*
src/modules/mymodule
mod_example 모듈 사용하기srm.conf 파일에
다음과 같은 설정을 추가하라:
<Location /example-info>
SetHandler example-handler
</Location>
.htaccess
파일에 다음과 같은 내용을 추가하고, 그 위치에서 "test.example"
같은 파일을 요청하라:
AddHandler example-handler .example
Example 지시어
설명: 아파치 모듈 API를 설명하기위한 예제 지시어 문법: Example사용장소: 주서버설정, 가상호스트, directory, .htaccess 상태: Experimental 모듈: mod_example Example 지시어는 example 모듈의
내용핸들러가 간단한 문구를 보일지 여부를 설정한다. 이 지시어는
아규먼트를 받지않는다. example 내용핸들러를 적용한 URL에
접속하면 문서 요청을 서비스하기위해 모듈안에 함수들이 어떻게
그리고 어떤 순서로 불리는지 알 수 있다. 이 지시어의 효과는
"Example directive declared here: YES/NO"로
확인할 수 있다.
mod/mod_ext_filter.html 100644 0 0 36023 11074463123 12703 0 ustar 0 0
아파치 모듈 mod_expires
설명: 사용자가 지정한 기준에 따라 Expires와
Cache-Control HTTP 헤더를 생성한다상태: Extension 모듈명: expires_module 소스파일: mod_expires.c 요약
Expires HTTP 헤더와
Cache-Control HTTP 헤더의 max-age
지시어 설정을 조절한다. 만기일을 파일이 마직막 수정된 시간
혹은 클라이언트가 접속한 시간에 상대적으로 설정할 수 있다.Header 지시어를
사용하여 max-age 외의 다른
Cache-Control 지시어(RFC
2616, 14.9 절 참고)를 수정할 수 있다.
다른 내부 문법
ExpiresDefault와
ExpiresByType
지시어를 더 읽기 좋은 형식으로 기술할 수 있다:
ExpiresDefault "<base> [plus] {<num>
<type>}*"
ExpiresByType type/encoding "<base> [plus]
{<num> <type>}*"
accessnow ('access'와 같음)modificationplus 키워드는 없어도 된다. <num>은
[atoi()에 사용할 수 있는] 정수값이다.
<type>은 다음중 하나이다:
yearsmonthsweeksdayshoursminutesseconds
ExpiresDefault "access plus 1 month"
ExpiresDefault "access plus 4 weeks"
ExpiresDefault "access plus 30 days"
ExpiresByType text/html "access plus 1 month 15
days 2 hours"
ExpiresByType image/gif "modification plus 5 hours 3
minutes"
ExpiresActive 지시어
설명: Expires 헤더를 생성한다문법: ExpiresActive On|Off사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Extension 모듈: mod_expires .htaccess
파일에서 사용한다면 그 디렉토리 아래에 있는 문서들만 해당된다.)
Expires와 Cache-Control 헤더를
생성할지 유무를 결정한다. (.htaccess 파일 등으로
더 하위 단계에서 서버설정을 변경하지않는 한)
Off이면 해당 영역에 있는 문서에 이들 헤더를
생성하지 않는다. On이면 ExpiresByType과 ExpiresDefault 지시어로
(해당 항목을 참고하라) 지정한 규칙에 따라 서비스하려는
문서에 이 헤더들을 생성한다.Expires나 Cache-Control
헤더를 보장하지는 않는다. 규칙에 해당하지 않다면 마치 이
지시어가 없는 것처럼 헤더를 만들지 않는다.ExpiresByType 지시어
설명: MIME type으로 Expires 헤더값을 설정한다문법: ExpiresByType MIME-type
<code>seconds사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Extension 모듈: mod_expires text/html) 문서에 대한 Expires
헤더값과 Cache-Control 헤더의 max-age
지시어값을 정의한다. 두번째 아규먼트는 만기시간을 결정할때
기준 시간에 더할 초단위 값을 지정한다. Cache-Control:
max-age는 만기시간에서 요청한 시간을 빼서 계산하고,
결과는 초단위로 표시한다.<code> 필드로 결정해야 한다.
M은 기준 시간으로 파일의 최근 수정시간을
사용하고, A는 클라이언트의 접근 시간을 사용한다.M을 사용하면 캐쉬에 있는
모든 복사본이 같은 시간에 만료된다. 그래서 항상 같은 URL로
찾아볼 수 있는 주간일정 같은 용도에 좋다. A를
사용하면 복사본의 만기시간이 각각 다르다. 이는 자주 수정되지않는
그림파일에, 특히 여러 문서에서 같은 그림을 참조할때 (예를
들어, 이미지는 상대적으로 짧은 기간동안 반복해서 접근된다),
유용하다.예제:
# 만기헤더를 사용한다
ExpiresActive On
# 클라이언트 캐쉬의 GIF 그림은 한 달후에 만기한다
ExpiresByType image/gif A2592000
# HTML 문서는 변경후 일주일간 유효하다
ExpiresByType text/html M604800
ExpiresActive On을 사용할때만
유효함을 주의하라. ExpiresDefault 지시어를
사용하여 특정 MIME type에 대해서만 만기시간을
설정할 수 있다.ExpiresDefault 지시어
설명: 만기시간을 계산하는 기본 알고리즘 문법: ExpiresDefault <code>seconds사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Extension 모듈: mod_expires ExpiresByType 지시어를
사용하여 종류별로 설정할 수 있다. 아규먼트 문법에 대한
자세한 설명은 그 지시어와 다른 문법을
참고하라.
mod/mod_file_cache.html 100644 0 0 25337 11074463123 12606 0 ustar 0 0
아파치 모듈 mod_ext_filter
설명: 응답 내용을 외부 프로그램으로 처리한 후 클라이언트로
보낸다 상태: Extension 모듈명: ext_filter_module 소스파일: mod_ext_filter.c 요약
mod_ext_filter를 사용하면 간단하고 익숙한
방법으로 필터를 만들 수 있다.
표준입력에서 읽고 표준출력에 쓰는 프로그램(즉, 유닉스식
필터 명령어)을 아파치 필터로 사용할 수 있다. 이런 필터는
아파치 API로 쓰여지고 아파치 서버 프로세스 안에서 실행되는
필터에 비해 매우 느리지만, 다음과 같은 장점이 있다:
mod_ext_filter를 사용하여 필터를 빨리 만들어볼
수 있다.
예제
다른 type의 응답을 HTML로 만든다
# mod_ext_filter 지시어를 가지고
# 외부 프로그램 /usr/bin/enscript를 사용하여
# 문서파일과 text/c 파일을 HTML로 만들고 결과의
# type을 text/html로 변경하는 필터를 정의한다
ExtFilterDefine c-to-html mode=output \
intype=text/c outtype=text/html \
cmd="/usr/bin/enscript --color -W html -Ec -o - -"
<Directory "/export/home/trawick/apacheinst/htdocs/c">
# 출력에 새로운 필터를 실행하는 core 지시어
SetOutputFilter c-to-html
# .c 파일의 type을 text/c로 만드는 mod_mime
# 지시어
AddType text/c .c
# 디버그 수준을 높여서 요청마다 현재 설정을
# 알려주는 로그문을 기록하는 mod_ext_filter
# 지시어
ExtFilterOptions DebugLevel=1
</Directory>
content 인코딩 필터 구현하기
mod_deflate를
참고하길 바란다.
# 외부 필터를 정의하는 mod_ext_filter 지시어
ExtFilterDefine gzip mode=output cmd=/bin/gzip
<Location /gzipped>
# 출력할때 gzip 필터를 실행하는 core 지시어
SetOutputFilter gzip
# "Content-Encoding: gzip" 헤더를 추가하는
# mod_header 지시어
Header set Content-Encoding gzip
</Location>
서버를 느리게 하기
# cat으로 모든 내용을 통과하는 필터를 정의하는
# mod_ext_filter 지시어; cat은 아무것도 수정하지
# 않는다; 단지 처리경로를 길게 하여 자원을 더 소모한다
ExtFilterDefine slowdown mode=output cmd=/bin/cat \
preservescontentlength
<Location />
# 출력할때 slowdown 필터를 여러번 실행하는 core 지시어
#
SetOutputFilter slowdown;slowdown;slowdown
</Location>
sed를 사용하여 응답에서 글을 대체하기
# 응답에서 글을 대체하는 필터를 정의하는
# mod_ext_filter 지시어
#
ExtFilterDefine fixtext mode=output intype=text/html \
cmd="/bin/sed s/verdana/arial/g"
<Location />
# 출력할때 fixtext 필터를 실행하는 core 지시어
SetOutputFilter fixtext
</Location>
다른 필터를 추적하기
# 압축 문제가 있는 특정 클라이언트(IP 192.168.1.31)에
# 대해 mod_deflate가 읽고 쓰는 자료를 추적한다.
# 이 필터는 mod_deflate로 보내기 전 자료를 추적한다.
ExtFilterDefine tracebefore \
cmd="/bin/tracefilter.pl /tmp/tracebefore" \
EnableEnv=trace_this_client
# 이 필터는 mod_deflate에서 나오는 자료를 추적한다.
# ftype 파라미터를 사용하지않는 경우, 기본 필터형
# AP_FTYPE_RESOURCE는 필터 순서를 mod_deflate *이전에*
# 둔다. AP_FTYPE_CONTENT_SET 보다 조금 높은 숫자값을
# 지정하면 mod_deflate 이후에 실행한다.
ExtFilterDefine traceafter \
cmd="/bin/tracefilter.pl /tmp/traceafter" \
EnableEnv=trace_this_client ftype=21
<Directory /usr/local/docs>
SetEnvIf Remote_Addr 192.168.1.31 trace_this_client
SetOutputFilter tracebefore;deflate;traceafter
</Directory>
다음은 자료를 추적하는 필터이다:
#!/usr/local/bin/perl -w
use strict;
open(SAVE, ">$ARGV[0]")
or die "can't open $ARGV[0]: $?";
while (<STDIN>) {
print SAVE $_;
print $_;
}
close(SAVE);
ExtFilterDefine 지시어
설명: 외부 필터를 정의한다 문법: ExtFilterDefine filtername parameters사용장소: 주서버설정 상태: Extension 모듈: mod_ext_filter ExtFilterDefine 지시어는 외부
필터의 성질과 실행할 프로그램, 아규먼트를 정의한다.cmd= 파라미터는
반드시 필요하다. 사용할 수 있는 파라미터는 다음과 같다:
cmd=cmdlinecmd= 키워드는 실행할 외부 명령어를 지정한다.
프로그램명 뒤에 아규먼트가 있다면 명령행을 쌍따옴표로
묶어야 한다 (예를 들어,
cmd="/bin/mypgm arg1
arg2"). 쉘을 거치지않고 직접 프로그램을
실행하기때문에 일반적인 쉘 따옴표는 필요없다. 프로그램
아규먼트들은 공백으로 구분한다. 프로그램 아규먼트에 공백이
있다면 공백 앞에 백슬래쉬로 사용해야 한다. 백슬래쉬가
아규먼트의 일부라면 백슬래쉬를 두번 사용해야 한다. 프로그램을
실행할때 표준 CGI 환경변수와 추가로 DOCUMENT_URI,
DOCUMENT_PATH_INFO, QUERY_STRING_UNESCAPED 변수를 설정한다.mode=modemode는 현재 (기본값인) output만
가능하다. 미래에는 mode=input을 사용하여
요청 내용을 처리하는 필터를 지정할 수 있을 것이다.intype=imtintype=을 지정하면
다른 type의 문서는 필터로 처리하지 않는다.outtype=imtPreservesContentLengthPreservesContentLength 키워드는 필터가
content length를 유지하도록 한다. 대부분의 필터가 content
length를 변경하므로 이 키워드는 기본값이 아니다. 필터가
길이를 유지할때만 이 키워드를 사용해야 한다.ftype=filtertypedisableenv=envenableenv=envExtFilterOptions 지시어
설명: mod_ext_filter 옵션을 설정한다문법: ExtFilterOptions option [option] ...기본값: ExtFilterOptions DebugLevel=0 NoLogStderr사용장소: directory 상태: Extension 모듈: mod_ext_filter ExtFilterOptions 지시어는
mod_ext_filter의 특별한 처리옵션을 지정한다.
Option은 다음중 하나다.
DebugLevel=nDebugLevel 키워드는
mod_ext_filter가 기록하는 디버그 문구
수준을 정한다. 기본값은 디버그문을 기록하지 않는다.
이는 DebugLevel=0과 같다. 높은 숫자를
사용할수록, 더 많은 디버그문이 기록되고 서버 성능이
떨어진다. 숫자값의 실제 의미는 mod_ext_filter.c
앞부분에 있는 DBGLVL_ 상수 정의에 설명되있다.
LogLevel을 사용하여 디버그문을
아파치 오류로그에 기록해야 한다.LogStderr | NoLogStderrLogStderr 키워드는 외부 필터 프로그램이
표준오류로 출력하는 문구를 아파치 오류로그에 기록한다.
NoLogStderr는 이 기능을 하지 않는다.예제
ExtFilterOptions LogStderr DebugLevel=0
mod_ext_filter는
자체 디버그문을 기록하지 않는다.
mod/mod_headers.html 100644 0 0 32724 11074463123 12155 0 ustar 0 0
아파치 모듈 mod_file_cache
설명: 메모리에 정적 파일들을 캐쉬 상태: Experimental 모듈명: file_cache_module 소스파일: mod_file_cache.c 요약
이 모듈은 조심해서 사용해야 한다.
mod_file_cache를
사용하여 사이트를 엉망으로 만들기 쉽기때문에 이 문서를
꼼꼼히 읽길 바란다.
mod_file_cache는
자주 요청되는 정적 파일을 두가지 방식으로 캐쉬에
저장한다. 설정 지시어를 사용하여 mod_file_cache가
파일을 열고(open) mmap()할지 아니면 파일을
열고 파일 핸들을 저장할지 결정한다. 두 방식 모두
파일을 서비스하기위해 필요한 작업의 일부를 (특히 파일 입출력
작업) 파일을 요청할 때마다 매번 하는 대신 서버가 시작할때
한번만 하여 서버 부하가 감소한다.mod_mmap_static
모듈의 기능을 확장한 결과다.
mod_file_cache 사용하기
mod_file_cache는 주서버 설정에서 MMapFile과 CacheFile 지시어를 사용하여
설정한 정적 파일들을 캐쉬에 저장한다.MMapStatic 지시어를
지원하지 않지만, AIX 같은 다른 플래폼은 둘 모두를 지원한다.
지원하지않는 지시어를 사용할 경우 서버 오류 로그에 오류문을
남긴다. 지원하지않는 지시어를 사용해도 서버는 동작하지만
파일을 캐쉬에 저장하지 않는다. 두 지시어를 모두 지원하는
플래폼을 사용한다면 어떤 방식이 더 좋은지 실험해보라.MMapFile 지시어
mod_file_cache의 MMapFile 지시어는
설정한 정적 파일들을 mmap() 시스템호출을
사용하여 메모리에 대응한다. 최신 유닉스류 운영체제라면
보통 이 시스템호출이 있지만, 없는 운영체제도 있다. 또,
mmap()할 수 있는 파일 크기와 개수를 시스템이
제한할 수 있으므로 미리 실험해보는 것이 좋다.mmap()한다.
그래서 파일시스템에서 해당 파일중 하나라도 변경되면 서버를
재시작해야 한다 (중단과
재시작 문서 참고). 다시 말해서 파일이 변경되었는데
서버를 재시작하지 않으면 완전히 이상하게 요청을 서비스할지도
모른다. 이전 파일을 지우고(unlink) 그 자리에 새로운 파일을
만들는 방식으로 파일을 수정해야 한다. rdist나
mv와 같은 대다수의 도구가 이런 방식으로 동작한다.
매번 추가로 불필요한 stat() 검사가 필요하고
입출력 감소라는 원래 의도에 반하기때문에 이 모듈은 파일의
변화를 무시한다.CacheFile 지시어
mod_file_cache의 CacheFile 지시어는
설정 지시어에 열거한 파일(과 파일들)을 열어서 파일의
핸들(handle) 혹은 파일 기술자(file descriptor)를
캐쉬에 저장한다. 파일을 요청하면 서버는 캐쉬에서 핸들을
찾아서 소켓 API sendfile()에 (윈도우즈에서는
TransmitFile()) 넘긴다.rdist나 mv와
같은 대다수의 도구가 이런 방식으로 동작한다.주의
Include 지시어를 참고하여 다음과
같은 명령어를 실행한다:
find /www/htdocs -type f -print \
| sed -e 's/.*/mmapfile &/' > /www/conf/mmap.conf
CacheFile 지시어
설명: 시작시 여러 파일 핸들을 캐쉬한다 문법: CacheFile file-path [file-path] ...사용장소: 주서버설정 상태: Experimental 모듈: mod_file_cache CacheFile 지시어는 서버가 시작할때
여러 파일을 열고(open) 파일들의 핸들을 캐쉬에 저장한다.
서버 종료시 자동으로 캐쉬한 파일의 핸들을 닫는다(close).
파일시스템에서 파일이 변경되면 파일을 다시 캐쉬하기위해
서버를 재시작해야 한다.stat()
시스템호출이 필요하기때문에 inode나 심볼링크 등을
경로를 지정할 수 없다. 이 모듈은 mod_alias나
mod_rewrite로 재작성한 파일명을 다룰 수
있기도 없기도 하다.예제
CacheFile /usr/local/apache/htdocs/index.html
MMapFile 지시어
설명: 시작시 여러 파일을 메모리에 대응한다 문법: MMapFile file-path [file-path] ...사용장소: 주서버설정 상태: Experimental 모듈: mod_file_cache MMapFile 지시어는 서버가 시작할때
(공백으로 구분한 아규먼트로 지정한) 여러 파일을 메모리에
대응한다(map). 서버 종료시 자동으로 대응을 푼다(unmap).
파일시스템에서 파일이 변경되면 파일들을 다시
mmap()하기위해 최소한 서버에 HUP이나
USR1 시그널을 보내야 한다.stat()
시스템호출이 필요하기때문에 inode나 심볼링크 등을
경로를 지정할 수 없다. 이 모듈은 mod_alias나
mod_rewrite로 재작성한 파일명을 다룰 수
있기도 없기도 하다.예제
MMapFile /usr/local/apache/htdocs/index.html
mod/mod_imap.html 100644 0 0 40031 11074463123 11456 0 ustar 0 0
아파치 모듈 mod_headers
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: HTTP 요청 헤더와 응답 헤더 수정 상태: Extension 모듈명: headers_module 소스파일: mod_headers.c 지원: RequestHeader는 아파치 2.0에만
있다요약
처리 순서
mod_headers가 제공하는 지시어는 서버설정의
거의 모든 장소에서 사용할 수 있다. 지시어는 주서버설정,
가상호스트 섹션, <Directory>, <Location>, <Files> 섹션, .htaccess
파일에서 사용할 수 있다.
<Directory> 섹션과
.htaccess<Files><Location>
RequestHeader append MirrorID "mirror 12"
RequestHeader unset MirrorID
MirrorID 헤더가 나오지
않는다. 반대로 적으면 MirrorID 헤더를 "mirror 12"로 설정한다.
예제
Header echo ^TS
MyHeader 헤더를 추가한다. 클라이언트는
이 헤더를 보고 서버의 부하를 추정하거나 클라이언트와
서버간의 병목점을 찾을 수 있다.
Header add MyHeader "%D %t"
MyHeader: D=3775428 t=991424704447256
Header add MyHeader "Hello Joe. It took %D microseconds \
for Apache to serve this request."
MyHeader: Hello Joe. It took D=3775428 microseconds for Apache
to serve this request.
MyHeader를 보낸다. 특정 클라이언트에게만
응답에 헤더를 추가할때 유용하다. 이 예제가 동작하려면
mod_setenvif 모듈이 필요하다.
SetEnvIf MyRequestHeader value HAVE_MyRequestHeader
Header add MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
MyRequestHeader: value 헤더가
있다면, 응답에 다음과 같은 헤더가 생긴다.
MyHeader: D=3775428 t=991424704447256 mytext
Header 지시어
설명: HTTP 응답 헤더를 구성한다 문법: Header [condition] set|append|add|unset|echo
header [value] [env=[!]variable]사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Extension 모듈: mod_headers 지원: Condition은 아파치 2.0.51 부터 onsuccess 혹은 always를 사용한다.
이는 어떤 내부 헤더표에 동작할지를 결정한다.
onsuccess는 2xx 상태코드를
뜻하고, always는 (2xx를
포함한) 모든 상태코드를 뜻한다. 특히 어떤 모듈이 설정한
헤더를 해제하고 싶다면, 둘중 어떤 것을 사용할지 잘 살펴봐야
한다.
setappendaddappend를
사용해야 한다.unsetechoset,
append, add, unset에서
대소문자는 무시한다. echo의 header
이름은 대수문자를 구별하고 정규표현식을 사용할 수 있다.add, append, set을
사용할때는 세번째 아규먼트 value가 필요하다.
value 안에 공백이 있다면 쌍따옴표로 묶어야 한다.
value는 일반 문자열이나 형식을 기술하는 문자열이며,
두가지를 같이 사용할 수도 있다. value에서 지원하는
형식기술자는 다음과 같다.
%t요청을 받은 시간을 국제표준시로 epoch (1970년 1월
1일) 이후 지난 마이크로초 단위로. 값 앞에 t=이
붙는다.%D요청을 받은 시간부터 헤더를 네트웍에 쓸때까지 걸린
시간. 요청의 기간을 잰다. 값 앞에 D=이
붙는다.%{FOOBAR}e환경변수 FOOBAR의
내용.Header 지시어의 add,
append, set 아규먼트를 사용하는
경우 네번째 아규먼트로 작업에 필요한 조건을 지정할 수 있다.
env=... 아규먼트를 사용하면 해당 환경변수가 존재하는 경우에만 (아니면
env=!...에 나온 환경변수가 존재하지 않다면)
Header 지시어가 동작한다.
그렇지 않으면 지시어는 요청에 아무 영향을 미치지 않는다.Header 지시어를 처리한다.
그래서 헤더 필터가 추가하는 헤더를 제외한 대부분의 헤더를
설정하거나 덮어쓸 수 있다.RequestHeader 지시어
설명: HTTP 요청 헤더를 구성한다 문법: RequestHeader set|append|add|unset header
[value]사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Extension 모듈: mod_headers
setappendaddappend를
사용해야 한다.unsetadd,
append, set을 사용할때는 세번째
아규먼트 value가 필요하다. value 안에
공백이 있다면 쌍따옴표로 묶어야 한다. unset을 사용할때는
value를 적으면 안된다.RequestHeader 지시어를 처리한다.
그래서 브라우저에 따라 혹은 아파치 입력필터가 헤더를 덮어쓰거나
수정할 수 있다.
mod/mod_include.html 100644 0 0 113711 11074463123 12201 0 ustar 0 0
아파치 모듈 mod_imap
설명: 서버측 이미지맵(imagemap) 처리 상태: Base 모듈명: imap_module 소스파일: mod_imap.c 요약
imagemap CGI 프로그램을 대신하여
.map 파일을 처리한다. 이 모듈은 (AddHandler나 SetHandler를 사용하여)
imap-file 핸들러를 사용하도록 설정한 디렉토리나
문서를 처리한다..map으로 끝나는 파일을 이미지맵
파일로 설정한다.AddHandler imap-file mapAddType application/x-httpd-imap map
새로운 기능
base 맵지시어를 사용하여 기본
<base> 지정.imagemap.conf 파일 필요없음.
이미지맵 파일
directive value [x,y ...]
directive value "Menu text" [x,y
...]
directive value x,y ... "Menu text"
base, default,
poly, circle, rect,
point 중 하나다. value에는 절대 URL이나 상대
URL 혹은 아래에서 열거할 특수값을 사용한다. 좌표는 공백으로
구분한 x,y 쌍이다. 따옴표로
묶은 문구는 이미지맵 메뉴를 만들때 링크 제목으로 사용한다.
'#'로 시작하는 줄은 주석이다.이미지맵 파일 지시어
base 지시어<base href="value">
기능을 한다. 맵파일에서 나오는 URL은 절대 URL이 아니라면
이 값에 상대 URL로 취급한다. base 지시어는
.htaccess 파일이나 서버설정파일에서 설정한
ImapBase 값을
무시한다. ImapBase 설정지시어가
없다면 기본 base 값은
http://server_name/이다.base_uri는 base와 같다. URL에서
마지막 슬래쉬를 잊지마라.default 지시어poly, circle,
rect 지시어에 해당하지 않고 point
지시어를 사용하지 않은 경우 행동을 지정한다. ImapDefault 설정이 없다면
기본값은 204 No Content 상태코드를 반환하는
nocontent이다. 이 경우 클라이언트는 동일한
페이지를 보여줘야 한다.poly 지시어circlerect 지시어point 지시어point 지시어를 사용하고 유효한
좌표를 선택한 경우 default는 절대로 사용되지
않는다.지시어에 사용할 수 있는 값들
base 값을 기준으로
찾는다.base를 설정할때는 현재 base값은 무시한다.
그러나, base mailto: 문은 사용할 수 있다.mapImapMenu가 none이
아니라면 메뉴를 만든다.menumap과 같다.refererReferer: 헤더가 없다면 기본값은
http://servername/이다.nocontent204 No Content 상태코드를 보낸다.
base를 제외한 모든 지시어에서 사용할 수 있다.error500 Server Error를 보낸다.
base를 제외한 모든 지시어에서 사용할 수 있지만,
default 외에는 사용할 일이 없다.좌표
0,0 200,2000,0 좌표를 선택하였다면
좌표를 선택하지 않은 것처럼 동작한다.따옴표로 묶은 문구
"Menu Text"
<a href="http://foo.com/">Menu text</a>
<a href="http://foo.com/">http://foo.com</a>
"와
같이 적어야 한다.
맵파일 예제
#'formatted'나 'semiformatted' 메뉴는 주석을 출력한다.
#그리고 주석에 html 태그를 쓸 수 있다. <hr>
base referer
poly map "메뉴를 보여주세요." 0,0 0,10 10,10 10,0
rect .. 0,0 77,27 "참조 문서가 있는 디렉토리"
circle http://www.inetnebr.com/lincoln/feedback/ 195,0 305,27
rect another_file "참조 문서와 같은 디렉토리에 있는" 306,0 419,27
point http://www.zyzzyva.com/ 100,100
point http://www.tripod.com/ 200,200
rect mailto:nate@tripod.com 100,150 200,0 "버그?"
맵파일 사용하기
HTML 에제
<a href="/maps/imagemap1.map">
<img ismap src="/images/imagemap1.gif">
</a>
XHTML 예제
<a href="/maps/imagemap1.map">
<img ismap="ismap" src="/images/imagemap1.gif" />
</a>
ImapBase 지시어
설명: 이미지맵 파일에서 base 기본값문법: ImapBase map|referer|URL기본값: ImapBase http://servername/사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_imap ImapBase 지시어는 이미지맵 파일에서
사용할 base 기본값을 설정한다. 이미지맵 파일
안에서 base 지시어를 사용하면 여기서 설정한
값은 무시한다. 둘 모두 없다면, base 기본값은
http://servername/이다.참고
ImapDefault 지시어
설명: 이미지맵에 어느 영역에도 해당하지 않는 좌표를 준
경우 기본 행동 문법: ImapDefault error|nocontent|map|referer|URL기본값: ImapDefault nocontent사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_imap ImapDefault 지시어는 이미지맵
파일에서 사용할 default 기본값을 설정한다.
이미지맵 파일 안에서 default 지시어를 사용하면
여기서 설정한 값은 무시한다. 둘 모두 없다면, default
행동은 클라이언트에게 204 No Content를 보내는
nocontent이다. 이 경우 클라이언트는 원래 페이지를
그대로 보여줘야 한다.ImapMenu 지시어
설명: 좌표없이 이미지맵 요청시 취할 행동 문법: ImapMenu none|formatted|semiformatted|unformatted사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Indexes 상태: Base 모듈: mod_imap ImapMenu 지시어는 이미지맵 파일에
유효한 좌표를 주지 않은 경우 취할 행동을 결정한다.
nonenone이면, 메뉴를 만들지않고
default 행동을 취한다.formattedformatted 메뉴는 가장 간단한 메뉴다.
이미지맵 파일의 주석은 무시한다. 가장 큰 표제와 수직선을
출력하고, 링크를 한줄씩 출력한다. 메뉴는 일관되고 평이하며,
디렉토리 목록과 흡사하다.semiformattedsemiformatted 메뉴는 이미지맵 파일에
나오는 주석을 출력한다. 빈줄은 HTML 행바꿈으로 변환한다.
표제나 수직선을 그리지 않지만, 나머지는 formatted
메뉴와 같다.unformatted
mod/mod_info.html 100644 0 0 13050 11074463123 11464 0 ustar 0 0
Apache Module mod_include
Description: Server-parsed html documents (Server Side Includes) Status: Base Module쟅dentifier: include_module Source쟂ile: mod_include.c Compatibility: Implemented as an output filter since Apache
2.0 Summary
Directives
Topics
Enabling Server-Side Includes PATH_INFO with Server Side Includes Basic Elements Include Variables Variable Substitution Flow Control ElementsSee also
Enabling Server-Side Includes
INCLUDES filter. If
documents containing server-side include directives are given
the extension .shtml, the following directives will make Apache
parse them and assign the resulting document the mime type of
text/html:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
<Directory> section,
but this directive is also valid in .htaccess files if
AllowOverride Options
is set):
Options +Includes
server-parsed
handler also activates the
INCLUDES filter. As well, Apache will activate the INCLUDES
filter for any document with mime type
text/x-server-parsed-html or
text/x-server-parsed-html3 (and the resulting
output will have the mime type text/html).
PATH_INFO with Server Side Includes
PATH_INFO (trailing pathname information)
by default. You can use the AcceptPathInfo directive to
configure the server to accept requests with PATH_INFO.
Basic Elements
<!--#element attribute=value
attribute=value ... -->
') and backticks (`) are also
possible. Many commands only allow a single attribute-value pair.
Note that the comment terminator (-->) should be
preceded by whitespace to ensure that it isn't considered part of
an SSI token. Note that the leading <!--# is one
token and may not contain any whitespaces.
Element Description configconfigure output formats echoprint variables execexecute external programs fsizeprint size of a file flastmodprint last modification time of a file includeinclude a file printenvprint all available variables setset a value of a variable mod_include. In fact, the exec element is provided by
mod_cgi, and will only be available if this
module is loaded.The config Element
errmsgSSIErrorMsg directives.sizefmtbytes
for a count in bytes, or abbrev for a count
in Kb or Mb as appropriate, for example a size of 1024 bytes
will be printed as "1K".timefmtstrftime(3) library routine when printing
dates.The echo Element
SSIUndefinedEcho directive. Any dates printed are
subject to the currently configured timefmt.
varencodingnone, no encoding will be done. If set to
url, then URL encoding (also known as %-encoding;
this is appropriate for use within URLs in links, etc.) will be
performed. At the start of an echo element,
the default is set to entity, resulting in entity
encoding (which is appropriate in the context of a block-level
HTML element, e.g. a paragraph of text). This can be
changed by adding an encoding attribute, which will
remain in effect until the next encoding attribute
is encountered or the element ends, whichever comes first.encoding attribute must precede the
corresponding var attribute to be effective, and
only special characters as defined in the ISO-8859-1 character
encoding will be encoded. This encoding process may not have the
desired result if a different character encoding is in use.
In order to avoid cross-site scripting issues, you should
always encode user supplied data.
The exec Element
exec command executes a given shell command or
CGI script. It requires mod_cgi to be present
in the server. If Options
IncludesNOEXEC is set, this command is completely
disabled. The valid attributes are:
cgiScriptAlias
or Options
ExecCGI).PATH_INFO and query
string (QUERY_STRING) of the original request from the
client; these cannot be specified in the URL path. The
include variables will be available to the script in addition to
the standard CGI environment.Example
<!--#exec cgi="/cgi-bin/example.cgi" -->
Location: header instead of
output, then this will be translated into an HTML anchor.include virtual
element should be used in preference to exec cgi. In
particular, if you need to pass additional arguments to a CGI program,
using the query string, this cannot be done with exec
cgi, but can be done with include virtual, as
shown here:
<!--#include virtual="/cgi-bin/example.cgi?argument=value" -->
cmd/bin/sh. The include variables are available to the command, in addition
to the usual set of CGI variables.#include virtual is almost always prefered to using
either #exec cgi or #exec cmd. The former
(#include virtual) uses the standard Apache sub-request
mechanism to include files or scripts. It is much better tested and
maintained.exec directive, or otherwise include
spaces in the command. Thus, while the following will work under a
non-suexec configuration on unix, it will not produce the desired
result under Win32, or when running suexec:
<!--#exec cmd="perl /path/to/perlscript arg1 arg2" -->
The fsize Element
sizefmt format specification. Attributes:
filevirtualThe flastmod Element
timefmt format
specification. The attributes are the same as for the
fsize command.The include Element
IncludesNOEXEC set, then only documents with
a text MIME type (text/plain, text/html
etc.) will be included. Otherwise CGI scripts are invoked as normal
using the complete URL given in the command, including any query
string.
file../, nor can it be an absolute path.
Therefore, you cannot include files that are outside of the
document root, or above the current document in the directory
structure. The virtual attribute should always be
used in preference to this one.virtual
<!--#include virtual="/cgi-bin/example.cgi?argument=value" -->
include virtual should be used in preference
to exec cgi to include the output of CGI programs
into an HTML document.The printenv Element
echo element for details)
before being output. There are no attributes.Example
<!--#printenv -->
The set Element
varvalueExample
<!--#set var="category" value="help" -->
Include Variables
echo command, for
if and elif, and to any program
invoked by the document.
DATE_GMTDATE_LOCALDOCUMENT_NAMEDOCUMENT_URILAST_MODIFIEDQUERY_STRING_UNESCAPED& etc. are
preceded by backslashes).
Variable Substitution
config,
exec, flastmod, fsize,
include, echo, and set
directives, as well as the arguments to conditional operators.
You can insert a literal dollar sign into the string using backslash
quoting:
<!--#if expr="$a = \$test" -->
<!--#set var="Zed" value="${REMOTE_HOST}_${REQUEST_METHOD}" -->
Zed variable being set
to "X_Y" if REMOTE_HOST is
"X" and REQUEST_METHOD is
"Y".DOCUMENT_URI is /foo/file.html, "in bar"
if it is /bar/file.html and "in neither" otherwise:
<!--#if expr='"$DOCUMENT_URI" = "/foo/file.html"' -->
in foo
<!--#elif expr='"$DOCUMENT_URI" = "/bar/file.html"' -->
in bar
<!--#else -->
in neither
<!--#endif -->
Flow Control Elements
<!--#if expr="test_condition" -->
<!--#elif expr="test_condition" -->
<!--#else -->
<!--#endif -->
if element works like an if statement in a
programming language. The test condition is evaluated and if
the result is true, then the text until the next elif,
else or endif element is included in the
output stream.elif or else statements are be used
to put text into the output stream if the original
test_condition was false. These elements are optional.endif element ends the if element
and is required.
stringstring1 = string2
string1 != string2/string2/
then it is treated as a regular expression. Regular expressions are
implemented by the PCRE engine and
have the same syntax as those in perl
5.=), you can capture
grouped parts of the regular expression. The captured parts are
stored in the special variables $1 ..
$9.Example
<!--#if expr="$QUERY_STRING = /^sid=([a-zA-Z0-9]+)/" -->
<!--#set var="session" value="$1" -->
<!--#endif -->
string1 < string2
string1 <= string2
string1 > string2
string1 >= string2strcmp(3)). Therefore the string "100" is less than
"20".( test_condition )! test_conditiontest_condition1 &&
test_condition2test_condition1 ||
test_condition2=" and "!=" bind more tightly than
"&&" and "||". "!" binds
most tightly. Thus, the following are equivalent:
<!--#if expr="$a = test1 && $b = test2" -->
<!--#if expr="($a = test1) && ($b = test2)" -->
&& and ||
share the same priority. So if you want to bind such an operator more
tightly, you should use parentheses.'string'. Unquoted strings can't contain whitespace
(blanks and tabs) because it is used to separate tokens such as
variables. If multiple strings are found in a row, they are
concatenated using blanks. So,string1 string2 results in string1 string2
and
'string1 string2' results in string1 string2.SSIEndTag Directive
Description: String that ends an include element Syntax: SSIEndTag tagDefault: SSIEndTag "-->"Context: server config, virtual host Status: Base Module: mod_include Compatibility: Available in version 2.0.30 and later. mod_include
looks for to mark the end of an include element.Example
SSIEndTag "%>"
See also
SSIErrorMsg Directive
Description: Error message displayed when there is an SSI
error Syntax: SSIErrorMsg messageDefault: SSIErrorMsg "[an error occurred while processing this
directive]"Context: server config, virtual host, directory, .htaccess Override: All Status: Base Module: mod_include Compatibility: Available in version 2.0.30 and later. SSIErrorMsg directive changes the error
message displayed when mod_include encounters an
error. For production servers you may consider changing the default
error message to "<!-- Error -->" so that
the message is not presented to the user.<!--#config
errmsg=message --> element.Example
SSIErrorMsg "<!-- Error -->"
SSIStartTag Directive
Description: String that starts an include element Syntax: SSIStartTag tagDefault: SSIStartTag "<!--#"Context: server config, virtual host Status: Base Module: mod_include Compatibility: Available in version 2.0.30 and later. mod_include
looks for to mark an include element to process.Example
SSIStartTag "<%"
SSIEndTag "%>"
SSIEndTag, will
allow you to use SSI directives as shown in the example
below:SSI directives with alternate start and end tags
<%printenv %>
See also
SSITimeFormat Directive
Description: Configures the format in which date strings are
displayed Syntax: SSITimeFormat formatstringDefault: SSITimeFormat "%A, %d-%b-%Y %H:%M:%S %Z"Context: server config, virtual host, directory, .htaccess Override: All Status: Base Module: mod_include Compatibility: Available in version 2.0.30 and later. DATE environment variables. The
formatstring is as in strftime(3) from the
C standard library.<!--#config
timefmt=formatstring --> element.Example
SSITimeFormat "%R, %B %d, %Y"
SSIUndefinedEcho Directive
Description: String displayed when an unset variable is echoed Syntax: SSIUndefinedEcho stringDefault: SSIUndefinedEcho "(none)"Context: server config, virtual host Status: Base Module: mod_include Compatibility: Available in version 2.0.34 and later. mod_include
displays when a variable is not set and "echoed".Example
SSIUndefinedEcho "<!-- undef -->"
XBitHack Directive
Description: Parse SSI directives in files with the execute bit
set Syntax: XBitHack on|off|fullDefault: XBitHack offContext: server config, virtual host, directory, .htaccess Override: Options Status: Base Module: mod_include XBitHack directive controls the parsing
of ordinary html documents. This directive only affects files associated
with the MIME type text/html. XBitHack can take on the following values:
offontext/html file that has the user-execute bit
set will be treated as a server-parsed html document.fullon but also test the group-execute bit.
If it is set, then set the Last-modified date of the
returned file to be the last modified time of the file. If
it is not set, then no last-modified date is sent. Setting
this bit allows clients and proxies to cache the result of
the request.
Note
#include a CGI or otherwise produces different output on
each hit (or could potentially change on subsequent requests).
mod/mod_isapi.html 100644 0 0 44047 11074463123 11650 0 ustar 0 0
아파치 모듈 mod_info
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 서버 설정에 대한 종합적인 정보를 보여준다 상태: Extension 모듈명: info_module 소스파일: mod_info.c 요약
mod_info를 사용하려면 httpd.conf
파일에 다음과 같이 추가한다.
<Location /server-info>
SetHandler server-info
</Location>
<Location> 지시어 안에 <Limit> 구문을 추가할
수 있다.http://your.host.dom/server-info에
접근하여 서버에 대한 정보를 볼 수 있다.
모듈은 서버가 시작할때 설정파일을 읽기때문에, 서버를 재시작한
후에 파일을 수정하였다면 화면에 표시된 정보가 실행중인
서버의 실제 설정과 다를 수 있다. 또, 설정파일은
서버를 실행하는 사용자(
User 지시어 참고)가 읽을
수 있어야 한다. 읽을 수 없다면 지시어 설정을 보여주지
못한다.
mod_info가 컴파일되있다면,
디렉토리별 설정파일(예를 들어,
.htaccess)을 포함한 모든 설정파일에서
이 핸들러 기능을 사용할 수 있다. 그래서 사이트에 보안관련
문제가 될 수 있다.지시어들
AddModuleInfo 지시어
설명: 모듈에 대한 추가 정보를 server-info 핸들러가 보여주도록
추가한다 문법: AddModuleInfo module-name string사용장소: 주서버설정, 가상호스트 상태: Extension 모듈: mod_info 지원: 아파치 1.3 이후
AddModuleInfo mod_auth.c 'See <a \
href="http://www.apache.org/docs/2.0/mod/mod_auth.html">\
http://www.apache.org/docs/2.0/mod/mod_auth.html</a>'
mod/mod_ldap.html 100644 0 0 57001 11074463123 11455 0 ustar 0 0
아파치 모듈 mod_isapi
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: Windows용 아파치에서 ISAPI Extension 사용 상태: Base 모듈명: isapi_module 소스파일: mod_isapi.c 지원: Win32 only 요약
지시어들
ISAPIAppendLogToErrors ISAPIAppendLogToQuery ISAPICacheFile ISAPIFakeAsync ISAPILogNotSupported ISAPIReadAheadBuffer주제
사용법
AddHandler 지시어를 사용하여
ISAPI 파일 확장자와 isapi-isa 핸들러를 연결한다.
.dll 파일을 ISAPI extension으로 처리하려면 httpd.conf 파일에
다음과 같이 추가한다.
AddHandler isapi-isa .dll
ISAPICacheFile c:/WebWork/Scripts/ISAPI/mytest.dll
Options ExecCGI가
필요하다.
추가 설명
ISAPILogNotSupported Off 지시어를 사용하면
로그에 기록하지 않는다.ISAPICacheFile 지시어를 사용하지
않는다면 요청을 받을때마다 ISAPI extension을 메모리에 읽어들이고
버린다. 비효율적이지만, 아파치의 메모리 구조상 이것이 가장
효율적인 방법이다. 여러 ISAPI 모듈이 아파치 서버와 약간
호환이 안맞기때문에 서버의 안정성을 위해 모듈을 메모리에서
버린다.
개발자 정보
mod_isapi 모듈을 프로그래밍한다면,
ServerSupportFunction 호출을 다음 지시어로
제한해야 한다.
HSE_REQ_SEND_URL_REDIRECT_RESP
완전한 URL을 사용해야 한다 (예를 들어,
http://server/location).HSE_REQ_SEND_URL
완전한 URL이 아니며, 프로토콜과 서버명을 넘길 수 없다
(예를 들어, /location같은 것만 가능).
브라우저가 아니라 서버가 리다이렉션을 처리한다.
경고
HSE_REQ_SEND_URL
기능간의 차이를 없앤 것처럼 보인다. 아파치는 계속 이
둘의 아규먼트 조건과 행동을 다르게 처리할 것이다.HSE_REQ_SEND_RESPONSE_HEADERHSE_REQ_DONE_WITH_SESSIONHSE_REQ_MAP_URL_TO_PATHHSE_APPEND_LOG_PARAMETER
CustomLog
지시어의 \"%{isapi-parameter}n\" 항목에ISAPIAppendLogToQuery
On 지시어를 사용하여 %q
로그 항목에ISAPIAppendLogToErrors
On 지시어를 사용하여 오류 로그에%{isapi-parameter}n 항목은
언제나 사용할 수 있으며 권장한다.HSE_REQ_IS_KEEP_CONNHSE_REQ_SEND_RESPONSE_HEADER_EXfKeepConn 옵션을 무시하는 것을 제외하고는
문서에 나온데로 동작한다.HSE_REQ_IS_CONNECTEDServerSupportFunction 호출을
하면 아파치는 FALSE를 반환하고
GetLastError 값을
ERROR_INVALID_PARAMETER로 설정한다.ReadClient는 (ISAPIReadAheadBuffer로 정의한)
초기버퍼크기를 넘어선 요청 내용을 가져온다.
ISAPIReadAheadBuffer 설정 (ISAPI
핸들러를 부르기전 버퍼의 바이트수) 보다 짧은 요청은 extension을
부를때 전부 전달된다. 요청이 길면, ISAPI extension은
ReadClient로 나머지 요청 내용을 가져와야 한다.WriteClient를 지원하지만,
HSE_IO_SYNC 옵션만 사용하거나 (0
값) 아무 옵션도 사용하지 않아야 한다. 다른
WriteClient 요청은 FALSE를 반환하며
실패하고, GetLastError 값은
ERROR_INVALID_PARAMETER가 된다.GetServerVariable은 지원하지만, (다른 서버에서
정의하는) 확장 서버변수는 없다.
GetServerVariable에서 모든 일반적인 아파치
CGI 환경변수와 ALL_HTTP, ALL_RAW
값을 사용할 수 있다.mod_isapi는 이후 ISAPI 규약에
나온 추가 기능을 지원하고, 비동기 입출력과
TransmitFile 기능을 조금 흉내낸다. 또, ISAPI
.dll을 미리 읽어들여서 성능을 높이는 아파치 1.3
mod_isapi에는 없는 기능을 지원한다.ISAPIAppendLogToErrors 지시어
설명: ISAPI exntension의 HSE_APPEND_LOG_PARAMETER
요청을 오류 로그에 기록한다문법: ISAPIAppendLogToErrors on|off기본값: ISAPIAppendLogToErrors off사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_isapi HSE_APPEND_LOG_PARAMETER
요청을 오류 로그에 기록한다.ISAPIAppendLogToQuery 지시어
설명: ISAPI exntension의 HSE_APPEND_LOG_PARAMETER
요청을 질의문자열에 기록한다문법: ISAPIAppendLogToQuery on|off기본값: ISAPIAppendLogToQuery on사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_isapi HSE_APPEND_LOG_PARAMETER
요청을 질의문자열에 기록한다 (CustomLog %q
항목에 덧붙인다).ISAPICacheFile 지시어
설명: 서버가 시작할때 메모리로 읽어들일 ISAPI .dll 파일들 문법: ISAPICacheFile file-path [file-path]
...사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_isapi ServerRoot에 상대 경로로 받아들인다.ISAPIFakeAsync 지시어
설명: 비동기 ISAPI 콜백을 지원하는 척한다 문법: ISAPIFakeAsync on|off기본값: ISAPIFakeAsync off사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_isapi ISAPILogNotSupported 지시어
설명: ISAPI extension이 지원하지 않는 기능을 요청하면
로그에 기록한다 문법: ISAPILogNotSupported on|off기본값: ISAPILogNotSupported off사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_isapi ISAPIReadAheadBuffer 지시어
설명: ISAPI extension의 미리읽기버퍼(read ahead buffer)
크기 문법: ISAPIReadAheadBuffer size기본값: ISAPIReadAheadBuffer 49152사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_isapi ReadClient
콜백을 사용하여 읽어야 한다. 어떤 ISAPI extension은
ReadClient 기능을 지원하지 않는다. 이 경우
ISAPI extension 제작자에게 문의하라.
mod/mod_log_config.html 100644 0 0 51254 11074463123 12647 0 ustar 0 0
Apache Module mod_ldap
Description: LDAP connection pooling and result caching services for use
by other LDAP modules Status: Experimental Module쟅dentifier: ldap_module Source쟂ile: util_ldap.c Compatibility: Available in version 2.0.41 and later Summary
--with-ldap
flag to the configure script when building
Apache.mod_ldap be linked
with one of the following LDAP SDKs:
OpenLDAP SDK (both 1.x and 2.x),
Novell LDAP SDK or the
iPlanet(Netscape) SDK.Directives
LDAPCacheEntries LDAPCacheTTL LDAPConnectionTimeout LDAPOpCacheEntries LDAPOpCacheTTL LDAPSharedCacheFile LDAPSharedCacheSize LDAPTrustedCA LDAPTrustedCATypeTopics
Example Configuration
mod_ldap to increase the performance of HTTP Basic
authentication provided by mod_auth_ldap.
# Enable the LDAP connection pool and shared
# memory cache. Enable the LDAP cache status
# handler. Requires that mod_ldap and mod_auth_ldap
# be loaded. Change the "yourdomain.example.com" to
# match your domain.
LDAPSharedCacheSize 200000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600
<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPEnabled on
AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one
AuthLDAPAuthoritative on
Require valid-user
</Location>
LDAP Connection Pool
LDAP Cache
mod_ldap uses an aggressive
caching strategy to minimize the number of times that the LDAP
server must be contacted. Caching can easily double or triple
the throughput of Apache when it is serving pages protected
with mod_auth_ldap. In addition, the load on the LDAP server
will be significantly decreased.mod_ldap supports two types of LDAP caching during
the search/bind phase with a search/bind cache and
during the compare phase with two operation
caches. Each LDAP URL that is used by the server has
its own set of these three caches.The Search/Bind Cache
mod_ldap stores the username, the DN
retrieved, the password used to bind, and the time of the bind
in the cache. Whenever a new connection is initiated with the
same username, mod_ldap compares the password
of the new connection with the password in the cache. If the
passwords match, and if the cached entry is not too old,
mod_ldap bypasses the search/bind phase.LDAPCacheEntries and LDAPCacheTTL directives.Operation Caches
mod_ldap uses two operation caches
to cache the compare operations. The first compare cache is
used to cache the results of compares done to test for LDAP
group membership. The second compare cache is used to cache
the results of comparisons done between distinguished
names.LDAPOpCacheEntries
and LDAPOpCacheTTL
directives.Monitoring the Cache
mod_ldap has a content handler that allows
administrators to monitor the cache performance. The name of
the content handler is ldap-status, so the
following directives could be used to access the
mod_ldap cache information:
<Location /server/cache-info>
SetHandler ldap-status
</Location>
http://servername/cache-info,
the administrator can get a status report of every cache that is used
by mod_ldap cache. Note that if Apache does not
support shared memory, then each httpd instance has its
own cache, so reloading the URL will result in different
information each time, depending on which httpd
instance processes the request.
Using SSL
LDAPTrustedCA and
LDAPTrustedCAType. These directives specify the certificate
file or database and the certificate type. Whenever the LDAP url
includes ldaps://, mod_ldap will establish
a secure connection to the LDAP server.
# Establish an SSL LDAP connection. Requires that
# mod_ldap and mod_auth_ldap be loaded. Change the
# "yourdomain.example.com" to match your domain.
LDAPTrustedCA /certs/certfile.der
LDAPTrustedCAType DER_FILE
<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPEnabled on
AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
AuthLDAPAuthoritative on
Require valid-user
</Location>
mod_ldap is linked against the
Netscape/iPlanet LDAP SDK, it will not talk to any SSL server
unless that server has a certificate signed by a known Certificate
Authority. As part of the configuration
mod_ldap needs to be told where it can find
a database containing the known CAs. This database is in the same
format as Netscape Communicator's cert7.db
database. The easiest way to get this file is to start up a fresh
copy of Netscape, and grab the resulting
$HOME/.netscape/cert7.db file.LDAPCacheEntries Directive
Description: Maximum number of entries in the primary LDAP cache Syntax: LDAPCacheEntries numberDefault: LDAPCacheEntries 1024Context: server config Status: Experimental Module: mod_ldap LDAPCacheTTL Directive
Description: Time that cached items remain valid Syntax: LDAPCacheTTL secondsDefault: LDAPCacheTTL 600Context: server config Status: Experimental Module: mod_ldap LDAPConnectionTimeout Directive
Description: Specifies the socket connection timeout in seconds Syntax: LDAPConnectionTimeout secondsContext: server config Status: Experimental Module: mod_ldap LDAPOpCacheEntries Directive
Description: Number of entries used to cache LDAP compare
operations Syntax: LDAPOpCacheEntries numberDefault: LDAPOpCacheEntries 1024Context: server config Status: Experimental Module: mod_ldap mod_ldap
will use to cache LDAP compare operations. The default is 1024
entries. Setting it to 0 disables operation caching.LDAPOpCacheTTL Directive
Description: Time that entries in the operation cache remain
valid Syntax: LDAPOpCacheTTL secondsDefault: LDAPOpCacheTTL 600Context: server config Status: Experimental Module: mod_ldap LDAPSharedCacheFile Directive
Description: Sets the shared memory cache file Syntax: LDAPSharedCacheFile directory-path/filenameContext: server config Status: Experimental Module: mod_ldap LDAPSharedCacheSize Directive
Description: Size in bytes of the shared-memory cache Syntax: LDAPSharedCacheSize bytesDefault: LDAPSharedCacheSize 102400Context: server config Status: Experimental Module: mod_ldap LDAPTrustedCA Directive
Description: Sets the file containing the trusted Certificate Authority certificate or database Syntax: LDAPTrustedCA directory-path/filenameContext: server config Status: Experimental Module: mod_ldap mod_ldap should use when establishing an SSL
connection to an LDAP server. If using the Netscape/iPlanet Directory
SDK, the file name should be cert7.db.LDAPTrustedCAType Directive
Description: Specifies the type of the Certificate Authority file Syntax: LDAPTrustedCAType typeContext: server config Status: Experimental Module: mod_ldap
DER_FILE - file in binary DER format
BASE64_FILE - file in Base64 format
CERT7_DB_PATH - Netscape certificate database file ")
mod/mod_log_forensic.html 100644 0 0 22525 11074463123 13211 0 ustar 0 0
아파치 모듈 mod_log_config
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 서버로의 요청을 로그에 기록한다 상태: Base 모듈명: log_config_module 소스파일: mod_log_config.c 요약
TransferLog는 로그파일을
만들고, LogFormat은
원하는 형식을 정하고, CustomLog는 한번에 로그파일과
형식을 모두 지정한다. TransferLog와
CustomLog 지시어를 여러번 사용하면
요청을 여러 파일에 기록할 수 있다.
로그 형식 지정하기
LogFormat과
CustomLog
지시어의 형식 아규먼트는 문자열이다. 이 문자열에 따라 요청을
로그파일에 기록한다. 문자열에는 로그파일에 그대로 복사되는
문자와 행바꿈과 탭을 나타내는 C의 "\n"과 "\t" 제어문자를
사용할 수 있다. 로그파일에 따옴표나 백슬래쉬를 쓰려면 앞에
반드시 백슬래쉬를 적어줘야 한다.%" 지시어를
사용하여 기록한다. 이 지시어는 로그파일에서 다음과 같이
변경된다.형식 문자열
설명 %%퍼센트 기호 (아파치 2.0.44 이후) %...a원격 IP-주소 %...A(서버) IP-주소 %...BHTTP 헤더를 제외한 전송 바이트수. %...bHTTP 헤더를 제외한 전송 바이트수. CLF 형식과 같이
전송한 내용이 없는 경우 0 대신 ' -'가 나온다.%...{Foobar}C서버가 수신한 요청에서 Foobar 쿠키의
내용. %...D요청을 처리하는데 걸린 시간 (마이크로초 단위). %...{FOOBAR}e환경변수 FOOBAR의 내용 %...f파일명 %...h원격 호스트 %...H요청 프로토콜 %...{Foobar}i서버가 수신한 요청에서 Foobar:
헤더의 내용.%...l(있다면 identd가 제공한) 원격 로그인명.
IdentityCheck가
On이 아니면 빼기기호를 기록한다.%...m요청 메써드 %...{Foobar}n다른 모듈이 기록한 Foobar 노트(note)
내용. %...{Foobar}o응답의 Foobar: 헤더 내용.%...p요청을 서비스하는 서버의 정규 포트 %...P요청을 서비스하는 자식의 프로세스 ID. %...{format}P요청을 서비스하는 자식의 프로세스 ID 혹은 쓰레드
ID. format에는 pid와 tid가
가능하다. (아파치 2.0.46 이후)
%...q질의문자열 (질의문자열이 있다면 앞에 ?를
붙이고, 없다면 빈 문자열)%...r요청의 첫번째 줄 %...s상태(status). 내부 리다이렉션된 요청의 경우 *원래*
요청의 상태이다. 최종 요청의 상태는 %...>s.%...tcommon log format 시간 형식(표준 영어 형식)의 시간 %...{format}tstrftime(3) 형식 format의 시간. (지역시간일
수 있음)%...T요청을 처리하는데 걸린 시간 (초 단위). %...u원격 사용자 (auth가 제공하며, 상태( %s)가
401인 경우 이상한 값을 나올 수 있음)%...U질의문자열을 제외한 요청 URL 경로. %...v요청을 서비스한 서버의 정규 ServerName.%...VUseCanonicalName
설정에 따른 서버명.%...X응답을 마쳤을때 연결 상태.
X =응답을 마치기 전에 연결이 끊어졌다. + =응답을 보낸후에도 연결이 살아있다(keep alive). - = 응답을 보낸후 연결이 끊어졌다. %...c였지만, 전통적인 ssl
%...{var}c 문법과 겹쳐서
변경했다.)%...I요청과 헤더를 포함한 수신 바이트수로 0일 수 없다.
이를 사용하려면 mod_logio가 필요하다.%...O헤더를 포함한 송신 바이트수로 0일 수 없다. 이를
사용하려면 mod_logio가 필요하다."%h %u %r %s %b") 아무것도 없거나, 항목을 포함할
조건이 나온다 (조건을 만족하지 않으면 자리에 "-"를 기록한다).
조건은 앞에 "!"를 붙이거나 안붙인 HTTP 상태코드 목록으로
작성한다. 예를 들어, "%400,501{User-agent}i"는 400 (Bad
Request) 오류와 501 (Not Implemented) 오류일때만
User-agent:를 로그에 남기고,
"%!200,304,302{Referer}i"는 정상적인 상태가 아닌
모든 요청에 대해 Referer:를 로그에 남긴다.%s, %U, %T, %D, %r은 처음 요청을 보고, 나머지
% 지시어는 마지막 요청을 본다. 그래서
%>s는 요청의 마지막 상태(status)를 기록하고,
%<u는 인증으로 보호하지 않는 자원으로 내부
라다이렉션된 경우에도 처음에 인증한 사용자를 기록한다.%...r,
%...i, %...o의 결과 문자열을 그대로
두었다. 이유는 Common Log Format의 요구사항을 따르기위해서였다.
즉, 클라이언트가 제어문자를 로그에 집어넣을 수 있기때문에
로그파일을 그대로 다룰 때는 조심해야 한다.\xhh로 표현한다. 여기서 hh는
해당 바이트의 16진수 표현을 나타낸다. 이 규칙의 예외는 백슬래쉬를
앞에 붙이는 "와 \, 그리고 C언어
형식의 공백문자들(\n, \t 등)이다.
"%h %l %u %t \"%r\" %>s %b""%v %h %l %u %t \"%r\" %>s %b""%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-agent}i\"""%{Referer}i -> %U""%{User-agent}i"ServerName과 Listen은 각각 %v와
%p를 사용한다. 로그분석 프로그램이 실제로 요청을
서비스하는 호스트를 알기위해 가상호스트 찾기 알고리즘을
가질 필요없도록 이들 값은 UseCanonicalName 설정과 무관하다.CookieLog 지시어
설명: 쿠키를 로그에 남기기위해 사용할 파일명을 설정한다 문법: CookieLog filename사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_log_config 지원: 이 지시어는 사용되지 않는다. CookieLog 지시어는 쿠키를 로그에
남기기위해 사용할 파일명을 설정한다. 파일명은 ServerRoot에 상대경로이다. 이
지시어는 mod_cookies와 호환을 위해 포함했을뿐,
실제 사용되지 않는다.CustomLog 지시어
설명: 로그파일 이름과 형식을 지정한다 문법: CustomLog file|pipe
format|nickname
[env=[!]environment-variable]사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_log_config CustomLog
지시어를 사용한다. 로그 형식을 지정하고, 환경변수를 사용하여
요청의 특징에 따라 선택적으로 로그를 남길 수도 있다.
ServerRoot에
상대적인 파일명.|"뒤에 로그 정보를 표준입력으로
받을 프로그램 경로를 적는다.
보안:
주의
LogFormat으로
정의한 nickname을 사용하거나 직접 로그 형식 절에서 설명한 format
문자열을 사용할 수 있다.
# 형식 별칭을 사용한 CustomLog
LogFormat "%h %l %u %t \"%r\" %>s %b" common
CustomLog logs/access_log common
# 직접 형식 문자열을 사용한 CustomLog
CustomLog logs/access_log "%h %l %u %t \"%r\" %>s %b"
env=!name'를 사용한 경우 없다면)
요청을 로그에 기록한다.mod_setenvif나 mod_rewrite
모듈을 사용하여 요청별로 환경변수를 설정할 수 있다. 예를
들어, 서버가 GIF 그림에 대한 모든 요청을 주서버 로그가 아닌
다른 로그파일에 기록하려면,
SetEnvIf Request_URI \.gif$ gif-image
CustomLog gif-requests.log common env=gif-image
CustomLog nongif-requests.log common env=!gif-image
LogFormat 지시어
설명: 로그파일에 사용할 형식을 기술한다 문법: LogFormat format|nickname
[nickname]기본값: LogFormat "%h %l %u %t \"%r\" %>s %b"사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_log_config LogFormat 지시어는 두가지 형식으로
사용한다. 첫번째 형식은 아규먼트를 한개만 사용하여 다음
TransferLog 지시어들이 사용할 로그
형식을 지정한다. 이 아규먼트에 위의 로그
형식 지정하기 절에서 설명한 format을 직접
사용하거나, 다음에 설명할 LogFormat
지시어로 미리 정의한 (로그 형식을 지칭하는) nickname을
사용할 수 있다.LogFormat 지시어의 두번째 형식은
format과 nickname을 연결한다. 그러면
뒤에서 사용하는 LogFormat이나 CustomLog 지시어에 반복해서
형식 문자열을 모두 입력하는 대신 nickname을 사용할
수 있다. 별칭을 정의하는 LogFormat
지시어는 이 외에는 아무 기능을 하지 않는다.
즉, 별칭만을 정의하며, 실제로 형식을 적용하거나
형식을 기본값으로 만들지 않는다. 그러므로 다음에 나오는
TransferLog
지시어에 영향을 주지 않는다. 또,
LogFormat은 별칭으로 다른 별칭을
정의할 수 있다. 별칭 이름에는 퍼센트 기호(%)를
사용할 수 없음을 주의하라.예제
LogFormat "%v %h %l %u %t \"%r\" %>s %b" vhost_common
TransferLog 지시어
설명: 로그파일 위치를 설정한다 문법: TransferLog file|pipe사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_log_config CustomLog 지시어와 아규먼트와
기능이 비슷하지만, 로그 형식을 직접 지정하거나 요청을 조건에
따라 로그에 남길 수 없다. 대신 가장 최근 사용한 (별칭을
정의하지 않은) LogFormat 지시어가 지정한
로그 형식을 사용한다. 미리 형식을 지정하지 않았다면 Common
Log Format을 사용한다.예제
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\""
TransferLog logs/access_log
mod/mod_logio.html 100644 0 0 7552 11074463123 11634 0 ustar 0 0
Apache Module mod_log_forensic
Description: Forensic Logging of the requests made to the server Status: Extension Module쟅dentifier: log_forensic_module Source쟂ile: mod_log_forensic.c Compatibility: Available in version 2.0.50 and later Summary
CoreDumpDirectory
configuration).check_forensic script, which can be found in the
distribution's support directory, may be helpful in evaluating the
forensic log output.
This module was backported from version 2.1 which uses a more powerful
APR version in order to generate the forensic IDs. If you want to run
mod_log_forensic in version 2.0, you need to include
mod_unique_id as well.
Directives
Topics
See also
Forensic Log Format
%{forensic-id}n format string. If you're using
mod_unique_id, its generated ID will be used.|). A sample line
looks like the following (all on one line):
+yQtJf8CoAB4AAFNXBIEAAAAA|GET /manual/de/images/down.gif
HTTP/1.1|Host:localhost%3a8080|User-Agent:Mozilla/5.0 (X11;
U; Linux i686; en-US; rv%3a1.6) Gecko/20040216
Firefox/0.8|Accept:image/png, etc...
-yQtJf8CoAB4AAFNXBIEAAAAA
check_forensic script takes as its argument the name
of the logfile. It looks for those +/- ID pairs
and complains if a request was not completed.
Security Considerations
ForensicLog Directive
Description: Sets filename of the forensic log Syntax: ForensicLog filename|pipeContext: server config, virtual host Status: Extension Module: mod_log_forensic ForensicLog directive is used to
log requests to the server for forensic analysis. Each log entry
is assigned a unique ID which can be associated with the request
using the normal CustomLog
directive. mod_log_forensic takes the unique ID from
mod_unique_id, so you need to load this module as well.
(This requirement will not be necessary in version 2.1 and later, because
of a more powerful APR version.) The ID token is attached to the request
under the name forensic-id, which can be added to the
transfer log using the %{forensic-id}n format string.
ServerRoot.|", followed by the path
to a program to receive the log information on its standard
input. The program name can be specified relative to the ServerRoot directive.
Security:
httpd. This will be root if the server was
started by root; be sure that the program is secure or switches to a
less privileged user.Note
mod/mod_mem_cache.html 100644 0 0 33144 11074463123 12440 0 ustar 0 0
아파치 모듈 mod_logio
설명: 요청당 입출력 바이트수를 기록 상태: Extension 모듈명: logio_module 소스파일: mod_logio.c 요약
mod_log_config이
필요하다.
사용자정의 로그 형식
%" 지시어를 사용하여 기록한다.
지시어는 로그파일에 다음과 같은 값을 기록한다:형식문자열
설명 %...I요청과 헤더를 포함하여 받은 바이트수. 0일 수 없다. %...O헤더를 포함하여 보낸 바이트수. 0일 수 없다.
"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-agent}i\" %I %O"
mod/mod_mime.html 100644 0 0 160471 11074463123 11512 0 ustar 0 0
아파치 모듈 mod_mem_cache
설명: URI를 키로 사용하여 내용을 캐쉬한다. 상태: Experimental 모듈명: mem_cache_module 소스파일: mod_mem_cache.c 요약
이 모듈은 실험적인 상태이다. 문서는 아직 작업중이다...
mod_cache가
필요하다. 이 모듈은 mod_cache를
지원하며 메모리기반 저장관리자를 제공한다.
mod_mem_cache는 파일기술자를 캐쉬에 저장하거나
객체를 힙 공간에 캐쉬하는 두가지 방식으로 동작한다.
mod_mem_cache는 직접 서버가 생성한 페이지를
캐쉬하거나 ProxyPass로
설정한 (역프록시(reverse proxy))
mod_proxy의 뒷단 서버내용을 캐쉬할때 주로
사용한다.지시어들
MCacheMaxObjectCount MCacheMaxObjectSize MCacheMaxStreamingBuffer MCacheMinObjectSize MCacheRemovalAlgorithm MCacheSize참고
MCacheMaxObjectCount 지시어
설명: 캐쉬에 저장할 수 있는 최대 객체개수 문법: MCacheMaxObjectCount value기본값: MCacheMaxObjectCount 1009사용장소: 주서버설정 상태: Experimental 모듈: mod_mem_cache MCacheMaxObjectCount 지시어는
캐쉬할 수 있는 최대 객체개수를 설정한다. 이 값은 해쉬테이블을
만들때 사용한다. 새로운 객체를 캐쉬에 추가해야 하는데 최대
객체개수에 도달하였다면, 새로운 객체를 캐쉬할 수 있도록
다른 객체를 제거한다. MCacheRemovalAlgorithm으로
지정한 알고리즘을 사용하여 제거할 객체를 선택한다.예제
MCacheMaxObjectCount 13001
MCacheMaxObjectSize 지시어
설명: 캐쉬에 저장할 문서의 최대 크기 (바이트 단위) 문법: MCacheMaxObjectSize bytes기본값: MCacheMaxObjectSize 10000사용장소: 주서버설정 상태: Experimental 모듈: mod_mem_cache MCacheMaxObjectSize 지시어는 캐쉬에
저장할 문서의 최대 크기를 바이트 단위로 지정한다.예제
MCacheMaxObjectSize 6400000
Note
MCacheMaxObjectSize 값은 MCacheMinObjectSize
지시어로 지정한 값보다 커야 한다.MCacheMaxStreamingBuffer 지시어
설명: 응답을 캐쉬안한다고 결정하기 전까지 메모리 버퍼에
저장할 스트림 응답의 최대 크기 문법: MCacheMaxStreamingBuffer size_in_bytes기본값: MCacheMaxStreamingBuffer 100000과 MCacheMaxObjectSize
중에 작은 값사용장소: 주서버설정 상태: Experimental 모듈: mod_mem_cache MCacheMaxStreamingBuffer 지시어는
응답이 너무 커서 캐쉬할 수 없을때까지 버퍼에 저장할 스트림
응답의 최대 바이트수를 설정한다. 스트림 응답(streamed response)은
전체 내용을 즉시 알 수 없고 Content-Length도
모르는 응답이다. 프록시된 응답이나 CGI 스크립트의 출력이
스트림 응답에 속한다. 기본적으로 Content-Length
헤더가 없다면 스트림 응답을 캐쉬에 저장하지 않는다.
이유는 캐쉬에 저장하기에 너무 큰 응답의 일부를 버퍼에
저장하기위해 많은 메모리를 낭비하지 않기위해서이다.
MCacheMaxStreamingBuffer 지시어를
사용하면 Content-Length가 없는 스트림 응답을
지정한 크기까지만 버퍼에 저장한다. 최대 크기를 넘어서면
버퍼 내용을 버리고 캐쉬하지 않는다.주의:
MCacheMaxStreamingBuffer에 0이
아닌 값을 설정하여도 클라이언트로 응답을 늦게 보내지 않는다.
mod_mem_cache는 스트림 응답의 일부를
버퍼에 복사하자마자 클라이언트로 보내기위해 다음 출력필터로
보낸다.
# 스트림 응답을 64KB까지 캐쉬한다:
MCacheMaxStreamingBuffer 65536
MCacheMinObjectSize 지시어
설명: 캐쉬에 저장할 문서의 최소 크기 (바이트 단위) 문법: MCacheMinObjectSize bytes기본값: MCacheMinObjectSize 0사용장소: 주서버설정 상태: Experimental 모듈: mod_mem_cache MCacheMinObjectSize 지시어는 캐쉬에
저장할 문서의 최소 크기를 바이트 단위로 지정한다.예제
MCacheMinObjectSize 10000
MCacheRemovalAlgorithm 지시어
설명: 캐쉬에서 제거할 문서를 찾는 알고리즘 문법: MCacheRemovalAlgorithm LRU|GDSF기본값: MCacheRemovalAlgorithm GDSF사용장소: 주서버설정 상태: Experimental 모듈: mod_mem_cache MCacheRemovalAlgorithm 지시어는
캐쉬에서 제거할 문서를 찾는 알고리즘을 지정한다.
LRU (Least Recently Used)LRU는 가장 오래동안 접근하지 않은 문서를
먼저 제거한다.GDSF (GreadyDual-Size)GDSF는 캐쉬 실패(cache miss) 비용과 문서의
크기를 가지고 캐쉬한 문서에 우선순위를 부여한다. 가장
우선순위가 낮은 문서를 먼저 제거한다.예제
MCacheRemovalAlgorithm GDSF
MCacheRemovalAlgorithm LRU
MCacheSize 지시어
설명: 캐쉬에 사용할 최대 메모리량 (KByte 단위) 문법: MCacheSize KBytes기본값: MCacheSize 100사용장소: 주서버설정 상태: Experimental 모듈: mod_mem_cache MCacheSize 지시어는 캐쉬에 사용할
최대 메모리량을 KByte 단위로 (1024 바이트 단위) 설정한다.
새로운 객체을 캐쉬에 추가해야 하는데 객체의 크기가 남은
메모리보다 크다면 새로운 객체을 캐쉬할 수 있을때까지 다른
객체를 제거한다. MCacheRemovalAlgorithm으로
지정한 알고리즘을 사용하여 제거할 객체를 선택한다.예제
MCacheSize 700000
주의
MCacheSize 값은 MCacheMaxObjectSize
지시어로 지정한 값보다 커야 한다.
mod/mod_mime_magic.html 100644 0 0 32242 11074463123 12624 0 ustar 0 0
Apache Module mod_mime
Description: Associates the requested filename's extensions
with the file's behavior (handlers and filters)
and content (mime-type, language, character set and
encoding) Status: Base Module쟅dentifier: mime_module Source쟂ile: mod_mime.c Summary
mod_negotiation for more information
about content negotiation.AddCharset, AddEncoding, AddLanguage and AddType are all used to map file
extensions onto the meta-information for that file. Respectively
they set the character set, content-encoding, content-language,
and MIME-type (content-type) of documents. The directive TypesConfig is used to specify a
file which also maps extensions onto MIME types. mod_mime may define the handler and filters that originate and process
content. The directives AddHandler, AddOutputFilter, and AddInputFilter control the modules
or scripts that serve the document. The MultiviewsMatch directive allows
mod_negotiation to consider these file extensions
to be included when testing Multiviews matches.mod_mime associates meta-information
with filename extensions, the core server
provides directives that are used to associate all the files in a
given container (e.g., <Location>, <Directory>, or <Files>) with particular
meta-information. These directives include ForceType, SetHandler, SetInputFilter, and SetOutputFilter. The core directives
override any filename extension mappings defined in
mod_mime.Last-Modified header.
Thus, previously cached copies may still be used by a client or
proxy, with the previous headers. If you change the
meta-information (language, content type, character set or
encoding) you may need to 'touch' affected files (updating
their last modified date) to ensure that all visitors are
receive the corrected content headers.Directives
AddCharset AddEncoding AddHandler AddInputFilter AddLanguage AddOutputFilter AddType DefaultLanguage ModMimeUsePathInfo MultiviewsMatch RemoveCharset RemoveEncoding RemoveHandler RemoveInputFilter RemoveLanguage RemoveOutputFilter RemoveType TypesConfigTopics
See also
Files with Multiple Extensions
welcome.html.fr maps onto content type
text/html and language French then the file
welcome.fr.html will map onto exactly the same information.
If more than one extension is given which maps onto the same
type of meta-information, then the one to the right will be
used, except for languages and content encodings. For example, if
.gif maps to the MIME-type image/gif and
.html maps to the MIME-type text/html, then the
file welcome.gif.html will be associated with the MIME-type
text/html.welcome.html.en.de will be delivered with
Content-Language: en, de and Content-Type:
text/html..imap
extension is mapped to the handler imap-file (from
mod_imap) and the .html extension is
mapped to the MIME-type text/html, then the file
world.imap.html will be associated with both the
imap-file handler and text/html MIME-type.
When it is processed, the imap-file handler will be used,
and so it will be treated as a mod_imap imagemap
file.
Content encoding
gzip, it can also refer to encryption, such a
pgp or to an encoding such as UUencoding, which is
designed for transmitting a binary file in an ASCII (text)
format.
.doc extension is associated with the Microsoft
Word file type, and the .zip extension is
associated with the pkzip file encoding, then the file
Resume.doc.zip would be known to be a pkzip'ed Word
document.Content-encoding header with the
resource, in order to tell the client browser about the
encoding method.Content-encoding: pkzip
Character sets and languages
mod_negotiation) to determine
which document to give to the client, when there are
alternative documents in more than one character set, language,
encoding or mime type. All filename extensions associations
created with AddCharset,
AddEncoding, AddLanguage and AddType directives
(and extensions listed in the MimeMagicFile) participate in this select process.
Filename extensions that are only associated using the AddHandler, AddInputFilter or AddOutputFilter directives may be included or excluded
from matching by using the MultiviewsMatch directive.Charset
Content-Language header, to specify the language
that the document is in, and can append additional information
onto the Content-Type header to indicate the
particular character set that should be used to correctly
render the information.
Content-Language: en, fr
Content-Type: text/plain; charset=ISO-8859-1
charset is the name of the
particular character set which should be used.AddCharset Directive
Description: Maps the given filename extensions to the specified content
charset Syntax: AddCharset charset extension
[extension] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime AddCharset directive maps the given
filename extensions to the specified content charset. charset
is the MIME
charset parameter of filenames containing
extension. This mapping is added to any already in force,
overriding any mappings that already exist for the same
extension.Example
AddLanguage ja .ja
AddCharset EUC-JP .euc
AddCharset ISO-2022-JP .jis
AddCharset SHIFT_JIS .sjis
xxxx.ja.jis will be treated
as being a Japanese document whose charset is ISO-2022-JP
(as will the document xxxx.jis.ja). The
AddCharset directive is useful for both to
inform the client about the character encoding of the document so that
the document can be interpreted and displayed appropriately, and for content negotiation,
where the server returns one from several documents based on
the client's charset preference.See also
AddEncoding Directive
Description: Maps the given filename extensions to the specified encoding
type Syntax: AddEncoding MIME-enc extension
[extension] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime AddEncoding directive maps the given
filename extensions to the specified encoding type. MIME-enc
is the MIME encoding to use for documents containing the
extension. This mapping is added to any already in force,
overriding any mappings that already exist for the same
extension.Example
AddEncoding x-gzip .gz
AddEncoding x-compress .Z
.gz extension
to be marked as encoded using the x-gzip encoding, and
filenames containing the .Z extension to be marked as
encoded with x-compress.x-gzip and x-compress,
however the standard dictates that they're equivalent to
gzip and compress respectively. Apache does
content encoding comparisons by ignoring any leading x-.
When responding with an encoding Apache will use whatever form
(i.e., x-foo or foo) the
client requested. If the client didn't specifically request a
particular form Apache will use the form given by the
AddEncoding directive. To make this long story
short, you should always use x-gzip and
x-compress for these two specific encodings. More
recent encodings, such as deflate should be
specified without the x-.AddHandler Directive
Description: Maps the filename extensions to the specified
handler Syntax: AddHandler handler-name extension
[extension] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime .cgi, you
might use:
AddHandler cgi-script .cgi
.cgi extension will be treated as a CGI program.See also
AddInputFilter Directive
Description: Maps filename extensions to the filters that will process
client requests Syntax: AddInputFilter filter[;filter...]
extension [extension] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime Compatibility: AddInputFilter is only available in Apache 2.0.26 and
later. AddInputFilter maps the filename extension
extension to the filters which
will process client requests and POST input when they are received by
the server. This is in addition to any filters defined elsewhere,
including the SetInputFilter
directive. This mapping is merged over any already in force, overriding
any mappings that already exist for the same extension.See also
AddLanguage Directive
Description: Maps the given filename extension to the specified content
language Syntax: AddLanguage MIME-lang extension
[extension] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime AddLanguage directive maps the given
filename extension to the specified content language.
MIME-lang is the MIME language of filenames containing
extension. This mapping is added to any already in force,
overriding any mappings that already exist for the same
extension.Example
AddEncoding x-compress .Z
AddLanguage en .en
AddLanguage fr .fr
xxxx.en.Z will be treated as
being a compressed English document (as will the document
xxxx.Z.en). Although the content language is
reported to the client, the browser is unlikely to use this
information. The AddLanguage directive is
more useful for content
negotiation, where the server returns one from several documents
based on the client's language preference.
AddLanguage en .en
AddLanguage en-gb .en
AddLanguage en-us .en
.en would be treated as
being en-us.See also
AddOutputFilter Directive
Description: Maps filename extensions to the filters that will process
responses from the server Syntax: AddOutputFilter filter[;filter...]
extension [extension] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime Compatibility: AddOutputFilter is only available in Apache 2.0.26 and
later. AddOutputFilter directive maps the
filename extension extension to the filters which will process responses
from the server before they are sent to the client. This is in
addition to any filters defined elsewhere, including SetOutputFilter and AddOutputFilterByType directive. This mapping is merged
over any already in force, overriding any mappings that already exist
for the same extension..shtml files for server-side includes and will then
compress the output using mod_deflate.
AddOutputFilter INCLUDES;DEFLATE shtml
See also
AddType Directive
Description: Maps the given filename extensions onto the specified content
type Syntax: AddType MIME-type extension
[extension] ...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime AddType directive maps the given filename
extensions onto the specified content type. MIME-type is the
MIME type to use for filenames containing extension. This
mapping is added to any already in force, overriding any mappings that
already exist for the same extension. This directive can
be used to add mappings not listed in the MIME types file (see the
TypesConfig directive).Example
AddType image/gif .gif
It is recommended that new MIME types be added using the
AddType directive rather than changing the
TypesConfig file.
See also
DefaultLanguage Directive
Description: Sets all files in the given scope to the specified
language Syntax: DefaultLanguage MIME-langContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime DefaultLanguage directive tells Apache
that all files in the directive's scope (e.g., all files
covered by the current <Directory> container) that don't have an explicit language
extension (such as .fr or .de as configured
by AddLanguage) should be
considered to be in the specified MIME-lang language. This
allows entire directories to be marked as containing Dutch content, for
instance, without having to rename each file. Note that unlike using
extensions to specify languages, DefaultLanguage
can only specify a single language.DefaultLanguage directive is in force,
and a file does not have any language extensions as configured
by AddLanguage, then that file
will be considered to have no language attribute.Example
DefaultLanguage en
See also
ModMimeUsePathInfo Directive
Description: Tells mod_mime to treat path_info
components as part of the filenameSyntax: ModMimeUsePathInfo On|OffDefault: ModMimeUsePathInfo OffContext: directory Status: Base Module: mod_mime Compatibility: Available in Apache 2.0.41 and later ModMimeUsePathInfo directive is used to
combine the filename with the path_info URL component to
apply mod_mime's directives to the request. The default
value is Off - therefore, the path_info
component is ignored.Example
ModMimeUsePathInfo On
/bar/foo.shtml where
/bar is a Location and ModMimeUsePathInfo is On,
mod_mime will treat the incoming request as
/bar/foo.shtml and directives like AddOutputFilter
INCLUDES .shtml will add the INCLUDES filter to the
request. If ModMimeUsePathInfo is not set, the
INCLUDES filter will not be added.See also
MultiviewsMatch Directive
Description: The types of files that will be included when searching for
a matching file with MultiViews Syntax: MultiviewsMatch Any|NegotiatedOnly|Filters|Handlers
[Handlers|Filters]Default: MultiviewsMatch NegotiatedOnlyContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime Compatibility: Available in Apache 2.0.26 and later. MultiviewsMatch permits three different
behaviors for mod_negotiation's
Multiviews feature. Multiviews allows a request for a file,
e.g. index.html, to match any negotiated
extensions following the base request, e.g.
index.html.en, index.html.fr, or
index.html.gz.NegotiatedOnly option provides that every extension
following the base name must correlate to a recognized
mod_mime extension for content negotation, e.g.
Charset, Content-Type, Language, or Encoding. This is the strictest
implementation with the fewest unexpected side effects, and is the
default behavior.MultiviewsMatch directive to either
Handlers, Filters, or both option keywords.
If all other factors are equal, the smallest file will be served,
e.g. in deciding between index.html.cgi of 500
bytes and index.html.pl of 1000 bytes, the .cgi
file would win in this example. Users of .asis files
might prefer to use the Handler option, if .asis files are
associated with the asis-handler.Any extensions to match, even if
mod_mime doesn't recognize the extension. This was the
behavior in Apache 1.3, and can cause unpredicatable results, such as
serving .old or .bak files the webmaster never expected to be served.
MultiviewsMatch Handlers Filters
See also
RemoveCharset Directive
Description: Removes any character set associations for a set of file
extensions Syntax: RemoveCharset extension [extension]
...Context: virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime Compatibility: RemoveCharset is only available in Apache 2.0.24 and
later. RemoveCharset directive removes any
character set associations for files with the given extensions.
This allows .htaccess files in subdirectories to
undo any associations inherited from parent directories or the
server config files.Example
RemoveCharset .html .shtml
RemoveEncoding Directive
Description: Removes any content encoding associations for a set of file
extensions Syntax: RemoveEncoding extension [extension]
...Context: virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime RemoveEncoding directive removes any
encoding associations for files with the given extensions. This
allows .htaccess files in subdirectories to undo
any associations inherited from parent directories or the
server config files. An example of its use might be:/foo/.htaccess:
AddEncoding x-gzip .gz
AddType text/plain .asc
<Files *.gz.asc>
RemoveEncoding .gz
</Files>
foo.gz to be marked as being
encoded with the gzip method, but foo.gz.asc as an
unencoded plaintext file.Note
RemoveEncoding directives are processed
after any AddEncoding
directives, so it is possible they may undo the effects of the latter
if both occur within the same directory configuration.RemoveHandler Directive
Description: Removes any handler associations for a set of file
extensions Syntax: RemoveHandler extension [extension]
...Context: virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime RemoveHandler directive removes any
handler associations for files with the given extensions. This allows
.htaccess files in subdirectories to undo any
associations inherited from parent directories or the server
config files. An example of its use might be:/foo/.htaccess:
AddHandler server-parsed .html
/foo/bar/.htaccess:
RemoveHandler .html
.html files in
the /foo/bar directory to being treated as normal
files, rather than as candidates for parsing (see the mod_include module).RemoveInputFilter Directive
Description: Removes any input filter associations for a set of file
extensions Syntax: RemoveInputFilter extension [extension]
...Context: virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime Compatibility: RemoveInputFilter is only available in Apache 2.0.26 and
later. RemoveInputFilter directive removes any
input filter associations for files with
the given extensions.
This allows .htaccess files in subdirectories to
undo any associations inherited from parent directories or the
server config files.See also
RemoveLanguage Directive
Description: Removes any language associations for a set of file
extensions Syntax: RemoveLanguage extension [extension]
...Context: virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime Compatibility: RemoveLanguage is only available in Apache 2.0.24 and
later. RemoveLanguage directive removes any
language associations for files with the given extensions. This
allows .htaccess files in subdirectories to undo
any associations inherited from parent directories or the
server config files.RemoveOutputFilter Directive
Description: Removes any output filter associations for a set of file
extensions Syntax: RemoveOutputFilter extension [extension]
...Context: virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime Compatibility: RemoveOutputFilter is only available in Apache 2.0.26 and
later. RemoveOutputFilter directive removes any
output filter associations for files with
the given extensions.
This allows .htaccess files in subdirectories to
undo any associations inherited from parent directories or the
server config files.Example
RemoveOutputFilter shtml
See also
RemoveType Directive
Description: Removes any content type associations for a set of file
extensions Syntax: RemoveType extension [extension]
...Context: virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_mime RemoveType directive removes any MIME
type associations for files with the given extensions. This allows
.htaccess files in subdirectories to undo any
associations inherited from parent directories or the server
config files. An example of its use might be:/foo/.htaccess:
RemoveType .cgi
.cgi
files in the /foo/ directory and any beneath it,
causing the files to be treated as being of the DefaultType.Note
RemoveType directives are processed
after any AddType
directives, so it is possible they may undo the effects of the
latter if both occur within the same directory configuration.TypesConfig Directive
Description: The location of the mime.types fileSyntax: TypesConfig file-pathDefault: TypesConfig conf/mime.typesContext: server config Status: Base Module: mod_mime TypesConfig directive sets the location
of the MIME types configuration file. File-path is relative
to the ServerRoot. This file sets
the default list of mappings from filename extensions to content
types. Most administrators use the provided mime.types
file, which associates common filename extensions with IANA registered
content types. The current list is maintained at http://www.iana.org/assignments/media-types/index.html.
This simplifies the httpd.conf file by providing the
majority of media-type definitions, and may be overridden by
AddType directives as
needed. You should not edit the mime.types file, because
it may be replaced when you upgrade your server.AddType directive:
MIME-type [extension] ...
#) are ignored.
Please do not send requests to the Apache HTTP
Server Project to add any new entries in the distributed
mime.types file unless (1) they are already
registered with IANA, and (2) they use widely accepted,
non-conflicting filename extensions across platforms.
category/x-subtype requests will be automatically
rejected, as will any new two-letter extensions as they will
likely conflict later with the already crowded language and
character set namespace.
See also
mod/mod_negotiation.html 100644 0 0 40433 11074463123 13056 0 ustar 0 0
Apache Module mod_mime_magic
Description: Determines the MIME type of a file
by looking at a few bytes of its contents Status: Extension Module쟅dentifier: mime_magic_module Source쟂ile: mod_mime_magic.c Summary
file(1) command works: it looks at the first
few bytes of the file. It is intended as a "second line of defense"
for cases that mod_mime can't resolve.file(1) command for Unix, which uses "magic
numbers" and other hints from a file's contents to figure out
what the contents are. This module is active only if the magic
file is specified by the MimeMagicFile directive.
Format of the Magic File
#). The remaining lines are parsed for
the following columns:Column Description 1
byte number to begin checking from
">" indicates a dependency upon the previous
non-">" line2
bytesingle character shortmachine-order 16-bit integer longmachine-order 32-bit integer stringarbitrary-length string datelong integer date (seconds since Unix epoch/1970) beshortbig-endian 16-bit integer belongbig-endian 32-bit integer bedatebig-endian 32-bit integer date leshortlittle-endian 16-bit integer lelonglittle-endian 32-bit integer ledatelittle-endian 32-bit integer date 3
contents of data to match 4
MIME type if matched 5
MIME encoding if matched (optional) # Sun/NeXT audio data
0 string .snd
>12 belong 1 audio/basic
>12 belong 2 audio/basic
>12 belong 3 audio/basic
>12 belong 4 audio/basic
>12 belong 5 audio/basic
>12 belong 6 audio/basic
>12 belong 7 audio/basic
>12 belong 23 audio/x-adpcm
*.doc
files containing Microsoft Word or FrameMaker documents. (These are
incompatible file formats which use the same file suffix.)# Frame
0 string \<MakerFile application/x-frame
0 string \<MIFFile application/x-frame
0 string \<MakerDictionary application/x-frame
0 string \<MakerScreenFon application/x-frame
0 string \<MML application/x-frame
0 string \<Book application/x-frame
0 string \<Maker application/x-frame
# MS-Word
0 string \376\067\0\043 application/msword
0 string \320\317\021\340\241\261 application/msword
0 string \333\245-\0\0\0 application/msword
# gzip (GNU zip, not to be confused with
# [Info-ZIP/PKWARE] zip archiver)
0 string \037\213 application/octet-stream x-gzip
Performance Issues
file(1) code to make it fit in a busy web
server. It was designed for a server where there are thousands of users
who publish their own documents. This is probably very common
on intranets. Many times, it's helpful if the server can make
more intelligent decisions about a file's contents than the
file name allows ...even if just to reduce the "why doesn't my
page work" calls when users improperly name their own files.
You have to decide if the extra work suits your
environment.
Notes
mod_mime_magic
module and are included here for compliance with contributors'
copyright restrictions that require their acknowledgment.
Copyright (c) 1996-1997 Cisco Systems, Inc.
realloc().MimeMagicFile Directive
Description: Enable MIME-type determination based on file contents
using the specified magic file Syntax: MimeMagicFile file-pathContext: server config, virtual host Status: Extension Module: mod_mime_magic MimeMagicFile directive can be used to
enable this module, the default file is distributed at
conf/magic. Non-rooted paths are relative to the
ServerRoot. Virtual hosts will use
the same file as the main server unless a more specific setting is
used, in which case the more specific setting overrides the main
server's file.Example
MimeMagicFile conf/magic
mod/mod_nw_ssl.html 100644 0 0 14164 11074463123 12045 0 ustar 0 0
Apache Module mod_negotiation
Description: Provides for content negotiation Status: Base Module쟅dentifier: negotiation_module Source쟂ile: mod_negotiation.c Summary
type-map) which explicitly lists the files
containing the variants.MultiViews
Options), where the server does
an implicit filename pattern match, and choose from amongst the
results.Directives
Topics
See also
Type maps
Content-Encoding:AddEncoding directive.
This normally includes the encodings x-compress
for compress'd files, and x-gzip for gzip'd
files. The x- prefix is ignored for encoding
comparisons.Content-Language:en,
meaning English. If the variant contains more than one
language, they are separated by a comma.Content-Length:Content-Type:name=value. Common parameters include:
leveltext/html this defaults to 2, otherwise
0.qsqs values are therefore specific to a given
resource.Example
Content-Type: image/jpeg; qs=0.8
URI:Body:Example:
Body:----xyz----
<html>
<body>
<p>Content of the page.</p>
</body>
</html>
----xyz----
MultiViews
MultiViews
Options. If the server receives a
request for /some/dir/foo and
/some/dir/foo does not exist, then the
server reads the directory looking for all files named
foo.*, and effectively fakes up a type map which
names all those files, assigning them the same media types and
content-encodings it would have if the client had asked for one
of them by name. It then chooses the best match to the client's
requirements, and returns that document.MultiViewsMatch
directive configures whether Apache will consider files
that do not have content negotiation meta-information assigned
to them when choosing files.CacheNegotiatedDocs Directive
Description: Allows content-negotiated documents to be
cached by proxy servers Syntax: CacheNegotiatedDocs On|OffDefault: CacheNegotiatedDocs OffContext: server config, virtual host Status: Base Module: mod_negotiation Compatibility: The syntax changed in version 2.0. CacheNegotiatedDocs did not take an
argument; it was turned on by the presence of the directive by
itself.ForceLanguagePriority Directive
Description: Action to take if a single acceptable document is not
found Syntax: ForceLanguagePriority None|Prefer|Fallback [Prefer|Fallback]Default: ForceLanguagePriority PreferContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_negotiation Compatibility: Available in version 2.0.30 and later ForceLanguagePriority directive uses
the given LanguagePriority to satisfy
negotation where the server could otherwise not return a single
matching document.ForceLanguagePriority Prefer uses
LanguagePriority to serve a one valid result, rather
than returning an HTTP result 300 (MULTIPLE CHOICES) when there
are several equally valid choices. If the directives below were
given, and the user's Accept-Language header assigned
en and de each as quality .500
(equally acceptable) then the first matching variant, en,
will be served.
LanguagePriority en fr de
ForceLanguagePriority Prefer
ForceLanguagePriority Fallback uses
LanguagePriority to
serve a valid result, rather than returning an HTTP result 406
(NOT ACCEPTABLE). If the directives below were given, and the user's
Accept-Language only permitted an es
language response, but such a variant isn't found, then the first
variant from the LanguagePriority list below will be served.
LanguagePriority en fr de
ForceLanguagePriority Fallback
Prefer and Fallback, may be
specified, so either the first matching variant from LanguagePriority will be served if
more than one variant is acceptable, or first available document will
be served if none of the variants matched the client's acceptable list
of languages.See also
LanguagePriority Directive
Description: The precendence of language variants for cases where
the client does not express a preference Syntax: LanguagePriority MIME-lang [MIME-lang]
...Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Base Module: mod_negotiation LanguagePriority sets the precedence
of language variants for the case where the client does not
express a preference, when handling a MultiViews request. The list
of MIME-lang are in order of decreasing preference.Example:
LanguagePriority en fr de
foo.html, where
foo.html.fr and foo.html.de both
existed, but the browser did not express a language preference,
then foo.html.fr would be returned.ForceLanguagePriority directive
is not None. In general, the client determines the
language preference, not the server.See also
mod/mod_proxy.html 100644 0 0 165423 11074463123 11746 0 ustar 0 0
Apache Module mod_nw_ssl
Description: Enable SSL encryption for NetWare Status: Base Module쟅dentifier: nwssl_module Source쟂ile: mod_nw_ssl.c Compatibility: NetWare only Summary
Directives
NWSSLTrustedCerts Directive
Description: List of additional client certificates Syntax: NWSSLTrustedCerts filename [filename] ...Context: server config Status: Base Module: mod_nw_ssl .der file.NWSSLUpgradeable Directive
Description: Allows a connection to be upgraded to an SSL connection upon request Syntax: NWSSLUpgradeable [IP-address:]portnumberContext: server config Status: Base Module: mod_nw_ssl Listen
directive.SecureListen Directive
Description: Enables SSL encryption for the specified port Syntax: SecureListen [IP-address:]portnumber
Certificate-Name [MUTUAL]Context: server config Status: Base Module: mod_nw_ssl
mod/mod_proxy_connect.html 100644 0 0 6755 11074463123 13421 0 ustar 0 0
Apache Module mod_proxy
Description: HTTP/1.1 proxy/gateway server Status: Extension Module쟅dentifier: proxy_module Source쟂ile: mod_proxy.c Summary
Warning
ProxyRequests until you have secured your server. Open proxy servers are dangerous both to your
network and to the Internet at large.FTP, CONNECT (for SSL),
HTTP/0.9, HTTP/1.0, and HTTP/1.1.
The module can be configured to connect to other proxy modules for these
and other protocols.mod_proxy:
mod_proxy_http, mod_proxy_ftp
and mod_proxy_connect. Thus, if you want to use
one or more of the particular proxy functions, load
mod_proxy and the appropriate module(s)
into the server (either statically at compile-time or dynamically
via the LoadModule
directive).mod_cache and related
modules. The ability to contact remote servers using the SSL/TLS
protocol is provided by the SSLProxy* directives of
mod_ssl. These additional modules will need
to be loaded and configured to take advantage of these features.Directives
AllowCONNECT NoProxy <Proxy> ProxyBadHeader ProxyBlock ProxyDomain ProxyErrorOverride ProxyFtpDirCharset ProxyIOBufferSize <ProxyMatch> ProxyMaxForwards ProxyPass ProxyPassReverse ProxyPreserveHost ProxyReceiveBufferSize ProxyRemote ProxyRemoteMatch ProxyRequests ProxyTimeout ProxyViaTopics
Forward and Reverse Proxies Basic Examples Controlling access to your proxy FTP Proxy Slow Startup Intranet Proxy Protocol AdjustmentsSee also
Forward and Reverse Proxies
mod_cache) to reduce network usage.ProxyRequests directive. Because
forward proxys allow clients to access arbitrary sites through
your server and to hide their true origin, it is essential that
you secure your server so that only
authorized clients can access the proxy before activating a
forward proxy.ProxyPass directive or the
[P] flag to the RewriteRule directive. It is
not necessary to turn ProxyRequests on in order to
configure a reverse proxy.
Basic Examples
mod_cache.Forward Proxy
ProxyRequests On
ProxyVia On
<Proxy *>
Order deny,allow
Deny from all
Allow from internal.example.com
</Proxy>
Reverse Proxy
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /foo http://foo.example.com/bar
ProxyPassReverse /foo http://foo.example.com/bar
Controlling access to your proxy
<Proxy> control block as in
the following example:
<Proxy *>
Order Deny,Allow
Deny from all
Allow from 192.168.0
</Proxy>
mod_access.ProxyRequests directive).
Otherwise, your server can be used by any client to access
arbitrary hosts while hiding his or her true identity. This is
dangerous both for your network and for the Internet at large.
When using a reverse proxy (using the ProxyPass directive with
ProxyRequests Off), access control is less
critical because clients can only contact the hosts that you
have specifically configured.
FTP Proxy
Why doesn't file type xxx
download via FTP?
application/octet-stream in your proxy's mime.types
configuration file. A useful line can beapplication/octet-stream bin dms lha lzh exe class tgz taz
How can I force an FTP ASCII download of
File xxx?
ASCII transfer method (while the default transfer is in
binary mode), you can override mod_proxy's
default by suffixing the request with ;type=a to force an
ASCII transfer. (FTP Directory listings are always executed in ASCII mode,
however.)How can I access FTP files outside
of my home directory?
/%2f to the path of your request, you can make
such a proxy change the FTP starting directory to / (instead
of the home directory). For example, to retrieve the file
/etc/motd, you would use the URL:
ftp://user@host/%2f/etc/motd
How can I hide the FTP cleartext password
in my browser's URL line?
user: anonymous
password: apache_proxy@
ftp://username@host/myfile
401 (Authorization
required) response, which causes the Browser to pop up the
username/password dialog. Upon entering the password, the connection
attempt is retried, and if successful, the requested resource is
presented. The advantage of this procedure is that your browser does not
display the password in cleartext (which it would if you had used
ftp://username:password@host/myfile
Note
Slow Startup
ProxyBlock directive, hostnames' IP addresses are looked up
and cached during startup for later match test. This may take a few
seconds (or more) depending on the speed with which the hostname lookups
occur.
Intranet Proxy
ProxyRemote directive
to forward the respective scheme to the firewall proxy).
However, when it has to
access resources within the intranet, it can bypass the firewall when
accessing hosts. The NoProxy
directive is useful for specifying which hosts belong to the intranet and
should be accessed directly.http://somehost.example.com/. Some commercial proxy servers
let them get away with this and simply serve the request, implying a
configured local domain. When the ProxyDomain directive is used and the server is configured for proxy service, Apache can return
a redirect response and send the client to the correct, fully qualified,
server address. This is the preferred method since the user's bookmark
files will then contain fully qualified hosts.
Protocol Adjustments
SetEnv directive.force-proxy-request-1.0 and
proxy-nokeepalive notes.
<Location /buggyappserver/>
ProxyPass http://buggyappserver:7001/foo/
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
</Location>
AllowCONNECT Directive
Description: Ports that are allowed to CONNECT through the
proxySyntax: AllowCONNECT port [port] ...Default: AllowCONNECT 443 563Context: server config, virtual host Status: Extension Module: mod_proxy AllowCONNECT directive specifies a list
of port numbers to which the proxy CONNECT method may
connect. Today's browsers use this method when a https
connection is requested and proxy tunneling over HTTP is in effect.443) and the
default snews port (563) are enabled. Use the
AllowCONNECT directive to override this default and
allow connections to the listed ports only.mod_proxy_connect present
in the server in order to get the support for the CONNECT at
all.NoProxy Directive
Description: Hosts, domains, or networks that will be connected to
directly Syntax: NoProxy host [host] ...Context: server config, virtual host Status: Extension Module: mod_proxy NoProxy directive specifies a
list of subnets, IP addresses, hosts and/or domains, separated by
spaces. A request to a host which matches one or more of these is
always served directly, without forwarding to the configured
ProxyRemote proxy server(s).Example
ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
NoProxy
directive are one of the following type list:
Examples
.com .apache.org.
Note
.MyDomain.com and
.mydomain.com. (note the trailing period) are considered
equal. Since a domain comparison does not involve a DNS lookup, it is much
more efficient than subnet comparison.
192.168 or 192.168.0.0255.255.0.0)192.168.112.0/21192.168.112.0/21 with a netmask of 21
valid bits (also used in the form 255.255.248.0)Example
192.168.123.7
Note
Examples
prep.ai.mit.edu
www.apache.org
Note
WWW.MyDomain.com
and www.mydomain.com. (note the trailing period) are
considered equal.See also
<Proxy> Directive
Description: Container for directives applied to proxied resources Syntax: <Proxy wildcard-url> ...</Proxy>Context: server config, virtual host Status: Extension Module: mod_proxy <Proxy>
sections apply only to matching proxied content. Shell-style wildcards are
allowed.yournetwork.example.com to access content via your proxy
server:
<Proxy *>
Order Deny,Allow
Deny from all
Allow from yournetwork.example.com
</Proxy>
foo
directory of example.com through the INCLUDES
filter when they are sent through the proxy server:
<Proxy http://example.com/foo/*>
SetOutputFilter INCLUDES
</Proxy>
ProxyBadHeader Directive
Description: Determines how to handle bad header lines in a
response Syntax: ProxyBadHeader IsError|Ignore|StartBodyDefault: ProxyBadHeader IsErrorContext: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.44 and later ProxyBadHeader directive determines the
behaviour of mod_proxy if it receives syntactically invalid
header lines (i.e. containing no colon). The following arguments
are possible:
IsErrorIgnoreStartBodyProxyBlock Directive
Description: Words, hosts, or domains that are banned from being
proxied Syntax: ProxyBlock *|word|host|domain
[word|host|domain] ...Context: server config, virtual host Status: Extension Module: mod_proxy ProxyBlock directive specifies a list of
words, hosts and/or domains, separated by spaces. HTTP, HTTPS, and
FTP document requests to sites whose names contain matched words,
hosts or domains are blocked by the proxy server. The proxy
module will also attempt to determine IP addresses of list items which
may be hostnames during startup, and cache them for match test as
well. That may slow down the startup time of the server.Example
ProxyBlock joes-garage.com some-host.co.uk rocky.wotsamattau.edu
rocky.wotsamattau.edu would also be matched if referenced by
IP address.wotsamattau would also be sufficient to match
wotsamattau.edu.
ProxyBlock *
ProxyDomain Directive
Description: Default domain name for proxied requests Syntax: ProxyDomain DomainContext: server config, virtual host Status: Extension Module: mod_proxy ProxyDomain directive specifies
the default domain which the apache proxy server will belong to. If a
request to a host without a domain name is encountered, a redirection
response to the same host with the configured Domain appended
will be generated.Example
ProxyRemote * http://firewall.mycompany.com:81
NoProxy .mycompany.com 192.168.112.0/21
ProxyDomain .mycompany.com
ProxyErrorOverride Directive
Description: Override error pages for proxied content Syntax: ProxyErrorOverride On|OffDefault: ProxyErrorOverride OffContext: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in version 2.0 and later ProxyFtpDirCharset Directive
Description: Define the character set for proxied FTP listings Syntax: ProxyFtpDirCharset character setDefault: ProxyFtpDirCharset ISO-8859-1Context: server config, virtual host, directory Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.62 and later ProxyFtpDirCharset directive defines the
character set to be set for FTP directory listings in HTML generated by
mod_proxy_ftp.ProxyIOBufferSize Directive
Description: Determine size of internal data throughput buffer Syntax: ProxyIOBufferSize bytesDefault: ProxyIOBufferSize 8192Context: server config, virtual host Status: Extension Module: mod_proxy ProxyIOBufferSize directive adjusts the size
of the internal buffer, which is used as a scratchpad for the data between
input and output. The size must be less or equal 8192.<ProxyMatch> Directive
Description: Container for directives applied to regular-expression-matched
proxied resources Syntax: <ProxyMatch regex> ...</ProxyMatch>Context: server config, virtual host Status: Extension Module: mod_proxy <ProxyMatch> directive is
identical to the <Proxy> directive, except it matches URLs
using regular expressions.ProxyMaxForwards Directive
Description: Maximium number of proxies that a request can be forwarded
through Syntax: ProxyMaxForwards numberDefault: ProxyMaxForwards 10Context: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0 and later ProxyMaxForwards directive specifies the
maximum number of proxies through which a request may pass, if there's no
Max-Forwards header supplied with the request. This is
set to prevent infinite proxy loops, or a DoS attack.Example
ProxyMaxForwards 15
ProxyPass Directive
Description: Maps remote servers into the local server URL-space Syntax: ProxyPass [path] !|urlContext: server config, virtual host, directory Status: Extension Module: mod_proxy http://example.com/;
then
ProxyPass /mirror/foo/ http://backend.example.com/
http://example.com/mirror/foo/bar to be internally converted
into a proxy request to http://backend.example.com/bar.! directive is useful in situations where you don't want
to reverse-proxy a subdirectory, e.g.
ProxyPass /mirror/foo/i !
ProxyPass /mirror/foo http://backend.example.com
/mirror/foo to
backend.example.com except requests made to
/mirror/foo/i.Note
<Location> section, the first argument is omitted and the local
directory is obtained from the <Location>.The
ProxyRequests directive should
usually be set off when using
ProxyPass.RewriteRule directive with the
[P] flag.ProxyPassReverse Directive
Description: Adjusts the URL in HTTP response headers sent from a reverse
proxied server Syntax: ProxyPassReverse [path] urlContext: server config, virtual host, directory Status: Extension Module: mod_proxy Location,
Content-Location and URI headers on HTTP redirect
responses. This is essential when Apache is used as a reverse proxy to avoid
by-passing the reverse proxy because of HTTP redirects on the backend
servers which stay behind the reverse proxy.ProxyPass directive.http://example.com/; then
ProxyPass /mirror/foo/ http://backend.example.com/
ProxyPassReverse /mirror/foo/ http://backend.example.com/
http://example.com/mirror/foo/bar to be internally converted
into a proxy request to http://backend.example.com/bar
(the functionality ProxyPass provides here). It also takes care
of redirects the server backend.example.com sends: when
http://backend.example.com/bar is redirected by him to
http://backend.example.com/quux Apache adjusts this to
http://example.com/mirror/foo/quux before forwarding the HTTP
redirect response to the client. Note that the hostname used for
constructing the URL is chosen in respect to the setting of the UseCanonicalName directive.ProxyPassReverse directive can
also be used in conjunction with the proxy pass-through feature
(RewriteRule ... [P]) from mod_rewrite
because its doesn't depend on a corresponding ProxyPass directive.<Location> section, the first argument is omitted and the local
directory is obtained from the <Location>.ProxyPreserveHost Directive
Description: Use incoming Host HTTP request header for proxy
request Syntax: ProxyPreserveHost On|OffDefault: ProxyPreserveHost OffContext: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.31 and later. Off. It is mostly
useful in special configurations like proxied mass name-based virtual
hosting, where the original Host header needs to be evaluated by the
backend server.ProxyReceiveBufferSize Directive
Description: Network buffer size for proxied HTTP and FTP
connections Syntax: ProxyReceiveBufferSize bytesDefault: ProxyReceiveBufferSize 0Context: server config, virtual host Status: Extension Module: mod_proxy ProxyReceiveBufferSize directive specifies an
explicit (TCP/IP) network buffer size for proxied HTTP and FTP connections,
for increased throughput. It has to be greater than 512 or set
to 0 to indicate that the system's default buffer size should
be used.Example
ProxyReceiveBufferSize 2048
ProxyRemote Directive
Description: Remote proxy used to handle certain requests Syntax: ProxyRemote match remote-serverContext: server config, virtual host Status: Extension Module: mod_proxy * to indicate
the server should be contacted for all requests. remote-server is
a partial URL for the remote server. Syntax:
remote-server =
scheme://hostname[:port]
http is supported by
this module.Example
ProxyRemote http://goodguys.com/ http://mirrorguys.com:8000
ProxyRemote * http://cleversite.com
ProxyRemote ftp http://ftpproxy.mydomain.com:8080
ProxyRemoteMatch Directive
Description: Remote proxy used to handle requests matched by regular
expressions Syntax: ProxyRemoteMatch regex remote-serverContext: server config, virtual host Status: Extension Module: mod_proxy ProxyRemoteMatch is identical to the
ProxyRemote directive, except the
first argument is a regular expression match against the requested URL.ProxyRequests Directive
Description: Enables forward (standard) proxy requests Syntax: ProxyRequests On|OffDefault: ProxyRequests OffContext: server config, virtual host Status: Extension Module: mod_proxy Off does not disable use of
the ProxyPass directive.)Off.mod_proxy_http or mod_proxy_ftp
(or both) present in the server.Warning
ProxyRequests until you have secured your server. Open proxy servers are dangerous
both to your network and to the Internet at large.ProxyTimeout Directive
Description: Network timeout for proxied requests Syntax: ProxyTimeout secondsDefault: ProxyTimeout 300Context: server config, virtual host Status: Extension Module: mod_proxy Compatibility: Available in Apache 2.0.31 and later ProxyVia Directive
Description: Information provided in the Via HTTP response
header for proxied requestsSyntax: ProxyVia On|Off|Full|BlockDefault: ProxyVia OffContext: server config, virtual host Status: Extension Module: mod_proxy Via: HTTP
header by the proxy. Its intended use is to control the flow of of
proxy requests along a chain of proxy servers. See RFC 2616 (HTTP/1.1), section
14.45 for an explanation of Via: header lines.
Off, which is the default, no special processing
is performed. If a request or reply contains a Via: header,
it is passed through unchanged.On, each request and reply will get a
Via: header line added for the current host.Full, each generated Via: header
line will additionally have the Apache server version shown as a
Via: comment field.Block, every proxy request will have all its
Via: header lines removed. No new Via: header will
be generated.
mod/mod_proxy_ftp.html 100644 0 0 6354 11074463123 12554 0 ustar 0 0
Apache Module mod_proxy_connect
Description: mod_proxy extension for
CONNECT request handlingStatus: Extension Module쟅dentifier: proxy_connect_module Source쟂ile: proxy_connect.c Summary
mod_proxy. It provides support for the CONNECT
HTTP method. This method is mainly used to tunnel SSL requests
through proxy servers.CONNECT
requests, mod_proxy and
mod_proxy_connect have to be present in the server.Warning
mod/mod_proxy_http.html 100644 0 0 7320 11074463123 12734 0 ustar 0 0
Apache Module mod_proxy_ftp
Description: FTP support module for
mod_proxyStatus: Extension Module쟅dentifier: proxy_ftp_module Source쟂ile: proxy_ftp.c Summary
mod_proxy. It provides support for the proxying
FTP sites.mod_proxy and mod_proxy_ftp
have to be present in the server.Warning
mod/mod_rewrite.html 100644 0 0 234567 11074463123 12254 0 ustar 0 0
Apache Module mod_proxy_http
Description: HTTP support module for
mod_proxyStatus: Extension Module쟅dentifier: proxy_http_module Source쟂ile: proxy_http.c Summary
mod_proxy. It provides the features used for
proxying HTTP requests. mod_proxy_http
supports HTTP/0.9, HTTP/1.0 and HTTP/1.1. It does not
provide any caching abilities. If you want to set up a caching
proxy, you might want to use the additional service of the
mod_cache module.mod_proxy and mod_proxy_http
have to be present in the server.Warning
mod/mod_setenvif.html 100644 0 0 31172 11074463123 12361 0 ustar 0 0
Apache Module mod_rewrite
Description: Provides a rule-based rewriting engine to rewrite requested
URLs on the fly Status: Extension Module쟅dentifier: rewrite_module Source쟂ile: mod_rewrite.c Compatibility: Available in Apache 1.3 and later Summary
httpd.conf) and per-directory context
(.htaccess) and can generate query-string
parts on result. The rewritten result can lead to internal
sub-processing, external request redirection or even to an
internal proxy throughput.Directives
RewriteBase RewriteCond RewriteEngine RewriteLock RewriteLog RewriteLogLevel RewriteMap RewriteOptions RewriteRuleTopics
API Phases
mod_rewrite uses two of
these hooks: the URL-to-filename translation hook
(used after the HTTP request has been read, but before any
authorization starts) and the Fixup hook (triggered
after the authorization phases, and after the per-directory
config files (.htaccess) have been read, but
before the content handler is activated).
Ruleset Processing
RewriteRule directives, with or without
RewriteConds), rule by rule.
When a particular rule is matched, mod_rewrite
also checks the corresponding conditions (RewriteCond
directives). For historical reasons the conditions are given
first, making the control flow a little bit long-winded. See
Figure 1 for more details.![[Needs graphics capability to display]](../images/mod_rewrite_fig1.gif)
Figure 1:The control flow of the rewrite engine through a
rewrite ruleset
mod_rewrite immediately stops processing that rule,
and goes on to the next rule. If the Pattern matches,
mod_rewrite checks for rule conditions.
If none are present, the URL will be replaced with a new string,
constructed from the Substitution string, and mod_rewrite goes on to the next rule.RewriteConds exist, an
inner loop is started, processing them in the order that they are
listed. Conditions are not matched against the current URL directly.
A TestString is constructed by expanding variables,
back-references, map lookups, etc., against which the
CondPattern is matched. If the pattern fails to match one
of the conditions, the complete set of rule and associated conditions
fails. If the pattern matches a given condition, then matching continues
to the next condition, until no more conditions are
available. If all conditions match, processing is continued
with the substitution of the Substitution string for the URL.
Regex Back-Reference Availability
$N and
%N (see below), for creating
the Substitution and TestString strings.
Figure 2 attempts to show how the back-references are
transferred through the process for later expansion.![[Needs graphics capability to display]](../images/mod_rewrite_fig2.gif)
Figure 2: The back-reference flow through a rule.
Quoting Special Characters
\$'; this keeps mod_rewrite from trying
to treat it as a backreference.
Environment Variables
SCRIPT_URL
and SCRIPT_URI. These contain the
logical Web-view to the current resource, while the
standard CGI/SSI variables SCRIPT_NAME and
SCRIPT_FILENAME contain the physical
System-view. Example
SCRIPT_NAME=/sw/lib/w3s/tree/global/u/rse/.www/index.html
SCRIPT_FILENAME=/u/rse/.www/index.html
SCRIPT_URL=/u/rse/
SCRIPT_URI=http://en1.engelschall.com/u/rse/
Practical Solutions
RewriteBase Directive
Description: Sets the base URL for per-directory rewrites Syntax: RewriteBase URL-pathDefault: See usage for information.Context: directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite RewriteBase directive explicitly
sets the base URL for per-directory rewrites. As you will see
below, RewriteRule
can be used in per-directory config files
(.htaccess). In such a case, it will act locally,
stripping the local directory prefix before processing, and applying
rewrite rules only to the remainder. When processing is complete, the
prefix is automatically added back to the
path. The default setting is; RewriteBase physical-directory-pathRewriteBase directive to specify the
correct URL-prefix. If your webserver's URLs are not directly
related to physical file paths, you will need to use
RewriteBase in every .htaccess
file where you want to use RewriteRule directives.
#
# /abc/def/.htaccess -- per-dir config file for directory /abc/def
# Remember: /abc/def is the physical path of /xyz, i.e., the server
# has a 'Alias /xyz /abc/def' directive e.g.
#
RewriteEngine On
# let the server know that we were reached via /xyz and not
# via the physical path prefix /abc/def
RewriteBase /xyz
# now the rewriting rules
RewriteRule ^oldstuff\.html$ newstuff.html
/xyz/oldstuff.html gets correctly rewritten to
the physical file /abc/def/newstuff.html.For Apache Hackers
Request:
/xyz/oldstuff.html
Internal Processing:
/xyz/oldstuff.html -> /abc/def/oldstuff.html (per-server Alias)
/abc/def/oldstuff.html -> /abc/def/newstuff.html (per-dir RewriteRule)
/abc/def/newstuff.html -> /xyz/newstuff.html (per-dir RewriteBase)
/xyz/newstuff.html -> /abc/def/newstuff.html (per-server Alias)
Result:
/abc/def/newstuff.html
RewriteCond Directive
Description: Defines a condition under which rewriting will take place
Syntax: RewriteCond
TestString CondPatternContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite RewriteCond directive defines a
rule condition. One or more RewriteCond
can precede a RewriteRule
directive. The following rule is then only used if both
the current state of the URI matches its pattern, and if these conditions are met.
$N
(0 <= N <= 9), which provide access to the grouped
parts (in parentheses) of the pattern, from the
RewriteRule which is subject to the current
set of RewriteCond conditions..
%N
(1 <= N <= 9), which provide access to the grouped
parts (again, in parentheses) of the pattern, from the last matched
RewriteCond in the current set
of conditions.
${mapname:key|default}.
See the documentation for
RewriteMap for more details.
%{ NAME_OF_VARIABLE
}
where NAME_OF_VARIABLE can be a string taken
from the following list:
HTTP headers: connection & request:
HTTP_USER_AGENT
HTTP_REFERER
HTTP_COOKIE
HTTP_FORWARDED
HTTP_HOST
HTTP_PROXY_CONNECTION
HTTP_ACCEPT
REMOTE_ADDR
REMOTE_HOST
REMOTE_PORT
REMOTE_USER
REMOTE_IDENT
REQUEST_METHOD
SCRIPT_FILENAME
PATH_INFO
QUERY_STRING
AUTH_TYPE
server internals: system stuff: specials:
DOCUMENT_ROOT
SERVER_ADMIN
SERVER_NAME
SERVER_ADDR
SERVER_PORT
SERVER_PROTOCOL
SERVER_SOFTWARE
TIME_YEAR
TIME_MON
TIME_DAY
TIME_HOUR
TIME_MIN
TIME_SEC
TIME_WDAY
TIME
API_VERSION
THE_REQUEST
REQUEST_URI
REQUEST_FILENAME
IS_SUBREQ
HTTPS
struct tm fields of the Unix system.
Most are documented elsewhere in the Manual or in
the CGI specification. Those that are special to
mod_rewrite include those below.
IS_SUBREQAPI_VERSIONTHE_REQUESTGET
/index.html HTTP/1.1"). This does not
include any additional headers sent by the
browser.REQUEST_URIREQUEST_FILENAMEHTTPSmod_ssl is loaded).
filename field of the internal
request_rec structure of the Apache server.
The first name is the commonly known CGI variable name
while the second is the appropriate counterpart of
REQUEST_URI (which contains the value of the
uri field of request_rec).%{ENV:variable}, where variable can be
any environment variable, is also available.
This is looked-up via internal
Apache structures and (if not found there) via
getenv() from the Apache server process.%{SSL:variable}, where variable is the
name of an SSL environment
variable, can be used whether or not
mod_ssl is loaded, but will always expand to
the empty string if it is not. Example:
%{SSL:SSL_CIPHER_USEKEYSIZE} may expand to
128.%{HTTP:header}, where header can be
any HTTP MIME-header name, can always be used to obtain the
value of a header sent in the HTTP request.
Example: %{HTTP:Proxy-Connection} is
the value of the HTTP header
``Proxy-Connection:''.%{LA-U:variable} can be used for look-aheads which perform
an internal (URL-based) sub-request to determine the final
value of variable. This can be used to access
variable for rewriting which is not available at the current
stage, but will be set in a later phase.
REMOTE_USER variable from within the
per-server context (httpd.conf file) you must
use %{LA-U:REMOTE_USER} - this
variable is set by the authorization phases, which come
after the URL translation phase (during which mod_rewrite
operates)..htaccess file) via
the Fixup phase of the API and because the authorization
phases come before this phase, you just can use
%{REMOTE_USER} in that context.%{LA-F:variable} can be used to perform an internal
(filename-based) sub-request, to determine the final value
of variable. Most of the time, this is the same as
LA-U above.
!' character (exclamation mark) to specify a
non-matching pattern.
Treats the CondPattern as a plain string and
compares it lexicographically to TestString. True if
TestString lexicographically precedes
CondPattern.
Treats the CondPattern as a plain string and
compares it lexicographically to TestString. True if
TestString lexicographically follows
CondPattern.
Treats the CondPattern as a plain string and
compares it lexicographically to TestString. True if
TestString is lexicographically equal to
CondPattern (the two strings are exactly
equal, character for character). If CondPattern
is "" (two quotation marks) this
compares TestString to the empty string.
Treats the TestString as a pathname and tests
whether or not it exists, and is a directory.
Treats the TestString as a pathname and tests
whether or not it exists, and is a regular file.
Treats the TestString as a pathname and tests
whether or not it exists, and is a regular file with size greater
than zero.
Treats the TestString as a pathname and tests
whether or not it exists, and is a symbolic link.
Checks whether or not TestString is a valid file,
accessible via all the server's currently-configured
access controls for that path. This uses an internal
subrequest to do the check, so use it with care -
it can impact your server's performance!
Checks whether or not TestString is a valid URL,
accessible via all the server's currently-configured
access controls for that path. This uses an internal
subrequest to do the check, so use it with care -
it can impact your server's performance!Note
All of these tests can
also be prefixed by an exclamation mark ('!') to
negate their meaning.
[flags]
as the third argument to the RewriteCond
directive, where flags is a comma-separated list of any of the
following flags:
nocase|NC'
(no case)
This makes the test case-insensitive - differences
between 'A-Z' and 'a-z' are ignored, both in the
expanded TestString and the CondPattern.
This flag is effective only for comparisons between
TestString and CondPattern. It has no
effect on filesystem and subrequest checks.ornext|OR'
(or next condition)
Use this to combine rule conditions with a local OR
instead of the implicit AND. Typical example:
Without this flag you would have to write the condition/rule
pair three times.
RewriteCond %{REMOTE_HOST} ^host1.* [OR]
RewriteCond %{REMOTE_HOST} ^host2.* [OR]
RewriteCond %{REMOTE_HOST} ^host3.*
RewriteRule ...some special stuff for any of these hosts...
User-Agent:'' header of the request, you can
use the following:
RewriteCond %{HTTP_USER_AGENT} ^Mozilla.*
RewriteRule ^/$ /homepage.max.html [L]
RewriteCond %{HTTP_USER_AGENT} ^Lynx.*
RewriteRule ^/$ /homepage.min.html [L]
RewriteRule ^/$ /homepage.std.html [L]
RewriteEngine Directive
Description: Enables or disables runtime rewriting engine Syntax: RewriteEngine on|offDefault: RewriteEngine offContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite RewriteEngine directive enables or
disables the runtime rewriting engine. If it is set to
off this module does no runtime processing at
all. It does not even update the SCRIPT_URx
environment variables.RewriteRule directives!RewriteEngine on directive for each virtual host
in which you wish to use it.RewriteLock Directive
Description: Sets the name of the lock file used for RewriteMap
synchronizationSyntax: RewriteLock file-pathContext: server config Status: Extension Module: mod_rewrite RewriteMap
programs. Set this lockfile to a local path (not on a
NFS-mounted device) when you want to use a rewriting
map-program. It is not required for other types of rewriting
maps.RewriteLog Directive
Description: Sets the name of the file used for logging rewrite engine
processing Syntax: RewriteLog file-pathContext: server config, virtual host Status: Extension Module: mod_rewrite RewriteLog directive sets the name
of the file to which the server logs any rewriting actions it
performs. If the name does not begin with a slash
('/') then it is assumed to be relative to the
Server Root. The directive should occur only once per
server config. To disable the logging of
rewriting actions it is not recommended to set
Filename to
/dev/null, because
although the rewriting engine does not then output to a
logfile it still creates the logfile output internally.
This will slow down the server with no advantage
to the administrator! To disable logging either
remove or comment out the RewriteLog
directive or use RewriteLogLevel 0!
Security
See the Apache Security Tips
document for details on how your security could be compromised if the
directory where logfiles are stored is writable by anyone other than
the user that starts the server.
Example
RewriteLog "/usr/local/var/apache/logs/rewrite.log"
RewriteLogLevel Directive
Description: Sets the verbosity of the log file used by the rewrite
engine Syntax: RewriteLogLevel LevelDefault: RewriteLogLevel 0Context: server config, virtual host Status: Extension Module: mod_rewrite RewriteLogLevel directive sets the
verbosity level of the rewriting logfile. The default level 0
means no logging, while 9 or more means that practically all
actions are logged. Using a high value for
Level will slow down your Apache server
dramatically! Use the rewriting logfile at a
Level greater than 2 only for debugging!
Example
RewriteLogLevel 3
RewriteMap Directive
Description: Defines a mapping function for key-lookup Syntax: RewriteMap MapName MapType:MapSource
Context: server config, virtual host Status: Extension Module: mod_rewrite Compatibility: The choice of different dbm types is available in
Apache 2.0.41 and later RewriteMap directive defines a
Rewriting Map which can be used inside rule
substitution strings by the mapping-functions to
insert/substitute fields through a key lookup. The source of
this lookup can be of various types.${ MapName :
LookupKey }
${ MapName :
LookupKey | DefaultValue
}
RewriteMap as:
RewriteMap examplemap txt:/path/to/file/map.txt
RewriteRule as follows:
RewriteRule ^/ex/(.*) ${examplemap:$1}
MapType: txt, MapSource: Unix filesystem
path to valid regular file
Example
##
## map.txt -- rewriting map
##
Ralf.S.Engelschall rse # Bastard Operator From Hell
Mr.Joe.Average joe # Mr. Average
RewriteMap real-to-user txt:/path/to/file/map.txt
MapType: rnd, MapSource: Unix filesystem
path to valid regular file
|'' characters which have the meaning of
``or''. In other words they indicate a set of
alternatives from which the actual returned value is
chosen randomly. For example, you might use the following map
file and directives to provide a random load balancing between
several back-end server, via a reverse-proxy. Images are sent
to one of the servers in the 'static' pool, while everything
else is sent to one of the 'dynamic' pool.Rewrite map file
##
## map.txt -- rewriting map
##
static www1|www2|www3|www4
dynamic www5|www6
Configuration directives
RewriteMap servers rnd:/path/to/file/map.txt
RewriteRule ^/(.*\.(png|gif|jpg)) http://${servers:static}/$1
[NC,P,L]
RewriteRule ^/(.*) http://${servers:dynamic}/$1 [P,L]
MapType:
dbm[=type], MapSource: Unix filesystem
path to valid regular file
#!/path/to/bin/perl
##
## txt2dbm -- convert txt map to dbm format
##
use NDBM_File;
use Fcntl;
($txtmap, $dbmmap) = @ARGV;
open(TXT, "<$txtmap") or die "Couldn't open $txtmap!\n";
tie (%DB, 'NDBM_File', $dbmmap,O_RDWR|O_TRUNC|O_CREAT, 0644)
or die "Couldn't create $dbmmap!\n";
while (<TXT>) {
next if (/^\s*#/ or /^\s*$/);
$DB{$1} = $2 if (/^\s*(\S+)\s+(\S+)/);
}
untie %DB;
close(TXT);
$ txt2dbm map.txt map.db
MapType: int, MapSource: Internal Apache
function
Converts the key to all upper case.
Converts the key to all lower case.
Translates special characters in the key to
hex-encodings.
Translates hex-encodings in the key back to
special characters.
MapType: prg, MapSource: Unix filesystem
path to valid regular file
#!/path/to/interpreter' as the first
line).stdin and stdout
file-handles. For each map-function lookup it will
receive the key to lookup as a newline-terminated string
on stdin. It then has to give back the
looked-up value as a newline-terminated string on
stdout or the four-character string
``NULL'' if it fails (i.e., there
is no corresponding value for the given key). A trivial
program which will implement a 1:1 map (i.e.,
key == value) could be:
#!/usr/bin/perl
$| = 1;
while (<STDIN>) {
# ...put here any transformations or lookups...
print $_;
}
stdout. Avoid this, as it will cause a deadloop!
``$|=1'' is used above, to prevent this.RewriteLock directive can
be used to define a lockfile which mod_rewrite can use to synchronize
communication with the mapping program. By default no such
synchronization takes place.RewriteMap directive can occur more than
once. For each mapping-function use one
RewriteMap directive to declare its rewriting
mapfile. While you cannot declare a map in
per-directory context it is of course possible to
use this map in per-directory context. Note
For plain text and DBM format files the
looked-up keys are cached in-core until the mtime of the
mapfile changes or the server does a restart. This way you can have
map-functions in rules which are used for every
request. This is no problem, because the external lookup only happens
once!
RewriteOptions Directive
Description: Sets some special options for the rewrite engine Syntax: RewriteOptions OptionsDefault: RewriteOptions MaxRedirects=10Context: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite Compatibility: MaxRedirects is available in Apache 2.0.45 and
laterRewriteOptions directive sets some
special options for the current per-server or per-directory
configuration. The Option strings can be one of the
following:
inherit.htaccess configuration are inherited.MaxRedirects=numberRewriteRules, mod_rewrite aborts
the request after reaching a maximum number of such redirects and
responds with an 500 Internal Server Error. If you really need
more internal redirects than 10 per request, you may increase
the default to the desired value.RewriteRule Directive
Description: Defines rules for the rewriting engine Syntax: RewriteRule
Pattern SubstitutionContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_rewrite Compatibility: The cookie-flag is available in Apache 2.0.40 and later. RewriteRule directive is the real
rewriting workhorse. The directive can occur more than once, with
each instance defining a single rewrite rule. The
order in which these rules are defined is important - this is the order
in which they will be applied at run-time.
Text:
. Any single character
[chars] Character class: Any character of the class ``chars''
[^chars] Character class: Not a character of the class ``chars''
text1|text2 Alternative: text1 or text2
Quantifiers:
? 0 or 1 occurrences of the preceding text
* 0 or N occurrences of the preceding text (N > 0)
+ 1 or N occurrences of the preceding text (N > 1)
Grouping:
(text) Grouping of text
(used either to set the borders of an alternative as above, or
to make backreferences, where the Nth group can
be referred to on the RHS of a RewriteRule as $N)
Anchors:
^ Start-of-line anchor
$ End-of-line anchor
Escaping:
\char escape the given char
(for instance, to specify the chars ".[]()" etc.)
Jeffrey E.F. Friedl
O'Reilly & Associates, Inc. 2002
ISBN 0-596-00289-0
!') is also available as a possible pattern
prefix. This enables you to negate a pattern; to say, for instance:
``if the current URL does NOT match this
pattern''. This can be used for exceptional cases, where
it is easier to match the negative pattern, or as a last
default rule.Note
When using the NOT character to negate a pattern, you cannot include
grouped wildcard parts in that pattern. This is because, when the
pattern does NOT match (ie, the negation matches), there are no
contents for the groups. Thus, if negated patterns are used, you
cannot use $N in the substitution string!
$N) to the RewriteRule
pattern%N) to the last matched
RewriteCond pattern%{VARNAME})${mapname:key|default})$N
(N=0..9), which will be replaced
by the contents of the Nth group of the
matched Pattern. The server-variables are the same
as for the TestString of a RewriteCond
directive. The mapping-functions come from the
RewriteMap directive and are explained there.
These three types of variables are expanded in the order above.L flag - see below.-' which means: NO
substitution! This is useful in providing
rewriting rules which only match
URLs but do not substitute anything for them. It is commonly used
in conjunction with the C (chain) flag, in order
to apply more than one pattern before substitution occurs.[flags]
as the third argument to the RewriteRule
directive. Flags is a comma-separated list of any of the
following flags:
chain|C'
(chained with next rule)
This flag chains the current rule with the next rule
(which itself can be chained with the following rule,
and so on). This has the following effect: if a rule
matches, then processing continues as usual -
the flag has no effect. If the rule does
not match, then all following chained
rules are skipped. For instance, it can be used to remove the
``.www'' part, inside a per-directory rule set,
when you let an external redirect happen (where the
``.www'' part should not occur!).cookie|CO=NAME:VAL:domain[:lifetime[:path]]'
(set cookie)
This sets a cookie in the client's browser. The cookie's name
is specified by NAME and the value is
VAL. The domain field is the domain of the
cookie, such as '.apache.org', the optional lifetime
is the lifetime of the cookie in minutes, and the optional
path is the path of the cookieenv|E=VAR:VAL'
(set environment variable)
This forces an environment variable named VAR to
be set to the value VAL, where VAL can
contain regexp backreferences ($N and
%N) which will be expanded. You can use this
flag more than once, to set more than one variable. The
variables can later be dereferenced in many situations, most commonly
from within XSSI (via <!--#echo
var="VAR"-->) or CGI ($ENV{'VAR'}).
You can also dereference the variable in a later RewriteCond pattern, using
%{ENV:VAR}. Use this to strip
information from URLs, while maintaining a record of that information.forbidden|F' (force URL
to be forbidden)
This forces the current URL to be forbidden - it immediately
sends back a HTTP response of 403 (FORBIDDEN).
Use this flag in conjunction with
appropriate RewriteConds to conditionally block some
URLs.gone|G' (force URL to be
gone)
This forces the current URL to be gone - it
immediately sends back a HTTP response of 410 (GONE). Use
this flag to mark pages which no longer exist as gone.last|L'
(last rule)
Stop the rewriting process here and don't apply any more
rewrite rules. This corresponds to the Perl
last command or the break command
in C. Use this flag to prevent the currently
rewritten URL from being rewritten further by following
rules. For example, use it to rewrite the root-path URL
('/') to a real one, e.g.,
'/e/www/'.next|N'
(next round)
Re-run the rewriting process (starting again with the
first rewriting rule). This time, the URL to match is no longer
the original URL, but rather the URL returned by the last rewriting rule.
This corresponds to the Perl next command or
the continue command in C. Use
this flag to restart the rewriting process -
to immediately go to the top of the loop.
Be careful not to create an infinite
loop!nocase|NC'
(no case)
This makes the Pattern case-insensitive,
ignoring difference between 'A-Z' and
'a-z' when Pattern is matched against the current
URL.noescape|NE'
(no URI escaping of
output)
This flag prevents mod_rewrite from applying the usual URI
escaping rules to the result of a rewrite. Ordinarily,
special characters (such as '%', '$', ';', and so on)
will be escaped into their hexcode equivalents ('%25',
'%24', and '%3B', respectively); this flag prevents this
from happening. This allows percent symbols to appear in
the output, as in
which would turn '
RewriteRule /foo/(.*) /bar?arg=P1\%3d$1 [R,NE]
/foo/zed' into a safe
request for '/bar?arg=P1=zed'.
nosubreq|NS' (
not for internal
sub-requests)
This flag forces the rewrite engine to skip a
rewrite rule if the current request is an internal
sub-request. For instance, sub-requests occur internally
in Apache when mod_include tries to find out
information about possible directory default files
(index.xxx). On sub-requests it is not
always useful, and can even cause errors, if
the complete set of rules are applied. Use this flag to
exclude some rules.
To decide whether or not to use this rule: if you
prefix URLs with CGI-scripts, to force them to be
processed by the CGI-script, it's likely that you
will run into problems (or significant overhead) on
sub-requests. In these cases, use this flag.
proxy|P' (force
proxy)
This flag forces the substitution part to be internally
sent as a proxy request and immediately (rewrite
processing stops here) put through the proxy module. You must make
sure that the substitution string is a valid URI
(typically starting with
http://hostname) which can be
handled by the Apache proxy module. If not, you will get an
error from the proxy module. Use this flag to achieve a
more powerful implementation of the ProxyPass directive,
to map remote content into the namespace of the local
server.
mod_proxy must be enabled in order
to use this flag.passthrough|PT'
(pass through to next
handler)
This flag forces the rewrite engine to set the
uri field of the internal
request_rec structure to the value of the
filename field. This flag is just a hack to
enable post-processing of the output of
RewriteRule directives, using
Alias, ScriptAlias,
Redirect, and other directives from
various URI-to-filename translators. For example, to rewrite
/abc to /def using
mod_rewrite, and then
/def to /ghi using
mod_alias:
If you omit the
RewriteRule ^/abc(.*) /def$1 [PT]
Alias /def /ghi
PT flag,
mod_rewrite will rewrite
uri=/abc/... to
filename=/def/... as a full API-compliant
URI-to-filename translator should do. Then
mod_alias will try to do a
URI-to-filename transition, which will fail.
mod_alias and
mod_rewrite.qsappend|QSA'
(query string
append)
This flag forces the rewrite engine to append a query
string part of the substitution string to the existing string,
instead of replacing it. Use this when you want to add more
data to the query string via a rewrite rule.redirect|R
[=code]' (force redirect)
Prefix Substitution with
http://thishost[:thisport]/ (which makes the
new URL a URI) to force a external redirection. If no
code is given, a HTTP response of 302 (MOVED
TEMPORARILY) will be returned. If you want to use other response
codes in the range 300-400, simply specify the appropriate number
or use one of the following symbolic names:
temp (default), permanent,
seeother. Use this for rules to
canonicalize the URL and return it to the client - to
translate ``/~'' into
``/u/'', or to always append a slash to
/u/user, etc.
Note: When you use this flag, make
sure that the substitution field is a valid URL! Otherwise,
you will be redirecting to an invalid location. Remember
that this flag on its own will only prepend
http://thishost[:thisport]/ to the URL, and rewriting
will continue. Usually, you will want to stop rewriting at this point,
and redirect immediately. To stop rewriting, you should add
the 'L' flag.
skip|S=num'
(skip next rule(s))
This flag forces the rewriting engine to skip the next
num rules in sequence, if the current rule
matches. Use this to make pseudo if-then-else constructs:
The last rule of the then-clause becomes
skip=N, where N is the number of rules in the
else-clause. (This is not the same as the
'chain|C' flag!)type|T=MIME-type'
(force MIME type)
Force the MIME-type of the target file to be
MIME-type. This can be used to
set up the content-type based on some conditions.
For example, the following snippet allows .php files to
be displayed by mod_php if they are called with
the .phps extension:
RewriteRule ^(.+\.php)s$ $1 [T=application/x-httpd-php-source]
Home directory expansion
mod_userdir.RewriteRule
directive.Note: Enabling rewrites in per-directory context
To enable the rewriting engine
for per-directory configuration files, you need to set
``RewriteEngine On'' in these files
and ``Options
FollowSymLinks'' must be enabled. If your
administrator has disabled override of
FollowSymLinks for a user's directory, then
you cannot use the rewriting engine. This restriction is
needed for security reasons.
Note: Pattern matching in per-directory context
Never forget that Pattern is
applied to a complete URL in per-server configuration
files. However, in per-directory configuration files, the
per-directory prefix (which always is the same for a specific
directory) is automatically removed for the pattern matching
and automatically added after the substitution has been
done. This feature is essential for many sorts of rewriting -
without this, you would always have to match the parent
directory which is not always possible.
http://'', then the directory
prefix will not be added, and an
external redirect or proxy throughput (if flag
P is used) is forced!Note: Substitution of Absolute URLs
http://thishost[:thisport],
mod_rewrite will automatically strip that
out. This auto-reduction on URLs with an implicit external redirect
is most useful in combination with
a mapping-function which generates the
hostname part.http://thishost because of this feature. To
achieve such a self-redirect, you have to use the
R-flag.Note: Query String
RewriteCond with the
%{QUERY_STRING} variable. You can, however, create
URLs in the substitution string, containing a query string
part. Simply use a question mark inside the substitution string, to
indicate that the following text should be re-injected into the
query string. When you want to erase an existing query string,
end the substitution string with just a question mark. To
combine a new query string with an old one, use the
[QSA] flag.httpd.conf)
for request ``GET
/somepath/pathinfo'':
Given Rule Resulting Substitution
---------------------------------------------- ----------------------------------
^/somepath(.*) otherpath$1 invalid, not supported
^/somepath(.*) otherpath$1 [R] invalid, not supported
^/somepath(.*) otherpath$1 [P] invalid, not supported
---------------------------------------------- ----------------------------------
^/somepath(.*) /otherpath$1 /otherpath/pathinfo
^/somepath(.*) /otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^/somepath(.*) /otherpath$1 [P] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^/somepath(.*) http://thishost/otherpath$1 /otherpath/pathinfo
^/somepath(.*) http://thishost/otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^/somepath(.*) http://thishost/otherpath$1 [P] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^/somepath(.*) http://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo
via external redirection
^/somepath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo
via external redirection
(the [R] flag is redundant)
^/somepath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
via internal proxy
/somepath
(/physical/path/to/somepath/.htacccess, with
RewriteBase /somepath)
for request ``GET
/somepath/localpath/pathinfo'':
Given Rule Resulting Substitution
---------------------------------------------- ----------------------------------
^localpath(.*) otherpath$1 /somepath/otherpath/pathinfo
^localpath(.*) otherpath$1 [R] http://thishost/somepath/otherpath/pathinfo
via external redirection
^localpath(.*) otherpath$1 [P] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^localpath(.*) /otherpath$1 /otherpath/pathinfo
^localpath(.*) /otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^localpath(.*) /otherpath$1 [P] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^localpath(.*) http://thishost/otherpath$1 /otherpath/pathinfo
^localpath(.*) http://thishost/otherpath$1 [R] http://thishost/otherpath/pathinfo
via external redirection
^localpath(.*) http://thishost/otherpath$1 [P] doesn't make sense, not supported
---------------------------------------------- ----------------------------------
^localpath(.*) http://otherhost/otherpath$1 http://otherhost/otherpath/pathinfo
via external redirection
^localpath(.*) http://otherhost/otherpath$1 [R] http://otherhost/otherpath/pathinfo
via external redirection
(the [R] flag is redundant)
^localpath(.*) http://otherhost/otherpath$1 [P] http://otherhost/otherpath/pathinfo
via internal proxy
mod/mod_so.html 100644 0 0 20512 11074463123 11153 0 ustar 0 0
아파치 모듈 mod_setenvif
설명: 요청의 성격에 따라 환경변수 설정을 변경한다 상태: Base 모듈명: setenvif_module 소스파일: mod_setenvif.c 요약
mod_setenvif 모듈은 요청의 성격이
정규표현식에 해당하는지 여부로 환경변수를 설정한다. 서버의
다른 부분이 행동을 결정할때 이 환경변수를 사용할 수 있다.netscape를
설정하는 아래 예와 같이 여러 지시어를 함께 사용할 수 있다.
BrowserMatch ^Mozilla netscape
BrowserMatch MSIE !netscape
BrowserMatch 지시어
설명: HTTP User-Agent에 따라 환경변수를 설정한다 문법: BrowserMatch regex [!]env-variable[=value]
[[!]env-variable[=value]] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_setenvif BrowserMatch는 SetEnvIf 지시어의 특별한
경우로, HTTP 요청 헤더 User-Agent에 따라 환경변수를
설정한다. 다음 두 줄은 같다:
BrowserMatchNoCase Robot is_a_robot
SetEnvIfNoCase User-Agent Robot is_a_robot
BrowserMatch ^Mozilla forms jpeg=yes browser=netscape
BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript
BrowserMatch MSIE !javascript
BrowserMatchNoCase 지시어
설명: 대소문자를 구별하지않고 User-Agent에 따라 환경변수를
설정한다 문법: BrowserMatchNoCase regex [!]env-variable[=value]
[[!]env-variable[=value]] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_setenvif 지원: 아파치 1.2 이상 (아파치 1.2에서 이 지시어는 현재
없어진 mod_browser 모듈에 있었다) BrowserMatchNoCase 지시어는 BrowserMatch 지시어와
의미상 같다. 그러나 이 지시어는 대소문자를 구별하지않는다.
예를 들어:
BrowserMatchNoCase mac platform=macintosh
BrowserMatchNoCase win platform=windows
BrowserMatch와
BrowserMatchNoCase 지시어는
SetEnvIf와
SetEnvIfNoCase
지시어의 특별한 경우다. 다음 주 줄은 같다:
BrowserMatchNoCase Robot is_a_robot
SetEnvIfNoCase User-Agent Robot is_a_robot
SetEnvIf 지시어
설명: 요청의 성질에 따라 환경변수를 설정한다 문법: SetEnvIf attribute
regex [!]env-variable[=value]
[[!]env-variable[=value]] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_setenvif SetEnvIf 지시어는 요청의 성질에
따라 환경변수를 정의한다. 첫번째 아규먼트 attribute는
다음 세가지중 하나다:
Host, User-Agent,
Referer, Accept-Language. 정규표현식을
사용하여 여러 요청 헤더를 지칭할 수 있다.
Remote_Host - (있다면) 요청하는 클라이언트의
호스트명Remote_Addr - 요청하는 클라이언트의 IP 주소Server_Addr - 요청을 받는 서버의 IP 주소
(2.0.43 버전 이후에만)Request_Method - 사용한 메써드 이름
(GET, POST, 등등)Request_Protocol - 요청의 프로토콜 이름과
버전 (예를 들어, "HTTP/0.9", "HTTP/1.1", 등.)Request_URI - HTTP 요청에서 요청한 자원
-- 일반적으로 URL에서 질의문자열을 제외한 스킴(scheme)과
호스트 이후 부분SetEnvIf
지시어는 이전 지시어의 결과를 검사할 수 있다. 이전에
SetEnvIf[NoCase] 지시어로 정의한 환경변수만을
검사할 수 있다. '이전'이란 (서버전역과 같이) 더 넓은 영역 혹은
지시어의 현재 영역 이전을 뜻한다. 요청 성질이 아니고 정규표현식이
아닌 attribute는 환경변수로 취급한다.
varname, 혹은!varname, 혹은varname=valuevalue를 설정한다. 아파치 2.0.51부터
value에 있는 $1..$9를
regex의 괄호친 하위표현식으로 대체한다.예제:
SetEnvIf Request_URI "\.gif$" object_is_image=gif
SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
:
SetEnvIf Referer www\.mydomain\.com intra_site_referral
:
SetEnvIf object_is_image xbm XBIT_PROCESSING=1
:
SetEnvIf ^TS* ^[a-z].* HAVE_TS
object_is_image를 설정한다. 네번째 줄은 페이지를
www.mydomain.com 웹사이트에서 참조한 경우
intra_site_referral을 설정한다.HAVE_TS를 설정한다.참고
SetEnvIfNoCase 지시어
설명: 대소문자를 구별하지않고 요청의 성질에 따라 환경변수를
설정한다 문법: SetEnvIfNoCase attribute regex
[!]env-variable[=value]
[[!]env-variable[=value]] ...사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: FileInfo 상태: Base 모듈: mod_setenvif 지원: 아파치 1.3 이후 SetEnvIfNoCase는 의미상 SetEnvIf 지시어와 같지만,
대소문자를 구별하지않고 정규표현식을 찾는다. 예를 들어:
SetEnvIfNoCase Host Apache\.Org site=apache
Host:가
Apache.Org, apache.org 등을 포함하면
site 환경변수를 "apache"로 설정한다.
mod/mod_speling.html 100644 0 0 12307 11074463123 12176 0 ustar 0 0
아파치 모듈 mod_so
설명: 시작할때 혹은 재시작할때 실행가능한 코드와 모듈을
서버로 읽어들인다 상태: Extension 모듈명: so_module 소스파일: mod_so.c 지원: 윈도우즈에서 (항상 포함하는) Base 모듈이다. 요약
.so 확장자를
가진) 일반적인 공유객체파일이고, 윈도우즈에서는 .so
혹은 .dll 확장자를 가진다.경고
윈도우즈에서 읽어들일 모듈 만들기
주의
Configure 프로그램이 없기때문에
모듈의 소스파일을 ApacheCore 프로젝트 파일에 추가하고, 심볼을
os\win32\modules.c 파일에 추가해야 한다.LoadModuleAP_MODULE_DECLARE_DATA를 추가한다.
예를 들어, 다음과 같은 모듈이 있다면:
module foo_module;
module AP_MODULE_DECLARE_DATA foo_module;
.DEF 파일에
익숙하다면 대신 이 파일을 사용하여 module record를 export할
수도 있다.modules 디렉토리에 두고,
LoadModule 지시어를 사용하여 읽어들인다.LoadFile 지시어
설명: 지정한 목적파일이나 라이브러리를 읽어들인다 문법: LoadFile filename [filename] ...사용장소: 주서버설정 상태: Extension 모듈: mod_so LoadFile libexec/libxmlparse.soLoadModule 지시어
설명: 목적파일이나 라이브러리를 읽어들이고, 사용가능한
모듈 목록에 추가한다 문법: LoadModule module filename사용장소: 주서버설정 상태: Extension 모듈: mod_so module 자료형 외부변수명이며, 모듈 문서의 모듈명에
나온다. 예를 들면:
LoadModule status_module modules/mod_status.so
mod/mod_ssl.html 100644 0 0 275456 11074463123 11376 0 ustar 0 0
아파치 모듈 mod_speling
설명: 사용자가 대소문자를 잘못 사용하거나 맞춤법이 틀리는
것을 한번까지 허용하여 잘못된 URL을 고치려고 시도한다 상태: Extension 모듈명: speling_module 소스파일: mod_speling.c 요약
지시어들
CheckSpelling 지시어
설명: 맞춤법 모듈을 사용한다 문법: CheckSpelling on|off기본값: CheckSpelling Off사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: Options 상태: Extension 모듈: mod_speling 지원: 아파치 1.1은 CheckSpelling을 별도로 제공하였지만,
대소문자가 다른 경우만을 처리할 수 있었다. 아파치 1.3에서 아파치
배포본의 일부가 되었다. 아파치 1.3.2 이전에는
CheckSpelling 지시어를 "주서버"와 "가상호스트"
사용장소에서만 사용할 수 있었다.
http://my.host/~apahce/와 같이) 맞춤법이
틀린 사용자명을 교정하지 못한다.<Location /status>에 대한 요청을
내용협상을 거친 "/stats.html" 파일로 오인할
수 있다.
mod/mod_status.html 100644 0 0 15356 11074463123 12067 0 ustar 0 0
Apache Module mod_ssl
Description: Strong cryptography using the Secure Sockets
Layer (SSL) and Transport Layer Security (TLS) protocols Status: Extension Module쟅dentifier: ssl_module Source쟂ile: mod_ssl.c Summary
Directives
SSLCACertificateFile SSLCACertificatePath SSLCARevocationFile SSLCARevocationPath SSLCertificateChainFile SSLCertificateFile SSLCertificateKeyFile SSLCipherSuite SSLEngine SSLMutex SSLOptions SSLPassPhraseDialog SSLProtocol SSLProxyCACertificateFile SSLProxyCACertificatePath SSLProxyCARevocationFile SSLProxyCARevocationPath SSLProxyCipherSuite SSLProxyEngine SSLProxyMachineCertificateFile SSLProxyMachineCertificatePath SSLProxyProtocol SSLProxyVerify SSLProxyVerifyDepth SSLRandomSeed SSLRequire SSLRequireSSL SSLSessionCache SSLSessionCacheTimeout SSLUserName SSLVerifyClient SSLVerifyDepthTopics
Environment Variables
Variable Name:
Value Type:
Description:
HTTPSflag HTTPS is being used. SSL_PROTOCOLstring The SSL protocol version (SSLv2, SSLv3, TLSv1) SSL_SESSION_IDstring The hex-encoded SSL session id SSL_CIPHERstring The cipher specification name SSL_CIPHER_EXPORTstring true if cipher is an export cipherSSL_CIPHER_USEKEYSIZEnumber Number of cipher bits (actually used) SSL_CIPHER_ALGKEYSIZEnumber Number of cipher bits (possible) SSL_VERSION_INTERFACEstring The mod_ssl program version SSL_VERSION_LIBRARYstring The OpenSSL program version SSL_CLIENT_M_VERSIONstring The version of the client certificate SSL_CLIENT_M_SERIALstring The serial of the client certificate SSL_CLIENT_S_DNstring Subject DN in client's certificate SSL_CLIENT_S_DN_x509string Component of client's Subject DN SSL_CLIENT_I_DNstring Issuer DN of client's certificate SSL_CLIENT_I_DN_x509string Component of client's Issuer DN SSL_CLIENT_V_STARTstring Validity of client's certificate (start time) SSL_CLIENT_V_ENDstring Validity of client's certificate (end time) SSL_CLIENT_A_SIGstring Algorithm used for the signature of client's certificate SSL_CLIENT_A_KEYstring Algorithm used for the public key of client's certificate SSL_CLIENT_CERTstring PEM-encoded client certificate SSL_CLIENT_CERT_CHAINnstring PEM-encoded certificates in client certificate chain SSL_CLIENT_VERIFYstring NONE, SUCCESS, GENEROUS or FAILED:reasonSSL_SERVER_M_VERSIONstring The version of the server certificate SSL_SERVER_M_SERIALstring The serial of the server certificate SSL_SERVER_S_DNstring Subject DN in server's certificate SSL_SERVER_S_DN_x509string Component of server's Subject DN SSL_SERVER_I_DNstring Issuer DN of server's certificate SSL_SERVER_I_DN_x509string Component of server's Issuer DN SSL_SERVER_V_STARTstring Validity of server's certificate (start time) SSL_SERVER_V_ENDstring Validity of server's certificate (end time) SSL_SERVER_A_SIGstring Algorithm used for the signature of server's certificate SSL_SERVER_A_KEYstring Algorithm used for the public key of server's certificate SSL_SERVER_CERTstring PEM-encoded server certificate C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email ]
Custom Log Formats
mod_ssl is built into Apache or at least
loaded (under DSO situation) additional functions exist for the Custom Log Format of
mod_log_config. First there is an
additional ``%{varname}x''
eXtension format function which can be used to expand any variables
provided by any module, especially those provided by mod_ssl which can
you find in the above table.%{name}c'' cryptography format function
provided. Information about this function is provided in the Compatibility chapter.
CustomLog logs/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
SSLCACertificateFile Directive
Description: File of concatenated PEM-encoded CA Certificates
for Client Auth Syntax: SSLCACertificateFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCACertificatePath.Example
SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt
SSLCACertificatePath Directive
Description: Directory of PEM-encoded CA Certificates for
Client Auth Syntax: SSLCACertificatePath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .N. And you should always make sure this directory
contains the appropriate symbolic links. Example
SSLCACertificatePath /usr/local/apache2/conf/ssl.crt/
SSLCARevocationFile Directive
Description: File of concatenated PEM-encoded CA CRLs for
Client Auth Syntax: SSLCARevocationFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCARevocationPath.Example
SSLCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-client.crl
SSLCARevocationPath Directive
Description: Directory of PEM-encoded CA CRLs for
Client Auth Syntax: SSLCARevocationPath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .rN. And you should always make sure this directory
contains the appropriate symbolic links. Example
SSLCARevocationPath /usr/local/apache2/conf/ssl.crl/
SSLCertificateChainFile Directive
Description: File of PEM-encoded Server CA Certificates Syntax: SSLCertificateChainFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCACertificatePath for explicitly
constructing the server certificate chain which is sent to the browser
in addition to the server certificate. It is especially useful to
avoid conflicts with CA certificates when using client
authentication. Because although placing a CA certificate of the
server certificate chain into SSLCACertificatePath has the same effect
for the certificate chain construction, it has the side-effect that
client certificates issued by this same CA certificate are also
accepted on client authentication. That's usually not one expect.Example
SSLCertificateChainFile /usr/local/apache2/conf/ssl.crt/ca.crt
SSLCertificateFile Directive
Description: Server PEM-encoded X.509 Certificate file Syntax: SSLCertificateFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl Example
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt
SSLCertificateKeyFile Directive
Description: Server PEM-encoded Private Key file Syntax: SSLCertificateKeyFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLCertificateFile, use this additional directive to
point to the file with the stand-alone Private Key. When
SSLCertificateFile is used and the file
contains both the Certificate and the Private Key this directive need
not be used. But we strongly discourage this practice. Instead we
recommend you to separate the Certificate and the Private Key. If the
contained Private Key is encrypted, the Pass Phrase dialog is forced
at startup time. This directive can be used up to two times
(referencing different filenames) when both a RSA and a DSA based
private key is used in parallel.Example
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key
SSLCipherSuite Directive
Description: Cipher Suite available for negotiation in SSL
handshake Syntax: SSLCipherSuite cipher-specDefault: SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXPContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
RSA or Diffie-Hellman variants.
RSA, Diffie-Hellman, DSS or none.
DES, Triple-DES, RC4, RC2, IDEA or none.
MD5, SHA or SHA1.
Tag Description Key Exchange Algorithm: kRSARSA key exchange kDHrDiffie-Hellman key exchange with RSA key kDHdDiffie-Hellman key exchange with DSA key kEDHEphemeral (temp.key) Diffie-Hellman key exchange (no cert) Authentication Algorithm: aNULLNo authentication aRSARSA authentication aDSSDSS authentication aDHDiffie-Hellman authentication Cipher Encoding Algorithm: eNULLNo encoding DESDES encoding 3DESTriple-DES encoding RC4RC4 encoding RC2RC2 encoding IDEAIDEA encoding MAC Digest Algorithm: MD5MD5 hash function SHA1SHA1 hash function SHASHA hash function Aliases: SSLv2all SSL version 2.0 ciphers SSLv3all SSL version 3.0 ciphers TLSv1all TLS version 1.0 ciphers EXPall export ciphers EXPORT40all 40-bit export ciphers only EXPORT56all 56-bit export ciphers only LOWall low strength ciphers (no export, single DES) MEDIUMall ciphers with 128 bit encryption HIGHall ciphers using Triple-DES RSAall ciphers using RSA key exchange DHall ciphers using Diffie-Hellman key exchange EDHall ciphers using Ephemeral Diffie-Hellman key exchange ADHall ciphers using Anonymous Diffie-Hellman key exchange DSSall ciphers using DSS authentication NULLall ciphers using no encryption SSLv2, SSLv3, TLSv1, EXP, LOW, MEDIUM,
HIGH) for certain groups of ciphers. These tags can be joined
together with prefixes to form the cipher-spec. Available
prefixes are:
+: add ciphers to list and pull them to current location in list-: remove cipher from list (can be added later again)!: kill cipher from list completely (can not be added later again)openssl ciphers
-v'' command which provides a nice way to successively create the
correct cipher-spec string. The default cipher-spec string
is ``ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'' which
means the following: first, remove from consideration any ciphers that do not
authenticate, i.e. for SSL only the Anonymous Diffie-Hellman ciphers. Next,
use ciphers using RC4 and RSA. Next include the high, medium and then the low
security ciphers. Finally pull all SSLv2 and export ciphers to the
end of the list.
$ openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'
NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1
NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
... ... ... ... ...
EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
Example
SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW
Cipher-Tag Protocol Key Ex. Auth. Enc. MAC Type RSA Ciphers: DES-CBC3-SHASSLv3 RSA RSA 3DES(168) SHA1 DES-CBC3-MD5SSLv2 RSA RSA 3DES(168) MD5 IDEA-CBC-SHASSLv3 RSA RSA IDEA(128) SHA1 RC4-SHASSLv3 RSA RSA RC4(128) SHA1 RC4-MD5SSLv3 RSA RSA RC4(128) MD5 IDEA-CBC-MD5SSLv2 RSA RSA IDEA(128) MD5 RC2-CBC-MD5SSLv2 RSA RSA RC2(128) MD5 RC4-MD5SSLv2 RSA RSA RC4(128) MD5 DES-CBC-SHASSLv3 RSA RSA DES(56) SHA1 RC4-64-MD5SSLv2 RSA RSA RC4(64) MD5 DES-CBC-MD5SSLv2 RSA RSA DES(56) MD5 EXP-DES-CBC-SHASSLv3 RSA(512) RSA DES(40) SHA1 export EXP-RC2-CBC-MD5SSLv3 RSA(512) RSA RC2(40) MD5 export EXP-RC4-MD5SSLv3 RSA(512) RSA RC4(40) MD5 export EXP-RC2-CBC-MD5SSLv2 RSA(512) RSA RC2(40) MD5 export EXP-RC4-MD5SSLv2 RSA(512) RSA RC4(40) MD5 export NULL-SHASSLv3 RSA RSA None SHA1 NULL-MD5SSLv3 RSA RSA None MD5 Diffie-Hellman Ciphers: ADH-DES-CBC3-SHASSLv3 DH None 3DES(168) SHA1 ADH-DES-CBC-SHASSLv3 DH None DES(56) SHA1 ADH-RC4-MD5SSLv3 DH None RC4(128) MD5 EDH-RSA-DES-CBC3-SHASSLv3 DH RSA 3DES(168) SHA1 EDH-DSS-DES-CBC3-SHASSLv3 DH DSS 3DES(168) SHA1 EDH-RSA-DES-CBC-SHASSLv3 DH RSA DES(56) SHA1 EDH-DSS-DES-CBC-SHASSLv3 DH DSS DES(56) SHA1 EXP-EDH-RSA-DES-CBC-SHASSLv3 DH(512) RSA DES(40) SHA1 export EXP-EDH-DSS-DES-CBC-SHASSLv3 DH(512) DSS DES(40) SHA1 export EXP-ADH-DES-CBC-SHASSLv3 DH(512) None DES(40) SHA1 export EXP-ADH-RC4-MD5SSLv3 DH(512) None RC4(40) MD5 export SSLEngine Directive
Description: SSL Engine Operation Switch Syntax: SSLEngine on|offDefault: SSLEngine offContext: server config, virtual host Status: Extension Module: mod_ssl <VirtualHost> section to enable SSL/TLS for a
particular virtual host. By default the SSL/TLS Protocol Engine is
disabled for both the main server and all configured virtual hosts.Example
<VirtualHost _default_:443>
SSLEngine on
...
</VirtualHost>
SSLMutex Directive
Description: Semaphore for internal mutual exclusion of
operations Syntax: SSLMutex typeDefault: SSLMutex noneContext: server config Status: Extension Module: mod_ssl
none | no
posixsem
sysvsem
sem
pthread
fcntl:/path/to/mutex
fcntl()
fucntion are used as the Mutex.
Always use a local disk filesystem for /path/to/mutex and never a file
residing on a NFS- or AFS-filesystem. It is only available when the underlying platform
and APR supports it. Note: Internally, the Process ID (PID) of the
Apache parent process is automatically appended to
/path/to/mutex to make it unique, so you don't have to worry
about conflicts yourself. Notice that this type of mutex is not available
under the Win32 environment. There you have to use the semaphore
mutex.flock:/path/to/mutex
fcntl:/path/to/mutex method with the
exception that the flock() function is used to provide file
locking. It is only available when the underlying platform
and APR supports it.file:/path/to/mutex
fcntl and flock,
in that order. It is only available when the underlying platform and APR supports
at least one of the 2.default | yes
Example
SSLMutex file:/usr/local/apache/logs/ssl_mutex
SSLOptions Directive
Description: Configure various SSL engine run-time options Syntax: SSLOptions [+|-]option ...Context: server config, virtual host, directory, .htaccess Override: Options Status: Extension Module: mod_ssl SSLOptions
could apply to a directory, then the most specific one is taken
completely; the options are not merged. However if all the
options on the SSLOptions directive are preceded by a
plus (+) or minus (-) symbol, the options
are merged. Any options preceded by a + are added to the
options currently in force, and any options preceded by a
- are removed from the options currently in force.
StdEnvVars
CompatEnvVars
ExportCertData
SSL_SERVER_CERT, SSL_CLIENT_CERT and
SSL_CLIENT_CERT_CHAINn (with n = 0,1,2,..).
These contain the PEM-encoded X.509 Certificates of server and client for
the current HTTPS connection and can be used by CGI scripts for deeper
Certificate checking. Additionally all other certificates of the client
certificate chain are provided, too. This bloats up the environment a
little bit which is why you have to use this option to enable it on
demand.FakeBasicAuth
openssl x509 command: openssl x509 -noout -subject -in
certificate.crt). Note that no password is
obtained from the user. Every entry in the user file needs this password:
``xxj31ZMTZzkVA'', which is the DES-encrypted version of the
word `password''. Those who live under MD5-based encryption
(for instance under FreeBSD or BSD/OS, etc.) should use the following MD5
hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.StrictRequire
SSLRequireSSL or
SSLRequire successfully decided that access should be
forbidden. Usually the default is that in the case where a ``Satisfy
any'' directive is used, and other access restrictions are passed,
denial of access due to SSLRequireSSL or
SSLRequire is overridden (because that's how the Apache
Satisfy mechanism should work.) But for strict access restriction
you can use SSLRequireSSL and/or SSLRequire in
combination with an ``SSLOptions +StrictRequire''. Then an
additional ``Satisfy Any'' has no chance once mod_ssl has
decided to deny access.OptRenegotiate
Example
SSLOptions +FakeBasicAuth -StrictRequire
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars +CompatEnvVars -ExportCertData
<Files>
SSLPassPhraseDialog Directive
Description: Type of pass phrase dialog for encrypted private
keys Syntax: SSLPassPhraseDialog typeDefault: SSLPassPhraseDialog builtinContext: server config Status: Extension Module: mod_ssl SSLCertificateFile) and
Private Key (see SSLCertificateKeyFile) files of the
SSL-enabled virtual servers. Because for security reasons the Private
Key files are usually encrypted, mod_ssl needs to query the
administrator for a Pass Phrase in order to decrypt those files. This
query can be done in two ways which can be configured by
type:
builtin
exec:/path/to/program
servername:portnumber'', the second is either
``RSA'' or ``DSA''), which indicate for which
server and algorithm it has to print the corresponding Pass Phrase to
stdout. The intent is that this external program first runs
security checks to make sure that the system is not compromised by an
attacker, and only when these checks were passed successfully it provides
the Pass Phrase.stdout.
Nothing more or less! So, if you're really paranoid about security, here
is your interface. Anything else has to be left as an exercise to the
administrator, because local security requirements are so different.
SSLPassPhraseDialog exec:/usr/local/apache/sbin/pp-filter
SSLProtocol Directive
Description: Configure usable SSL protocol flavors Syntax: SSLProtocol [+|-]protocol ...Default: SSLProtocol allContext: server config, virtual host Override: Options Status: Extension Module: mod_ssl
SSLv2
SSLv3
TLSv1
All
+SSLv2 +SSLv3 +TLSv1'' and a
convinient way for enabling all protocols except one when used in
combination with the minus sign on a protocol as the example above
shows.Example
# enable SSLv3 and TLSv1, but not SSLv2
SSLProtocol all -SSLv2
SSLProxyCACertificateFile Directive
Description: File of concatenated PEM-encoded CA Certificates
for Remote Server Auth Syntax: SSLProxyCACertificateFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLProxyCACertificatePath.Example
SSLProxyCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-remote-server.crt
SSLProxyCACertificatePath Directive
Description: Directory of PEM-encoded CA Certificates for
Remote Server Auth Syntax: SSLProxyCACertificatePath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .N. And you should always make sure this directory
contains the appropriate symbolic links. Use the Makefile which
comes with mod_ssl to accomplish this task.Example
SSLProxyCACertificatePath /usr/local/apache2/conf/ssl.crt/
SSLProxyCARevocationFile Directive
Description: File of concatenated PEM-encoded CA CRLs for
Remote Server Auth Syntax: SSLProxyCARevocationFile file-pathContext: server config, virtual host Status: Extension Module: mod_ssl SSLProxyCARevocationPath.Example
SSLProxyCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-remote-server.crl
SSLProxyCARevocationPath Directive
Description: Directory of PEM-encoded CA CRLs for
Remote Server Auth Syntax: SSLProxyCARevocationPath directory-pathContext: server config, virtual host Status: Extension Module: mod_ssl .rN. And you should always make sure this directory
contains the appropriate symbolic links. Use the Makefile which
comes with mod_ssl to accomplish this task.Example
SSLProxyCARevocationPath /usr/local/apache2/conf/ssl.crl/
SSLProxyCipherSuite Directive
Description: Cipher Suite available for negotiation in SSL
proxy handshake Syntax: SSLProxyCipherSuite cipher-specDefault: SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXPContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl SSLCipherSuite, but for the proxy connection.
Please refer to SSLCipherSuite
for additional information.SSLProxyEngine Directive
Description: SSL Proxy Engine Operation Switch Syntax: SSLProxyEngine on|offDefault: SSLProxyEngine offContext: server config, virtual host Status: Extension Module: mod_ssl <VirtualHost> section to enable SSL/TLS for proxy
usage in a particular virtual host. By default the SSL/TLS Protocol Engine is
disabled for proxy image both for the main server and all configured virtual hosts.Example
<VirtualHost _default_:443>
SSLProxyEngine on
...
</VirtualHost>
SSLProxyMachineCertificateFile Directive
Description: File of concatenated PEM-encoded client certificates and keys to be used by the proxy Syntax: SSLProxyMachineCertificateFile filenameContext: server config Override: Not applicable Status: Extension Module: mod_ssl SSLProxyMachineCertificatePath.
SSLProxyMachineCertificateFile /usr/local/apache2/conf/ssl.crt/proxy.pem
SSLProxyMachineCertificatePath Directive
Description: Directory of PEM-encoded client certificates and keys to be used by the proxy Syntax: SSLProxyMachineCertificatePath directoryContext: server config Override: Not applicable Status: Extension Module: mod_ssl hash-value.N. And you should always make sure this
directory contains the appropriate symbolic links. Use the Makefile which
comes with mod_ssl to accomplish this task.
SSLProxyMachineCertificatePath /usr/local/apache2/conf/proxy.crt/
SSLProxyProtocol Directive
Description: Configure usable SSL protocol flavors for proxy usage Syntax: SSLProxyProtocol [+|-]protocol ...Default: SSLProxyProtocol allContext: server config, virtual host Override: Options Status: Extension Module: mod_ssl SSLProtocol
for additional information.
SSLProxyVerify Directive
Description: Type of remote server Certificate verification Syntax: SSLProxyVerify levelDefault: SSLProxyVerify noneContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
but it need not to be (successfully) verifiable.Example
SSLProxyVerify require
SSLProxyVerifyDepth Directive
Description: Maximum depth of CA Certificates in Remote Server
Certificate verification Syntax: SSLProxyVerifyDepth numberDefault: SSLProxyVerifyDepth 1Context: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl SSLProxyCACertificatePath), etc.Example
SSLProxyVerifyDepth 10
SSLRandomSeed Directive
Description: Pseudo Random Number Generator (PRNG) seeding
source Syntax: SSLRandomSeed context source
[bytes]Context: server config Status: Extension Module: mod_ssl startup) and/or just before a new SSL connection is established
(context is connect). This directive can only be used
in the global server context because the PRNG is a global facility.
builtin
file:/path/to/source
/path/to/source as the
source for seeding the PRNG. When bytes is specified, only the
first bytes number of bytes of the file form the entropy (and
bytes is given to /path/to/source as the first
argument). When bytes is not specified the whole file forms the
entropy (and 0 is given to /path/to/source as
the first argument). Use this especially at startup time, for instance
with an available /dev/random and/or
/dev/urandom devices (which usually exist on modern Unix
derivates like FreeBSD and Linux)./dev/random provides only as
much entropy data as it actually has, i.e. when you request 512 bytes of
entropy, but the device currently has only 100 bytes available two things
can happen: On some platforms you receive only the 100 bytes while on
other platforms the read blocks until enough bytes are available (which
can take a long time). Here using an existing /dev/urandom is
better, because it never blocks and actually gives the amount of requested
data. The drawback is just that the quality of the received data may not
be the best.exec:/path/to/program/ variant (see below) or use
egd:/path/to/egd-socket (see below).exec:/path/to/program
/path/to/program as the source for seeding the
PRNG. When bytes is specified, only the first
bytes number of bytes of its stdout contents
form the entropy. When bytes is not specified, the
entirety of the data produced on stdout form the
entropy. Use this only at startup time when you need a very strong
seeding with the help of an external program (for instance as in
the example above with the truerand utility you can
find in the mod_ssl distribution which is based on the AT&T
truerand library). Using this in the connection context
slows down the server too dramatically, of course. So usually you
should avoid using external programs in that context.egd:/path/to/egd-socket (Unix only)
Example
SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/random
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed startup exec:/usr/local/bin/truerand 16
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/random
SSLRandomSeed connect file:/dev/urandom 1024
SSLRequire Directive
Description: Allow access only when an arbitrarily complex
boolean expression is true Syntax: SSLRequire expressionContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
expr ::= "true" | "false"
| "!" expr
| expr "&&" expr
| expr "||" expr
| "(" expr ")"
| comp
comp ::= word "==" word | word "eq" word
| word "!=" word | word "ne" word
| word "<" word | word "lt" word
| word "<=" word | word "le" word
| word ">" word | word "gt" word
| word ">=" word | word "ge" word
| word "in" "{" wordlist "}"
| word "=~" regex
| word "!~" regex
wordlist ::= word
| wordlist "," word
word ::= digit
| cstring
| variable
| function
digit ::= [0-9]+
cstring ::= "..."
variable ::= "%{" varname "}"
function ::= funcname "(" funcargs ")"
varname any variable from Table 3 can be used. Finally for
funcname the following functions are available:
file(filename)
Example
SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
HTTP_USER_AGENT PATH_INFO AUTH_TYPE
HTTP_REFERER QUERY_STRING SERVER_SOFTWARE
HTTP_COOKIE REMOTE_HOST API_VERSION
HTTP_FORWARDED REMOTE_IDENT TIME_YEAR
HTTP_HOST IS_SUBREQ TIME_MON
HTTP_PROXY_CONNECTION DOCUMENT_ROOT TIME_DAY
HTTP_ACCEPT SERVER_ADMIN TIME_HOUR
HTTP:headername SERVER_NAME TIME_MIN
THE_REQUEST SERVER_PORT TIME_SEC
REQUEST_METHOD SERVER_PROTOCOL TIME_WDAY
REQUEST_SCHEME REMOTE_ADDR TIME
REQUEST_URI REMOTE_USER ENV:variablename
REQUEST_FILENAME
HTTPS SSL_CLIENT_M_VERSION SSL_SERVER_M_VERSION
SSL_CLIENT_M_SERIAL SSL_SERVER_M_SERIAL
SSL_PROTOCOL SSL_CLIENT_V_START SSL_SERVER_V_START
SSL_SESSION_ID SSL_CLIENT_V_END SSL_SERVER_V_END
SSL_CIPHER SSL_CLIENT_S_DN SSL_SERVER_S_DN
SSL_CIPHER_EXPORT SSL_CLIENT_S_DN_C SSL_SERVER_S_DN_C
SSL_CIPHER_ALGKEYSIZE SSL_CLIENT_S_DN_ST SSL_SERVER_S_DN_ST
SSL_CIPHER_USEKEYSIZE SSL_CLIENT_S_DN_L SSL_SERVER_S_DN_L
SSL_VERSION_LIBRARY SSL_CLIENT_S_DN_O SSL_SERVER_S_DN_O
SSL_VERSION_INTERFACE SSL_CLIENT_S_DN_OU SSL_SERVER_S_DN_OU
SSL_CLIENT_S_DN_CN SSL_SERVER_S_DN_CN
SSL_CLIENT_S_DN_T SSL_SERVER_S_DN_T
SSL_CLIENT_S_DN_I SSL_SERVER_S_DN_I
SSL_CLIENT_S_DN_G SSL_SERVER_S_DN_G
SSL_CLIENT_S_DN_S SSL_SERVER_S_DN_S
SSL_CLIENT_S_DN_D SSL_SERVER_S_DN_D
SSL_CLIENT_S_DN_UID SSL_SERVER_S_DN_UID
SSL_CLIENT_S_DN_Email SSL_SERVER_S_DN_Email
SSL_CLIENT_I_DN SSL_SERVER_I_DN
SSL_CLIENT_I_DN_C SSL_SERVER_I_DN_C
SSL_CLIENT_I_DN_ST SSL_SERVER_I_DN_ST
SSL_CLIENT_I_DN_L SSL_SERVER_I_DN_L
SSL_CLIENT_I_DN_O SSL_SERVER_I_DN_O
SSL_CLIENT_I_DN_OU SSL_SERVER_I_DN_OU
SSL_CLIENT_I_DN_CN SSL_SERVER_I_DN_CN
SSL_CLIENT_I_DN_T SSL_SERVER_I_DN_T
SSL_CLIENT_I_DN_I SSL_SERVER_I_DN_I
SSL_CLIENT_I_DN_G SSL_SERVER_I_DN_G
SSL_CLIENT_I_DN_S SSL_SERVER_I_DN_S
SSL_CLIENT_I_DN_D SSL_SERVER_I_DN_D
SSL_CLIENT_I_DN_UID SSL_SERVER_I_DN_UID
SSL_CLIENT_I_DN_Email SSL_SERVER_I_DN_Email
SSL_CLIENT_A_SIG SSL_SERVER_A_SIG
SSL_CLIENT_A_KEY SSL_SERVER_A_KEY
SSL_CLIENT_CERT SSL_SERVER_CERT
SSL_CLIENT_CERT_CHAINn
SSL_CLIENT_VERIFY
SSLRequireSSL Directive
Description: Deny access when SSL is not used for the
HTTP request Syntax: SSLRequireSSLContext: directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl Example
SSLRequireSSL
SSLSessionCache Directive
Description: Type of the global/inter-process SSL Session
Cache Syntax: SSLSessionCache typeDefault: SSLSessionCache noneContext: server config Status: Extension Module: mod_ssl
none
dbm:/path/to/datafile
shm:/path/to/datafile[(size)]
/path/to/datafile) to synchronize the local OpenSSL memory
caches of the server processes. This storage type is not available on all
platforms.Examples
SSLSessionCache dbm:/usr/local/apache/logs/ssl_gcache_data
SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000)
SSLSessionCacheTimeout Directive
Description: Number of seconds before an SSL session expires
in the Session Cache Syntax: SSLSessionCacheTimeout secondsDefault: SSLSessionCacheTimeout 300Context: server config, virtual host Status: Extension Module: mod_ssl Example
SSLSessionCacheTimeout 600
SSLUserName Directive
Description: Variable name to determine user name Syntax: SSLUserName varnameContext: server config, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl Compatibility: Available in Apache 2.0.51 and later REMOTE_USER to be set. The varname can be
any of the SSL environment variables.Example
SSLUserName SSL_CLIENT_S_DN_CN
SSLVerifyClient Directive
Description: Type of Client Certificate verification Syntax: SSLVerifyClient levelDefault: SSLVerifyClient noneContext: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl
but it need not to be (successfully) verifiable.Example
SSLVerifyClient require
SSLVerifyDepth Directive
Description: Maximum depth of CA Certificates in Client
Certificate verification Syntax: SSLVerifyDepth numberDefault: SSLVerifyDepth 1Context: server config, virtual host, directory, .htaccess Override: AuthConfig Status: Extension Module: mod_ssl SSLCACertificatePath), etc.Example
SSLVerifyDepth 10
mod/mod_suexec.html 100644 0 0 10150 11074463123 12023 0 ustar 0 0
아파치 모듈 mod_status
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 서버 활동과 성능에 대한 정보를 제공한다 상태: Base 모듈명: status_module 소스파일: mod_status.c 요약
Status 사용하기
httpd.conf 설정파일에 다음과 같이 추가한다
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .foo.com
</Location>
http://your.server.name/server-status 페이지에
접근하면 서버 통계를 볼 수 있다.
자동 갱신
http://your.server.name/server-status?refresh=N
페이지를 사용하라.
컴퓨터가 읽을 수 있는 Status 파일
http://your.server.name/server-status?auto에서
컴퓨터가 쉽게 읽을 수 있는 status 파일을 얻을 수 있다. 이
형식은 아파치 /support 디렉토리에 있는
log_server_status Perl 프로그램과 같이 자동으로
실행하는 프로그램에 유용하다.
mod_status를 서버와 같이
컴파일하였다면 디렉토리별 설정파일을 (예를
들어, .htaccess) 포함하여 모든
설정파일에서 핸들러를 사용할 수 있다. 그래서 사이트에
보안 문제가 발생할 수 있다.
mod/mod_unique_id.html 100644 0 0 22430 11074463123 12515 0 ustar 0 0
아파치 모듈 mod_suexec
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: CGI 스크립트를 특정 사용자와 그룹 권한으로 실행한다 상태: Extension 모듈명: suexec_module 소스파일: mod_suexec.c 지원: 아파치 2.0 이후부터 요약
SuexecUserGroup 지시어
설명: CGI 프로그램이 사용할 사용자와 그룹 권한 문법: SuexecUserGroup User Group사용장소: 주서버설정, 가상호스트 상태: Extension 모듈: mod_suexec 지원: SuexecUserGroup은 2.0 이후에만 있다. SuexecUserGroup 지시어는 CGI 프로그램이
사용할 사용자와 그룹을 설정한다. CGI가 아닌 요청은 계속
User 지시어로 지정한 사용자가 처리한다. 이 지시어는 아파치
1.3에서 VirtualHost 안에 사용한 User와 Group 지시어를
대체한다.예제
SuexecUserGroup nobody nogroup
mod/mod_userdir.html 100644 0 0 15311 11074463123 12210 0 ustar 0 0
아파치 모듈 mod_unique_id
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 각 요청마다 유일한 식별자를 가지는 환경변수를
제공한다 상태: Extension 모듈명: unique_id_module 소스파일: mod_unique_id.c 요약
UNIQUE_ID를 설정한다. 유일한 식별자는 여러가지
용도로 사용할 수 있지만, 설명은 이 문서의 범위를 넘어선다.
이론
UNIQUE_ID는 MIME base64 인코딩과
비슷한 방법으로 112비트 (32비트 IP 주소, 32비트 pid, 32비트
시간, 16비트 카운터) 묶음을 알파벳 [A-Za-z0-9@-]로
표현한다. 실제 MIME base64 알파벳은
[A-Za-z0-9+/]이지만 +와
/는 URL에서 특별한 의미로 사용하므로 제외했다.
모든 값을 네트웍 바이트순서로 인코딩하기때문에 다른 바이트순서를
사용하는 아키텍쳐간에 값이 같다. 실제 인코딩 순서는
시간, IP 주소, pid, 카운터 순서이다. 이 순서에는 어떤 목적이
있지만, 프로그램은 인코딩 순서에 의존하여 값들을 분석하면
안됨을 강조한다. 프로그램은 인코딩된 UNIQUE_ID
전체를 한 단위로 생각하고, 다른 UNIQUE_ID와
동일한지만 비교할 수 있다.UNIQUE_ID 데이터베이스와
충돌을 염려하지않고 인코딩을 변경할 수 있도록 고안했다.
새로운 인코딩은 첫 항목으로 시간을 사용하거나, 같은 알파벳과
비트 길이를 사용할 수도 있다. 시간이 기본적으로 증가하는 값이므로
클러스터에 있는 모든 컴퓨터가 요청 서비스를 중단하고 이전
인코딩 형식을 그만 사용하기위해 기준 초(flag second)만으로
충분하다. 이후 요청을 재게하고 새로운 인코딩을 시작할 수
있다.
mod/mod_usertrack.html 100644 0 0 34653 11074463123 12550 0 ustar 0 0
아파치 모듈 mod_userdir
설명: 사용자별 디렉토리 상태: Base 모듈명: userdir_module 소스파일: mod_userdir.c 요약
http://example.com/~user/ 식으로
사용자별 디렉토리에 접근할 수 있다.UserDir 지시어
설명: 사용자별 디렉토리 위치 문법: UserDir directory-filename기본값: UserDir public_html사용장소: 주서버설정, 가상호스트 상태: Base 모듈: mod_userdir UserDir 지시어는 사용자의 문서에 대한
요청을 받을때 사용자 홈디렉토리 안에서 사용할 실제 디렉토리를
지정한다. Directory-filename은 다음 중 하나이다:
disabled 키워드.
enabled 키워드로 (아래 참고) 직접 이름을 지정하지 않았다면
모든 사용자명-디렉토리 변환을 하지 않는다.disabled 키워드 뒤에 공백으로 구분한 사용자명 목록.
사용자명이 enabled 구문에 있다고 하더라도, 이 목록에
있는 사용자명은 디렉토리 변환을 하지 않는다.enabled 키워드 뒤에 공백으로 구분한 사용자명 목록.
전체 disable을 사용하고 사용자명이 disabled 구문에
없더라도, 사용자명을 디렉토리 변환한다.Userdir 지시어에 enabled나
disabled 키워드를 사용하지 않으면, 아규먼트를
파일명 패턴으로 처리하여 디렉토리로 변환한다.
http://www.foo.com/~bob/one/two.html에 대한 요청은
다음과 같이 변환된다:
사용한 UserDir 지시어
변환한 경로 UserDir public_html ~bob/public_html/one/two.html UserDir /usr/web /usr/web/bob/one/two.html UserDir /home/*/www /home/bob/www/one/two.html
사용한 UserDir 지시어
변환한 경로 UserDir http://www.foo.com/users http://www.foo.com/users/bob/one/two.html UserDir
http://www.foo.com/*/usr http://www.foo.com/bob/usr/one/two.html UserDir
http://www.foo.com/~*/ http://www.foo.com/~bob/one/two.html
이 지시어를 사용할때 주의하라; 예를 들어,
"UserDir ./"는 "/~root"를 아마도 바람직하지 않게
"/"로 변환한다. 설정에 "UserDir
disabled root"를 포함하길 강력히 권한다. 자세한 정보를 알려면
Directory 지시어와 보안 팁도 참고하라.
UserDir 디렉토리를 허용한다면,
다음과 같다:
UserDir disabled
UserDir enabled user1 user2 user3
UserDir 디렉토리를 허용하고
일부만 거부한다면, 다음과 같다:
UserDir enabled
UserDir disabled user4 user5 user6
Userdir public_html /usr/web http://www.foo.com/
참고
mod/mod_version.html 100644 0 0 14761 11074463123 12230 0 ustar 0 0
Apache Module mod_usertrack
Description:
Clickstream logging of user activity on a site
Status: Extension Module쟅dentifier: usertrack_module Source쟂ile: mod_usertrack.c Summary
Directives
Topics
Logging
CookieLog
directive. In this release, this module does no logging at all.
Instead, a configurable log format file should be used to log
user click-streams. This is possible because the logging module
now allows multiple log files. The cookie itself is logged by
using the text %{cookie}n in the log file format. For
example:
CustomLog logs/clickstream "%{cookie}n %r %t"
CookieLog directive, but this
should be upgraded to the above CustomLog directive.
2-digit or 4-digit dates for cookies?
From: "Christian Allen" <christian@sane.com>
Subject: Re: Apache Y2K bug in mod_usertrack.c
Date: Tue, 30 Jun 1998 11:41:56 -0400
Did some work with cookies and dug up some info that might be useful.
True, Netscape claims that the correct format NOW is four digit dates, and
four digit dates do in fact work... for Netscape 4.x (Communicator), that
is. However, 3.x and below do NOT accept them. It seems that Netscape
originally had a 2-digit standard, and then with all of the Y2K hype and
probably a few complaints, changed to a four digit date for Communicator.
Fortunately, 4.x also understands the 2-digit format, and so the best way to
ensure that your expiration date is legible to the client's browser is to
use 2-digit dates.
However, this does not limit expiration dates to the year 2000; if you use
an expiration year of "13", for example, it is interpreted as 2013, NOT
1913! In fact, you can use an expiration year of up to "37", and it will be
understood as "2037" by both MSIE and Netscape versions 3.x and up (not sure
about versions previous to those). Not sure why Netscape used that
particular year as its cut-off point, but my guess is that it was in respect
to UNIX's 2038 problem. Netscape/MSIE 4.x seem to be able to understand
2-digit years beyond that, at least until "50" for sure (I think they
understand up until about "70", but not for sure).
Summary: Mozilla 3.x and up understands two digit dates up until "37"
(2037). Mozilla 4.x understands up until at least "50" (2050) in 2-digit
form, but also understands 4-digit years, which can probably reach up until
9999. Your best bet for sending a long-life cookie is to send it for some
time late in the year "37".
CookieDomain Directive
Description: The domain to which the tracking cookie applies Syntax: CookieDomain domainContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_usertrack .foo.com is legal, but foo.bar.com and
.com are not.Most browsers in use today will not allow cookies to be set
for a two-part top level domain, such as
.co.uk,
although such a domain ostensibly fulfills the requirements
above.
These domains are equivalent to top level domains such as
.com, and allowing such cookies may be a security
risk. Thus, if you are under a two-part top level domain, you
should still use your actual domain, as you would with any other top
level domain (for example, use .foo.co.uk).
CookieExpires Directive
Description: Expiry time for the tracking cookie Syntax: CookieExpires expiry-periodContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_usertrack CookieName Directive
Description: Name of the tracking cookie Syntax: CookieName tokenDefault: CookieName ApacheContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_usertrack Apache".CookieStyle Directive
Description: Format of the cookie header field Syntax: CookieStyle
Netscape|Cookie|Cookie2|RFC2109|RFC2965Default: CookieStyle NetscapeContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_usertrack
CookieStyle Netscape.CookieTracking Directive
Description: Enables tracking cookie Syntax: CookieTracking on|offDefault: CookieTracking offContext: server config, virtual host, directory, .htaccess Override: FileInfo Status: Extension Module: mod_usertrack mod_usertrack is loaded, and
CookieTracking on is set, Apache will send a
user-tracking cookie for all new requests. This directive can
be used to turn this behavior on or off on a per-server or
per-directory basis. By default, enabling
mod_usertrack will not
activate cookies.
mod/mod_vhost_alias.html 100644 0 0 37400 11074463123 13052 0 ustar 0 0
아파치 모듈 mod_version
이 문서는 최신판 번역이 아닙니다.
최근에 변경된 내용은 영어 문서를 참고하세요.
설명: 버전별 설정 상태: Extension 모듈명: version_module 소스파일: mod_version.c 지원: 아파치 2.0.54 이후부터 요약
<IfVersion>을
제공한다.예제
<IfVersion 2.1.0>
# 현재 웹서버 버전은 정확히 2.1.0이다
</IfVersion>
<IfVersion >= 2.2>
# 진짜 새로운 기능을 사용한다 :-)
</IfVersion>
지시어들
<IfVersion> 지시어
설명: 버전별 설정을 묶는다 문법: <IfVersion [[!]operator] version> ...
</IfVersion>사용장소: 주서버설정, 가상호스트, directory, .htaccess Override 옵션: All 상태: Extension 모듈: mod_version <IfVersion> 섹션은
웹서버 버전이 원하는 조건을 만족할때만 실행할 설정 지시어를
묶는다. 일반적인 (숫자) 비교의 경우 version 아규먼트는
2.1.0이나 2.2와 같이
major[.minor[.patch]]
형식이다. minor와 patch는 없어도 된다.
이들 숫자가 없다면 0이라고 가정한다. 다음과 같은 숫자
operator가 가능하다.operator 설명 = 혹은 ==동일한 웹서버 버전 >보다 큰 웹서버 버전 >=크거나 같은 웹서버 버전 <보다 작은 웹서버 버전 <=작거나 같은 웹서버 버전 예제
<IfVersion >= 2.1>
# 버전이 2.1.0 보다 크거나 같을때만
# 실행한다.
</IfVersion>
operator 설명 = 혹은 ==version은
/regex/ 형식이다~version은
regex 형식이다예제
<IfVersion = /^2.1.[01234]$/>
# 예를 들어, 여기에 버그가 있는 특정 버전에 대한 해결책이 나온다
</IfVersion>
!)를 쓰면 의미를 반대로
해석한다.
<IfVersion !~ ^2.1.[01234]$>
# 이 버전이 아니면
</IfVersion>
=이라고
생각한다.
mod/module-dict.html 100644 0 0 11756 11074463123 12113 0 ustar 0 0
Apache Module mod_vhost_alias
Description: Provides for dynamically configured mass virtual
hosting Status: Extension Module쟅dentifier: vhost_alias_module Source쟂ile: mod_vhost_alias.c Summary
Host: header of
the HTTP request to be used as part of the pathname to
determine what files to serve. This allows for easy use of a
huge number of virtual hosts with similar configurations.Note
mod_alias or mod_userdir are
used for translating URIs to filenames, they will override the
directives of mod_vhost_alias described below. For
example, the following configuration will map
/cgi-bin/script.pl to
/usr/local/apache2/cgi-bin/script.pl in all cases:
ScriptAlias /cgi-bin/ /usr/local/apache2/cgi-bin/
VirtualScriptAlias /never/found/%0/cgi-bin/
Directives
Topics
See also
Directory Name Interpolation
UseCanonicalName
directive for details on how this is determined) or the IP
address of the virtual host on the server in dotted-quad
format. The interpolation is controlled by specifiers inspired
by printf which have a number of formats:
%%insert a %%pinsert the port number of the virtual host %N.Minsert (part of) the name N and M are used to specify
substrings of the name. N selects from the
dot-separated components of the name, and M
selects characters within whatever N has selected.
M is optional and defaults to zero if it isn't
present; the dot must be present if and only if M
is present. The interpretation is as follows:
0the whole name 1the first part 2the second part -1the last part -2the penultimate part 2+the second and all subsequent parts -2+the penultimate and all preceding parts 1+ and -1+the same as 0N or M is greater than the number
of parts available a single underscore is interpolated.
Examples
UseCanonicalName Off
VirtualDocumentRoot /usr/local/apache/vhosts/%0
http://www.example.com/directory/file.html will be
satisfied by the file
/usr/local/apache/vhosts/www.example.com/directory/file.html.
vhosts directory. To do this you might use the
following in your configuration file:
UseCanonicalName Off
VirtualDocumentRoot /usr/local/apache/vhosts/%3+/%2.1/%2.2/%2.3/%2
http://www.domain.example.com/directory/file.html
will be satisfied by the file
/usr/local/apache/vhosts/example.com/d/o/m/domain/directory/file.html.
VirtualDocumentRoot /usr/local/apache/vhosts/%3+/%2.-1/%2.-2/%2.-3/%2
/usr/local/apache/vhosts/example.com/n/i/a/domain/directory/file.html.
VirtualDocumentRoot /usr/local/apache/vhosts/%3+/%2.1/%2.2/%2.3/%2.4+
/usr/local/apache/vhosts/example.com/d/o/m/ain/directory/file.html.
UseCanonicalName DNS
VirtualDocumentRootIP /usr/local/apache/vhosts/%1/%2/%3/%4/docs
VirtualScriptAliasIP /usr/local/apache/vhosts/%1/%2/%3/%4/cgi-bin
http://www.domain.example.com/directory/file.html
would be satisfied by the file
/usr/local/apache/vhosts/10/20/30/40/docs/directory/file.html
if the IP address of www.domain.example.com were
10.20.30.40. A request for
http://www.domain.example.com/cgi-bin/script.pl would
be satisfied by executing the program
/usr/local/apache/vhosts/10/20/30/40/cgi-bin/script.pl.. character in a
VirtualDocumentRoot directive, but it clashes with
a % directive, you can work around the problem in
the following way:
VirtualDocumentRoot /usr/local/apache/vhosts/%2.0.%3.0
http://www.domain.example.com/directory/file.html
will be satisfied by the file
/usr/local/apache/vhosts/domain.example/directory/file.html.LogFormat
directives %V and %A are useful
in conjunction with this module.VirtualDocumentRoot Directive
Description: Dynamically configure the location of the document root
for a given virtual host Syntax: VirtualDocumentRoot interpolated-directory|noneDefault: VirtualDocumentRoot noneContext: server config, virtual host Status: Extension Module: mod_vhost_alias VirtualDocumentRoot directive allows you to
determine where Apache will find your documents based on the
value of the server name. The result of expanding
interpolated-directory is used as the root of the
document tree in a similar manner to the DocumentRoot directive's argument.
If interpolated-directory is none then
VirtualDocumentRoot is turned off. This directive
cannot be used in the same context as VirtualDocumentRootIP.VirtualDocumentRootIP Directive
Description: Dynamically configure the location of the document root
for a given virtual host Syntax: VirtualDocumentRootIP interpolated-directory|noneDefault: VirtualDocumentRootIP noneContext: server config, virtual host Status: Extension Module: mod_vhost_alias VirtualDocumentRootIP directive is like the
VirtualDocumentRoot
directive, except that it uses the IP address of the server end
of the connection for directory interpolation instead of the server
name.VirtualScriptAlias Directive
Description: Dynamically configure the location of the CGI directory for
a given virtual host Syntax: VirtualScriptAlias interpolated-directory|noneDefault: VirtualScriptAlias noneContext: server config, virtual host Status: Extension Module: mod_vhost_alias VirtualScriptAlias directive allows you to
determine where Apache will find CGI scripts in a similar
manner to VirtualDocumentRoot does for other documents. It matches
requests for URIs starting /cgi-bin/, much like ScriptAlias
/cgi-bin/ would.VirtualScriptAliasIP Directive
Description: Dynamically configure the location of the cgi directory for
a given virtual host Syntax: VirtualScriptAliasIP interpolated-directory|noneDefault: VirtualScriptAliasIP noneContext: server config, virtual host Status: Extension Module: mod_vhost_alias VirtualScriptAliasIP directive is like the
VirtualScriptAlias
directive, except that it uses the IP address of the server end
of the connection for directory interpolation instead of the server
name.
mod/mpm_common.html 100644 0 0 203571 11074463123 12064 0 ustar 0 0
모듈을 설명하기위해 사용한 용어들
설명
상태
소스파일
<IfModule>
지시어에서 사용하는 이름이기도 하다.
모듈명
LoadModule 지시어에서
사용한다. 정확히 말하면 소스파일에서 module 형의 외부변수
이름이다.
지원
mod/mpm_netware.html 100644 0 0 17364 11074463123 12224 0 ustar 0 0
Apache MPM Common Directives
Description: A collection of directives that are implemented by
more than one multi-processing module (MPM) Status: MPM Directives
AcceptMutex BS2000Account CoreDumpDirectory EnableExceptionHook Group Listen ListenBackLog LockFile MaxClients MaxMemFree MaxRequestsPerChild MaxSpareThreads MinSpareThreads PidFile ReceiveBufferSize ScoreBoardFile SendBufferSize ServerLimit StartServers StartThreads ThreadLimit ThreadsPerChild UserAcceptMutex Directive
Description: Method that Apache uses to serialize multiple children
accepting requests on network sockets Syntax: AcceptMutex Default|methodDefault: AcceptMutex DefaultContext: server config Status: MPM Module: leader, perchild, prefork, threadpool, workerAcceptMutex directives sets the
method that Apache uses to serialize multiple children accepting
requests on network sockets. Prior to Apache 2.0, the method was
selectable only at compile time. The optimal method to use is
highly architecture and platform dependent. For further details,
see the performance tuning
documentation.Default, then the
compile-time selected default will be used. Other possible
methods are listed below. Note that not all methods are
available on all platforms. If a method is specified which is
not available, a message will be written to the error log
listing the available methods.
flockflock(2) system call to lock the
file defined by the LockFile directive.fcntlfcntl(2) system call to lock the
file defined by the LockFile directive.posixsempthreadsysvsemLogLevel to debug. Then the default AcceptMutex will be written into the ErrorLog.BS2000Account Directive
Description: Define the non-privileged account on BS2000
machines Syntax: BS2000Account accountContext: server config Status: MPM Module: perchild, preforkCompatibility: Only available for BS2000 machines BS2000Account directive is available for
BS2000 hosts only. It must be used to define the account number for
the non-privileged apache server user (which was configured using the
User directive). This is
required by the BS2000 POSIX subsystem (to change the underlying BS2000
task environment by performing a sub-LOGON) to prevent CGI scripts
from accessing resources of the privileged account which started the
server, usually SYSROOT.Note
BS2000Account directive can be used.See also
CoreDumpDirectory Directive
Description: Directory where Apache attempts to
switch before dumping core Syntax: CoreDumpDirectory directoryDefault: See usage for the default settingContext: server config Status: MPM Module: beos, leader, mpm_winnt, perchild, prefork, threadpool, workerServerRoot directory, however
since this should not be writable by the user the server runs
as, core dumps won't normally get written. If you want a core
dump for debugging, you can use this directive to place it in a
different location.Core Dumps on Linux
CoreDumpDirectory.EnableExceptionHook Directive
Description: Enables a hook that runs exception handlers
after a crash Syntax: EnableExceptionHook On|OffDefault: EnableExceptionHook OffContext: server config Status: MPM Module: leader, perchild, prefork, threadpool, workerCompatibility: Available in version 2.0.49 and later --enable-exception-hook option. It
enables a hook that allows external modules to plug in and do something
after a child crashed.mod_whatkilledus and
mod_backtrace that make use of this hook. Please have a
look at Jeff Trawick's EnableExceptionHook site for more information about these.Group Directive
Description: Group under which the server will answer
requests Syntax: Group unix-groupDefault: Group #-1Context: server config Status: MPM Module: beos, leader, mpmt_os2, perchild, prefork, threadpool, workerCompatibility: Only valid in global server config since Apache
2.0 Group directive sets the group under
which the server will answer requests. In order to use this
directive, the server must be run initially as root. If
you start the server as a non-root user, it will fail to change to the
specified group, and will instead continue to run as the group of the
original user. Unix-group is one of:
# followed by a group number.Example
Group www-group
nobody,
but this is not always possible or desirable.Security
Group (or User) to root unless
you know exactly what you are doing, and what the dangers are.<VirtualHost> is no longer supported. To
configure your server for suexec use
SuexecUserGroup.Listen Directive
Description: IP addresses and ports that the server
listens to Syntax: Listen [IP-address:]portnumberContext: server config Status: MPM Module: beos, leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, workerCompatibility: Required directive since Apache 2.0 Listen directive instructs Apache to
listen to only specific IP addresses or ports; by default it
responds to requests on all IP interfaces. Listen
is now a required directive. If it is not in the config file, the
server will fail to start. This is a change from previous versions
of Apache.Listen directive tells the server to
accept incoming requests on the specified port or address-and-port
combination. If only a port number is specified, the server listens to
the given port on all interfaces. If an IP address is given as well
as a port, the server will listen on the given port and
interface.Listen directives may be used to
specify a number of addresses and ports to listen to. The server will
respond to requests from any of the listed addresses and ports.
Listen 80
Listen 8000
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
Listen [2001:db8::a00:20ff:fea7:ccea]:80
Error condition
Multiple Listen directives for the same ip
address and port will result in an Address already in use
error message.
See also
ListenBackLog Directive
Description: Maximum length of the queue of pending connections Syntax: ListenBacklog backlogDefault: ListenBacklog 511Context: server config Status: MPM Module: beos, leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, workerlisten(2) system call.LockFile Directive
Description: Location of the accept serialization lock file Syntax: LockFile filenameDefault: LockFile logs/accept.lockContext: server config Status: MPM Module: leader, perchild, prefork, threadpool, workerLockFile directive sets the path to
the lockfile used when Apache is used with an AcceptMutex value of either
fcntl or flock. This directive should
normally be left at its default value. The main reason for changing
it is if the logs directory is NFS mounted, since
the lockfile must be stored on a local disk. The PID
of the main server process is automatically appended to the
filename.Security
/var/tmp because someone could create
a denial of service attack and prevent the server from starting by
creating a lockfile with the same name as the one the server will try
to create.See also
MaxClients Directive
Description: Maximum number of child processes that will be created
to serve requests Syntax: MaxClients numberDefault: See usage for detailsContext: server config Status: MPM Module: beos, leader, prefork, threadpool, workerMaxClients directive sets the limit
on the number of simultaneous requests that will be served. Any
connection attempts over the MaxClients
limit will normally be queued, up to a number based on the
ListenBacklog
directive. Once a child process is freed at the end of a different
request, the connection will then be serviced.prefork),
MaxClients translates into the maximum
number of child processes that will be launched to serve requests.
The default value is 256; to increase it, you must also raise
ServerLimit.beos
or worker) MaxClients restricts
the total number of threads that will be available to serve clients.
The default value for beos is 50. For
hybrid MPMs the default value is 16 (ServerLimit) multiplied by the value of
25 (ThreadsPerChild). Therefore, to increase MaxClients to a value that requires more than 16 processes,
you must also raise ServerLimit.MaxMemFree Directive
Description: Maximum amount of memory that the main allocator is allowed
to hold without calling free()Syntax: MaxMemFree KBytesDefault: MaxMemFree 0Context: server config Status: MPM Module: beos, leader, mpm_netware, prefork, threadpool, worker, mpm_winntMaxMemFree directive sets the
maximum number of free Kbytes that the main allocator is allowed
to hold without calling free(). When not set, or when set
to zero, the threshold will be set to unlimited.MaxRequestsPerChild Directive
Description: Limit on the number of requests that an individual child server
will handle during its life Syntax: MaxRequestsPerChild numberDefault: MaxRequestsPerChild 10000Context: server config Status: MPM Module: leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, workerMaxRequestsPerChild directive sets
the limit on the number of requests that an individual child
server process will handle. After
MaxRequestsPerChild requests, the child
process will die. If MaxRequestsPerChild is
0, then the process will never expire.Different default values
mpm_netware and
mpm_winnt is 0.MaxRequestsPerChild to a
non-zero limit has two beneficial effects:
Note
KeepAlive requests, only
the first request is counted towards this limit. In effect, it
changes the behavior to limit the number of connections per
child.MaxSpareThreads Directive
Description: Maximum number of idle threads Syntax: MaxSpareThreads numberDefault: See usage for detailsContext: server config Status: MPM Module: beos, leader, mpm_netware, mpmt_os2, perchild, threadpool, workerperchild the default is
MaxSpareThreads 10. This MPM monitors the number of
idle threads on a per-child basis. If there are too many idle
threads in that child, the server will begin to kill threads
within that child.worker, leader and threadpool the default is MaxSpareThreads 250.
These MPMs deal with idle threads on a server-wide basis. If there
are too many idle threads in the server then child processes are
killed until the number of idle threads is less than this number.mpm_netware the default is
MaxSpareThreads 100. Since this MPM runs a
single-process, the spare thread count is also server-wide.beos and mpmt_os2 work
similar to mpm_netware. The default for
beos is MaxSpareThreads 50. For
mpmt_os2 the default value is 10.Restrictions
MaxSpareThreads value
is restricted. Apache will correct the given value automatically
according to the following rules:
perchild requires MaxSpareThreads to be less or equal than ThreadLimit.mpm_netware wants the value to be greater than
MinSpareThreads.leader, threadpool and
worker the value must be greater or equal than
the sum of MinSpareThreads
and ThreadsPerChild.See also
MinSpareThreads Directive
Description: Minimum number of idle threads available to handle request
spikes Syntax: MinSpareThreads numberDefault: See usage for detailsContext: server config Status: MPM Module: beos, leader, mpm_netware, mpmt_os2, perchild, threadpool, workerperchild uses a default of
MinSpareThreads 5 and monitors the number of idle
threads on a per-child basis. If there aren't enough idle threads
in that child, the server will begin to create new threads within
that child. Thus, if you set NumServers to 10 and a MinSpareThreads value of 5, you'll have
at least 50 idle threads on your system.worker, leader and
threadpool use a default of MinSpareThreads
75 and deal with idle threads on a server-wide basis. If
there aren't enough idle threads in the server then child
processes are created until the number of idle threads is greater
than number.mpm_netware uses a default of
MinSpareThreads 10 and, since it is a single-process
MPM, tracks this on a server-wide bases.beos and mpmt_os2 work
similar to mpm_netware. The default for
beos is MinSpareThreads 1. For
mpmt_os2 the default value is 5.See also
PidFile Directive
Description: File where the server records the process ID
of the daemon Syntax: PidFile filenameDefault: PidFile logs/httpd.pidContext: server config Status: MPM Module: beos, leader, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, workerPidFile directive sets the file to
which the server records the process id of the daemon. If the
filename is not absolute then it is assumed to be relative to the
ServerRoot.Example
PidFile /var/run/apache.pid
ErrorLog and TransferLog, and
re-reads its configuration files. This is done by sending a
SIGHUP (kill -1) signal to the process id listed in the
PidFile.PidFile is subject to the same
warnings about log file placement and security.Note
apachectl script for (re-)starting or stopping the server.ReceiveBufferSize Directive
Description: TCP receive buffer size Syntax: ReceiveBufferSize bytesDefault: ReceiveBufferSize 0Context: server config Status: MPM Module: beos, leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, worker0, the server will use the
OS default.ScoreBoardFile Directive
Description: Location of the file used to store coordination data for
the child processes Syntax: ScoreBoardFile file-pathDefault: ScoreBoardFile logs/apache_statusContext: server config Status: MPM Module: beos, leader, mpm_winnt, perchild, prefork, threadpool, workerExample
ScoreBoardFile /var/run/apache_status
ScoreBoardFile then
you may see improved speed by placing it on a RAM disk. But be
careful that you heed the same warnings about log file placement
and security.See also
SendBufferSize Directive
Description: TCP buffer size Syntax: SendBufferSize bytesDefault: SendBufferSize 0Context: server config Status: MPM Module: beos, leader, mpm_netware, mpm_winnt, mpmt_os2, perchild, prefork, threadpool, worker0, the server will use the
OS default.ServerLimit Directive
Description: Upper limit on configurable number of processes Syntax: ServerLimit numberDefault: See usage for detailsContext: server config Status: MPM Module: leader, perchild, prefork, threadpool, workerprefork MPM, this directive sets the
maximum configured value for MaxClients for the lifetime of the
Apache process. For the worker MPM, this directive
in combination with ThreadLimit sets
the maximum configured value for MaxClients for the lifetime of the
Apache process. Any attempts to change this directive during a
restart will be ignored, but MaxClients can be modified during
a restart.ServerLimit is set to a value much higher
than necessary, extra, unused shared memory will be allocated. If
both ServerLimit and MaxClients are set to values
higher than the system can handle, Apache may not start or the
system may become unstable.prefork MPM, use this directive only
if you need to set MaxClients higher than 256 (default).
Do not set the value of this directive any higher than what you
might want to set MaxClients to.worker, leader and
threadpool use this directive only
if your MaxClients and
ThreadsPerChild
settings require more than 16 server processes (default). Do not set
the value of this directive any higher than the number of server
processes required by what you may want for MaxClients and ThreadsPerChild.perchild MPM, use this directive only
if you need to set NumServers higher than 8 (default).Note
ServerLimit 20000 compiled
into the server. This is intended to avoid nasty effects caused by
typos.See also
StartServers Directive
Description: Number of child server processes created at startup Syntax: StartServers numberDefault: See usage for detailsContext: server config Status: MPM Module: leader, mpmt_os2, prefork, threadpool, workerStartServers directive sets the
number of child server processes created on startup. As the number
of processes is dynamically controlled depending on the load,
there is usually little reason to adjust this parameter.leader, threadpool and
worker the default is StartServers 3.
For prefork defaults to 5 and for
mpmt_os2 to 2.StartThreads Directive
Description: Number of threads created on startup Syntax: StartThreads numberDefault: See usage for detailsContext: server config Status: MPM Module: beos, mpm_netware, perchildperchild the default is StartThreads
5 and this directive tracks the number of threads per
process at startup.mpm_netware the default is
StartThreads 50 and, since there is only a single
process, this is the total number of threads created at startup to
serve requests.beos the default is StartThreads
10. It also reflects the total number of threads created
at startup to serve requests.ThreadLimit Directive
Description: Sets the upper limit on the configurable number of threads
per child process Syntax: ThreadLimit numberDefault: See usage for detailsContext: server config Status: MPM Module: leader, mpm_winnt, perchild, threadpool, workerCompatibility: Available for mpm_winnt in Apache 2.0.41
and laterThreadsPerChild for the lifetime
of the Apache process. Any attempts to change this directive
during a restart will be ignored, but ThreadsPerChild can be modified
during a restart up to the value of this directive.ThreadLimit is set to a value much higher
than ThreadsPerChild,
extra unused shared memory will be allocated. If both
ThreadLimit and ThreadsPerChild are set to values
higher than the system can handle, Apache may not start or the
system may become unstable. Do not set the value of this directive
any higher than your greatest predicted setting of ThreadsPerChild for the
current run of Apache.ThreadLimit is
1920 when used with mpm_winnt and
64 when used with the others.Note
ThreadLimit 20000 (or
ThreadLimit 15000 with mpm_winnt)
compiled into the server. This is intended to avoid nasty effects
caused by typos.ThreadsPerChild Directive
Description: Number of threads created by each child process Syntax: ThreadsPerChild numberDefault: See usage for detailsContext: server config Status: MPM Module: leader, mpm_winnt, threadpool, workermpm_winnt,
where there is only one child process, this number should be high
enough to handle the entire load of the server. If using an MPM
like worker, where there are multiple child processes,
the total number of threads should be high enough to handle
the common load on the server.ThreadsPerChild is
64 when used with mpm_winnt and
25 when used with the others.User Directive
Description: The userid under which the server will answer
requests Syntax: User unix-useridDefault: User #-1Context: server config Status: MPM Module: leader, perchild, prefork, threadpool, workerCompatibility: Only valid in global server config since Apache
2.0 User directive sets the user ID as
which the server will answer requests. In order to use this
directive, the server must be run initially as root.
If you start the server as a non-root user, it will fail to change
to the lesser privileged user, and will instead continue to run as
that original user. If you do start the server as root,
then it is normal for the parent process to remain running as root.
Unix-userid is one of:
nobody, but
this is not always desirable, since the nobody user
can have other uses on the system.Security
User (or Group) to root unless
you know exactly what you are doing, and what the dangers are.perchild MPM, which is intended to
server virtual hosts run under different user IDs, the
User directive defines the user ID for the
main server and the fallback for <VirtualHost> sections without an
AssignUserID directive.<VirtualHost> is no longer supported. To
configure your server for suexec use
SuexecUserGroup.
mod/mpm_winnt.html 100644 0 0 13214 11074463123 11704 0 ustar 0 0
Apache MPM netware
Description: Multi-Processing Module implementing an exclusively threaded web
server optimized for Novell NetWare Status: MPM Module쟅dentifier: mpm_netware_module Source쟂ile: mpm_netware.c Summary
StartThreads,
MinSpareThreads,
MaxSpareThreads, and
MaxThreads
regulate how the main thread creates worker threads to serve
requests. In general, Apache is very self-regulating, so most
sites do not need to adjust these directives from their default
values. Sites with limited memory may need to decrease MaxThreads to keep the server from
thrashing (spawning and terminating idle threads). More information
about tuning process creation is provided in the performance hints
documentation.MaxRequestsPerChild
controls how frequently the server recycles processes by killing old
ones and launching new ones. On the NetWare OS it is highly
recommended that this directive remain set to 0. This allows worker
threads to continue servicing requests indefinitely.Directives
Listen ListenBacklog MaxMemFree MaxRequestsPerChild MaxSpareThreads MaxThreads MinSpareThreads ReceiveBufferSize SendBufferSize StartThreads ThreadStackSizeSee also
MaxThreads Directive
Description: Set the maximum number of worker threads Syntax: MaxThreads numberDefault: MaxThreads 2048Context: server config Status: MPM Module: mpm_netware MaxThreads directive sets the desired
maximum number worker threads allowable. The default value is
also the compiled in hard limit. Therefore it can only be lowered,
for example:
MaxThreads 512
ThreadStackSize Directive
Description: Determine the stack size for each thread Syntax: ThreadStackSize numberDefault: ThreadStackSize 65536Context: server config Status: MPM Module: mpm_netware
mod/mpmt_os2.html 100644 0 0 10704 11074463123 11435 0 ustar 0 0
Apache MPM winnt
Description: This Multi-Processing Module is optimized for Windows
NT. Status: MPM Module쟅dentifier: mpm_winnt_module Source쟂ile: mpm_winnt.c Summary
Directives
Win32DisableAcceptEx Directive
Description: Use accept() rather than AcceptEx() to accept network connections Syntax: Win32DisableAcceptExDefault: AcceptEx() is enabled by default. Use this directive to disable use of
AcceptEx()Context: server config Status: MPM Module: mpm_winnt Compatibility: Available in Version 2.0.49 and later AcceptEx() is a Microsoft WinSock v2 API that provides
some performance improvements over the use of the BSD style
accept() API in certain circumstances. Some popular Windows
products, typically virus scanning or virtual private network
packages, have bugs that interfere with the proper operation of
AcceptEx(). If you encounter an error condition like:
[error] (730038)An operation was attempted on something that is
not a socket.: winnt_accept: AcceptEx failed. Attempting to recover.
AcceptEx().
mod/perchild.html 100644 0 0 41115 11074463123 11467 0 ustar 0 0
Apache MPM os2
Description: Hybrid multi-process, multi-threaded MPM for OS/2 Status: MPM Module쟅dentifier: mpm_mpmt_os2_module Source쟂ile: mpmt_os2.c Summary
StartServers processes
accepting connections.MinSpareThreads and
MaxSpareThreads.
Apache MPM perchild
Description: Multi-Processing Module allowing for daemon processes serving
requests to be assigned a variety of different userids Status: MPM Module쟅dentifier: mpm_perchild_module Source쟂ile: perchild.c Summary
This module is not functional. Development of this module is not
complete and is not currently active. Do not use
perchild unless you are a programmer willing to
help fix it.
Directives
AcceptMutex AssignUserID BS2000Account ChildPerUserID CoreDumpDirectory EnableExceptionHook Group Listen ListenBacklog LockFile MaxRequestsPerChild MaxSpareThreads MaxThreadsPerChild MinSpareThreads NumServers PidFile ReceiveBufferSize ScoreBoardFile SendBufferSize ServerLimit StartThreads ThreadLimit UserTopics
See also
How it works
NumServers
directive at server startup. Each child process creates threads as
specified in the StartThreads directive.
The individual threads then
listen for connections and serve them when they arrive.MinSpareThreads
and MaxSpareThreads.
Since this process is very self-regulating, it is rarely
necessary to modify these directives from their default values.
The maximum number of clients that may be served simultaneously
is determined by multiplying the number of server processes
that will be created (NumServers) by the maximum
number of threads created in each process
(MaxThreadsPerChild).User and Group directives are used to
set the privileges of the Apache child processes. The child
processes must be able to read all the content that will be
served, but should have as few privileges beyond that as
possible. In addition, unless suexec is used,
these directives also set the privileges which will be inherited
by CGI scripts.MaxRequestsPerChild
controls how frequently the
server recycles processes by killing old ones and launching new
ones.Working with different user-IDs
perchild MPM adds the extra ability to
specify that particular processes should serve requests under
different user-IDs. These user-IDs can then be associated with
specific virtual hosts. You have to use one ChildPerUserID directive for
every user/group combination you want to be run. Then you can tie
particular virtual hosts to that user and group IDs.user1/group1. The next four are run
under user2/group2 and the remaining
process uses the User and Group
of the main server:Global config
NumServers 7
ChildPerUserID user1 group1 2
ChildPerUserID user2 group2 4
server2 has to serve about twice of the hits of
server1.Example
NameVirtualHost *
<VirtualHost *>
ServerName fallbackhost
# no assignment; use fallback
</VirtualHost>
<VirtualHost *>
ServerName server1
AssignUserID user1 group1
</VirtualHost>
<VirtualHost *>
ServerName server2
AssignUserID user2 group2
</VirtualHost>
AssignUserID Directive
Description: Tie a virtual host to a user and group ID Syntax: AssignUserID user-id group-idContext: virtual host Status: MPM Module: perchild ChildPerUserID directive. See the section above for a
configuration example.ChildPerUserID Directive
Description: Specify user ID and group ID for a number of child
processes Syntax: ChildPerUserID user-id group-id
num-childrenContext: server config Status: MPM Module: perchild root.
If you start the server as a non-root user, it will fail to change
to the lesser privileged user.ChildPerUserID directives
in the config file, is less than NumServers, then all remaining children will inherit the
User and Group settings from the main server.
See the section above for a configuration
example.Security