httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From n.@apache.org
Subject cvs commit: httpd-2.0/docs/manual/vhosts details.xml.ko examples.xml.ko fd-limits.xml.ko index.xml.ko ip-based.xml.ko mass.xml.ko name-based.xml.ko
Date Sat, 10 May 2003 15:05:37 GMT
nd          2003/05/10 08:05:36

  Added:       docs/manual bind.xml.ko cgi_path.xml.ko configuring.xml.ko
                        content-negotiation.xml.ko custom-error.xml.ko
                        dns-caveats.xml.ko dso.xml.ko env.xml.ko
                        filter.xml.ko glossary.xml.ko handler.xml.ko
                        index.xml.ko install.xml.ko invoking.xml.ko
                        logs.xml.ko mpm.xml.ko new_features_2_0.xml.ko
                        sections.xml.ko server-wide.xml.ko sitemap.xml.ko
                        stopping.xml.ko suexec.xml.ko upgrading.xml.ko
                        urlmapping.xml.ko
               docs/manual/style/lang ko.xml
               docs/manual/vhosts details.xml.ko examples.xml.ko
                        fd-limits.xml.ko index.xml.ko ip-based.xml.ko
                        mass.xml.ko name-based.xml.ko
  Log:
  Incorporate new Korean translations
  
  Translated by: Jeongho Jeon <maczniak@operamail.com>
  Reviewed by: Choi Kyusic <kyusic@hotmail.com>
  
  Revision  Changes    Path
  1.1                  httpd-2.0/docs/manual/bind.xml.ko
  
  Index: bind.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.7 -->
  
  <manualpage metafile="bind.xml.meta">
  
    <title>주소와 포트 지정 (Binding)</title>
  
    <summary>
      <p>아파치가 특정 주소와 포트에서 서비스하도록 설정하기.</p>
    </summary>
    
    <seealso><a href="vhosts/">가상호스트</a></seealso>
    <seealso><a href="dns-caveats.html">DNS 문제</a></seealso>
  
    <section id="overview">
      <title>개요</title>
      
      <related>
        <modulelist>
          <module>core</module>
          <module>mpm_common</module>
        </modulelist>
        <directivelist>
          <directive module="core" type="section">VirtualHost</directive>
          <directive module="mpm_common">Listen</directive>
        </directivelist>
      </related>
      
      
      <p>아파치를 시작하면 아파치는 컴퓨터의 어떤 포트와 주소에
      연결하여, 들어오는 요청을 기다린다. 기본적으로 아파치는
      컴퓨터의 모든 주소에서 기다린다. 그러나 아파치가 특정 포트나
      선택한 주소만을 기다리게 해야할 경우가 있다. 또 이 문제는
      아파치가 어떻게 다른 IP 주소, 호스트명, 포트에 반응할지를
      결정하는 가상호스트 기능과도 관련되있다.</p>
  
      <p><directive module="mpm_common">Listen</directive> 지시어는
      서버가 특정 포트나 주소와 포트 조합에서만 요청을 받게
      한다. <directive module="mpm_common">Listen</directive>
      지시어에 포트 번호만 지정하면, 서버는 모든 인터페이스에서
      지정한 포트를 기다린다. 여러 Listen 지시어로 기다릴 여러
      주소와 포트를 지정할 수도 있다. 서버는 열거한 주소와 포트로
      요청이 들어오면 응답한다.</p>
  
      <p>예를 들어, 서버가 80번과 8000번 포트 모두에서 연결을
      받도록 하려면:</p>
  
      <example>
        Listen 80<br />
        Listen 8000
      </example>
  
      <p>서버가 지정한 두 인터페이스와 포트에서 연결을 기다리도록
      하려면,</p>
  
      <example>
        Listen 192.170.2.1:80<br />
        Listen 192.170.2.5:8000
      </example>
  
      <p>IPv6 주소는 다음과 같이 대괄호로 묶어야 한다:</p>
  
      <example>
        Listen [fe80::a00:20ff:fea7:ccea]:80
      </example>
    </section>
  
    <section id="ipv6">
      <title>IPv6에서 특별히 고려할 점</title>
  
      <p>IPv6를 구현한 플래폼이 늘고 있고 APR이 이들 플래폼 대부분에서
  	IPv6를 지원하기때문에, 아파치는 IPv6 소켓을 할당하여 IPv6로
  	받은 요청을 처리할 수 있다.</p>
  
      <p>아파치 관리자에게 복잡한 부분은 IPv6 소켓이 IPv4 연결과
  	IPv6 연결을 모두 처리할 수 있느냐는 점이다. 대부분의 플래폼에서는
      IPv4-대응(mapped) IPv6 주소를 사용하여 IPv6 소켓에서 IPv4
  	연결을 받지만, FreeBSD와 NetBSD와 OpenBSD은 시스템전체 정책때문에
  	기본적으로 허용하지 않는다. 그러나 기본적으로 허용하지않는
  	시스템이라도 아파치를 위해 특별한 설정 파라미터로 변경할
  	수 있다.</p>
  
      <p>아파치가 최소한의 소켓을 사용하여 IPv4 연결과 IPv6 연결을
  	모두 받도록하려면 IPv4-대응 IPv6 주소를 사용해야 한다. 그러기위해서
  	컴파일때 구성 옵션 <code>--enable-v4-mapped</code>를 사용하고,
  	다음과 같이 일반적인 Listen 지시어를 사용한다:</p>
  
      <example>
        Listen 80
      </example>
  
      <p><code>--enable-v4-mapped</code>를 사용할때 아파치가 만드는
  	기본 설정파일의 Listen 지시어는 위와 같다.
  	<code>--enable-v4-mapped</code>는 FreeBSD, NetBSD, OpenBSD를
  	제외한 모든 플래폼에서 기본값이고, 아마도 당신의 아파치도
  	마찬가지일 것이다.</p>
  
      <p>플래폼과 APR의 지원여부와 관계없이 아파치가 IPv4 연결만을
  	받도록하려면, 다음 예제와 같이 모든 Listen 지시어에 IPv4 주소를
  	사용한다:</p>
  
      <example>
        Listen 0.0.0.0:80<br />
        Listen 192.170.2.1:80
      </example>
  
      <p>IPv4 연결과 IPv6 연결을 서로 다른 소켓으로 받으려면,
  	컴파일때 구성 옵션 <code>--disable-v4-mapped</code>를 사용하고
  	다음과 같이 Listen 지시어를 따로 사용한다:</p>
  
      <example>
        Listen [::]:80<br />
        Listen 0.0.0.0:80
      </example>
  
      <p><code>--disable-v4-mapped</code>를 사용할때 아파치가 만드는
  	기본 설정파일의 Listen 지시어는 위와 같다.
      <code>--disable-v4-mapped</code>는 FreeBSD, NetBSD, OpenBSD에서
  	기본값이다.</p>
  
    </section>
  
    <section id="virtualhost">
      <title>가상호스트와 어떻게 연관되나</title>
  
      <p>Listen은 가상호스트를 만들지 않는다. 이는 단지 주서버가
      어떤 주소와 포트를 기다릴지만 알려준다. <directive
      module="core" type="section">VirtualHost</directive> 지시어를
      사용하지 않으면, 서버는 받은 모든 요청을 똑같이 처리한다.
      그러나 <directive module="core"
      type="section">VirtualHost</directive>로 여러 주소와 포트에
      대해 다른 행동을 지정할 수 있다. 가상호스트를 만들려면
      먼저 서버에게 사용할 주소와 포트를 알려줘야 한다. 그리고
      특정 주소와 포트에 대한 가상호스트의 행동을 지정할
      <directive module="core" type="section">VirtualHost</directive>
      섹션이 필요하다. 주서버가 기다리지않는 주소와 포트를 사용하는
      <directive module="core" type="section">VirtualHost</directive>는
      접근할 수 없음을 주의하라.</p>
    </section>
  </manualpage>
  
  
  
  
  1.1                  httpd-2.0/docs/manual/cgi_path.xml.ko
  
  Index: cgi_path.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.3 -->
  
  <manualpage metafile="cgi_path.xml.meta">
  
    <title>CGI 환경에서 PATH_INFO의 변화</title>
  
    <summary>
      <p>아파치 1.1.1과 그 이전 버전의 경우 CGI 환경에서
      PATH_INFO를 만드는 방법이 직관적이지 않고 어떤 경우 서버를
      죽이기도 했다. 아파치 1.2 이후 이 방법이 변했다. 기존의
      어떤 CGI 프로그램들과 약간의 호환문제가 있지만
      아파치 1.2의 행동은 아직도 CGI/1.1 규약을 벋어나지않으며,
      쉽게 CGI 스크립트를 수정할 수 있다. (<a href="#compat">아래
      참고</a>)</p>
    </summary>
  
    <section id="prob"><title>문제점</title>
      <p>아파치 1.1.1과 그 이전 버전은 URL 대신 파일명을
      가지고 PATH_INFO와 SCRIPT_NAME 환경변수를 구현했다. 많은
      경우 올바른 결과를 얻지만, 파일시스템 경로가 path
      정보를 포함한다면 잘못된 결과가 나올 수 있다. 예를 들어,
      설정파일에 다음과 같은 내용이 있다면:</p>
  
      <example>
        Alias /cgi-ralph /usr/local/httpd/cgi-bin/user.cgi/ralph
      </example>    
      
      <p>이 경우 <code>user.cgi</code>는 CGI 스크립트이고, "/ralph"는
      CGI에 넘겨지는 정보다. 이 경우
      "<code>/cgi-ralph/script/</code>"로 요청이 들어오면 PATH는
      "<code>/ralph/script</code>"가 되고, SCRIPT_NAME은
      "<code>/cgi-</code>"가 된다. 후자는 분명히 잘못되었다.
      심지어 어떤 경우 서버가 죽기도 한다.</p>
    </section>
  
    <section id="solution"><title>해결책</title>
      <p>아파치 1.2 이후에서는 URL에서 클라이언트가 조절가능한
      부분을 판단하여 SCRIPT_NAME과 PATH_INFO를 설정한다. 위의
      예에서 PATH_INFO는 "<code>/script</code>"가 되고, SCRIPT_NAME은
      "<code>/cgi-ralph</code>"가 된다. 이는 합리적이며 서버에
      문제를 일으키지 않는다. 또, 이전 버전과 달리 스크립트에서
      "<code>http://$SERVER_NAME:$SERVER_PORT$SCRIPT_NAME$PATH_INFO</code>"가
      현재 스크립트를 가리키는 URL임을 보장할 수 있다.</p>
  
      <p>그러나 불행히도 <code>Alias</code> 지시어의
      "<code>/ralph</code>" 정보는 사라진다. 그러나 우리는
      파일시스템을 사용하여 이런 정보를 넘겨주는 것이 바람직한
      방법이 아니며, 이를 사용하는 스크립트는 작동할"만하지"
      않다고 생각한다. 그러나 아파치 1.2b3 이후에는 이에 대한
      <a href="#compat">해결책</a>이 있다.</p>
    </section>
  
    <section id="compat">
      <title>이전 서버와 호환성</title>
  
      <p>아파치 이전 버전이나 다른 서버용으로 설계된 스크립트는
      이전 PATH_INFO 변수가 제공했던 정보가 필요할 수 있다. 그래서
      아파치 1.2 (1.2b3 이후)는 FILEPATH_INFO라는 변수를 더 설정한다.
      이 환경변수는 아파치 1.1.1의 PATH_INFO 값을 가진다.</p>
  
      <p>스크립트가 아파치 1.2와 이전 버전 모두에서 동작하게하려면,
      먼저 FILEPATH_INFO가 있는지 검사하고 있다면 그것을
      사용한다. 없다면 PATH_INFO를 사용한다. 예를 들어,
      Perl로는 다음과 같다:</p>
  
      <example>
        $path_info = $ENV{'FILEPATH_INFO'} || $ENV{'PATH_INFO'};
      </example>
  
      <p>이렇게 하면 모든 아파치를 포함하여 CGI/1.1 규정을 따르는
      모든 서버에서 스크립트가 동작할 수 있다.</p>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/configuring.xml.ko
  
  Index: configuring.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.7 -->
  <manualpage metafile="configuring.xml.meta">
  
    <title>설정파일</title>
  
  <summary>
  <p>이 문서는 아파치 웹서버를 설정하는 파일들을 설명한다.</p>
  </summary>
  
    <section id="main">
      <title>주설정파일</title>
      <related>
        <modulelist>
          <module>mod_mime</module>
        </modulelist>
        <directivelist>
          <directive module="core" type="section">IfDefine</directive>
          <directive module="core">Include</directive>
          <directive module="mod_mime">TypesConfig</directive>
        </directivelist>
      </related>
  
      <p>일반 문서 파일인 설정파일에 <a
      href="mod/directives.html">지시어</a>를 사용하여 아파치를
      설정한다. 주설정파일을 보통 <code>httpd.conf</code>라고
      부른다. 이 파일의 위치는 컴파일시 정해지나, <code>-f</code>
      명령행 옵션으로 지정해줄 수 있다. 또 다른 설정파일을 <directive
      module="core">Include</directive> 지시어를 사용하여 포함할
      수 있고, 와일드카드를 사용하여 많은 설정파일을 포함할 수도
      있다. 이 경우 지시어를 어떤 설정파일에나 사용해도 된다.
      주설정파일을 수정하면 아파치를 시작하거나 재시작한 이후에
      반영된다.</p>
  
      <p>서버는 mime 문서타입을 담은 파일도 읽는다. 파일명은
      <directive module="mod_mime">TypesConfig</directive> 지시어로
      설정하고, 기본값은 <code>mime.types</code>이다.</p>
    </section>
  
    <section id="syntax">
      <title>설정파일 문법</title>
  
      <p>아파치 설정파일은 한줄에 한 지시어를 사용한다. 줄 마지막
      문자가 백슬래쉬 "\"이면 지시어가 다음 줄에서 계속됨을 뜻한다.
      이 경우 백슬래쉬 뒤에 어떤 문자나 공백도 나오면 안된다.</p>
  
      <p>설정파일의 지시어는 대소문자를 구별하지 않지만, 지시어의
      아규먼트는 대소문자를 구별하는 경우가 있다. 해쉬문자 "#"로
      시작하는 줄은 주석으로 무시한다. 주석을 설정 지시어와 같은
      줄에 사용할 수 <strong>없다</strong>. 빈줄과 지시어 앞에 나오는
      공백은 무시하므로, 간결하게 보이도록 지시어를 줄들임할(indent)
      수 있다.</p>
  
      <p><code>apachectl configtest</code>나 <code>-t</code> 명령행
      옵션을 사용하여 아파치를 실행하지 않고도 설정파일의 문법
      오류를 검사할 수 있다.</p>
    </section>
  
    <section id="modules">
      <title>모듈</title>
  
      <related>
        <modulelist>
          <module>mod_so</module>
        </modulelist>
        <directivelist>
          <directive module="core" type="section">IfModule</directive>
          <directive module="mod_so">LoadModule</directive>
        </directivelist>
      </related>
  
      <p>아파치는 모듈화된 서버다. 이는 매우 기본적인 기능만이
      서버 핵심에 포함되있음을 뜻한다. 아파치는 <a
      href="mod/">모듈</a>을 읽어들여서 기능을
      확장한다. 기본적으로 컴파일하면 서버에 <a
      href="mod/module-dict.html#Status">base</a> 모듈들이 포함된다.
      서버를 <a href="dso.html">동적으로 읽어들이는</a> 모듈을
      사용할 수 있게 컴파일하였다면 모듈을 따로 컴파일하여 아무때나
      <directive module="mod_so">LoadModule</directive> 지시어로
      추가할 수 있다. 그렇지 않으면 모듈을 추가하거나 빼기위해
      아파치를 다시 컴파일해야 한다. 설정 지시어를 <directive
      module="core">IfModule</directive> 블록으로 감싸서 특정
      모듈이 있는 경우에만 선택적으로 처리할 수 있다.</p>
  
      <p>현재 서버에 어떤 모듈이 컴파일되있는지 보려면 <code>-l</code>
      명령행 옵션을 사용한다.</p>
    </section>
  
    <section id="scope">
      <title>지시어 적용범위</title>
  
      <related>
        <directivelist>
          <directive module="core" type="section">Directory</directive>
          <directive module="core" type="section">DirectoryMatch</directive>
          <directive module="core" type="section">Files</directive>
          <directive module="core" type="section">FilesMatch</directive>
          <directive module="core" type="section">Location</directive>
          <directive module="core" type="section">LocationMatch</directive>
          <directive module="core" type="section">VirtualHost</directive>
        </directivelist>
      </related>
  
      <p>주설정파일에 있는 지시어는 서버 전체에 적용된다. 지시어가
      서버의 일부에만 적용되게 하려면 지시어를 <directive module="core"
      type="section">Directory</directive>, <directive module="core"
      type="section">DirectoryMatch</directive>, <directive module="core"
      type="section">Files</directive>, <directive module="core"
      type="section">FilesMatch</directive>, <directive module="core"
      type="section">Location</directive>, <directive module="core"
      type="section">LocationMatch</directive> 섹션 안에 두어야한다.
      이 섹션들은 그들이 감싸는 지시어의 적용범위를 파일시스템이나
      URL의 특정 위치로 한정한다. 또, 서로 겹쳐서 사용할 수 있기때문에
      매우 세밀한 설정이 가능하다.</p>
  
      <p>아파치는 여러 다른 웹사이트를 동시에 서비스하는
      능력이 있다. 이를 <a href="vhosts/">가상호스트</a>라고 한다.
      지시어를
      <directive module="core" type="section">VirtualHost</directive>
      섹션 안에 두어 특정 웹사이트에만 지시어를 적용할 수 있다.</p>
  
      <p>지시어는 대부분 어떤 섹션에 나와도 되지만, 어떤 지시어는
      특정 장소에서 의미가 없다. 예를 들어 프로세스 생성을 조절하는
      지시어는 주서버설정 장소에서만 사용할 수 있다. 지시어가
      어떤 섹션에 위치할 수 있는지 알려면 지시어의 <a
      href="mod/directive-dict.html#Context">사용장소</a>를 확인하라.
      더 자세한 정보는 <a href="sections.html">어떻게 Directory,
      Location, Files 섹션이 동작하나</a>를 참고하라.</p>
    </section>
  
    <section id="htaccess">
      <title>.htaccess 파일</title>
  
      <related>
        <directivelist>
          <directive module="core">AccessFileName</directive>
          <directive module="core">AllowOverride</directive>
        </directivelist>
      </related>
  
      <p>아파치는 특별한 파일을 사용하여 설정을
      나눠서(분권적으로) 관리할 수 있다. 이 특별한 파일을 보통
      <code>.htaccess</code>라고 부르지만, 이름은 <directive
      module="core">AccessFileName</directive> 지시어로
      지정할 수 있다. <code>.htaccess</code> 파일에 있는 지시어는
      파일이 있는 디렉토리와 모든 하위디렉토리에 적용된다.
      <code>.htaccess</code> 파일은 주설정파일과 같은 문법을
      따른다. <code>.htaccess</code> 파일은 매 요청때마다 읽기때문에
      파일을 수정하면 즉시 효과를 볼 수 있다.</p>
  
      <p>어떤 지시어를 <code>.htaccess</code> 파일에 사용할 수
      있는지 알려면 지시어의 <a
      href="mod/directive-dict.html#Context">사용장소</a>를
      확인하라. 서버 관리자는 주설정파일의 <directive
      module="core">AllowOverride</directive> 지시어로
      <code>.htaccess</code> 파일에 어떤 지시어를 사용할 수 있는지
      조절할 수 있다.</p>
  
      <p><code>.htaccess</code> 파일에 대한 더 자세한 정보는
      <a href="howto/htaccess.html">.htaccess 투토리얼</a>을
      참고하라.</p>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/content-negotiation.xml.ko
  
  Index: content-negotiation.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.7 -->
  <manualpage metafile="content-negotiation.xml.meta">
  
  <title>내용협상 (Content Negotiation)</title>
  
  <summary>
  
      <p>아파치는 HTTP/1.1 규약에 기술된 내용협상(content
      negotiation)을 지원한다. 내용협상은 media type, 언어, 문자집합,
      인코딩 등에 대해 브라우저가 제공한 선호도에 따라 자원의
      가장 적합한 표현을 선택한다. 또 불완전한 협상 정보를 보내는
      브라우저의 요청을 지능적으로 처리하는 기능도 있다.</p>
  
      <p>기본적으로 컴파일되는 <module>mod_negotiation</module>
      모듈이 내용협상 기능을 제공한다.</p>
  </summary>
  
  <section id="about"><title>내용협상에 대해</title>
  
      <p>자원은 여러 다른 표현을 가질 수 있다. 예를 들어, 다른
      언어나 다른 media type 혹은 둘 모두가 다른 표현들이 있을
      수 있다. 가장 적당한 표현을 선택하는 한가지 방법은 사용자에게
      목록 페이지를 보여주고 선택하게 하는 것이다. 그러나 서버가
      자동으로 선택하는 것도 가능하다. 이는 브라우저가 요청의
      일부로 그들이 선호하는 표현에 대한 정보를 보내기때문에
      가능하다. 예를 들어, 브라우저는 가능한한 불어로, 그러나
      없다면 영어로 정보를 보고싶다고 알려줄 수 있다. 브라우저는
      요청의 헤더로 그들의 기호를 나타낸다. 오직 불어로된 표현만을
      요청한다면 브라우저는 다음과 같이 보낸다.</p>
  
  <example>Accept-Language: fr</example>
  
      <p>이런 기호는 표현이 언어별로 다를 경우에만 고려된다.</p>
  
      <p>다음은 더 복잡한 요청의 예로 브라우저가 불어와 영어를
      받을 수 있지만, 불어를 더 선호하고, 여러 media type을 받을
      수 있지만, 일반 텍스트 보다는 HTML, 다른 media type 보다는
      GIF와 JPEG을 선호한다고 알려준다.</p>
  
  <example>
    Accept-Language: fr; q=1.0, en; q=0.5<br />
    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
  </example>
  
      <p>아파치는 HTTP/1.1 규약에 정의된 '서버 주도(server driven)'
      내용협상을 지원한다. 아파치는 Accept, Accept-Language,
      Accept-Charset, Accept-Encoding 요청 헤더를 모두 지원한다.
      또, 아파치는 RFC 2295와 RFC 2296에 정의된 실험적인 내용협상인
      '자연스러운(transparent)' 요청 헤더도 지원한다.</p>
  
      <p><strong>자원(resource)</strong>은 (RFC 2396) URI로 구별하는
      개념적인 존재다. 아파치와 같은 웹서버는 자원의
      <strong>표현(representations)</strong>을 제공한다. 표현은
      지정된 media type, 문자집합, 인코딩 등을 가진 바이트들로
      되있다. 자원은 여러 표현과 (때로는 없을 수도 있다) 연관된다.
      자원에 여러 표현이 있다면 자원을
      <strong>협상가능하다고(negotiable)</strong> 부르며, 이때
      각 표현을 <strong>변형(variant)</strong>이라고 한다.
      협상가능한 자원의 변형 종류를 협상의
      <strong>범위(dimension)</strong>라고 한다.</p>
  </section>
  
  <section id="negotiation"><title>아파치의 협상</title>
  
      <p>자원을 협상하기위해 서버는 각 변형에 대한 정보가 필요하다.
      다음 두가지 방법중 하나로 정보를 얻는다:</p>
  
      <ul>
        <li>변형을 담은 파일들을 직접 열거한 type map을 (<em>예를
        들어</em>, <code>*.var</code> 파일) 사용하거나,</li>
  
        <li>직접 지정하지않아도 서버가 파일명에서 규칙을 찾아서
        결과를 선택하는 'MultiViews'를 사용한다.</li>
      </ul>
  
     <section id="type-map"><title>type-map 파일 사용하기</title>
  
      <p>type map은 <code>type-map</code>이란 핸들러와 연결된
      (혹은 이전 아파치 설정과 호환을 위해 mime type이
      <code>application/x-type-map</code>인) 문서다. 이 기능을
      사용하려면 설정에서 <code>type-map</code> 핸들러에 대한
      파일 확장자를 지정해야 한다. 서버 설정파일에 다음과 같이
      설정하는 것이 좋다.</p>
  <example>AddHandler type-map .var</example>
  
      <p>Type map 파일은 해당하는 자원과 이름이 같아야 하고,
      각 변형에 대한 항목이 있어야 한다. 항목은 여러 HTTP형식
      헤더 줄로 구성된다. 변형에 대한 각각의 항목들은 빈줄로
      구분한다. 항목안에서 빈줄을 사용할 수 없다. (이렇게 할
      필요가 없고, 있어도 무시하지만) 여러 항목이 공통으로 가지고
      있는 내용으로 map 파일을 시작하는 것이 보통이다. 다음은
      map 파일 예다. 이 파일의 이름은 <code>foo.var</code>로,
      <code>foo</code>라는 자원을 설명한다.</p>
  
  <example>
    URI: foo<br />
  <br />
    URI: foo.en.html<br />
    Content-type: text/html<br />
    Content-language: en<br />
  <br />
    URI: foo.fr.de.html<br />
    Content-type: text/html;charset=iso-8859-2<br />
    Content-language: fr, de<br />
  </example>
      <p>typemap 파일이 파일명 확장자 보다, 심지어 Multiviews를
      사용하여도, 우선권을 가짐을 주의하라. 변형이 서로 다른 품질을
      가진다면, 다음과 같이 (jpeg, gif, ASCII-art에 해당하는)
      media type에 "qs" 파라미터로 품질(source quality)을 표시할
      수 있다:</p>
  
  <example>
    URI: foo<br />
  <br />
    URI: foo.jpeg<br />
    Content-type: image/jpeg; qs=0.8<br />
  <br />
    URI: foo.gif<br />
    Content-type: image/gif; qs=0.5<br />
  <br />
    URI: foo.txt<br />
    Content-type: text/plain; qs=0.01<br />
  </example>
  
      <p>qs 값은 0.000에서 1.000 사이다. qs 값이 0.000인 변형은
      절대 선택되지 않음을 주의하라. 'qs' 값이 없는 변형은 1.0으로
      취급된다. qs 값은 클라이언트의 능력과는 관계없이 다른 변형들과
      비교하여 그 변형의 상대적인 '품질'을 나타낸다. 예를 들어,
      사진을 나타내려는 경우 jpeg 파일이 ascii 파일보다는 항상
      높은 품질을 가진다. 그러나 자원이 원래 ascii art였다면
      ascii 표현이 jpeg 표현보다 더 높은 품질을 가질 수 있다.
      그러므로 어떤 변형의 qs 값은 표현하려는 자원의 성질에
      따라 다르다.</p>
  
      <p>지원하는 모든 헤더 목록은 <a
      href="mod/mod_negotiation.html#typemaps">mod_negotation
      typemap</a> 문서를 참고하라.</p>
  </section>
  
  <section id="multiviews"><title>Multiviews</title>
  
      <p><code>MultiViews</code>는 디렉토리별 옵션이므로,
      <code>httpd.conf</code>의
      <directive module="core" type="section">Directory</directive>,
      <directive module="core" type="section">Location</directive>,
      <directive module="core" type="section">Files</directive>
      섹션 혹은 (<directive module="core">AllowOverride</directive>가
      적절히 설정되었다면) <code>.htaccess</code> 파일의
      <directive module="core">Options</directive> 지시어에 설정할
      수 있다. <code>Options All</code>은 <code>MultiViews</code>를
      포함하지않음을 주의하라. 따로 직접 써줘야 한다.</p>
  
      <p><code>MultiViews</code>를 사용하면 다음과 같은 일이 일어난다:
      서버가 <code>/some/dir/foo</code>에 대한 요청을 받고
      <code>/some/dir/foo</code>에 <code>MultiViews</code>가 동작하며
      <code>/some/dir/foo</code>가 존재하지 <em>않을</em> 경우,
      서버는 디렉토리에서 이름이 foo.*인 파일들을 모든 포함하는
      가상의 type map을 만든다. 클라이언트가 요청한 media type과
      content-encoding을 가지고 이중에 가장 적합한 것을 선택한다.</p>
  
      <p><code>MultiViews</code>는 서버가 디렉토리를 참조할때
      파일을 찾는 <directive
      module="mod_dir">DirectoryIndex</directive> 지시어에도
      적용된다. 설정파일이 다음과 같다면,</p>
  <example>DirectoryIndex index</example>
      <p><code>index.html</code>과 <code>index.html3</code>이
      모두 있다면 서버는 이둘 중에 하나를 결정한다. 둘 모두 없고
      <code>index.cgi</code>가 있다면, 서버는 그것을 실행한다.</p>
  
      <p>디렉토리를 읽을때 파일중 하나가 Charset, Content-Type,
      Language, Encoding를 판단하는 <code>mod_mime</code>이 모르는
      확장자를 가진다면, 결과는 <directive
      module="mod_mime">MultiViewsMatch</directive> 지시어 설정에
      달렷다. 이 지시어는 핸들러, 필터, 다른 확장형들이 MultiViews
      협상에 참여할지 여부를 결정한다.</p>
  </section>
  </section>
  
  <section id="methods"><title>협상방법</title>
  
      <p>아파치가 type-map 파일이나 디렉토리에 있는 파일명들로
      주어진 자원에 대한 변형 목록을 얻게되면 '최적의' 변형을
      결정하기위해 두 방법중 하나를 사용한다. 아파치 내용협상
      기능을 사용하기위해 정확히 협상이 어떻게 일어나는지 자세히
      알 필요는 없다. 그러나 궁금한 사람을 위해 이 방법을 설명한다.</p>
  
      <p>두가지 협상방법이 있다:</p>
  
      <ol>
        <li><strong>아파치 알고리즘을 사용하여 서버가 주도하는
        협상</strong>은 일반적인 경우에 사용한다. 아파치 알고리즘은
        아래서 자세히 설명한다. 이 알고리즘을 사용하면 아파치는
        더 나은 결과를 얻기위해 종종 특정 범위의
        품질계수(quality factor)를 '조작한다'. 아파치가 품질계수를
        조작하는 방법은 아래서 자세히 설명한다.</li>
  
        <li><strong>자연스러운(Transparent) 내용협상</strong>은
        브라우저가 RFC 2295에 정의된 방법으로 요청할 경우에만
        사용한다. 이 협상방법은 '최적의' 변형을 결정할 권한을
        브라우저에게 부여한다. 그래서 결과는 브라우저의 알고리즘에
        달렸다. 자연스러운 협상과정중에 브라우저는 아파치에게
        RFC 2296에 정의된 '원격 변형선택 알고리즘(remote variant
        selection algorithm)'을 요청할 수 있다.</li>
      </ol>
  
  <section id="dimensions"><title>협상의 범위</title>
  
      <table>
        <tr valign="top">
          <th>범위</th>
  
          <th>설명</th>
        </tr>
  
        <tr valign="top">
          <td>Media Type</td>
  
          <td>브라우저는 Accept 헤더로 선호를 나타낸다. 각 항목은
          품질계수를 가질 수 있다. 변형의 설명도 품질계수를 ("qs"
          파라미터) 가질 수 있다.</td>
        </tr>
  
        <tr valign="top">
          <td>Language</td>
  
          <td>브라우저는 Accept-Language 헤더로 선호를 나타낸다.
          각 항목은 품질계수를 가질 수 있다. 변형은 여러 언어를
          가질 (혹은 아무 언어도 없을) 수 있다.</td>
        </tr>
  
        <tr valign="top">
          <td>Encoding</td>
  
          <td>브라우저는 Accept-Encoding 헤더로 선호를 나타낸다.
          각 항목은 품질계수를 가질 수 있다.</td>
        </tr>
  
        <tr valign="top">
          <td>Charset</td>
  
          <td>브라우저는 Accept-Charset 헤더로 선호를 나타낸다.
          각 항목은 품질계수를 가질 수 있다. 변형은 media type의
          파라미터로 문자집합을 나타낼 수 있다.</td>
        </tr>
      </table>
  </section>
  
  <section id="algorithm"><title>아파치 협상 알고리즘</title>
  
      <p>아파치는 브라우저에게 보낼 '최적의' 변형을 (있다면)
      선택하기위해 아래 알고리즘을 사용한다. 이 알고리즘은 변경할
      수 없다. 다음와 같이 동작한다:</p>
  
      <ol>
        <li>먼저, 협상의 각 범위에 대해 해당하는 <em>Accept*</em>
        헤더를 검사하고, 각 변형에 품질값을 매긴다. 어떤 범위의
        <em>Accept*</em> 헤더가 받아들이지 않는 변형은 후보에서
        제외한다. 어떤 변형도 남지않으면 4 단계로 간다.</li>
  
        <li>
          후보에서 하나씩 제외하여 '최적의' 변형을 찾는다. 다음
          각 검사는 순서대로 일어난다. 각 검사에서 선택되지않은
          변형은 제외된다. 각 검사후 한 변형만 남으면 이를 최적의
          변형으로 선택하고 3 단계로 간다. 여러 변형이 남으면
          다음 검사를 진행한다.
  
          <ol>
            <li>Accept 헤더의 품질계수와 변형의 media type에 대한
            품질값을 곱하여 가장 높은 값을 가진 변형을 선택한다.</li>
  
            <li>가장 높은 언어(language) 품질계수를 가진 변형을
            선택한다.</li>
  
            <li>Accept-Language 헤더에 (있다면) 나온 언어의 순서
            혹은 <code>LanguagePriority</code> 지시어에 (있다면)
            나온 언어의 순서를 가지고 가장 적합한 언어를 가진
            변형을 선택한다.</li>
  
            <li>가장 높은 (text/html media type의 버전을 나타내는)
            'level' media 파라미터를 가진 변형을 선택한다.</li>
  
            <li>Accept-Charset 헤더를 가지고 가장 적합한 charset
            media 파라미터를 가진 변형을 찾는다. 헤더가 없다면
            ISO-8859-1 문자집합을 가장 선호한다. <code>text/*</code>
            media type을 가지지만 명시적으로 특정 문자집합과
            연결되지않은 변형은 ISO-8859-1로 가정한다.</li>
  
            <li>ISO-8859-1이 <em>아닌</em> charset media 파라미터를
            가진 변형들을 선택한다. 그런 변형이 없다면, 대신 모든
            변형을 선택한다.</li>
  
            <li>가장 적합한 인코딩을 가진 변형을 선택한다.
            user-agent에 적합한 인코딩을 가진 변형이 있다면 그
            변형만을 선택한다. 그렇지않고 인코딩된 변형과 인코딩안된
            변형이 같이 있다면 인코딩안됨 변형만을 선택한다. 변형이
            모두 인코딩되었거나 모두 인코딩안된 경우 모든 변형을
            선택한다.</li>
  
            <li>content length가 가장 적은 변형을 선택한다.</li>
  
            <li>남은 것중 첫번재 변형을 선택한다. 이는 type-map
            파일의 앞에 나왔거나, 디렉토리에서 변형을 읽은 경우
            파일명을 ASCII 코드 순서로 하여 앞에 나오는 것이다.</li>
          </ol>
        </li>
  
        <li>이제 알고리즘이 '최적의' 변형을 선택했다. 이것을 응답으로
        보낸다. HTTP 응답 헤더 Vary는 협상의 범위를 나타내게 된다.
        (브라우저와 캐쉬는 자원을 캐쉬할때 이 정보를 사용할 수
        있다.) 끝.</li>
  
        <li>이 단계에 도달했다면 (모두 브라우저가 받지못하기 때문에)
        어떤 변형도 선택이 안된 경우다. ("No acceptable
        representation"를 뜻하는) 상태 406과 내용으로 사용가능한
        변형의 목록을 담은 HTML 문서를 응답을 보낸다. 또, HTML
        Vary 헤더는 변형의 범위를 나타낸다.</li>
      </ol>
  </section>
  </section>
  
  <section id="better"><title>품질계수 조작하기</title>
  
      <p>아파치는 종종 위의 아파치 협상 알고리즘을 엄격히 지키지않고
      품질계수를 변경한다. 이유는 완전하고 정확한 정보를 보내지않는
      브라우저에게 (알고리즘의) 더 나은 결과를 보내기 위해서다.
      널리 쓰이는 브라우저중 일부는 자주 잘못된 변형을 선택하도록
      Accept 헤더를 보낸다. 브라우저가 완전하고 올바른 정보를
      보낸다면, 조작을 하지않는다.</p>
  
  <section id="wildcards"><title>Media Type과 와일드카드</title>
  
      <p>Accept: 요청 헤더는 media type에 대한 선호를 나타낸다.
      또, *는 어떤 문자열이라도 가능하기때문에 "image/*"나 "*/*"
      같이 '와일드카드' media type을 사용할 수도 있다. 그래서
      다음과 같은 요청은:</p>
  
  <example>Accept: image/*, */*</example>
  
      <p>"image/"로 시작하는 어떤 type과 다른 어떤 type도 가능함을
      의미한다. 어떤 브라우저는
      자신이 실제로 다룰 수 있는 type에 추가로 와일드카드를 보낸다.
      예를 들면:</p>
  
  <example>
    Accept: text/html, text/plain, image/gif, image/jpeg, */*
  </example>
      <p>이유는 직접 열거한 type을 선호하지만 다른 표현이 있다면
      그것도 괜찮음을 나타내기 위해서다. 브라우저가 실제로 원한
  	것은 다음과 같이 명시적으로 품질값을 사용한 것이다.</p>
  <example>
    Accept: text/html, text/plain, image/gif, image/jpeg, */*; q=0.01
  </example>
      <p>직접 열거한 type은 품질계수가 없어서 기본값인 (가장 높은)
      1.0을 가진다. 와일드카드 */*는 낮은 선호도 0.01을 가지므로
      직접 열거한 type에 맞는 변형이 없는 경우에만 다른 type들이
      사용된다.</p>
  
      <p>Accept: 헤더에 q 계수가 전혀 <em>없고</em> "*/*"가 있다면,
      아파치는 바람직한 행동을 위해 q 값으로 0.01을 지정한다.
      또, "type/*" 형태의 와일드카드에는 ("*/*"보다는 더 선호하도록)
      0.02를 지정한다. Accept: 헤더에서 q 계수를 가지는 media type이
      있다면 이런 특별한 값을 추가하지 <em>않는다</em>. 그래서
      명시적인 정보를 보내는 브라우저의 요청은 요청한데로 처리한다.</p>
  </section>
  
  <section id="exceptions"><title>언어(language) 협상의 예외</title>
  
      <p>아파치 2.0은 언어 협상이 실패한 경우 부드럽게 복구하기위해
      협상 알고리즘에 새로 예외를 몇개 추가했다.</p>
  
      <p>클라이언트가 서버에 페이지를 요청했을때 서버가 브라우저가
      보낸 Accept-language에 맞는 페이지를 단 한개만 찾으면 문제가
      없지만, 그러지 않은 경우 서버는 클라이언트에게 "No Acceptable
      Variant"나 "Multiple Choices" 응답을 보낸다. 이런 오류문을
      피하기위해 이 경우 Accept-language를 무시하고 클라이언트의
      요청에 명확히 맞지는 않지만 문서를 보내도록 아파치를 설정할
      수 있다. <directive
      module="mod_negotiation">ForceLanguagePriority</directive>
      지시어는 서버가 이런 오류문중 하나 혹은 둘다를 무시하고
      <directive module="mod_negotiation">LanguagePriority</directive>
      지시어로 판단하도록 한다.</p>
  
      <p>또, 서버는 맞는 언어를 못찾은 경우 부모언어를 찾을 수도
      있다. 예를 들어 클라이언트가 영국영어를 뜻하는
      <code>en-GB</code> 언어로 문서를 요청한 경우, HTTP/1.1 표준에
      따르면 서버는 <code>en</code>으로만 표시된 문서를 일반적으로
      선택하지 못한다. (그래서 영국영어를 이해하는 독자가 일반적인
      영어도 이해할 수 있으므로 Accept-Language 헤더에
      <code>en-GB</code>만 포함하고 <code>en</code>을 포함하지않으면
      거의 확실히 잘못된 설정임을 유의하라. 불행히도 현재 많은
      클라이언트들은 이런 식으로 기본설정되있다.) 다른 언어를
      찾지 못하여 서버가 "No Acceptable Variants" 오류를 보내거나
      <directive module="mod_negotiation">LanguagePriority</directive>로
      돌아가야 한다면, 서버는 하위언어 규약을 무시하고
      <code>en-GB</code>를 <code>en</code> 문서에 대응한다.
      암묵적으로 아파치는 부모언어를 매우 낮은 품질값으로
      클라이언트의 허용언어 목록에 추가한다. 그러나 클라이언트가
      "en-GB; qs=0.9, fr; qs=0.8"을 요청하고 서버에 "en"과 "fr"
      문서가 있다면, "fr" 문서가 선택됨을 주의하라. 이는 HTTP/1.1
      표준을 지키고, 올바로 설정된 클라이언트와 효율적으로
      동작하기위함이다.</p>
  
      <p>사용자가 선호하는 언어를 알아내기위한 (쿠키나 특별한
  	URL-경로 같은) 고급 기법을 지원하기위해 아파치 2.1부터
  	<module>mod_negotiation</module>은 <code>prefer-language</code>라는
  	<a href="env.html">환경변수</a>를 인식한다. 이 환경변수가
  	존재하고 적절한 언어태그를 포함한다면,
  	<module>mod_negotiation</module>은 해당하는 변형을 선택하려고
  	시도한다. 그런 변형이 없다면 일반적인 협상과정을 시작한다.</p>
  
      <example><title>예제</title>
        SetEnvIf Cookie "language=(.+)" prefer-language=$1
      </example>
  </section>
  </section>
  
  <section id="extensions"><title>자연스러운(transparent) 내용협상의 확장</title> 
  
  <p>아파치는 다음과 같이 자연스러운 내용확장 프로토콜을 (RFC 2295)
  확장한다. 변형 목록의 새로운 <code>{encoding ..}</code>는 특정
  content-encoding을 가진 변형만을 지칭한다. RVSA/1.0 알고리즘은
  (RFC 2296) 목록에서 인코딩된 변형을 인식할 수 있고, 인코딩이
  Accept-Encoding 요청 헤더에 맞는 경우 인코딩된 변형들도 후보로
  사용하도록 확장되었다. RVSA/1.0 구현은 최적의 변형을 찾기 전에
  계산된 품질계수를 소수점 5자리에서 반올림하지 않는다.</p>
  </section>
  
  <section id="naming"><title>하이퍼링크와 이름규칙에 대하여</title>
  
      <p>언어(language) 협상을 사용한다면 파일은 여러 확장자를
      가지고 확장자의 순서는 보통 관계없으므로 파일명에 여러 다른
      이름규칙을 사용할 수 있다. (자세한 내용은 <a
      href="mod/mod_mime.html#multipleext">mod_mime</a> 문서를
      참고하라.)</p>
  
      <p>전형적인 파일은 MIME-type 확장자 (<em>예를 들어</em>,
      <code>html</code>), 경우에 따라 encoding 확장자 (<em>예를
      들어</em>, <code>gz</code>), 파일에 여러 언어 변형이 있는
      경우 물론 언어 확장자를 (<em>예를 들어</em>, <code>en</code>)
      가진다.</p>
  
      <p>예제:</p>
  
      <ul>
        <li>foo.en.html</li>
  
        <li>foo.html.en</li>
  
        <li>foo.en.html.gz</li>
      </ul>
  
      <p>다음은 몇몇 파일명과 그 파일에 대한 유효하고 유효하지않은
      하이퍼링크를 보인다:</p>
  
      <table border="1" cellpadding="8" cellspacing="0">
        <tr>
          <th>파일명</th>
  
          <th>유효한 하이퍼링크</th>
  
          <th>유효하지않은 하이퍼링크</th>
        </tr>
  
        <tr>
          <td><em>foo.html.en</em></td>
  
          <td>foo<br />
           foo.html</td>
  
          <td>-</td>
        </tr>
  
        <tr>
          <td><em>foo.en.html</em></td>
  
          <td>foo</td>
  
          <td>foo.html</td>
        </tr>
  
        <tr>
          <td><em>foo.html.en.gz</em></td>
  
          <td>foo<br />
           foo.html</td>
  
          <td>foo.gz<br />
           foo.html.gz</td>
        </tr>
  
        <tr>
          <td><em>foo.en.html.gz</em></td>
  
          <td>foo</td>
  
          <td>foo.html<br />
           foo.html.gz<br />
           foo.gz</td>
        </tr>
  
        <tr>
          <td><em>foo.gz.html.en</em></td>
  
          <td>foo<br />
           foo.gz<br />
           foo.gz.html</td>
  
          <td>foo.html</td>
        </tr>
  
        <tr>
          <td><em>foo.html.gz.en</em></td>
  
          <td>foo<br />
           foo.html<br />
           foo.html.gz</td>
  
          <td>foo.gz</td>
        </tr>
      </table>
  
      <p>위 표를 보면 하이퍼링크에 어떤 확장자도 없는 이름을
      (<em>예를 들어</em>, <code>foo</code>) 항상 사용할 수 있음을
      알 수 있다. 이 경우 장점은 문서의 실제 종류를 숨길 수 있어서,
      <em>예를 들어</em> 하이러링크 참조를 수정하않고
      <code>html</code> 파일을 <code>shtml</code>이나
      <code>cgi</code>로 변경할 수 있다는 점이다.</p>
  
      <p>계속 하이퍼링크에 MIME-type을 (<em>예를 들어</em>,
      <code>foo.html</code>) 사용하고 싶다면 (encoding 확장자가
      있다면 이것도 포함하여) 언어 확장자를 MIME-type 확장자보다
      오른쪽에 (<em>예를 들어</em>, <code>foo.html.en</code>)
      두어야한다.</p>
  </section>
  
  <section id="caching"><title>캐쉬에 대하여</title>
  
      <p>캐쉬가 표현을 저장하면 표현과 요청 URL을 연관시킨다.
      다음번 그 URL을 요청하면 캐쉬는 저장된 표현을 사용한다.
      그러나 서버와 협상이 가능한 자원인 경우 첫번째 요청한 변형만
      캐쉬되어 이후 요청은 캐쉬된 잘못된 응답을 얻을 수 있다.
      이를 막기위해 아파치는 보통 내용협상후 반환되는 모든 요청에
      HTTP/1.0 클라이언트가 캐쉬를 못하도록 표시를 한다. 또, 아파치는
      협상한 응답의 캐쉬를 허용하는 HTTP/1.1 프로토콜의 기능을
      지원한다.</p>
  
      <p><directive
      module="mod_negotiation">CacheNegotiatedDocs</directive>
      지시어는 HTTP/1.0 호환 클라이언트(브라우저 혹은 캐쉬)가
      보낸 요청에 대해 협상한 응답을 캐쉬할 수 있게 한다. 이 지시어는
      서버나 가상호스트 설정에 사용하며, 아규먼트를 받지않는다.
      이 지시어는 HTTP/1.1 클라이언트의 요청과는 관계가 없다.</p>
  </section>
  
  <section id="more"><title>다른 정보</title>
  
      <p>내용협상에 대한 다른 정보는 Alan J. Flavell가 쓴 <a
      href="http://ppewww.ph.gla.ac.uk/~flavell/www/lang-neg.html">Language
      Negotiation Notes</a>를 참고하라. 그러나 이 문서는 아직
      아파치 2.0의 변화를 반영하지 않을 수 있다.</p>
  </section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/custom-error.xml.ko
  
  Index: custom-error.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.4 -->
  
  <manualpage metafile="custom-error.xml.meta">
    
    <title>사용자정의 오류 응답</title>
    
    <summary>
      <p>웹마스터는 오류나 문제가 발생했을때 아파치의 응답을
      설정할 수 있다.</p>
      
      <p>서버가 오류나 문제를 발견했을때 보낼 사용자정의 응답을
      정의할 수 있다.</p>
      
      <p>스크립트가 죽은 경우 "500 Server Error" 응답 대신 사용자에게
      더 친근한 문구를 사용하거나 다른 (같은 사이트나 외부 사이트의)
      URL로 리다이렉션을 할 수 있다.</p>
    </summary>
    
    <section id="behavior">
      <title>행동</title>
      
      <section>
        <title>이전 행동</title>
        
        <p>NCSA httpd 1.3은 사용자에게 무의미하고 지루한 오류문을
        보냈다. 문제가 발생한 이유를 로그에 남길 수도 없었다.</p>
      </section>
      
      <section>
        <title>새로운 행동</title>
        
        <p>서버는 다음과 같은 일을 할 수 있다:</p>
        
        <ol>
          <li>NCSA의 고정된 문구 대신 다른 문구를 보여주거나</li>
        
          <li>같은 사이트의 URL로 리다이렉션하거나</li>
        
          <li>외부 사이트의 URL로 리다이렉션한다.</li>
        </ol>
        
        <p>다른 사이트의 URL로 리다이렉션하는 것이 유용할 수 있지만,
        이 경우 문제를 설명하거나 로그하는데 필요한 정보중 일부만
        전달된다.</p>
        
        <p>오류에 대한 정보를 전달하기위해 아파치는 CGI식의 새로운
        환경변수를 정의한다:</p>
        
        <example>
          REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, 
              image/jpeg<br />
          REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 
              9000/712)<br />
          REDIRECT_PATH=.:/bin:/usr/local/bin:/etc<br />
          REDIRECT_QUERY_STRING=<br />
          REDIRECT_REMOTE_ADDR=121.345.78.123<br />
          REDIRECT_REMOTE_HOST=ooh.ahhh.com<br />
          REDIRECT_SERVER_NAME=crash.bang.edu<br />
          REDIRECT_SERVER_PORT=80<br />
          REDIRECT_SERVER_SOFTWARE=Apache/0.8.15<br />
          REDIRECT_URL=/cgi-bin/buggy.pl
        </example>
        
        <p><code>REDIRECT_</code> 접두사에 주목하라.</p>
        
        <p>최소한 <code>REDIRECT_URL</code>과
        <code>REDIRECT_QUERY_STRING</code>은 (cgi-script나
        cgi-include일) 새 URL로 넘겨진다. 다른 변수는 오류가
        발생하기 이전에 <transnote>이름에서 <code>REDIRECT_</code>를
        뺀 환경변수가</transnote> 존재한 경우에만 있다.
        <directive module="core">ErrorDocument</directive>가
        <em>외부로</em> (같은 서버라도 <code>http:</code>와
        같은 스킴(scheme)으로 시작한다면) 리다이렉션한다면
        이중 어떤 것도 설정되지 <strong>않는다</strong>.</p>
      </section>
    </section>
    
    <section id="configuration">
      <title>설정</title>
      
      <p><directive module="core">AllowOverride</directive>가
      적절히 설정되었다면 .htaccess 파일에서
      <directive module="core">ErrorDocument</directive>를 사용할
      수 있다.</p>
      
      <p>다음은 예이다...</p>
      
      <example>
        ErrorDocument 500 /cgi-bin/crash-recover <br />
        ErrorDocument 500 "Sorry, our script crashed. Oh dear" <br />
        ErrorDocument 500 http://xxx/ <br />
        ErrorDocument 404 /Lame_excuses/not_found.html <br />
        ErrorDocument 401 /Subscription/how_to_subscribe.html
      </example>
      
      <p>문법은,</p>
      
      <example>
        ErrorDocument &lt;3-digit-code&gt; &lt;action&gt;
      </example>
      
      <p>가능한 action은,</p>
      
      <ol>
        <li>출력할 문구. 따옴표 (")를 문구 앞에 붙인다. 뒤에 나오는
        따옴표는 출력된다. <em>주의: 앞에 붙은 따옴표 (")는 출력되지
        않는다.</em></li>
      
        <li>리다이렉션할 외부 URL.</li>
      
        <li>리다이렉션할 내부 URL.</li>
      </ol>
    </section>
    
    <section id="custom">
      <title>사용자정의 오류 응답과 리다이렉션</title>
      
      <p>URL로 리다이렉션하는 아파치 행동은
      스크립트/server-include에 환경변수를 더 넘겨주도록 변경되었다.</p>
      
      <section>
        <title>이전 행동</title>
      
        <p>리다이렉션되는 스크립트에 표준 CGI 변수들이 넘어간다.
        어디에서 리다이렉션이 일어났는지 알 수 없다.</p>
      </section>
      
      <section>
        <title>새로운 행동</title>
      
        <p>리다이렉션된 스크립트는 새로운 환경변수들을 사용할
        수 있다. 모두 앞에 <code>REDIRECT_</code>가 붙어있다.
        <code>REDIRECT_</code> 환경변수는 원래 CGI 환경변수명
        앞에 <code>REDIRECT_</code>를 붙여서 만든다. <em>예를
        들어</em>, <code>HTTP_USER_AGENT</code>는
        <code>REDIRECT_HTTP_USER_AGENT</code>가 되었다. 이런 변수에
        추가로 스크립트가 원래 URL을 알도록 아파치는
        <code>REDIRECT_URL</code>과 <code>REDIRECT_STATUS</code>를
        정의한다. 원래 URL과 리다이렉션된 URL 모두 접근 로그에
        기록할 수 있다.</p>
      
        <p>ErrorDocument가 같은 서버에 있는 CGI 스크립트로
        리다이렉션한다면, 스크립트는 클라이언트에게 오류 상황을
        확실히 전달하기위해 출력에 "<code>Status:</code>" 헤더
        필드를 포함해야 한다. 예를 들어, Perl로 작성한 ErrorDocument
        스크립트는 다음과 같다:</p>
      
        <example>
          ... <br />
          print  "Content-type: text/html\n"; <br />
          printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; <br />
          ...
        </example>
      
        <p><code>404&nbsp;Not&nbsp;Found</code>와 같은 특정 오류
        상황에 대한 스크립트라면, 대신 <transnote>고정된</transnote>
        특정 상태코드와 오류문을 사용할 수 있다.</p>
  
        <p>(클라이언트에게 리다이렉션을 요청하기위해) 응답에
        <code>Location:</code> 헤더를 포함한다면, 스크립트는
        <em>반드시</em> (<code>302&nbsp;Found</code> 같은) 적절한
        <code>Status:</code> 헤더를 출력해야 함을 주의하라. 그렇지않으면
        <code>Location:</code> 헤더가 아무 소용없게 될 수 있다.</p>
      </section>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/dns-caveats.xml.ko
  
  	<<Binary file>>
  
  
  1.1                  httpd-2.0/docs/manual/dso.xml.ko
  
  Index: dso.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.5 -->
  
  <manualpage metafile="dso.xml.meta">
  
    <title>동적공유객체 (DSO) 지원</title>
  
    <summary>
      <p>아파치 웹서버는 관리자가 모듈들을 선택하여 서버에 포함할
      기능을 결정할 수 있는 모듈화된 프로그램이다. 서버를 컴파할때
      <code>httpd</code> 실행파일에 정적으로 모듈을 컴파일할
      수 있다. 아니면 모듈을 <code>httpd</code> 실행파일과
      분리하여 동적공유객체(Dynamic Shared Objects, DSO)로 컴파일할
      수 있다. DSO 모듈은 서버를 컴파일할때 컴파일하거나, Apache
      Extension Tool (<a href="programs/apxs.html">apxs</a>)을
      사용하여 나중에 컴파일하여 추가할 수 있다.</p>
  
      <p>이 문서는 DSO 모듈 사용법과 배경 이론을 설명한다.</p>
    </summary>
  
  
  <section id="implementation"><title>구현</title>
  
  <related>
  <modulelist>
  <module>mod_so</module>
  </modulelist>
  <directivelist>
  <directive module="mod_so">LoadModule</directive>
  </directivelist>
  </related>
  
      <p>아파치 핵심에 정적으로 컴파일해야할
      <module>mod_so.c</module>라는 모듈은 아파치 모듈을
      읽어들이기위한 DSO를 지원한다.
      이 모듈은 <module>core</module>를 제외하고 DSO가
      될 수 없는 유일한 모듈이다. 실제로 다른 모든 아파치 모듈은
      <a href="install.html">설치 문서</a>에서 설명한
      <code>configure</code>의 <code>--enable-<i>module</i>=shared</code>
      옵션을 사용하여 DSO로 컴파일할 수 있다. 모듈을
      <code>mod_foo.so</code>와 같이 DSO로 컴파일한후 <code>httpd.conf</code>
      파일에 <module>mod_so</module>의
      <directive module="mod_so">LoadModule</directive> 명령어를
      사용하여 서버 시작시 혹은 재시작시 그 모듈을 읽어들일 수
      있다.</p>
  
      <p>아파치 모듈(특히 제삼자가 만든 모듈)로 사용할 DSO 파일을 쉽게
      만들기위해 <a href="programs/apxs.html">apxs</a> (<em>APache
      eXtenSion</em>)라는 새로운 지원 프로그램이 있다. 이 프로그램은
      아파치 소스 트리 <em>밖에서</em> DSO로 사용할 모듈을
      컴파일할때 사용한다. 개념은 쉽다. 아파치를 설치할때
      <code>configure</code>와 <code>make install</code>이
      아파치 C 헤더파일을 설치하고, DSO 파일을 컴파일하기위한
      플래폼 특유의 컴파일러 옵션과 링커 옵션을 <code>apxs</code>
      프로그램에 기록한다. 그래서 <code>apxs</code>를 사용하는 사용자는
      아파치 배포본 소스 트리없이, 또 DSO 지원을 위한 플래폼 특유의
      컴파일러 옵션와 링커 옵션에 신경을 쓰지않고 자신의 아파치
      모듈 소스를 컴파일할 수 있다.</p>
  </section>
  
  <section id="usage"><title>사용법 요약</title>
  
      <p>Apache 2.0의 DSO 기능에 대한 짧고 간략한 요약이다:</p>
  
      <ol>
        <li>
          <em>배포본에 있는</em> 아파치 모듈을 컴파일하고 설치하는
          경우. 예를 들어 <code>mod_foo.c</code>를 DSO
          <code>mod_foo.so</code>로:
  
  <example>
  $ ./configure --prefix=/path/to/install --enable-foo=shared<br />
  $ make install
  </example>
        </li>
  
        <li>
          <em>제삼자가 만든</em> 아파치 모듈을 컴파일하고 설치하는
          경우. 예를 들어 <code>mod_foo.c</code>를 DSO
          <code>mod_foo.so</code>로:
  
  <example>
  $ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared<br />
  $ make install
  </example>
        </li>
  
        <li>
          공유 모듈을 <em>나중에 사용하기위해</em> 아파치를 구성하는
          경우:
  
  <example>
  $ ./configure --enable-so<br />
  $ make install
  </example>
        </li>
  
        <li>
          <em>제삼자가 만든</em> 아파치 모듈을 컴파일하고 설치하는
          경우. <a href="programs/apxs.html">apxs</a>를 사용하여
          아파치 소스 트리 <em>밖에서</em> <code>mod_foo.c</code>를
          DSO <code>mod_foo.so</code>로:
  
  <example>
  $ cd /path/to/3rdparty<br />
  $ apxs -c mod_foo.c<br />
  $ apxs -i -a -n foo mod_foo.la
  </example>
        </li>
      </ol>
  
      <p>모든 경우 일단 공유 모듈이 컴파일되면, <code>httpd.conf</code>에
      <directive module="mod_so">LoadModule</directive> 지시어를
      사용하여 아파치가 그 모듈을 읽어들이게 만든다.</p>
  </section>
  
  <section id="background"><title>배경지식</title>
  
      <p>현대적인 유닉스류에는 <em>동적공유객체</em> (DSO)의
      동적 링킹/로딩(dynamic linking/loading)이라고 하여, 특별한
      형식의 실행코드 조각을 만들어 실행중인 실행프로그램의
      주소공간에 읽어들이는 멋진 기능이 있다.</p>
  
      <p>보통 두가지 방법으로 읽어들일 수 있다. 하나는 실행프로그램이
      시작할때 <code>ld.so</code>라는 시스템 프로그램이 자동으로
      읽어들이는 경우고, 다른 하나는 실행중인 프로그램이
      <code>dlopen()/dlsym()</code> 시스템호출로 유닉스 로더(loader)의
      시스템 인터페이스을 사용하여 직접 읽어들이는 경우다.</p>
  
      <p>첫번째 경우 DSO를 보통 <em>공유라이브러리(shared libraries)</em>
      혹은 <em>DSO 라이브러리</em>라고 부르며, 파일은
      <code>libfoo.so</code>나 <code>libfoo.so.1.2</code> 같은
      이름을 가진다. 이들은 시스템 디렉토리(보통 <code>/usr/lib</code>)에
      있고, 컴파일시 링커 명령어에 <code>-lfoo</code>를 주어
      실행파일과 연결한다. 이렇게 직접 써준 라이브러리는 실행파일에
      참조되여서, 프로그램이 시작할때 링커 옵션 <code>-R</code>로
      직접 지정한 경로, 환경변수 <code>LD_LIBRARY_PATH</code>로
      지정한 경로 혹은 <code>/usr/lib</code>에서 유닉스 로더가
      <code>libfoo.so</code>를 찾을 수 있다. 그러면 실행프로그램의
      (아직 못찾은(unresolved)) 심볼(symbol)을 DSO에서 찾게된다.</p>
  
      <p>DSO는 보통 실행프로그램의 심볼을 찾지않기 때문에 (DSO가
      재사용가능한 일반적인 코드 라이브러리이므로) 찾기는 여기서
      끝난다. 유닉스 로더가 심볼 찾기를 완전히 담당하므로 실행프로그램이
      직접 DSO에서 심볼을 찾을 필요가 없다. (사실 <code>ld.so</code>를
      부르는 코드는 정적이 아닌 모든 실행프로그램에 링크되는 실행시
      시작코드의 일부다.) 공통된 라이브러리 코드를 동적으로 읽어들이는
      장점은 명확하다. 라이브러리 코드가 모든 프로그램에 중복해서
      저장되는 대신 <code>libc.so</code>와 같은 시스템 라이브러리에
      한번만 저장되기 때문에 디스크 공간이 절약된다.</p>
  
      <p>두번째 경우 DSO를 보통 <em>공유객체(shared objects)</em>
      혹은 <em>DSO 파일</em>이라고 부르고, (규칙상 이름은
      <code>foo.so</code>이지만) 파일의 확장자는 자유롭다. 이
      파일들은 보통 프로그램 자체 디렉토리에 위치하고 실행프로그램에
      자동으로 연결되지 않는다. 대신 실행프로그램은 실행시
      <code>dlopen()</code>을 사용하여 DSO를 주소공간에
      직접 읽어들여야 한다. 이때 실행프로그램은 DSO에서 심볼을
      찾지 않는다. 대신 앞에서 본 유닉스 로더는 자동으로 실행파일과
      실행파일이 이미 읽어들인 DSO 라이브러리(특히 항상 존재하는
      <code>libc.so</code>의 모든 심볼)에서 DSO의 (아직 못찾은)
      심볼을 찾는다. 그래서 DSO는 마치 처음부터 실행프로그램에
      정적으로 링크된것과 같이 실행파일의 심볼을 알게된다.</p>
  
      <p>DSO의 API를 이용하기위해서 마지막으로 실행프로그램은
      <code>dlsym()</code>으로 DSO에서 특정 심볼을 찾아서, 앞으로
      사용하기위해 디스패치(dispatch) 표 <em>등</em>에 저장한다.
      다른 말로 실행프로그램은 사용할 모든 실볼을 직접 찾아야한다.
      이런 구조의 장점은 프로그램의 일부를 프로그램이
      필요할때까지 읽어들이지 않아도 (그래서 메모리를 낭비하지
      않게) 된다는 점이다. 기본 프로그램의 기능을 확장하기위해
      필요한 경우 이 부분을 동적으로 읽어들일 수 있다.</p>
  
      <p>이런 DSO 구조가 자연스럽게 보이지만, 최소한 어려운 점이
      한가지있다. 프로그램을 확장하기위해 DSO를 사용할때 DSO가
      실행프로그램의 심볼을 찾는 일이다. 왜? DSO가 실행프로그램의
      심볼을 "역으로 찾는 것"은 (라이브러리는 자신을 사용하는 프로그램에
      대해 모른다는) 라이브러리 설계에 반하며, 모든 플래폼에서
      지원되지않고 표준화되지도 않았기 때문이다. 실제로 실행파일의
      전역심볼(global symbol)은 보통 익스포트(export)되지 않기때문에
      DSO가 사용할 수 없다. DSO를 사용하여 실행중 프로그램을 확장하려면
      링커에게 모든 전역심볼을 익스포트하도록 강제하는 것이 주된
      해결책이다.</p>
  
      <p>공유라이브러리는 DSO 방식의 설계원칙대로 전형적이기때문에
      운영체제가 제공하는 거의 모든 종류의 라이브러리가 사용한다.
      반대로 많은 프로그램은 프로그램을 확장하기위해 공유객체를
      사용하지 않는다.</p>
  
      <p>1998년 실행중 실제로 기능을 확장하기위해 DSO 구조를 사용한
      소프트웨어 패키지는 (XS 구조와 DynaLoader 모듈을 사용한)
      Perl 5, Netscape Server <em>등</em>으로 드물었다. 아파치는
      이미 기능을 확장하기위해 모듈 개념을 사용했고 외부 모듈을
      아파치 핵심기능에 연결하기위해 내부적으로 디스패치목록을
      이용한 접근방법을 사용했기때문에 1.3 버전부터 이 대열에 합류했다.
      그래서 아파치는 실행중 모듈을 읽어들이는데 DSO를 사용하도록
      운명지워졌다.</p>
  </section>
  
  <section id="advantages"><title>장단점</title>
  
      <p>앞에서 말한 DSO를 사용하면 다음과 같은 장점이 있다:</p>
  
      <ul>
        <li>실제 서버 프로세스가 컴파일시 <code>configure</code>
        옵션대신 <code>httpd.conf</code>의 <directive
        module="mod_so">LoadModule</directive>을 사용하여 실행중에
        결합되므로 서버 패키지 실행이 더 유연하다. 예를 들어 한번의
        아파치 설치만으로 다른 서버(표준 버전과 SSL 버전, 최소화
        버전과 기능추가 버전 [mod_perl, PHP3] <em>등</em>)를 실행할
        수 있다.</li>
  
        <li>서버는 설치후에도 제삼자가 만든 모듈을 사용하여 쉽게
        확장할 수 있다. 최소한 기업의 패키지 제작자는 아파치 핵심
        패키지와 별도로 PHP3, mod_perl, mod_fastcgi <em>등</em>을
        추가 패키지로 만들 수 있어서 큰 이득이다.</li>
  
        <li>DSO와 <code>apxs</code>를 가지고 아파치 소스 트리 밖에서
        작업하고 <code>apxs -i</code>와 <code>apachectl restart</code>
        명령어만으로 현재 개발한 모듈의 새 버전을 실행중인 아파치
        서버에 반영할 수 있어서 더 쉽게 아파치 모듈을 개발할 수
        있다.</li>
      </ul>
  
      <p>DSO는 다음과 같은 단점이 있다:</p>
  
      <ul>
        <li>프로그램의 주소공간에 코드를 동적으로 읽어들이는 기능을
        지원하지않는 운영체제가 있기 때문에 모든 플래폼에서 DSO를
        사용할 수 없다.</li>
  
        <li>유닉스 로더가 심볼을 찾아야하기 때문에 서버 시작이
        약 20% 정도 늦어진다.</li>
  
        <li>서버는 위치독립코드(position independent code, PIC)
        때문에 절대주소지정(absolute addressing)보다 느린
        상대주소지정(relative addressing)의 복잡한 어셈블러 기법이
        필요하므로 어떤 플래폼에서 실행시 약 5% 정도 늦다.</li>
  
        <li>DSO 모듈을 다른 DSO기반 라이브러리(<code>ld -lfoo</code>)에
        링크할 수 없는 플래폼이 있기때문에 (예를 들어 ELF기반
        플래폼은 지원하지만 a.out기반 플래폼은 보통 이 기능을
        지원하지 않는다) 모든 종류의 모듈에 DSO를 사용할 수 없다.
        다른 말로 DSO 파일로 컴파일하는 모듈은 아파치 핵심과 아파치
        핵심이 사용하는 C 라이브러리(<code>libc</code>)와 다른
        동적/정적 라이브러리, 위치독립코드를 담고 있는 정적 라이브러리
        아카이브(<code>libfoo.a</code>)의 심볼만을 사용할 수 있다.
        다른 코드를 사용하려면 아파치 핵심이 그것을 참조하던지,
        <code>dlopen()</code>으로 직접 코드를 읽어들여야 한다.</li>
      </ul>
  
  </section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/env.xml.ko
  
  Index: env.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.13 -->
  
  <manualpage metafile="env.xml.meta">
  
    <title>아파치의 환경변수</title>
  
    <summary>
      <p>아파치 웹서버는 <em>환경변수(environment variable)</em>라는
      변수에 정보를 저장할 수 있다. 이 정보를 사용하여 로그나
      접근제어 등 여러 작업을 조절한다. 또, 환경변수는 CGI 스크립트와
      같은 외부 프로그램과 통신하는 수단이 된다. 이 문서는 환경변수를
      다루고 사용하는 다양한 방법들을 설명한다.</p>
          
      <p>이 변수들을 <em>환경변수</em>라고 부르지만, 운영체제에서
      말하는 환경변수와 다르다. 이 변수는 아파치 내부에 저장되고
      사용된다. 환경변수는 CGI 스크립트나 Server Side Include
      스크립트로 넘겨질때만 실제 운영체제 환경변수가 된다. 서버를
      실행하는 운영체제 환경을 수정하고 싶다면 운영체제 쉘에서
      환경을 수정해야 한다.</p>
    </summary>
  
    <section id="setting">
      <title>환경변수 설정하기</title>
      <related>
        <modulelist>
          <module>mod_env</module>
          <module>mod_rewrite</module>
          <module>mod_setenvif</module>
          <module>mod_unique_id</module>
        </modulelist>
        <directivelist>
          <directive module="mod_setenvif">BrowserMatch</directive>
          <directive module="mod_setenvif">BrowserMatchNoCase</directive>
          <directive module="mod_env">PassEnv</directive>
          <directive module="mod_rewrite">RewriteRule</directive>
          <directive module="mod_env">SetEnv</directive>
          <directive module="mod_setenvif">SetEnvIf</directive>
          <directive module="mod_setenvif">SetEnvIfNoCase</directive>
          <directive module="mod_env">UnsetEnv</directive>
        </directivelist>
      </related>
      
      <section id="basic-manipulation">
          <title>기본적인 환경설정</title>
      
          <p>아파치에서 환경변수를 설정하는 가장 기본적인 방법은
          무조건적인 <directive module="mod_env"
          >SetEnv</directive> 지시어를 사용하는 것이다. <directive
          module="mod_env">PassEnv</directive> 지시어를 사용하여
          서버를 시작한 쉘에서 환경변수를 가져올 수도 있다.</p>
      
      </section>
      <section id="conditional">
          <title>요청에 따른 조건부 설정</title>
      
          <p>더 유연하게, mod_setenvif가 제공하는 지시어는 요청마다
          요청의 특징에 따라 환경변수를 설정한다. 예를 들어, 특정
          브라우저로 (User-Agent) 요청하거나 특정 Referer (맞춤법이
          틀리지 않았다) 헤더가 있는 경우에만 변수를 설정할 수
          있다. 심지어 mod_rewrite에 있는 <directive
          module="mod_rewrite">RewriteRule</directive>의
          <code>[E=...]</code> 옵션을 사용하여 더 유연하게 환경변수를
          설정할 수도 있다.</p>
      
      </section>
      <section id="unique-identifiers">
          <title>유일한 식별자</title>
      
          <p>마지막으로 mod_unique_id는 각 요청에 대해 어떤 경우에도
          "모든" 요청중에 확실히 유일한(겹치지않은) 값으로
          <code>UNIQUE_ID</code> 환경변수를 설정한다.</p>
      
      </section>
      <section id="standard-cgi">
          <title>표준 CGI 변수</title>
      
          <p>CGI 스크립트와 SSI 문서는 아파치 설정에서 설정하였거나
          쉘에서 가져온 환경변수 외에 추가로 <a
          href="http://cgi-spec.golux.com/">CGI 규약</a>이 규정한
          요청에 대한 정보를 알려주는 환경변수들을 받는다.</p>
      
      </section>
      <section id="caveats">
          <title>주의할 점</title>
      
          <ul>
            <li>환경설정 지시어를 사용하여 표준 CGI 변수를 무시하거나
            수정할 수 없다.</li>
      
            <li><a href="suexec.html">suexec</a>가 CGI 스크립트를
            실행하는 경우, 시작하기전에 CGI 스크립트의 환경은
            <em>안전한</em> 변수들만 가지도록 청소된다.
            <em>안전한</em> 변수 목록은 컴파일시
            <code>suexec.c</code>에 정의된다.</li>
      
            <li>포팅을 위해 환경변수 이름에는 오직 문자, 숫자,
            밑줄문자만 사용하는 것이 좋다. 또, 첫번째 문자로
            숫자를 사용하지않는 것이 좋다. CGI 스크립트나 SSI
            페이지에 넘어갈때 이외의 문자는 밑줄로 대체된다.</li>
          </ul>
      </section>
    </section>
    <section id="using">
      <title>환경변수 사용하기</title>
      
      <related>
        <modulelist>
          <module>mod_authz_host</module>
          <module>mod_cgi</module>
          <module>mod_ext_filter</module>
          <module>mod_headers</module>
          <module>mod_include</module>
          <module>mod_log_config</module>
          <module>mod_rewrite</module>
        </modulelist>
        <directivelist>
          <directive module="mod_authz_host">Allow</directive>
          <directive module="mod_log_config">CustomLog</directive>
          <directive module="mod_authz_host">Deny</directive>
          <directive module="mod_ext_filter">ExtFilterDefine</directive>
          <directive module="mod_headers">Header</directive>
          <directive module="mod_log_config">LogFormat</directive>
          <directive module="mod_rewrite">RewriteCond</directive>
          <directive module="mod_rewrite">RewriteRule</directive>
        </directivelist>
      </related>
  
      <section id="cgi-scripts">
          <title>CGI 스크립트</title>
      
          <p>환경변수의 주된 용도중 하나는 CGI 스크립트와 정보를
          교환하는 것이다. 앞에서 설명했듯이 아파치 설정에서 설정한
          변수외에 요청에 대한 표준 정보를 가진 변수가 CGI 스크립트로
          넘어간다. 더 자세한 내용은 <a href="howto/cgi.html">CGI
          투토리얼</a>을 참고하라.</p>
      
      </section>
      <section id="ssi-pages">
          <title>SSI 페이지</title>
      
          <p>mod_include의 <code>INCLUDES</code> 필터가 처리하는
          서버파싱 (SSI) 문서는 <code>echo</code> 요소를 사용하여
          환경변수를 출력할 수 있고, 환경변수를 사용하여 요청의
          특징에 따라 흐름제어 요소로 페이지의 일부를 변경할 수
          있다. 아파치는 또 SSI 문서에게 위에서 설명한 표준 CGI
          환경변수를 제공한다. 더 자세한 내용은 <a
          href="howto/ssi.html">SSI 투토리얼</a>을 참고하라.</p>
      
      </section>
      <section id="access-control">
          <title>접근제어</title>
      
          <p><code>allow from env=</code>과 <code>deny from env=</code>
          지시어를 사용하여 환경변수 값에 따라 서버로의 접근을
          조절할 수 있다. <directive
          module="mod_setenvif">SetEnvIf</directive>와 같이 사용하면
          클라이언트의 특징에 따라 자유롭게 서버로의 접근을 제어할
          수 있다. 예를 들어, 특정 브라우저의 (User-Agent) 접근을
          거부할 수 있다.</p>
      
      </section>
      <section id="logging">
          <title>조건부 로그</title>
      
          <p><directive module="mod_log_config">LogFormat</directive>의
          <code>%e</code> 옵션을 사용하여 환경변수를 접근 로그에
          기록할 수 있다. 또, <directive
          module="mod_log_config">CustomLog</directive> 지시어의
          조건부 형식을 사용하면 환경변수의 상황에 따라 요청을
          로그할지 여부를 결정할 수 있다. <directive
          module="mod_setenvif">SetEnvIf</directive>와 같이 사용하여
          어떤 요청을 로그할지 자유롭게 결정할 수 있다. 예를 들어,
          파일명이 <code>gif</code>로 끝나는 요청은 로그하지 않거나,
          외부 네트웍에 있는 클라이언트의 요청만을 로그할 수 있다.</p>
  
      </section>
      <section id="response-headers">
          <title>조건부 응답 헤더</title>
      
          <p><directive module="mod_headers">Header</directive>
          지시어는 클라이언트에게 응답을 보낼때 환경변수의 유무에
          따라 어떤 HTTP 헤더를 포함할지 결정할 수 있다. 예를
          들어, 클라이언트의 요청에 특정 헤더가 있는 경우에만
          어떤 응답 헤더를 보낼 수 있다.</p>
      
      </section>
  
      <section id="external-filter">
          <title>외부 필터 실행하기</title>
  
          <p><module>mod_ext_filter</module>의 <directive
          module="mod_ext_filter">ExtFilterDefine</directive>
          지시어로 설정한 외부 필터를 <code>disableenv=</code>와
          <code>enableenv=</code> 옵션을 사용하여 환경변수에 따라
          선택적으로 실행할 수 있다.</p>
      </section>
  
      <section id="url-rewriting">
          <title>URL 재작성(Rewriting)</title>
      
          <p><directive module="mod_rewrite">RewriteCond</directive>의
          <em>TestString</em>에 <code>%{ENV:...}</code> 형식을
          사용하면 mod_rewrite의 재작성 엔진이 환경변수에 따라
          다르게 행동한다. mod_rewrite에서 앞에 <code>ENV:</code>를
          붙이지않고 접근하는 변수는 실제 환경변수가 아님을 주의하라.
          그들은 다른 모듈에서 읽을 수 없는 mod_rewrite에 한정된
          변수다.</p>
      </section>
    </section>
      
    <section id="special">
      <title>특별한 목적의 환경변수</title>
      
          <p>클라이언트와 원활한 동작하기위해 아파치는 특별한
          클라이언트에 대해 자신의 행동을 수정한다. 보통 <directive
          module="mod_setenvif">BrowserMatch</directive>에서
          환경변수를 정의하여 이런 문제를 해결한다. 그러나 <directive
          module="mod_env">SetEnv</directive>와 <directive
          module="mod_env">PassEnv</directive>로도 가능하다.</p>
  
      <section id="downgrade">
          <title>downgrade-1.0</title>
  
          <p>요청이 이후 버전을 사용하더라도 HTTP/1.0 요청으로
          처리한다.</p>
  
      </section>
      <section id="force-no-vary">
          <title>force-no-vary</title>
      
          <p>응답을 클라이언트에게 보내기 전에 응답 헤더에서
          <code>Vary</code> 필드를 뺀다. 어떤 클라이언트는 이
          필드를 제대로 해석하지 못한다. 이 변수는 이런 문제를
          해결한다. 또한, 이 변수는
          <strong>force-response-1.0</strong>을 가정한다.</p>
      
      </section>
      <section id="force-response">
          <title>force-response-1.0</title>
      
          <p>HTTP/1.0 요청을 하는 클라이언트에게 HTTP/1.0 응답을
          강제한다. 원래 AOL 프록시에 문제가 있어서 만들어졌다.
          어떤 HTTP/1.0 클라이언트는 HTTP/1.1 응답을 받으면 제대로
          동작하지 않으므로, 이 문제를 해결하기위해 사용한다.</p>
      </section>
  
      <section id="gzip-only-text-html">
          <title>gzip-only-text/html</title>
  
        <p>값이 "1"이면 <code>text/html</code>이 아닌 content-type에
        대해 <module>mod_deflate</module>의 DEFALTE 출력필터를
        사용하지 않는다. (gzip 뿐만 아니라 "identity"가 아닌 모든
        인코딩의) 정적으로 압축한 파일의 경우에도
        <module>mod_negotiation</module>은 이 변수를 참고한다.</p>
      </section>
  
      <section id="no-gzip"><title>no-gzip</title>
      
          <p>이 옵션을 설정하면 <module>mod_deflate</module>의
          <code>DEFLATE</code> 필터를 사용하지 않고,
          <module>mod_negotiation</module>은 인코딩된 자원을
          보내지 않는다.</p>
  
      </section>
  
      <section id="nokeepalive">
          <title>nokeepalive</title>
      
          <p><directive module="core">KeepAlive</directive>를
          무시한다.</p>
      
      </section>
  
      <section id="prefer-language"><title>prefer-language</title>
  
          <p>이 변수는 <module>mod_negotiation</module>의 행동에
          영향을 미친다. 변수가 (<code>en</code>, <code>ja</code>,
          <code>x-klingon</code> 등) 언어태그를 담고있다면,
          <module>mod_negotiation</module>는 그 언어로 된 변형을
          보내길 시도한다. 그런 변형이 없다면 일반적인 <a
          href="content-negotiation.html">협상</a> 과정을 시작한다.</p>
  
      </section>
  
      <section id="redirect-carefully">
          <title>redirect-carefully</title>
      
          <p>서버가 더 조심히 클라이언트에게 리다이렉션을 보낸다.
          보통 리다이렉션을 처리하는데 문제가 있는 클라이언트을
          위해 사용한다. 원래 Microsoft의 WebFolders 소프트웨어가
          DAV 메써드를 통해 디렉토리 자원의 리다이렉션을 처리하는데
          문제가 있어서 만들어졌다.</p>
      
      </section>
  
     <section id="suppress-error-charset">
         <title>suppress-error-charset</title>
  
      <p><em>2.0.40 이후 버전에 있다</em></p>
  
      <p>아파치가 클라이언트의 요청에 대한 응답으로 리다이렉션을
      보낼때 클라이언트가 자동으로 리다이렉션을 따라가지 못하는(혹은
      않는) 경우에 대비하여 응답에 사용자에게 보여줄 문구를 포함한다.
      아파치는 보통 이 글을 아파치가 사용하는 문자집합인 ISO-8859-1로
      표시한다.</p>
      <p>그러나 리다이렉션된 페이지가 다른 문자집합을 사용할 경우
      어떤 이상한 브라우저 버전은 실제 페이지가 아니라 리다이렉션
      페이지의 문자집합을 사용하려고 한다. 예를 들어, 그리스어가
      이상하게 보일 수 있다.</p>
      <p>이 환경변수는 아파치가 리다이렉션 페이지에 문자집합을
      설정하지않도록 하여, 이런 브라우저가 실제 페이지의 문자집합을
      올바로 사용하게 만든다.</p>
  
     </section>
  
    </section>
  
    <section id="examples">
      <title>예제</title>
      
      <section id="misbehaving">
          <title>잘못 동작하는 클라이언트들을 위해 프로토콜 행동
          변경하기</title>
      
          <p>클라이언트들의 이미 알려진 문제를 해결하기위해
          httpd.conf에 다음 내용을 포함하길 바란다.</p>
  <example><pre>
  #
  # 다음 지시어들은 일반적인 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</pre></example>
  
      </section>
      <section id="no-img-log">
          <title>접근 로그에 이미지에 대한 요청을 로그하지 않기</title>
  
          <p>이 예제는 이미지에 대한 요청을 접근 로그에 기록하지
          않는다. 특정 디렉토리에 대한 혹은 특정 호스트에서 온
          요청을 로그하지 않도록 쉽게 수정할 수 있다.</p>
      <example><pre>
  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</pre></example>
  
      </section>
      <section id="image-theft">
          <title>"이미지 도둑" 방지</title>
  
          <p>이 예는 현재 서버외의 사용자가 페이지에 서버에 있는
          이미지를 포함하지 못하도록 하는 방법을 설명한다. 이
          설정을 권장하지는 않으며, 제한된 경우에만 동작한다.
          우리는 모든 이미지가 /web/images 디렉토리 안에 있다고
          가정한다.</p>
      <example><pre>
  SetEnvIf Referer "^http://www.example.com/" local_referal
  # Referer 정보를 보내지 않는 브라우저를 허용한다
  SetEnvIf Referer "^$" local_referal
  &lt;Directory /web/images&gt;
     Order Deny,Allow
     Deny from all
     Allow from env=local_referal
  &lt;/Directory&gt;</pre></example>
      
          <p>이 기법에 대한 자세한 설명은 ApacheToday 투토리얼 "<a
          href="http://apachetoday.com/news_story.php3?ltsn=2000-06-14-002-01-PS">
      Keeping Your Images from Adorning Other Sites</a>"를 참고하라.</p>
      </section>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/filter.xml.ko
  
  Index: filter.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.6 -->
  
  <manualpage metafile="filter.xml.meta">
  
    <title>필터</title>
  
    <summary>
      <p>이 문서는 아파치에서 필터를 사용하는 방법을 설명한다.</p>
    </summary>
  
    <section id="filters">
      <title>필터</title>
      <related>
        <modulelist>
          <module>mod_deflate</module>
          <module>mod_ext_filter</module>
          <module>mod_include</module>
        </modulelist>
        <directivelist>
          <directive module="mod_mime">AddInputFilter</directive>
          <directive module="mod_mime">AddOutputFilter</directive>
          <directive module="mod_mime">RemoveInputFilter</directive>
          <directive module="mod_mime">RemoveOutputFilter</directive>
          <directive module="mod_ext_filter">ExtFilterDefine</directive>
          <directive module="mod_ext_filter">ExtFilterOptions</directive>
          <directive module="core">SetInputFilter</directive>
          <directive module="core">SetOutputFilter</directive>
        </directivelist>
      </related>
      
      <p><em>필터(filter)</em>는 서버가 보내거나 받는 자료에
      적용되는 작업이다. 클라이언트가 서버에게 보내는 자료는
      <em>입력필터(input filter)</em>가 처리하고, 서버가
      클라이언트에게 보내는 자료는 <em>출력필터(output filter)</em>가
      처리한다. 자료에 여러 필터를 사용할 수 있고, 직접 필터의
      순서를 지정할 수 있다.</p>
  
      <p>아파치는 이어받기(byte-range) 요청 등을 처리하기위해
      내부적으로 필터를 사용한다. 또, 설정 지시어를
      사용하여 선택가능한 필터를 제공하는 모듈도 있다.
      <directive module="core">SetInputFilter</directive>,
      <directive module="core">SetOutputFilter</directive>,
      <directive module="mod_mime">AddInputFilter</directive>,
      <directive module="mod_mime">AddOutputFilter</directive>,
      <directive module="mod_mime">RemoveInputFilter</directive>,
      <directive module="mod_mime">RemoveOutputFilter</directive>
      지시어로 자료를 처리하는 필터를 조절한다.</p>
  
      <p>현재 아파치 웹서버 배포본은 사용자가 선택할 수 있는 다음과
      같은 필터를 제공한다.</p>
  
      <dl>
        <dt>INCLUDES</dt>
        <dd><module>mod_include</module>가 처리하는 Server-Side Includes</dd>
        <dt>DEFLATE</dt>
        <dd><module>mod_deflate</module>를 사용하여 출력을
            클라이언트로 보내기 전에 압축
        </dd>
      </dl>
  
      <p>또, <module>mod_ext_filter</module> 모듈을 사용하여
      외부 프로그램을 필터로 사용할 수도 있다.</p>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/glossary.xml.ko
  
  Index: glossary.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.8 -->
  
  <manualpage metafile="glossary.xml.meta">
  
    <title>용어</title>
  
  <summary>
  <p>이 문서는 웹 서비스 일반에 대한, 특히 아파치와 관련된, 용어들을
  정의한다. 각 개념에 대한 자세한 정보는 링크를 참고하라.
  <transnote>현재 단어의 순서는 한글 순서가 아니라, 영문자
  순서입니다. 용어번역표는 <a
  href="http://www.whiterabbitpress.com/osp/apache/">여기</a>를
  참고하길 바랍니다.</transnote></p>
  </summary>
  
  <section id="definitions"><title>정의</title>
  
  <dl>
  <dt><a name="authentication">인증 (Authentication)</a></dt>
  <dd>서버, 클라이언트, 사용자 등 네트웍 실체에 대한
  확인.<br /> 참고: <a href="howto/auth.html">인증, 권한부여,
  접근제어</a></dd>
  
  <dt><a name="accesscontrol">접근제어 (Access Control)</a></dt>
  <dd>네트웍 영역에 대한 접근을 제한. 아파치에서는 보통 특정
  <em>URL</em>의 접근을 제한하기위해 사용한다.<br /> 참고: <a
  href="howto/auth.html">인증, 권한부여, 접근제어</a></dd>
  
  <dt><a name="algorithm">알고리즘 (Algorithm)</a></dt>
  <dd>유한한 단계를 거쳐 문제를 푸는 명확한 공식 혹은 규칙들.
  암호화를 위한 알고리즘을 보통 <dfn>암호기(Ciphers)</dfn>라고
  부른다.</dd>
  
  <dt><a name="apacheextensiontool">APache eXtension Tool</a>
  <a name="apxs">(apxs)</a></dt> <dd><a href="#module">모듈
  (module)</a> 소스를 동적공유객체 (<a href="#dso">DSO</a>)로
  컴파일하고 아파치 웹서버에 설치하는 작업을 돕는 perl
  스크립트.<br /> 참고: <a href="programs/apxs.html">Manpage:
  apxs</a></dd>
  
  <dt><a name="certificate">인증서 (Certificate)</a></dt>
  <dd>서버나 클라이언트와 같은 네트웍 실체를 인증하는 자료.
      인증서에는 소유자 (subject라고 함), 서명 <em>인증기관
      (Certificate Authority)</em> (issuer라고 함), 소유자의
      공개키, CA가 만든 서명 등에 대한 X.509 정보가 있다.
      네트웍 실체는 CA 인증서를 사용하여 서명을 검사한다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="certificationauthority">인증기관 (Certification
  Authority</a>, <a name="ca">CA)</a></dt> <dd>안전한 방법으로
  네트웍 실체에 대한 인증을 서명하는 신뢰하는 제삼자. 다른 네트웍
  실체들은 서명으로 CA가 인증서 소유자를 인증했는지 확인할 수
  있다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="certificatsigningrequest">인증 서명 요청 (Certificate
  Signing Request</a>, <a name="csr">CSR)</a></dt> <dd><em>인증기관
  (Certification Authority)</em>에 제출하여 CA <em>인증서
  (Certificate)</em>의 <em>개인키 (Private Key)</em>로 서명될
  아직 서명되지않은 인증서. CSR이 서명되면 실제 인증서가 된다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  
  <dt><a name="cipher">암호기 (Cipher)</a></dt> <dd>자료를
  암호화하는 알고리즘이나 시스템. 예를 들어, DES, IDEA, RC4 등이 있다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="ciphertext">암호문 (Ciphertext)</a></dt> <dd><a
  href="#plaintext">평문 (Plaintext)</a>을 <a href="#cipher">암호기
  (Cipher)</a>로 처리한 결과.<br /> 참고: <a href="ssl/">SSL/TLS
  암호화</a></dd>
  
  <dt><a name="commongatewayinterface">공통 게이트웨이 인터페이스
  (Common Gateway Interface</a>, <a name="cgi">CGI)</a></dt>
  <dd>외부 프로그램이 요청을 서비스할 수 있도록 만든 웹서버와 외부
  프로그램 사이의 인터페이스 표준. 인터페이스는 원래 <a
  href="http://hoohoo.ncsa.uiuc.edu/cgi/overview.html">NCSA</a>가
  정의했지만, <a href="http://cgi-spec.golux.com/">RFC
  프로젝트</a>이기도 하다.<br />
  참고: <a href="howto/cgi.html">CGI로 동적 내용 생성</a></dd>
  
  
  <dt><a name="configurationdirective">설정 지시어 (Configuration
  Directive)</a></dt>
  <dd>참고: <a href="#directive">지시어</a></dd>
  
  <dt><a name="configurationfile">설정파일 (Configuration File)</a></dt>
  <dd>아파치를 설정하는 <a href="#directive">지시어 (directive)</a>를
  적어둔 텍스트파일.<br />
  참고: <a href="configuring.html">설정파일</a></dd>
  
  <dt><a name="connect">CONNECT</a></dt> <dd>HTTP를 통해
  자료흐름을 프록시하는 HTTP <a href="#method">메써드 (method)</a>.
  SSL 프로토콜 등 다른 프로토콜을 감싸기위해 사용한다.</dd>
  
  <dt><a name="context">사용장소 (Context)</a></dt> <dd><a
  href="#configurationfile">설정파일 (configuration file)</a>에서
  특정 <a href="#directive">지시어 (directive)</a>를 사용할 수
  있는 장소.<br /> 참고: <a
  href="mod/directive-dict.html#Context">아파치 지시어를 설명하는데
  사용한 용어정의</a></dd>
  
  <dt><a name="digitalsignature">전자서명 (Digital Signature)</a></dt>
  <dd>인증서나 다른 파일을 검사하는 암호화된 문자들. <em>인증기관
      (Certification Authority)</em>은 <em>인증서 (Certificate)</em>에
      포함된 <em>공개키 (Public Key)</em>를 해쉬한 결과를 자신의
      <em>개인키 (Private Key)</em>로 암호화하여 서명을 만든다.
      오직 CA의 공개키만이 서명을 풀 수 있기때문에, CA가 <em>인증서
      (Certificate)</em>를 가진 네트웍 실체를 인증했음을 증명할
      수 있다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="directive">지시어 (Directive)</a></dt> <dd>아파치의
  여러 기능을 조절하는 설정 명령어. 지시어는 <a
  href="#configurationfile">설정파일 (Configuration File)</a>에서
  사용한다.<br /> 참고: <a href="mod/directives.html">지시어 목록</a></dd>
  
  <dt><a name="dynamicsharedobject">동적공유객체 (Dynamic Shared
  Object)</a> <a name="dso">(DSO)</a></dt> <dd> 아파치 httpd
  실행파일과 별도로 컴파일하여 필요할때 읽어들일 수 있는 <a
  href="#module">모듈 (Module)</a>.<br />
  참고: <a href="dso.html">동적공유객체 지원</a></dd>
  
  <dt><a name="environmentvariable">환경변수 (Environment Variable)</a>
  <a name="env-variable">(env-variable)</a></dt>
  <dd>정보를 저장하고 프로그램간에 통신을 위해 운영체제 쉘이 관리하는
  변수. 아파치에도 환경변수라는 내부 변수가 있지만, 쉘 환경이
  아니라 아파치 내부에 저장된다.<br />
  참고: <a href="env.html">아파치의 환경변수</a></dd>
  
  <dt><a name="export-crippled">수출용 (Export-Crippled)</a></dt>
  <dd>미국 수출관리규제(Export Administration Regulations, EAR)를
      준수하기위해 암호(와 보안)의 강도를 낮춤. 수출용 암호화
      소프트웨어는 키 크기가 작게 제한되어, <em>암호문
      (Ciphertext)</em>을 무식한 방법(brute force)으로 풀 수 있다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화 (SSL/TLS Encryption)</a></dd>
  
  <dt><a name="filter">필터 (Filter)</a></dt> <dd>서버가 보내거나
  받는 자료를 처리하는 과정. 입력필터는 클라이언트가 서버로 보내는
  자료를 처리하고, 출력필터는 서버가 클라이언트에게 보낼 문서를
  처리한다. 예를 들어, <code>INCLUDES</code> 출력필터는 문서의
  <a href="#ssi">Server Side Includes</a>를 처리한다. <br />
  참고: <a href="filter.html">필터</a></dd>
  
  <dt><a name="fully-qualifieddomain-name">완전한 도메인명
  (Fully-Qualified Domain-Name)</a> <a name="fqdn">(FQDN)</a></dt>
  <dd>IP 주소에 대응하는, 호스트명과 도메인명으로 구성된 네트웍
  실체의 유일한 이름. 예를 들어, <code>www</code>가 호스트명이고
  <code>example.com</code>이 도메인명일때,
  <code>www.example.com</code>은 완전한 도메인명이다.</dd>
  
  <dt><a name="handler">핸들러 (Handler)</a></dt> <dd>파일을
  요청할때 수행하는 작업에 대한 아파치 내부 표현. 일반적으로 파일은
  파일 종류에 따라 암묵적인 핸들러를 가진다. 보통 모든 파일은
  서버가 간단히 서비스하지만, 어떤 파일 종류는 따로
  "처리된다(handled)". 예를 들어, <code>cgi-script</code> 핸들러는
  <a href="#cgi">CGI</a>로 처리할 파일을 지정한다.<br />
  참고: <a href="handler.html">아파치에서 핸들러 사용</a></dd>
  
  <dt><a name="header">헤더 (Header)</a></dt>
  <dd><a href="#http">HTTP</a> 요청과 응답에서 실제 내용 이전에
  보내는 부분으로 내용을 설명하는 정보가 있다.</dd>
  
  <dt><a name=".htaccess">.htaccess</a></dt> <dd>웹문서들 안에 있는
  <a href="#configurationfile">설정파일 (configuration file)</a>로,
  설정 <a href="#directive">지시어 (directive)</a>를 자신이 위치한
  디렉토리와 모든 하위디렉토리에 적용한다. 이름과 달리 이
  파일에서는 단순한 접근제어 지시어외에 거의 모든 종류의 지시어를
  사용할 수 있다.<br />
  참고: <a href="configuring.html">설정파일</a></dd>
  
  <dt><a name="httpd.conf">httpd.conf</a></dt>
  <dd>아파치 주 <a href="#configurationfile">설정파일 (configuration
  file)</a>. 기본적인 위치는
  <code>/usr/local/apache2/conf/httpd.conf</code>이지만, 실행할때
  혹은 컴파일때 설정으로 변경할 수 있다.<br />
  참고: <a href="configuring.html">설정파일</a></dd>
  
  <dt><a name="hypertexttransferprotocol">HyperText Transfer
  Protocol</a> <a name="http">(HTTP)</a></dt> <dd>월드와이드웹에서
  사용하는 표준 전송 프로토콜. 아파치는
  <a href="http://ietf.org/rfc/rfc2616.txt">RFC 2616</a>에서
  정의한 HTTP/1.1이라는 프로토콜의 1.1 버전을 구현한다.</dd>
  
  <dt><a name="https">HTTPS</a></dt>
  <dd>월드화이드웹의 표준 암호통신 방법, HyperText Transport
      Protocol (Secure). 사실 밑단에 <a name="ssl">SSL</a>을
      사용한 HTTP이다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="method">메써드 (Method)</a></dt> <dd>클라이언트가
  보내는 <a href="#http">HTTP</a> 요청줄이
  자원에 수행하도록 지시한 행동. HTTP 메써드에는 <code>GET</code>,
  <code>POST</code>, <code>PUT</code> 등이 있다.</dd>
  
  <dt><a name="messagedigest">메시지 요약 (Message Digest)</a></dt>
  <dd>메시지 내용이 전송중 변경되지 않았음을 증명하기위한
      메시지의 해쉬.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="mime-type">MIME-type</a></dt> <dd>전송할 문서의
  종류를 설명하는 방식. Multipurpose Internet Mail Extensions
  형식을 빌려왔기때문에 이렇게 이름을 지었다. 슬래쉬를 사이에
  둔 major type과 minor type으로 이루어진다. 예를 들면,
  <code>text/html</code>, <code>image/gif</code>,
  <code>application/octet-stream</code> 등이다. MIME-type은 HTTP의
  <code>Content-Type</code> <a href="#header">헤더 (header)</a>로
  전송한다.<br /> 참고: <a href="mod/mod_mime.html">mod_mime</a></dd>
  
  <dt><a name="module">모듈 (Module)</a></dt> <dd>프로그램의 독립된
  부분. 많은 아파치 기능은 당신이 포함여부를 선택할 수 있는 모듈에
  들어있다. 아파치 httpd 실행파일과 같이 컴파일한 모듈을 <em>정적
  모듈</em>이라고 하며, 따로 분리되어 실행시 선택적으로 읽어들일
  수 있는 모듈을 <em>동적 모듈</em> 혹은 <a href="#dso">DSO</a>라고
  한다. 기본적으로 포함하는 모듈을 <em>base 모듈</em>이라고 한다.
  아파치 웹서버 <a href="#tarball">타볼 (tarball)</a>과 같이
  배포되지는 않지만 아파치에는 많은 모듈들이 있다. 이들을
  <em>제삼자가 만든(third-party) 모듈</em>이라고 한다.<br />
  참고: <a href="mod/">모듈 목록</a></dd>
  
  <dt><a name="modulemagicnumber">모듈 마법수 (Module Magic Number)</a>
  (<a name="mmn">MMN</a>)</dt>
  <dd>모듈 마법수는 아파치 소스코드가 정의한 상수로, 모듈의
  이진호환성과 관련이 있다. 모듈 마법수는 이진호환성을 더 이상 보장할
  수 없도록 아파치 내부 구조나 함수 호출, 다른 API 일부가 변경된
  경우에 바뀐다. MMN이 변하면 제삼자가 만든 모듈은 모두 최소한 다시
  컴파일되야 한다. 새 아파치 버전에 맞도록 조금 수정해야할 경우도
  있다.
  </dd>
  
  <dt><a name="openssl">OpenSSL</a></dt>
  <dd>SSL/TLS를 위한 오픈소스 도구<br />
      참고 <a href="http://www.openssl.org/">http://www.openssl.org/</a></dd>
  
  <dt><a name="passphrase">Pass Phrase</a></dt> <dd>개인키 파일을
  보호하는 문구. 인증하지않은 사용자가 이 개인키 파일을
  사용하여 암호화하지 못하도록 한다. 보통 <a name="cipher">암호기
  (Ciphers)</a>가 사용하는 비밀스런 암호/해독 키이다.<br /> 참고: <a
  href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="plaintext">평문 (Plaintext)</a></dt>
  <dd>암호화하지 않은 글.</dd>
  
  <dt><a name="privatekey">개인키 (Private Key)</a></dt> <dd>받은
  자료를 해독하고 보내는 자료를 서명하기위한 <a
  name="publickeycryptography">공개키 암호화 (Public Key
  Cryptography)</a> 시스템의 암호키.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="proxy">프록시 (Proxy)</a></dt> <dd>클라이언트와
  <em>실제 서버</em> 사이에 있는 중간 서버. 클라이언트에게 요청을
  받아 실제 서버로 보내고, 실제 서버에게서 받은 응답을 다시
  클라이언트에게 보낸다. 여러 클라이언트가 같은 내용을 요청하면
  프록시는 매번 서버에 요청하지않고 캐쉬에 저장된 내용을 사용하여
  응답시간을 줄일 수 있다.<br />
  참고: <a href="mod/mod_proxy.html">mod_proxy</a></dd>
  
  <dt><a name="publickey">공개키 (Public Key)</a></dt> <dd><a
  name="publickeycryptography">공개키 암호화 (Public Key
  Cryptography)</a> 시스템에서 키의 소유자에게 보내는 문구를 암호화하거나
  소유자가 만든 서명을 풀기위한 공개된 키.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="publickeycryptography">공개키 암호화 (Public Key
  Cryptography)</a></dt>
  <dd>암호와 해독에 서로 다른 키를 사용하는 비대칭(asymmetric)
  암호화 시스템의 연구 및 활용. 암호와 해독에 사용하는 두개의 키는
  키쌍(key pair)을 이룬다. 비대칭 암호화라고도 부른다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="regularexpresion">정규표현식 (Regular Expression)</a> <a
  name="regex">(Regex)</a></dt> <dd>글의 패턴을 기술하는 방식.
  예를 들어, "문자 A로 시작하는 모든 단어", "숫자 10개로된 전화번호",
  심지어 "쉼표가 두개있고 대문자 Q가 없는 문장" 등을 표현할 수 있다.
  정규표현식을 사용하면 매우 유연하게 파일이나 자원에 어떤 성질을 적용할
  수 있다. 예를 들어, "images"란 디렉토리 아래에 있는 모든 .gif와
  .jpg 파일은 "<code>/images/.*(jpg|gif)$</code>"로 지칭할 수
  있다. 아파치는 <a href="http://www.pcre.org/">PCRE</a> 라이브러리를
  사용하여 Perl호환 정규표현식을 지원한다.</dd>
  
  <dt><a name="reverseproxy">역프록시 (Reverse Proxy)</a></dt>
  <dd>클라이언트에게 <em>실제 서버</em>처럼 보이는 <a
  href="#proxy">프록시 (proxy)</a> 서버. 보안상 이유 혹은 부하를
  분산하기위해 클라이언트에게 실제 서버를 숨길때 유용하다.</dd>
  
  <dt><a name="securesocketslayer">Secure Sockets Layer</a> <a
  name="ssl">(SSL)</a></dt> <dd>Netscape Communications사가 TCP/IP
  네트웍의 일반적인 통신 인증과 암호화를 위해 만든 프로토콜.
  가장 일반적인 용도는 <em>HTTPS</em> (HyperText Transfer Protocol
  (HTTP) over SSL)이다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="serversideincludes">Server Side Includes</a> <a
  name="ssi">(SSI)</a></dt> <dd>HTML 파일 안에 처리지시어를 포함하는
  기술.<br /> 참고: <a
  href="howto/ssi.html">Server Side Includes 소개</a></dd>
  
  <dt><a name="session">세션 (Session)</a></dt>
  <dd>일반적으로 통신의 상황(context) 정보.</dd>
  
  <dt><a name="ssleay">SSLeay</a></dt>
  <dd>Eric A. Young이 개발한 원래 SSL/TLS 구현 라이브러리</dd>
  
  <dt><a name="symmetriccryptophraphy">대칭적 암호법 (Symmetric
  Cryptography)</a></dt>
  <dd>암호와 해독 작업에 같은 암호키를 사용하는 <em>암호기
      (Ciphers)</em>의 연구 및 활용.<br />
  참고: <a href="ssl/">SSL/TLS Encryption</a></dd>
  
  <dt><a name="tarball">타볼 (Tarball)</a></dt>
  <dd><code>tar</code> 도구를 사용하여 파일들을 모은 묶음. 아파치는
  tar 파일을 압축하거나 pkzip으로 압축하여 배포된다.</dd>
  
  <dt><a name="transportlayersecurity">Transport Layer Security</a> <a
  name="tls">(TLS)</a></dt> <dd>인터넷기술 관련 국제표준화기구(Internet
  Engineering Task Force, IETF)가 TCP/IP 네트웍의 일반적인 통신
  인증과 암호화를 위해 만든 SSL의 후속 프로토콜. TLS 버전 1은
  SSL 버전 3과 거의 유사하다.<br />
  참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  <dt><a name="uniformresourcelocator">Uniform Resource Locator</a>
  <a name="url">(URL)</a></dt> <dd>인터넷에 있는 자원의 이름/주소.
  정식으로는 <a href="#uniformresourceidentifier">Uniform Resource
  Identifier</a>라고 하는 것의 일상적인 비공식 용어다. 보통 URL은
  <code>http</code>나 <code>https</code>같은 스킴(scheme), 호스트명,
  경로로 구성된다. 이 페이지의 URL은
  <code>http://httpd.apache.org/docs-2.1/glossary.html</code>이다.</dd>
  
  <dt><a name="uniformresourceidentifier">Uniform Resource Identifier</a>
  <a name="URI">(URI)</a></dt> <dd>추상적인 자원이나 실제 자원을
  지칭하기위한 간결한 문자열. 공식적으로 <a
  href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>에서 정의한다.
  월드와이드웹에서 사용하는 URI를 보통 <a href="#url">URL</a>이라고
  부른다.</dd>
  
  <dt><a name="virtualhosting">가상호스트 (Virtual Hosting)</a></dt>
  <dd>아파치 하나로 여러 웹사이트를 서비스하기. <em>IP 가상호스트</em>는
  웹사이트마다 IP 주소가 다르다. <em>이름기반(name-based)
  가상호스트</em>는 호스트명만을 사용하므로 한 IP 주소에서 여러
  사이트를 서비스할 수 있다.<br />
  참고: <a href="vhosts/">아파치 가상호스트 문서</a></dd>
  
  <dt><a name="x.509">X.509</a></dt> <dd>국제전기통신연합(International
  Telecommunication Union, ITU-T)이 권장하는 인증서 양식. SSL/TLS
  인증에서 사용한다.<br /> 참고: <a href="ssl/">SSL/TLS 암호화</a></dd>
  
  </dl>
  </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/handler.xml.ko
  
  Index: handler.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.5 -->
  
  <manualpage metafile="handler.xml.meta">
  
    <title>아파치에서 핸들러 사용</title>
  
    <summary>
      <p>이 문서는 아파치에서 핸들러를 사용하는 방법을 설명한다.</p>
    </summary>
  
    <section id="definition">
      <title>핸들러가 무엇인가</title>
      <related>
        <modulelist>
          <module>mod_actions</module>
          <module>mod_asis</module>
          <module>mod_cgi</module>
          <module>mod_imap</module>
          <module>mod_info</module>
          <module>mod_mime</module>
          <module>mod_negotiation</module>
          <module>mod_status</module>
       </modulelist>
        <directivelist>
          <directive module="mod_actions">Action</directive>
          <directive module="mod_mime">AddHandler</directive>
          <directive module="mod_mime">RemoveHandler</directive>
          <directive module="core">SetHandler</directive>
        </directivelist>
      </related>
      
  
      <p>파일을 요청할때 아파치가 내부적으로 수행할 작업을
      "핸들러(handler)"라고 한다. 일반적으로 파일은 파일 종류에
      따라 암묵적인 핸들러를 가지고 있다. 모든 파일은 보통 간단히
      서버가 서비스하지만, 어떤 파일 종류는 따로 "처리된다(handled)".</p>
  
      <p>Apache 1.1부터 핸들러를 명시적으로 사용할 수 있게 되었다.
      파일 종류와 관계없이 핸들러를 파일의 확장자나 위치에 따라
      지정할 수 있다. 이는 더 훌륭한 방법이고 파일을 종류와 핸들러
      둘 모두와 연계할 수 있기때문에 좋다. (<a
      href="mod/mod_mime.html#multipleext">여러 확장자를 가진 파일</a>도
      참고)</p>
  
      <p>핸들러는 서버나 모듈로 구현하여, <directive
      module="mod_actions">Action</directive> 지시어로 추가할
      수 있다. 표준 배포본에 있는 기본 핸들러는 다음과 같다:</p>
  
      <ul>
        <li><strong>default-handler</strong>: 정적인 내용을
        처리하기위해 기본적으로 사용하는 핸들러
        <code>default_handler()</code>를 사용하여 파일을 보낸다.
        (core)</li>
  
        <li><strong>send-as-is</strong>: HTTP 헤더가 있는 파일을
        그대로 보낸다. (<module>mod_asis</module>)</li>
  
        <li><strong>cgi-script</strong>: 파일을 CGI로 처리한다.
        (<module>mod_cgi</module>)</li>
  
        <li><strong>imap-file</strong>: imagemap 규칙 파일로
        처리한다. (<module>mod_imap</module>)</li>
  
        <li><strong>server-info</strong>: 서버의 설정 정보를
        알려준다. (<module>mod_info</module>)</li>
  
        <li><strong>server-status</strong>: 서버의 상태를 보고한다.
        (<module>mod_status</module>)</li>
  
        <li><strong>type-map</strong>: 내용협상에 사용할
        type map으로 처리한다.
        (<module>mod_negotiation</module>)</li>
      </ul>
    </section>
    <section id="examples">
      <title>예제</title>
  
      <section id="example1">
        <title>CGI 스크립트를 사용하여 정적인 내용 수정하기</title>
  
        <p>다음 지시어는 확장자가 <code>html</code>인 파일을
        요청할 경우 <code>footer.pl</code> CGI 스크립트를 띄운다.</p>
        
        <example>
          Action add-footer /cgi-bin/footer.pl<br/>
          AddHandler add-footer .html
        </example>
  
        <p>CGI 스크립트는
        (<code>PATH_TRANSLATED</code> 환경변수가 지칭하는) 원래
        요청한 문서를 적절히 수정한 후 보낸다.</p>
   
      </section>
      <section id="example2">
        <title>HTTP 헤더를 포함하는 파일</title>
  
        <p>다음 지시어는 HTTP 헤더를 포함하는 파일에
        <code>send-as-is</code> 핸들러를 지시한다.
        <code>/web/htdocs/asis/</code> 디렉토리 안에 있는 모든
        파일은 확장자와 관계없이 <code>send-as-is</code> 핸들러가
        처리한다.</p>
  
        <example>
          &lt;Directory /web/htdocs/asis&gt;<br/>
          SetHandler send-as-is<br/>
          &lt;/Directory&gt;
        </example>
        
      </section>
    </section>
    <section id="programmer">
      <title>프로그래머를 위한 정보</title>
  
      <p>핸들러 기능을 구현하기위해 사용함직한
      <a href="developer/API.html">Apache API</a>가 추가되었다.
      특히 <code>request_rec</code> 구조체에 새로운 필드가
      추가되었다:</p>
  
      <example>
        char *handler
      </example>
  
      <p>모듈이 핸들러를 사용하려면, 요청의
      <code>invoke_handler</code> 단계 이전에
      <code>r-&gt;handler</code>에 핸들러 이름을 지정해주기만
      하면 된다. 핸들러는 content type 대신 핸들러 이름을 사용한
      것을 제외하고는 전과 같이 구현되었다. 꼭 지킬 필요는 없지만
      핸들러 이름에 슬래쉬를 사용하지 않고, 단어들 사이에 빼기
      기호를 사용하는 것이 일반적이다. 그래서 핸들러 이름이
      media type과 겹치지 않는다.</p>
    </section>
  </manualpage>
  
  
  
  
  
  
  
  
  1.1                  httpd-2.0/docs/manual/index.xml.ko
  
  Index: index.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE indexpage SYSTEM "./style/sitemap.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.4 -->
  
  <indexpage metafile="index.xml.meta">
  <parentdocument href="http://httpd.apache.org/docs-project/" />
  
  <title>Apache HTTP Server Version 2.1 문서</title>
  
  <category id="release"><title>발표문</title>
      <page href="new_features_2_0.html">버전 2.0의 새로운 기능</page>
      <page href="upgrading.html">1.3에서 2.0 버전으로 업그레이드</page>
      <page href="license.html">아파치 라이선스</page>
  </category>
  
  <category id="manual"><title>참조 설명서</title>
      <page href="install.html">컴파일과 설치</page>
      <page href="invoking.html">시작</page>
      <page href="stopping.html">중단과 재시작</page>
      <page href="mod/directives.html">설정 지시어</page>
      <page href="mod/quickreference.html">지시어 빠른참조</page>
      <page href="mod/">모듈</page>
      <page href="mpm.html">다중처리모듈 (MPM)</page>
      <page href="filter.html">필터</page>
      <page href="handler.html">핸들러</page>
      <page href="programs/">서버와 지원 프로그램</page>
      <page href="glossary.html">용어</page>
  </category>    
  
  <category id="usersguide"><title>사용자 지침서</title>
      <page href="bind.html">주소와 포트 지정</page>
      <page href="configuring.html">설정파일</page>
      <page href="sections.html">섹션 설정</page>
      <page href="content-negotiation.html">내용협상 (content negotiation)</page>
      <page href="dso.html">동적공유객체 (DSO)</page>
      <page href="env.html">환경변수</page>
      <page href="logs.html">로그파일</page>
      <page href="urlmapping.html">URL을 파일시스템에 대응</page>
      <page href="misc/perf-tuning.html">성능향상</page>
      <page href="misc/security_tips.html">보안 팁</page>
      <page href="server-wide.html">서버 전역 설정</page>
      <page href="ssl/">SSL/TLS 암호화</page>
      <page href="suexec.html">CGI의 Suexec 실행</page>
      <page href="misc/rewriteguide.html">URL 재작성(rewriting) 지침서</page>
      <page href="vhosts/">가상호스트</page>
  </category>
  
  <category id="howto"><title>How-To / 투토리얼</title>
      <page href="howto/auth.html">인증, 권한부여,
      접근제어</page>
      <page href="howto/cgi.html">CGI: 동적 내용 생성</page>
      <page href="howto/htaccess.html">.htaccess 파일</page>
      <page href="howto/ssi.html">Server Side Includes (SSI)</page>
      <page href="howto/public_html.html">사용자별 웹디렉토리
      (public_html)</page>
  </category>
  
  <category id="platform"><title>플래폼별 설명</title>
      <page href="platform/windows.html">Microsoft Windows</page>
      <page href="platform/netware.html">Novell NetWare</page>
      <page href="platform/ebcdic.html">EBCDIC 포팅</page>
  </category>
  
  <category id="other"><title>다른 주제</title>
      <page href="faq/">자주 물어보는 질문 (FAQ)</page>
      <page href="sitemap.html">사이트맵</page>
      <page href="developer/">개발자를 위한 문서</page>
      <page href="misc/">기타</page>
  </category>
  
  </indexpage>
  
  
  
  
  1.1                  httpd-2.0/docs/manual/install.xml.ko
  
  	<<Binary file>>
  
  
  1.1                  httpd-2.0/docs/manual/invoking.xml.ko
  
  Index: invoking.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.7 -->
  <manualpage metafile="invoking.xml.meta">
  
    <title>아파치 시작</title>
  
  <summary>
      <p>보통 아파치는 Windows NT, 2000, XP에서는 서비스로,
      Windows 95과 ME에서는 콘솔 프로그램으로 실행된다. 자세한
      내용은 <a href="platform/windows.html#winsvc">서비스로
      아파치를 실행하기</a>와 <a
      href="platform/windows.html#wincons">콘솔 프로그램으로
      아파치를 실행하기</a>.</p>
  
      <p>유닉스에서 <a href="programs/httpd.html">httpd</a>
      프로그램은 백그라운드에서 계속 요청을 처리하는 데몬으로
      실행된다. 이 문서는 <code>httpd</code>를 시작하는 방법을
      설명한다.</p>
  </summary>
  
  <seealso><a href="stopping.html">아파치 중단과 재시작</a></seealso>
  <seealso><a href="programs/httpd.html">httpd</a></seealso>
  <seealso><a href="programs/apachectl.html">apachectl</a></seealso>
  
  <section id="startup"><title>어떻게 아파치가 시작하나</title>
  
      <p>설정파일에서 <directive
      module="mpm_common">Listen</directive>이 기본값인 80(혹은
      1024이하의 다른 포트)이라면 이 특권 포트에 연결하기위해
      root 권한이 필요하다. 서버는 시작하여 로그파일을 여는 등의
      몇몇 기초적인 작업을 마친후, 클라이언트의 요청을 기다리고
      응답하는 <em>자식(child)</em> 프로세스를 여러개 띄운다.
      주 <code>httpd</code> 프로세스는 계속 root 사용자로 실행되지만,
      자식 프로세스들은 더 권한이 작은 사용자로 실행된다. 이는
      선택한 <a href="mpm.html">다중처리 모듈</a>로 조정한다.</p>
  
      <p><a href="programs/apachectl.html">apachectl</a>
      스크립트를 사용하여 <code>httpd</code> 실행파일을 시작하길
      권장한다. 이 스크립트는 <code>httpd</code>가 몇몇
      운영체제에서 정상적으로 동작하기위해 필요한 환경변수들을
      설정하고 <code>httpd</code> 실행파일을 시작한다.
      <code>apachectl</code>은 명령행 아규먼트를 그대로 넘기기때문에,
      <code>httpd</code>의 어떤 옵션이라도 <code>apachectl</code>에
      사용가능하다. 또, <code>apachectl</code> 스크립트의 앞부분에
      나오는 <code>HTTPD</code> 변수를 <code>httpd</code> 실행파일이
      있는 위치와 <em>항상</em> 사용할 명령행 아규먼트로 직접
      수정할 수 있다.</p>
  
      <p><code>httpd</code>를 실행하면 먼저 <a
      href="configuring.html">설정파일</a> <code>httpd.conf</code>를
      찾아서 읽는다. 이 파일의 위치는 컴파일 중에 지정하나, 실행시
      다음과 같이 <code>-f</code> 명령행 옵션으로 지정할 수도 있다.</p>
  
  <example>/usr/local/apache2/bin/apachectl -f
        /usr/local/apache/conf/httpd.conf</example>
  
      <p>시작하는 과정에서 문제가 없다면, 서버는 터미널에서
      떨어지고 명령 프롬프트가 거의 즉시 나오게된다. 이는 서버가
      실행됨을 의미한다. 브라우저로 서버에 연결하여 <directive
      module="core">DocumentRoot</directive> 디렉토리에 있는
      테스트 페이지와 그 페이지에 링크된 (로컬카피) 설명서를 볼
      수 있다.</p>
  </section>
  
  <section id="errors"><title>시작중 오류</title>
  
      <p>아파치가 시작하는 과정중에 심각한 문제가 발생하면,
      종료하기 전에 문제를 알리는 문구를 콘솔이나 <directive
      module="core">ErrorLog</directive>에 쓴다. 가장 흔한 오류문 중
      하나는 "<code>Unable to bind to Port ...</code>"이다.
      이 메세지는 보통 다음 두 경우에 발생한다:</p>
  
      <ul>
        <li>root 사용자로 로그인하지 않고 특권 포트에 서버를
        시작하려 한 경우. 혹은</li>
  
        <li>이미 아파치나 다른 웹서버가 사용중인 포트에
        서버를 시작하려 한 경우.</li>
      </ul>
  
      <p>기타 문제해결 방법은 아파치 <a href="faq/">FAQ</a>를
      참고하라.</p>
  </section>
  
  <section id="boot"><title>부팅할때 시작하기</title>
  
      <p>시스템이 재시작한 후에도 서버가 계속 실행되길 바란다면,
      시스템 시작파일(보통 <code>rc.local</code>이나 <code>rc.N</code>
      디렉토리에 있는 파일)에 <code>apachectl</code>을 추가해야
      한다. 이 경우 아파치는 root로 시작된다. 이전에 서버의 보안이나
      접근 제한(파일권한)이 올바로 설정되었는지 확인하라.</p>
  
      <p><code>apachectl</code>은 표준 SysV init 스크립트와 비슷하게
      동작하도록 만들어졌다. 스크립트는 아규먼트로 <code>start</code>,
      <code>restart</code>, <code>stop</code>을 받으면 각각 적절한
      시그널을 <code>httpd</code>에 보낸다. 그래서 보통은
      <code>apachectl</code>을 적절한 init 디렉토리로 링크를 걸면된다.
      그러나 사용하는 시스템의 정확한 요구사항을 확인하라.</p>
  </section>
  
  <section id="info"><title>추가 정보</title>
  
      <p><a href="programs/httpd.html">httpd</a>와 <a
      href="programs/apachectl.html">apachectl</a>, 기타 서버에
      포함된 지원 프로그램들의 명령행 옵션은
      <a href="programs/">서버와 지원 프로그램</a> 페이지를
      참고하라. 또 아파치 배포본에는 모든 <a href="mod/">모듈</a>과
      그들이 제공하는 <a href="mod/directives.html">지시어</a>에
      대한 문서가 있다.</p>
  </section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/logs.xml.ko
  
  	<<Binary file>>
  
  
  1.1                  httpd-2.0/docs/manual/mpm.xml.ko
  
  Index: mpm.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.4 -->
  <manualpage metafile="mpm.xml.meta">
  
    <title>다중처리 모듈 (MPM)</title>
  
  <summary>
  <p>이 문서는 다중처리 모듈 (Multi-Processing Module)이 무엇이며,
  아파치 웹서버가 이를 어떻게 사용하는지 설명한다.</p>
  </summary>
  
  <section id="introduction"><title>소개</title>
  
      <p>아파치 웹서버는 다양한 환경의 다양한 플래폼에서 동작할
      수 있도록 강력하고 유연하게 설계되었다. 다른 플래폼과 다른
      환경은 보통 다른 기능을 요구하며, 어떤 기능을 가장 효율적으로
      구현하는 방법이 다를 수 있다. 아파치는 모듈화된 설계로 이런
      다양한 환경에 항상 적응해왔다. 그래서 웹마스터는 컴파일시
      혹은 실행시 어떤 모듈을 읽어들일지 선택하여 서버에 포함할
      기능을 결정할 수 있다.</p>
  
      <p>Apache 2.0은 이런 모듈화된 설계를 웹서버의 가장 기본적인
      부분에까지 확장했다. 서버는 시스템의 네트웍 포트에 연결하고,
      요청을 받아들이며, 받아들인 요청을 처리하기위해 자식들에게
      분배하는 다중처리 모듈 (Multi-Processing Modules, MPMs)을
      선택할 수 있다.</p>
  
      <p>서버를 이 정도로 모듈화하면 두가지 중요한 장점이
      있다:</p>
  
      <ul>
        <li><module>mpm_winnt</module>가 Apache 1.3에서 사용한
        POSIX층 대신 자체 네트웍 기능을 사용할 수 있는 등,
        아파치는 여러 다양한 운영체제를 더 깔끔하고 효율적으로
        지원할 수 있다. 이 장점은 특화된 MPM을 구현한 다른
        운영체제에도 적용된다.</li>
  
        <li>서버는 특정 사이트의 요구조건에 더 특화될 수 있다.
        예를 들어 높은 확장가능성(scalability)이 필요한 사이트는
        <module>worker</module>와 같은 쓰레드 MPM을 사용하고,
        안정성과 오래된 소프트웨어와의 호환성이 필요한 사이트는
        <module>preforking MPM</module>을 사용할 수 있다.
        추가로 다른 사용자아이디로 여러 호스트를 서비스하는
        것(<module>perchild</module>)과 같은 특별한 기능도
        제공된다.</li>
      </ul>
  
      <p>사용자가 보기에 MPM은 다른 아파치 모듈과 거의 비슷해
      보인다. 주된 차이는 서버는 한번에 오직 한 MPM만을 사용해야
      한다는 점이다. 사용가능한 MPM 목록은 <a href="mod/">모듈
      목록 페이지</a>에 있다.</p>
  
  </section>
  
  <section id="choosing"><title>MPM 선택하기</title>
  
      <p>MPMs는 구성중에 선택하여 서버에 컴파일되야 한다.
      쓰레드를 사용하는 것을 컴파일러가 알면 많은 함수를
      최적화할 수 있다. 유닉스에서 몇몇 MPM은 쓰레드를 쓰고
      나머지는 아니므로, MPM이 구성중에 선택되어 아파치에
      컴파일될때 아파치는 더 빠른 속도를 낸다.</p>
  
      <p>원하는 MPM을 선택하려면 ./configure 스크립트에
      with-mpm= <em>NAME</em> 아규먼트를 사용하라. <em>NAME</em>은
      원하는 MPM 이름이다.</p>
  
      <p>서버를 컴파일한후 <code>./httpd -l</code> 명령어로 선택한
      MPM을 알 수 있다.  이 명령어는 MPM을 포함하여 서버에 컴파일된
      모든 모듈을 알려준다.</p>
  </section>
  
  <section id="defaults"><title>MPM 기본값</title>
  
  <p>다음 표는 여러 운영체제의 기본 MPM을 보여준다. 컴파일시
  다르게 선택하지 않으면 이 MPM이 선택된다.</p>
  
  <table>
  <tr><td>BeOS</td><td><module>beos</module></td></tr>
  <tr><td>Netware</td><td><module>mpm_netware</module></td></tr>
  <tr><td>OS/2</td><td><module>mpmt_os2</module></td></tr>
  <tr><td>유닉스</td><td><module>prefork</module></td></tr>
  <tr><td>윈도우즈</td><td><module>mpm_winnt</module></td></tr>
  </table>
  </section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/new_features_2_0.xml.ko
  
  Index: new_features_2_0.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.7 -->
  <manualpage metafile="new_features_2_0.xml.meta">
  
  <title>Apache 2.0의 새로운 기능 개요</title>
  
  <summary>
    <p>이 문서는 아파치 웹서버 1.3 버전과 2.0버전간의 주된 차이점을
       설명한다.</p>
  </summary>
  
  <seealso><a href="upgrading.html">1.3에서 2.0으로 업그레이드</a></seealso>
  
    <section id="core">
      <title>핵심 부분에서 나아진 점</title>
  
      <dl>
        <dt>유닉스 쓰레드</dt>
  
        <dd>POSIX 쓰레드를 지원하는 유닉스 시스템에서 아파치를
        여러 프로세스와 여러 쓰레드로 혼합해서 실행할 수 있다.
        전부는 아니지만 많은 경우 확장가능성(scalability)을 높인다.</dd>
  
        <dt>새로운 컴파일 시스템</dt>
  
        <dd>컴파일 시스템이 <code>autoconf</code>와 <code>libtool</code>을
        사용하도록 재작성되었다. 그래서 아파치 구성 시스템이 다른
        패키지들과 좀더 비슷해졌다.</dd>
  
        <dt>여러 프로토콜 지원</dt>
  
        <dd>이제 아파치는 여러 프로토콜을 서비스할 수 있는 구조를
        갖췄다. <module>mod_echo</module>가 그 예로 작성되었다.</dd>
  
        <dt>비유닉스 플래폼에 대한 더 나은 지원</dt>
  
        <dd>Apache 2.0는 BeOS, OS/2, 윈도우즈와 같은 비유닉스
        플래폼에서 더 빠르고 안정화되었다. 이제 아파치는 이들
        플래폼에서 버그가 많고 성능이 느렸던 POSIX 호환층 대신
        자체 API로 구현된 플래폼 특유의 <a href="mpm.html">다중처리 모듈</a>
        (MPM)과 Apache Portable Runtime (APR)을 사용하여 구현된다.</dd>
  
        <dt>새로운 아파치 API</dt>
  
        <dd>모듈 API가 2.0에서 상당히 변했다. 1.3의 여러 모듈
        순서와 우선순위 문제가 사라졌다. 2.0은 이를 대부분 자동으로
        처리하며, 모듈 순서는 이제 더 유연한 훅(hook) 단위로 지정한다.
        또, 아파치 서버 핵심 부분을 수정하지 않고 새로운 모듈 기능을
        제공하는 함수가 추가되었다.</dd>
  
        <dt>IPv6 지원</dt>
  
        <dd>하위 Apache Portable Runtine 라이브러리가 IPv6를 지원하는
        시스템에서 아파치는 기본적으로 IPv6 소켓을 기다린다. 또,
        <directive module="mpm_common">Listen</directive>,
        <directive module="core">NameVirtualHost</directive>,
        <directive module="core">VirtualHost</directive> 지시어가
        IPv6 숫자 주소를 지원한다. (예,
        "<code>Listen [fe80::1]:8080</code>").</dd>
  
        <dt>필터링</dt>
  
        <dd>이제 아파치 모듈을 서버로 오고가는 흐름에 대한
        필터로 사용할 수 있다. 예를 들어 <module>mod_include</module>의
        <code>INCLUDES</code> 필터를 사용하여 CGI 스크립트 출력에서
        Server Side Include 지시어를 처리할 수 있다.
        <module>mod_ext_filter</module> 모듈은 CGI 프로그램을
        핸들러로 사용하는 것과 같이 외부 프로그램을 필터로
        사용할 수 있게 한다.</dd>
  
        <dt>다국어 오류 응답</dt>
  
        <dd>브라우저로 보내는 오류 응답문이 이제 SSI 문서를
        사용하여 다국어로 제공된다. 관리자는 통일된 외관을 위해
        이 문서를 수정할 수 있다.</dd>
  
        <dt>간단해진 설정</dt>
  
        <dd>혼란을 주던 많은 지시어들이 간단해졌다. 자주 혼란을
        주던 <code>Port</code>와 <code>BindAddress</code> 지시어는
        없어지고 IP 주소 연결에
        <directive module="mpm_common">Listen</directive> 지시어만을
        사용한다. <directive module="core">ServerName</directive>
        지시어는 리다이렉션과 가상호스트 인식에만 사용될 서버명과
        포트를 지정한다.</dd>
  
        <dt>Windows NT 유니코드 자체 지원</dt>
  
        <dd>Windows NT에서 Apache 2.0은 이제 모든 파일명 인코딩에
        utf-8을 사용한다. 파일명은 하위 유니코드 파일시스템으로 직접
        변역되어, Windows 2000과 Windows XP를 포함한 모든 Windows NT기반
        시스템에 다국어 지원을 제공한다. <em>이 기능은 Windows 95,
        98, ME에는 지원되지않고, 파일시스템 접근에 전과 같이 시스템의
        지역 코드페이지를 사용한다.</em></dd>
  
        <dt>정규표현식 라이브러리 Updated</dt>
  
        <dd>Apache 2.0은 <a href="http://www.pcre.org/">Perl호환
        정규표현식 라이브러리 (Perl Compatible Regular Expression
        Library)</a> (PCRE)를 포함한다. 이제 모든 정규표현식에
        더 강력한 Perl 5 문법을 사용할 수 있다.</dd>
  
      </dl>
    </section>
  
    <section id="module">
      <title>모듈에서 나아진 점</title>
  
      <dl>
        <dt><module>mod_ssl</module></dt>
  
        <dd>Apache 2.0에서 새로 추가되었다. 이 모듈은 OpenSSL이
        제공하는 SSL/TLS 암호화 프로토콜의 인테페이스다.</dd>
  
        <dt><module>mod_dav</module></dt>
  
        <dd>Apache 2.0에서 새로 추가되었다. 이 모듈은 웹컨텐츠를
        올리고 관리하기위한 HTTP Distributed Authoring and Versioning
        (DAV) 표준을 구현한다.</dd>
  
        <dt><module>mod_deflate</module></dt>
  
        <dd>Apache 2.0에서 새로 추가되었다. 네트웍 사용량을
        줄이기위해 브라우저에게 컨텐츠를 압축해서 보내라고 요청할
        수 있다.</dd>
  
        <dt><module>mod_auth_ldap</module></dt>
  
        <dd>Apache 2.0.41에서 새로 추가되었다. 이 모듈은 HTTP
        Basic Authentication에 사용하는 정보를 LDAP 데이터베이스에
        저장한다. 관련된 <module>mod_ldap</module> 모듈은
        연결풀(connection pool)을 제공하고, 결과를 캐싱한다.</dd> 
  
        <dt><module>mod_auth_digest</module></dt>
  
        <dd>공유메모리를 사용하여 프로세스간 세션 캐싱을 지원한다.</dd>
  
        <dt><module>mod_charset_lite</module></dt>
  
        <dd>Apache 2.0에서 새로 추가되었다. 이 실험적인 모듈은
        문자집합 변환과 문자집합 재작성 기능을 제공한다.</dd>
  
        <dt><module>mod_file_cache</module></dt>
  
        <dd>Apache 2.0에서 새로 추가되었다. 이 모듈은 Apache 1.3의
        <code>mod_mmap_static</code> 기능에 더 나은 캐쉬 기능을
        추가했다.</dd>
  
        <dt><module>mod_headers</module></dt>
  
        <dd>이 모듈은 Apache 2.0에서 더 유연해졌다. 이제
        <module>mod_proxy</module>가 사용하는 요청 헤더를 수정할
        수 있고, 경우에 따라서 응답 헤더를 설정할 수도 있다.</dd>
  
        <dt><module>mod_proxy</module></dt>
  
        <dd>이 프록시 모듈은 새로운 필터 구조를 이용하고 더 믿을만한
        HTTP/1.1 프록시를 구현하기위해 완전히 재작성되었다. 추가로
        새로운 <directive module="mod_proxy" type="section">Proxy</directive>
        설정 섹션은 프록시 설정을 더 쉽게 (그리고 내부적으로 더
        빠르게) 만든다. 과거 <code>&lt;Directory "proxy:..."&gt;</code>
        설정은 이제 지원하지 않는다. 모듈은 <code>proxy_connect</code>,
        <code>proxy_ftp</code>, <code>proxy_http</code>와 같이
        지원하는 프로토콜 별로 나눠졌다.</dd>
  
        <dt><module>mod_negotiation</module></dt>
  
        <dd>새로운 <directive
        module="mod_negotiation">ForceLanguagePriority</directive>
        지시어는 클라이언트가 NOT ACCEPTABLE이나 MULTIPLE CHOICES
        응답 대신 모든 경우 한 문서를 받음을 보장한다. 추가로
        협상 알고리즘과 MultiViews 알고리즘이 더 일관된 결과를
        내도록 수정되었고, 문서 내용을 포함할 수 있는 새로운 형식의
        type map이 추가되었다.</dd>
  
        <dt><module>mod_autoindex</module></dt>
  
        <dd>자동으로 생성된 디렉토리 목록이 이제 더 깔끔한 형식을
        위해 HTML 표를 사용할 수 있게 되었고, 버전 정렬을 포함하여
        정렬순서를 자세히 조절할 수 있으며, 디렉토리 목록을 와일드카드로
        걸러낼 수 있다.</dd>
  
        <dt><module>mod_include</module></dt>
  
        <dd>새로운 지시어를 사용하여 SSI 요소의 기본 시작 태그와
        마침 태그를 변경할 수 있고, 오류와 시간형식을 SSI 문서외에
        주 설정파일에서도 설정할 수 있게 되었다. mod_include에서 (이제
        Perl 정규표현식 문법으로) 정규표현식 파싱과 그룹의
        결과를 <module>mod_include</module>의 <code>$0</code>
        ... <code>$9</code> 변수로 얻을 수 있다.</dd>
  
        <dt><module>mod_auth_dbm</module></dt>
  
        <dd>이제 <directive module="mod_auth_dbm">AuthDBMType</directive>
        지시어를 사용하여 여러 DBM류 데이터베이스를 지원한다.</dd>
  
      </dl>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/sections.xml.ko
  
  Index: sections.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.6 -->
  
  <manualpage metafile="sections.xml.meta">
  
  <title>섹션 설정</title>
  
  <summary> <p><a href="configuring.html">설정파일</a>에 있는
  지시어는 서버 전체에 적용되거나, 특정 디렉토리, 파일, 호스트,
  URL에만 적용될 수 있다. 이 문서는 다른 지시어의 적용범위를
  제한하기위해 설정 섹션이나 <code>.htaccess</code> 파일을
  사용하는 방법을 설명한다.</p>
  </summary>
  
  <section id="types"><title>설정 섹션의 종류</title>
  
  <related>
  <modulelist>
  <module>core</module>
  <module>mod_proxy</module>
  </modulelist>
  <directivelist>
  <directive type="section" module="core">Directory</directive>
  <directive type="section" module="core">DirectoryMatch</directive>
  <directive type="section" module="core">Files</directive>
  <directive type="section" module="core">FilesMatch</directive>
  <directive type="section" module="core">IfDefine</directive>
  <directive type="section" module="core">IfModule</directive>
  <directive type="section" module="core">Location</directive>
  <directive type="section" module="core">LocationMatch</directive>
  <directive type="section" module="mod_proxy">Proxy</directive>
  <directive type="section" module="mod_proxy">ProxyMatch</directive>
  <directive type="section" module="core">VirtualHost</directive>
  </directivelist>
  </related>
  
  <p>섹션에는 두가지 종류가 있다. 대부분은 매요청마다 처리된다.
  해당하는 요청에만 안에 포함한 지시어를 적용한다. 반대로, <directive
  type="section" module="core">IfDefine</directive>과 <directive
  type="section" module="core">IfModule</directive>은 서버가
  시작할때와 꺼질때만 처리한다. 시작할때 상태가 참이면 안에 있는
  지시어가 모든 요청에 적용된다. 참이 아니면 안에 있는 지시어는
  무시한다.</p>
  
  <p><directive type="section" module="core">IfDefine</directive>
  지시어는 <code>httpd</code> 명령행에 적절한 파라미터가 있는
  경우에만 안에 포함한 지시어를 적용한다. 다음 설정을 예로 들면,
  서버를 <code>httpd -DClosedForNow</code>로 시작할 경우에만
  모든 요청이 다른 사이트로 리다이렉션된다:</p>
  
  <example>
  &lt;IfDefine ClosedForNow&gt;<br />
  Redirect / http://otherserver.example.com/<br />
  &lt;/IfDefine&gt;
  </example>
  
  <p><directive type="section" module="core">IfModule</directive>
  지시어도 특정 모듈이 서버에 포함된 경우에만 안에 든 지시어를
  적용한다는 점을 제외하고는 매우 비슷하다. 모듈을 서버에 정적으로
  컴파일하거나 동적으로 컴파일한후 설정파일 앞에 <directive
  module="mod_so">LoadModule</directive> 줄이 있어야 한다. 이
  지시어는 특정 모듈의 설치유무에 따라 설정파일이 다를 필요가
  있을때만 사용해야 한다. 모듈이 없는 경우 유용한 오류문이 나오지않을
  수 있기 때문에 언제나 사용하길 원하는 지시어를 안에 두면 안된다.</p>
  
  <p>다음 예에서 <module>mod_mime_magic</module>이 있을때만 <directive
  module="mod_mime_magic">MimeMagicFiles</directive> 지시어를
  처리한다.</p>
  
  <example>
  &lt;IfModule mod_mime_magic.c&gt;<br />
  MimeMagicFile conf/magic<br />
  &lt;/IfModule&gt;
  </example>
  
  <p><directive type="section" module="core">IfDefine</directive>과
  <directive type="section" module="core">IfModule</directive>의
  검사 앞에 "!"을 붙여 조건을 역으로 할 수 있다. 또, 여러 섹션들을
  겹쳐서 사용하여 더 복잡한 효과를 얻을 수 있다.</p>
  </section>
  
  <section id="file-and-web"><title>파일시스템과 웹공간</title>
  
  <p>가장 자주 사용되는 설정 섹션은 파일시스템과 웹공간(webspace)의
  특정 장소에 대한 설정을 변경하는 것들이다. 먼저 이 둘의 차이를
  이해하는 것이 중요하다. 파일시스템은 운영체제 입장에서 디스크를
  보는 관점이다. 예를 들어, 기본값으로 아파치를 설치를 하면 유닉스
  파일시스템의 경우 <code>/usr/local/apache2</code>, 윈도우즈
  파일시스템의 경우 <code>"c:/Program Files/Apache
  Group/Apache2"</code>에 설치된다. (아파치는 윈도우즈에서 조차
  항상, 역슬래쉬가 아닌, 슬래쉬를 사용함을 주의하라.) 반대로
  웹공간은 웹서버가 제공하고 클라이언트가 보게될 사이트의 관점이다.
  그래서 유닉스에서 기본 아파치 설치를 한 경우 웹경로의 경로
  <code>/dir/</code>은 파일시스템 경로
  <code>/usr/local/apache2/htdocs/dir/</code>에 해당한다. 웹공간은
  데이타베이스 등에서 동적으로 생성될 수 있기때문에 반드시
  파일시스템에 직접 대응될 필요는 없다.</p>
  
  <section id="filesystem"><title>파일시스템 섹션</title>
  
  <p><directive type="section" module="core">Directory</directive>와
  <directive type="section" module="core">Files</directive> 지시어와
  정규표현식을 사용하는 지시어는 파일시스템의 특정 부분에 지시어를
  적용한다. <directive type="section"
  module="core">Directory</directive> 지시어에 포함된 지시어들은
  지정한 파일시스템 디렉토리와 그 하위 디렉토리에 적용된다. <a
  href="howto/htaccess.html">.htaccess 파일</a>을 사용해도 결과는
  같다. 다음 설정을 예로 들면, 디렉토리 목록(index)이
  <code>/var/web/dir1</code> 이하 디렉토리에서 디렉토리 목록(index)이
  가능하다.</p>
  
  <example>
  &lt;Directory /var/web/dir1&gt;<br />
  Options +Indexes<br />
  &lt;/Directory&gt;
  </example>
  
  <p><directive type="section"
  module="core">Files</directive> 섹션에 포함된 지시어들은 어떤
  디렉토리에 있는지 관계없이 지정한 이름을 가진 파일에 적용된다.
  설정파일의 주설정부분에 있는 다음 설정을 예로 들면, 장소와
  관계없이 <code>private.html</code>이란 이름을 한 파일의 접근을
  거부한다.</p>
  
  <example>
  &lt;Files private.html&gt;<br />
  Order allow,deny<br />
  Deny from all<br />
  &lt;/Files&gt;
  </example>
  
  <p>파일시스템의 특정 부분에 있는 파일을 지칭하기위해 <directive
  type="section" module="core">Files</directive>와 <directive
  type="section" module="core">Directory</directive> 섹션을 같이
  사용한다. 다음 설정을 예로 들면,
  <code>/var/web/dir1/private.html</code>,
  <code>/var/web/dir1/subdir2/private.html</code>,
  <code>/var/web/dir1/subdir3/private.html</code> 같이
  <code>/var/web/dir1/</code> 디렉토리 아래에 있는 이름이
  <code>private.html</code>인 파일의 접근을 거부한다.</p>
  
  <example>
  &lt;Directory /var/web/dir1&gt;<br />
  &lt;Files private.html&gt;<br />
  Order allow,deny<br />
  Deny from all<br />
  &lt;/Files&gt;<br />
  &lt;/Directory&gt;
  </example>
  </section>
  
  <section id="webspace"><title>웹공간 섹션</title>
  
  <p><directive type="section" module="core">Location</directive>
  지시어와 이에 해당하는 정규표현식을 사용하는 지시어는 반대로
  특정 웹공간의 설정을 바꾼다. 다음 설정을 예로 들면, /private으로
  시작하는 URL-경로의 접근이 거부된다. 여기에는
  <code>http://yoursite.example.com/private</code>,
  <code>http://yoursite.example.com/private123</code>,
  <code>http://yoursite.example.com/private/dir/file.html</code>
  같이 <code>/private</code> 문자열로 시작하는 요청이 해당된다.</p>
  
  <example>
  &lt;Location /private&gt;<br />
  Order Allow,Deny<br />
  Deny from all<br />
  &lt;/Location&gt;
  </example>
  
  <p><directive type="section" module="core">Location</directive>
  지시어는 파일시스템에 대응할 필요가 없다. 다음 예는 어떻게 특정
  URL을 <module>mod_status</module>가 제공하는 아파치 내부 핸들러로
  대응시키는지를 보여준다. 파일시스템에 <code>server-status</code>라는
  파일은 필요없다.</p>
  
  <example>
  &lt;Location /server-status&gt;<br />
  SetHandler server-status<br />
  &lt;/Location&gt;
  </example>
  </section>
  
  <section id="wildcards"><title>와일드카드와 정규표현식</title>
  
  <p><directive type="section" module="core">Directory</directive>,
  <directive type="section" module="core">Files</directive>,
  <directive type="section" module="core">Location</directive>
  지시어에서 C 표준 파이브러리의 <code>fnmatch</code>와 같은
  쉘에서 사용하는 와일드카드 문자를 사용할 수 있다.
  "*" 문자는 어떤 문자열이라도 나타내고, "?" 문자는 어떤 문자 한개를
  나타내며, "[<em>seq</em>]"는 <em>seq</em> 중에 한 문자를 나타낸다.
  어떤 와일드카드도 "/" 문자를 나타내지는 못한다. 그래서 이 문자는
  직접 사용해야 한다.</p>
  
  <p>더 유연한 설정이 필요하면 perl호환 <a
  href="glossary.html#regex">정규표현식</a>을 사용하는 <directive
  type="section" module="core">DirectoryMatch</directive>, <directive
  type="section" module="core">FilesMatch</directive>, <directive
  type="section" module="core">LocationMatch</directive>를 사용할
  수 있다. 그러나 아래 설정의 결합에 관한 절에서 정규표현식 섹션을
  사용하면 지시어가 적용되는 방법이 어떻게 변하는지 살펴봐라.</p>
  
  <p>모든 사용자 디렉토리 설정을 변경하는 비정규표현식 와일드카드
  섹션은 다음과 같다:</p>
  
  <example>
  &lt;Directory /home/*/public_html&gt;<br />
  Options Indexes<br />
  &lt;/Directory&gt;
  </example>
  
  <p>정규표현식 섹션을 사용하여 한번에 여러 종류의 그림파일에
  대한 접근을 거부할 수 있다:</p>
  <example>
  &lt;FilesMatch \.(?i:gif|jpe?g|png)$&gt;<br />
  Order allow,deny<br />
  Deny from all<br />
  &lt;/FilesMatch&gt;
  </example>
  
  </section>
  
  <section id="whichwhen"><title>무엇을 사용하나</title>
  
  <p>파일시스템 섹션과 웹공간 섹션 중 하나를 선택하는 것은 실제로
  매우 쉽다. 파일시스템에 있는 객체에 지시어를 적용할때는 항상
  <directive type="section" module="core">Directory</directive>나
  <directive type="section" module="core">Files</directive>를
  사용한다. (데이타베이스에서 생성한 웹페이지와 같이) 파일시스템에
  있지 않는 객체에 지시어를 적용할때는 <directive type="section"
  module="core">Location</directive>을 사용한다.</p>
  
  <p>파일시스템에 있는 객체의 접근을 제한하기위해 <directive
  type="section" module="core">Location</directive>을 사용하면
  절대 안된다. 여러 다른 웹공간 장소(URL)가 같은 파일시스템 장소에
  대응될 수 있으므로, 걸어둔 제한을 우회할 수 있기 때문이다. 다음
  설정의 예를 살펴보자:</p>
  
  <example>
  &lt;Location /dir/&gt;<br />
  Order allow,deny<br />
  Deny from all<br />
  &lt;/Location&gt;
  </example>
  
  <p>이 설정은 <code>http://yoursite.example.com/dir/</code>을
  요청한다면 잘 작동한다. 그러나 대소문자를 구별하지않는 파일시스템을
  사용한다면 어떻게되나?
  <code>http://yoursite.example.com/DIR/</code>을 요청하여 쉽게
  제한을 우회할 수 있다. 반대로 <directive type="section"
  module="core">Directory</directive> 지시어는 어떻게 요청하였는지
  관계없이 그 장소에서 서비스되는 내용에 적용된다. (예외는 파일시스템
  링크를 사용하는 경우다. 심볼링크를 사용하여 한 디렉토리를
  파일시스템의 여러 장소에 둘 수 있다. <directive type="section"
  module="core">Directory</directive> 지시어는 심볼링크를 따라간다.
  그러므로 높은 수준의 보안을 위해서는 적절한 <directive
  module="core">Options</directive> 지시어를 사용하여 심볼링크를
  무시해야 한다.)</p>
  
  <p>아마도 당신은 대소문자를 구별하는 파일시스템을 사용하므로
  이런 일이 일어나지 않는다고 생각할지도 모른다. 그러나 다른
  방법으로도 여러 웹공간 위치가 한 파일시스템 위치에 대응될 수
  있음을 기억하라. 그래서 가능하면 항상 파일시스템 섹션을 사용해야
  한다. 그러나 이 규칙에 예외가 하나 있다. 설정 제한을
  <code>&lt;Location /&gt;</code> 섹션에 두면 이 섹션이 특정
  URL이 아닌 모든 요청에 적용되므로 완벽하게 안전하다.</p>
  </section>
  
  </section>
  
  <section id="virtualhost"><title>가상호스트</title>
  
  <p><directive type="section" module="core">VirtualHost</directive>
  섹션은 특정 호스트에 적용되는 지시어들을 포함한다. 이는 한
  컴퓨터에서 각각 다른 설정을 사용한 여러 호스트를 서비스할때
  유용하다. 더 자세한 정보는 <a href="vhosts/">가상호스트 문서</a>를
  참고하라.</p>
  </section>
  
  <section id="proxy"><title>프록시</title>
  
  <p><directive type="section" module="mod_proxy">Proxy</directive>와
  <directive type="section" module="mod_proxy">ProxyMatch</directive>
  섹션은 지정한 URL에 대해 <module>mod_proxy</module> 프록시 서버를
  거쳐 접근하는 경우에만 적용된다. 다음 설정을 예로 들면, 프록시
  서버를 통해 <code>cnn.com</code> 웹사이트에 접근할 수 없다.</p>
  
  <example>
  &lt;Proxy http://cnn.com/*&gt;<br />
  Order allow,deny<br />
  Deny from all<br />
  &lt;/Proxy&gt;
  </example>
  </section>
  
  <section id="whatwhere"><title>안에 어떤 지시어를 사용할 수
  있나?</title>
  
  <p>어떤 설정 섹션안에 사용할 수 있는 지시어를 알려면 지시어의
  <a href="mod/directive-dict.html#Context">사용장소</a>를 확인하라.
  <directive type="section" module="core">Directory</directive>에서
  사용가능한 지시어는 <directive type="section"
  module="core">DirectoryMatch</directive>, <directive type="section"
  module="core">Files</directive>, <directive type="section"
  module="core">FilesMatch</directive>, <directive type="section"
  module="core">Location</directive>, <directive type="section"
  module="core">LocationMatch</directive>, <directive type="section"
  module="mod_proxy">Proxy</directive>, <directive type="section"
  module="mod_proxy">ProxyMatch</directive> 섹션에서도 사용가능하다.
  그러나, 예외가 있다.</p>
  
  <ul>
  <li><directive module="core">AllowOverride</directive> 지시어는
  <directive type="section" module="core">Directory</directive>
  섹션에서만 사용할 수 있다.</li>
  
  <li><code>FollowSymLinks</code>, <code>SymLinksIfOwnerMatch</code>,
  <directive module="core">Options</directive>는 <directive
  type="section" module="core">Directory</directive> 섹션이나
  <code>.htaccess</code> 파일에서만 사용할 수 있다.</li>
  
  <li><directive module="core">Options</directive> 지시어는
  <directive type="section" module="core">Files</directive>과
  <directive type="section" module="core">FilesMatch</directive>
  섹션에서 사용할 수 없다.</li>
  </ul>
  </section>
  
  <section id="mergin"><title>섹션들이 결합하는 방법</title>
  
  <p>설정 섹션은 매우 특별한 방법으로 적용된다. 이 순서가 설정
  지시어를 해석하는 방법에 중요한 영향을 주기때문에 이 방법을
  이해하는 것이 중요하다.</p>
  
      <p>결합하는 순서는:</p>
  
      <ol>
        <li> (정규표현식을 사용하지않는) <directive type="section"
        module="core">Directory</directive>와 .htaccess는 동시에
        일어난다 (경우에 따라 .htaccess이 <directive type="section"
        module="core">Directory</directive>를 무시하도록 설정할
        수 있다)</li>
  
        <li><directive type="section"
        module="core">DirectoryMatch</directive> (그리고
        <code>&lt;Directory ~&gt;</code>)</li>
  
        <li><directive type="section"
        module="core">Files</directive>와 <directive type="section"
        module="core">FilesMatch</directive>는 동시에 일어난다</li>
  
        <li><directive type="section"
        module="core">Location</directive>과 <directive type="section"
        module="core">LocationMatch</directive>는 동시에 일어난다</li>
      </ol>
  
      <p><directive type="section"
      module="core">Directory</directive>를 제외하고 각 섹션들을
      설정파일에 나온 순서대로 처리된다. (위의 순서 1) <directive
      type="section" module="core">Directory</directive>는 디렉토리
      내용이 가장 짧은 것에서 긴쪽으로 처리된다. 그래서 예를 들어,
      <code>&lt;Directory /var/web/dir&gt;</code>을
      <code>&lt;Directory /var/web/dir/subdir&gt;</code> 이전에
      처리한다. 같은 디렉토리를 지칭하는 여러 <directive
      type="section" module="core">Directory</directive> 섹션이
      있다면 이들을 설정파일 순서대로 처리한다. <directive
      module="core">Include</directive> 지시어로 포함한 설정은
      <directive module="core">Include</directive> 지시어 위치에
      포함한 파일 내용이 있는 것처럼 처리한다.</p>
  
      <p><directive type="section"
      module="core">VirtualHost</directive> 섹션 안에 포함된 섹션은
      가상호스트 정의 밖에 있는 해당 섹션 <em>이후에</em> 적용된다.
      그래서 가상호스트 안에서 주서버의 설정사항을 수정할 수 있다.</p>
  
      <p>다음에 나오는 섹션은 이전 섹션의 결과를 수정한다.</p>
  
  <note><title>기술적 주의</title>
        실제로
        <code>&lt;Location&gt;</code>/<code>&lt;LocationMatch&gt;</code>는
        (<code>Aliases</code>와 <code>DocumentRoot</code>를 사용하여
        URL을 파일명으로 변환하는) 이름번역 단계 이전에 처리된다.
        변역이 끝난 이후에는 완전히 무시한다.
  </note>
  
  <section id="merge-examples"><title>예제</title>
  
  <p>다음은 겹합하는 순서를 설명하는 예다. 이들 모두 요청에
  적용된다고 가정하면 지시어는 A &gt; B &gt; C &gt; D &gt; E
  순서로 처리된다.</p>
  
  <example>
  &lt;Location /&gt;<br />
  E<br />
  &lt;/Location&gt;<br />
  <br />
  &lt;Files f.html&gt;<br />
  D<br />
  &lt;/Files&gt;<br />
  <br />
  &lt;VirtualHost *&gt;<br />
  &lt;Directory /a/b&gt;<br />
  B<br />
  &lt;/Directory&gt;<br />
  &lt;/VirtualHost&gt;<br />
  <br />
  &lt;DirectoryMatch "^.*b$"&gt;<br />
  C<br />
  &lt;/DirectoryMatch&gt;<br />
  <br />
  &lt;Directory /a/b&gt;<br />
  A<br />
  &lt;/Directory&gt;<br />
  <br />
  </example>
  
  <p>더 현실적인 예는 다음과 같다. <directive module="core"
  type="section">Location</directive> 섹션을 나중에 처리하므로
  <directive module="core" type="section">Directory</directive>
  섹션에 있는 접근제한과 관계없이 서버에 무제한 접근을 가능하다.
  즉, 결합하는 순서는 중요하므로 주의하라!</p>
  
  <example>
  &lt;Location /&gt;<br />
  Order deny,allow<br />
  Allow from all<br />
  &lt;/Location&gt;<br />
  <br />
  # 악!  이 &lt;Directory&gt; 섹션은 아무런 효과가 없다<br />
  &lt;Directory /&gt;<br />
  Order allow,deny<br />
  Allow from all<br />
  Deny from badguy.example.com<br />
  &lt;/Directory&gt;
  </example>
  
  </section>
  
  </section>
  </manualpage>
  
  
  
  
  1.1                  httpd-2.0/docs/manual/server-wide.xml.ko
  
  Index: server-wide.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.3 -->
  <manualpage metafile="server-wide.xml.meta">
  
    <title>서버 전역 설정</title>
  
  <summary>
  <p>이 문서는 <module>core</module> 서버가 서버의 기본 행동을
  설정하기위해 제공하는 지시어중 일부를 설명한다.</p>
  </summary>
  
    <section id="identification">
      <title>서버 식별</title>
  
      <related>
        <directivelist>
          <directive module="core">ServerName</directive>
          <directive module="core">ServerAdmin</directive>
          <directive module="core">ServerSignature</directive>
          <directive module="core">ServerTokens</directive>
          <directive module="core">UseCanonicalName</directive>
        </directivelist>
      </related>
  
      <p><directive module="core">ServerAdmin</directive>과
      <directive module="core">ServerTokens</directive> 지시어는
      오류문 등 서버가 생성하는 문서에 나올 서버에 대한 정보를
      설정한다. <directive module="core">ServerTokens</directive>
      지시어는 서버 HTTP 응답 헤더를 설정한다.</p>
  
      <p>서버는 <directive module="core">ServerName</directive>과
      <directive module="core">UseCanonicalName</directive>
      지시어를 사용하여 자기참조 URL을 만든다. 예를 들어,
      클라이언트가 디렉토리를 요청했지만 디렉토리명 뒤에 슬래쉬를
      붙이지않은 경우 아파치는 뒤에 슬래쉬를 붙인 전체 이름을
      클라이언트에게 리다이렉트하여, 클라이언트가 문서의 상대참조를
      올바로 찾게 한다.</p>
    </section>
  
    <section id="locations">
      <title>파일 위치</title>
  
      <related>
        <directivelist>
          <directive module="mpm_common">CoreDumpDirectory</directive>
          <directive module="core">DocumentRoot</directive>
          <directive module="core">ErrorLog</directive>
          <directive module="mpm_common">LockFile</directive>
          <directive module="mpm_common">PidFile</directive>
          <directive module="mpm_common">ScoreBoardFile</directive>
          <directive module="core">ServerRoot</directive>
        </directivelist>
      </related>
  
      <p>이 지시어들은 아파치가 정상적으로 동작하기위해 필요한
      여러 파일들의 위치를 설정한다. 경로명이 슬래쉬(/)로 시작하지
      않으면, <directive module="core">ServerRoot</directive>에
      상대적인 파일을 찾는다. root가 아닌 사용자에게 쓰기권한이
      있는 경로에 파일을 두지않도록 조심해라. 더 자세한 정보는
      <a href="misc/security_tips.html#serverroot">보안 팁</a>
      문서를 참고하라.</p>
    </section>
  
    <section id="resource">
      <title>자원사용 제한</title>
  
      <related>
        <directivelist>
          <directive module="core">LimitRequestBody</directive>
          <directive module="core">LimitRequestFields</directive>
          <directive module="core">LimitRequestFieldsize</directive>
          <directive module="core">LimitRequestLine</directive>
          <directive module="core">RLimitCPU</directive>
          <directive module="core">RLimitMEM</directive>
          <directive module="core">RLimitNPROC</directive>
          <directive module="mpm_netware">ThreadStackSize</directive>
        </directivelist>
      </related>
  
      <p><directive>LimitRequest</directive>* 지시어는 아파치가
      클라이언트의 요청을 읽을 때 사용할 자원량을 제한한다. 이런
      값들을 제한하여 서비스거부(denial of service)류 공격을
      줄일 수 있다.</p>
  
      <p><directive>RLimit</directive>* 지시어는 아파치 자식이
      생성하는 프로세스가 사용할 자원량을 제한한다. 특히 CGI
      스크립트나 SSI exec 명령어가 사용할 자원을 제한한다.</p>
  
      <p><directive module="mpm_netware">ThreadStackSize</directive>
      지시어는 스택 크기를 조절하기위해 Netware에서만 사용한다.</p>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/sitemap.xml.ko
  
  Index: sitemap.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE sitemap SYSTEM "./style/sitemap.dtd"
    [ <!ENTITY allmodules SYSTEM "./mod/allmodules.xml.ko"> ]
  >
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.29 -->
  
  <sitemap metafile="sitemap.xml.meta">
  
    <title>사이트맵</title>
  
  <summary>
  <p>이 페이지는 현재
  <a href="./">Apache HTTP Server Version 2.1 문서</a> 목록을
  보여준다.</p>
  </summary>
  
  <category id="release">
  <title>발표문</title>
  <page href="upgrading.html">1.3에서 2.0으로 업그레이드</page>
  <page href="new_features_2_0.html">아파치 2.0의 새로운 기능</page>
  <page href="license.html">아파치 라이선스</page>
  </category>
  
  <category id="using">
  <title>아파치 웹서버 사용하기</title>
  <page href="install.html">아파치 컴파일과 설치</page>
  <page href="invoking.html">아파치 시작</page>
  <page href="stopping.html">서버 중단과 재시작</page>
  <page href="configuring.html">설정파일</page>
  <page href="sections.html">어떻게 Directory, Location, Files 섹션이
  동작하나</page>
  <page href="server-wide.html">서버 전역 설정</page>
  <page href="logs.html">로그파일</page>
  <page href="urlmapping.html">URL을 파일시스템에 대응</page>
  <page href="misc/security_tips.html">보안 팁</page>
  <page href="dso.html">동적공유객체 (DSO) 지원</page>
  <page href="content-negotiation.html">내용협상 (content negotiation)</page>
  <page href="custom-error.html">사용자정의 오류 응답</page>
  <page href="bind.html">아파치가 사용할 주소와 포트 지정</page>
  <page href="mpm.html">다중처리모듈 (MPM)</page>
  <page href="env.html">아파치의 환경변수</page>
  <page href="handler.html">아파치에서 핸들러 사용</page>
  <page href="filter.html">필터</page>
  <page href="suexec.html">suEXEC 지원</page>
  <page href="misc/perf-tuning.html">성능향상 힌트</page>
  <page href="misc/rewriteguide.html">URL 재작성(rewriting) 지침서</page>
  </category>
  
  <category id="vhosts">
  <title>아파치 가상호스트 문서</title>
  <page separate="yes" href="vhosts/">개요</page>
  <page href="vhosts/name-based.html">이름기반 가상호스트</page>
  <page href="vhosts/ip-based.html">IP기반 가상호스트 지원</page>
  <page href="vhosts/mass.html">대량의 가상호스트를 동적으로 설정하기</page>
  <page href="vhosts/examples.html">가상호스트 예</page>
  <page href="vhosts/details.html">가상호스트 찾기에 대한 자세한 설명</page>
  <page href="vhosts/fd-limits.html">파일기술자(file descriptor) 한계</page>
  <page href="dns-caveats.html">DNS와 아파치와 관련된 사항</page>
  </category>
  
  <category id="faq">
  <title>아파치 서버에 대해 자주 물어보는 질문</title>
  <page href="faq/">개요</page>
  <page separate="yes" href="faq/all_in_one.html">모두 한 페이지에</page>
  <page href="faq/support.html">지원</page>
  </category>
  
  <category id="ssl">
  <title>아파치 SSL/TLS 암호화</title>
  <page separate="yes" href="ssl/">소개</page>
  <page href="ssl/ssl_intro.html">SSL/TLS 암호화: 소개</page>
  <page href="ssl/ssl_compat.html">SSL/TLS 암호화: 호환성</page>
  <page href="ssl/ssl_howto.html">SSL/TLS 암호화: How-To</page>
  <page href="ssl/ssl_faq.html">SSL/TLS 암호화: FAQ</page>
  </category>
  
  <category id="howto">
  <title>지침서, 투토리얼, HowTo</title>
  <page separate="yes" href="howto/">개요</page>
  <page href="howto/auth.html">인증</page>
  <page href="howto/cgi.html">CGI로 동적 내용</page>
  <page href="howto/ssi.html">Server Side Includes 소개</page>
  <page href="howto/htaccess.html">.htaccess 파일</page>
  <page href="howto/public_html.html">사용자별 웹디렉토리</page>
  </category>
  
  <category id="platform">
  <title>플래폼별 설명</title>
  <page separate="yes" href="platform/">개요</page>
  <page href="platform/windows.html">Microsoft Windows에서 아파치
  사용하기</page>
  <page href="platform/win_compiling.html">Microsoft Windows에서
  아파치 컴파일하기</page>
  <page href="platform/netware.html">Novell NetWare에서 아파치
  사용하기</page>
  <page href="platform/perf-hp.html">HPUX에서 고성능 웹서버
  실행하기</page>
  <page href="platform/ebcdic.html">아파치 EBCDIC 포팅</page>
  </category>
  
  <category id="programs">
  <title>아파치 웹서버와 지원 프로그램</title>
  <page separate="yes" href="programs/">개요</page>
  <page href="programs/httpd.html">Manpage: httpd</page>
  <page href="programs/ab.html">Manpage: ab</page>
  <page href="programs/apachectl.html">Manpage: apachectl</page>
  <page href="programs/apxs.html">Manpage: apxs</page>
  <page href="programs/dbmmanage.html">Manpage: dbmmanage</page>
  <page href="programs/htdigest.html">Manpage: htdigest</page>
  <page href="programs/htpasswd.html">Manpage: htpasswd</page>
  <page href="programs/logresolve.html">Manpage: logresolve</page>
  <page href="programs/rotatelogs.html">Manpage: rotatelogs</page>
  <page href="programs/suexec.html">Manpage: suexec</page>
  <page href="programs/other.html">다른 프로그램들</page>
  </category>
  
  <category id="misc">
  <title>기타 아파치 문서</title>
  <page separate="yes" href="misc/">개요</page>
  <page href="cgi_path.html">CGI 환경에서 PATH_INFO의 변화</page>
  </category>
  
  <category id="modules">
  <title>아파치 모듈</title>
  <page href="mod/">모듈 목록</page>
  <page href="mod/directives.html">지시어 목록</page>
  <page href="mod/quickreference.html">지시어 빠른참조</page>
  &allmodules;
  </category>
  
  <category id="developer">
  <title>개발자 문서</title>
  <page separate="yes" href="developer/">개요</page>
  <page href="developer/API.html">Apache API 설명</page>
  <page href="developer/debugging.html">APR의 메모리할당 디버깅</page>
  <page href="developer/documenting.html">Apache 2.0 문서화</page>
  <page href="developer/hooks.html">Apache 2.0 훅(hook) 함수</page>
  <page href="developer/modules.html">Apache 1.3에서 Apache 2.0으로
  모듈을 수정하기</page>
  <page href="developer/request.html">Apache 2.0의 요청처리</page>
  <page href="developer/filters.html">Apache 2.0의 필터 동작법</page>
  </category>
  
  <category id="descriptive">
  <title>설명 정보</title>
  <page href="mod/module-dict.html">아파치 모듈을 설명하는데 사용한
  용어정의</page>
  <page href="mod/directive-dict.html">아파치 지시어를 설명하는데
  사용한 용어정의</page>
  <page href="glossary.html">용어</page>
  <page>사이트맵 (이 문서)</page>
  </category>
  
  </sitemap>
  
  
  
  1.1                  httpd-2.0/docs/manual/stopping.xml.ko
  
  Index: stopping.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.9 -->
  <manualpage metafile="stopping.xml.meta">
  
    <title>중단과 재시작</title>
  
  <summary>
      <p>이 문서는 유닉스류 시스템에서 아파치를 중단하고 재시작하는
      내용을 담고있다. 윈도우즈 NT, 2000, XP 사용자는 <a
      href="platform/windows.html#winsvc">서비스로 아파치
      실행하기</a>에서, 윈도우즈 9x와 ME 사용자는 <a
      href="platform/windows.html#wincons">콜솔 프로그램으로
      아파치 실행하기</a>에서 플래폼별 아파치 조작법을 알 수 있다.</p>
  </summary>
  
  <seealso><a href="programs/httpd.html">httpd</a></seealso>
  <seealso><a href="programs/apachectl.html">apachectl</a></seealso>
  
  <section id="introduction"><title>소개</title>
  
      <p>아파치를 중단하고 재시작하려면 실행하고 있는
      <code>httpd</code> 프로세스에 시그널을 보내야 한다. 시그널을
      보내는 방법은 두가지다. 하나는 유닉스 <code>kill</code>
      명령어를 사용하여 프로세스에 직접 시그널을 보내는 방법이다.
      시스템에 많은 <code>httpd</code>가 실행되지만, <directive
      module="mpm_common">PidFile</directive>에 pid가 기록된 부모외에
      다른 프로세스에 시그널(signal)을 보내면 안된다. 즉, 부모이외에
      다른 프로세스에 시그널을 보낼 필요가 없다는 말이다. 부모에게
      보낼 수 있는 시그널은 세가지로, 이제 설명할 <code><a
      href="#term">TERM</a></code>, <code><a
      href="#hup">HUP</a></code>, <code><a
      href="#graceful">USR1</a></code>이다.</p>
  
      <p>다음과 같이 부모에게 시그널을 보낸다:</p>
  
  <example>kill -TERM `cat /usr/local/apache2/logs/httpd.pid`</example>
  
      <p><code>httpd</code> 프로세스에게 시그널을 보내는 다른 방법은
      명령행 옵션 <code>-k</code>를 사용하는 것이다. 아래서 설명할
      <code>stop</code>, <code>restart</code>, <code>graceful</code>은
      <a href="programs/httpd.html">httpd</a> 실행파일의 아규먼트들이다.
      그러나 이 아규먼트들로 <code>httpd</code>를 실행하는, <a
      href="programs/apachectl.html">apachectl</a> 스크립트를
      사용하길 권한다.</p>
  
      <p><code>httpd</code>에 시그널을 보낸후, 다음 명령어로
      진행상황을 알 수 있다:</p>
  
  <example>tail -f /usr/local/apache2/logs/error_log</example>
  
      <p>위 예를 당신의 <directive
      module="core">ServerRoot</directive>와 <directive
      module="mpm_common">PidFile</directive> 설정에 알맞게 수정하라.</p>
  </section>
  
  <section id="term"><title>당장 중단</title>
  
  <dl><dt>시그널: TERM</dt>
  <dd><code>apachectl -k stop</code></dd>
  </dl>
  
      <p><code>TERM</code>이나 <code>stop</code> 시그널을 부모에게
      보내면 즉시 모든 자식을 죽인다. 자식을 완전히 죽이는데는
      몇 초가 걸릴 수 있다. 그런후 부모가 종료한다. 처리중인 요청은
      중단되고, 더 이상 요청을 받지않는다.</p>
  </section>
  
  <section id="graceful"><title>점잖은 재시작</title>
  
  <dl><dt>시그널: USR1</dt>
  <dd><code>apachectl -k graceful</code></dd>
  </dl>
  
      <p><code>USR1</code>이나 <code>graceful</code> 시그널을
      부모에게 보내면 부모 프로세스는 자식들에게 현재 요청을
      처리한후 종료하라고 (혹은 현재 아무것도 처리하지 않다면
      즉시 종료하라고) <em>조언한다</em>. 부모는 설정파일을
      다시읽고 로그파일도 다시 연다. 자식이 죽을때마다 부모는
      죽은 자식대신 새로운 설정 <em>세대</em>에 기초한 자식을
      실행하여 즉시 요청을 처리하게 한다.</p>
  
      <note>점잖은 재시작(graceful restart)으로 <code>USR1</code>을
      사용할 수 없는 플래폼에서는 대신 (<code>WINCH</code>와 같은)
      다른 시그널을 사용할 수 있다. <code>apachectl graceful</code>은
      플래폼에 알맞은 시그널을 보낸다.</note>
  
      <p>점잖은 재시작은 항상 MPM의 프로세스 조절 지시어 설정을
      고려하여, 재시작동안 클라이언트를 서비스하는 프로세스나 쓰레드가
      적당한 수를 유지하도록 설계되었다. 게다가 <directive
      module="mpm_common">StartServers</directive>는, 일초 후
      최소한 StartServers만큼 새로운 자식이 안만들어지면 자식이
      StartServers 개가 되도록 새로 만든다. 즉, 프로그램은 서버의
      현재 부하에 알맞은 자식의 개수를 유지하며,
      <directive>StartServers</directive> 파라미터로 지정한 당신의
      기대를 존중한다.</p>
  
      <p><module>mod_status</module> 사용자는 <code>USR1</code>을
      받을때 서버 통계가 0이 되지 <strong>않음을</strong> 봤을
      것이다. 서버는 새로운 요청을 (운영체제는 이들을 큐에 담아서
      어떤 경우에도 잃어버리지 않는다) 처리하지 못하는 시간을
      최소화하고 당신의 튜닝 파라미터를 존중하도록 만들어졌다.
      이를 위해 세대간 모든 자식을 기록하는 <em>scoreboard</em>를
      유지한다.</p>
  
      <p>status 모듈은 또한 점잖은 재시작 전에 시작하여 아직도
      요청을 처리하고 있는 자식을 <code>G</code>로 알려준다.</p>
  
      <p>현재로는 <code>USR1</code>을 사용하는 로그순환 스크립트가
      재시작전에 모든 자식이 로그작성을 마쳤는지 알 수 있는
      방법이 없다. 우리는 <code>USR1</code> 시그널을 보내고
      적당한 시간이 지난후 이전 로그를 다루도록 제안한다. 예를
      들어 낮은 대역폭 사용자의 경우 접속 대부분이 마치는데 10분이
      안걸린다면, 이전 로그를 다루기전에 15분 기다린다.</p>
  
      <note>설정파일에 오류가 있다면 재시작시 부모는 재시작하지
      않고 오류를 내며 종료한다. 또, 점잖은 재시작의 경우 종료할때
      자식이 실행되도록 놔둔다. (자식들은 자신의 마지막 요청을
      처리하고 "점잖게 종료한다".) 이는 서버를 재시작할때
      문제가 된다. 서버는 자신이 기다릴 포트에 연결하지 못한다.
      재시작전에 <code>-t</code> 명령행 옵션(<a
      href="programs/httpd.html">httpd</a> 참고)으로 설정파일
      문법을 검사할 수 있다. 그러나 이런 검사도 서버가 올바로
      재시작할지를 보장하지 못한다. 설정파일의 문법이 아닌 의미를
      검사하려면 root가 아닌 사용자로 <code>httpd</code>를 시작해볼 수 있다.
      root가 아니기때문에 (아니면 현재 그 포트를 사용하는
      <code>httpd</code>가 실행되기때문에) 오류가 없다면 소켓과
      로그파일을 열려고 시도하는 과정에서 실패할 것이다. 다른
      이유때문에 실패한다면 아마도 설정파일에 오류가 있을 것이다.
      점잖은 재시작을 하기전에 오류를 고쳐야한다.</note>
  </section>
  
  <section id="hup"><title>당장 재시작</title>
  
  <dl><dt>시그널: HUP</dt>
  <dd><code>apachectl -k restart</code></dd>
  </dl>
  
      <p><code>HUP</code>이나 <code>restart</code> 시그널을
      부모에게 보내면 <code>TERM</code>과 같이 모든 자식을
      죽이지만 부모는 종료하지 않는다. 부모는 설정파일을 다시읽고
      로그파일을 다시 연다. 그리고 새로운 자식들을 만들고 서비스를
      계속한다.</p>
  
      <p><module>mod_status</module> 사용자는 <code>HUP</code>를
      보내면 서버 통계가 0이 됨을 알 수 있다.</p>
  
  <note>설정파일에 오류가 있다면 재시작을 해도 부모는 재시작하지
  않고 오류를 내며 종료할 것이다. 이를 피하는 방법은 위를 참고하라.</note>
  </section>
  
  <section id="race"><title>부록: 시그널과 레이스 컨디션</title>
  
      <p>Apache 1.2b9 이전에는 재시작과 종료 시그널에 관계된
      <em>레이스 컨디션(race condition)</em>이 있었다. (레이스
      컨디션은 간단한 설명하자면, 어떤 일이 잘못된때 일어나서
      기대한대로 동작하지 않는 시간에 민감한 문제다.) "올바른"
      기능이 있는 아키텍쳐에서 우리는 이런 문제를 최대한 해결했다.
      그러나 어떤 아키텍쳐에는 아직도 레이스 컨디션이 존재함을
      주의하라.</p>
  
      <p><directive module="mpm_common">ScoreBoardFile</directive>을
      디스크에 저장하는 아키텍쳐는 scoreboard를 망가트릴 가능성이
      있다. 그러면 (<code>HUP</code>후) "bind: Address already in use"
      혹은 (<code>USR1</code> 후) "long lost child came home!"이
      발생할 수 있다. 전자는 심각한 오류이고, 후자는 단지 서버가
      scoreboard slot을 잃게 만든다. 그래서 강제 재시작을 줄이고
      점잖은 재시작을 사용하길 추천한다. 이 문제는 해결하기 매우
      힘들다. 그러나 다행히도 대부분의 아키텍쳐는 scoreboard로 파일을
      사용하지 않는다. 파일을 사용하는 아키텍쳐라면 <directive
      module="mpm_common">ScoreBoardFile</directive> 문서를 참고하라.</p>
  
      <p>모든 아키텍쳐에는 지속되는 HTTP 연결 (KeepAlive)에서
      두번째 이후 요청을 처리하는 자식에 약간의 레이스 컨디션이
      있다. 자식은 요청줄을 읽은 후 요청 헤더를 읽기전에 종료할 수
      있다. 이 문제는 너무 늦게 발견하여 1.2 버전이 나온후에야
      수정되었다. 그러나 네트웍 지연이나 서버 시간제한때문에 KeepAlive
      클라이언트는 이런 경우를 예상해야하기 때문에 이론상 문제는
      안된다. 실제로 서버를 검사하기위해 일초에 20번 재시작하는 동안
      클라이언트가 깨진 그림이나 빈 문서없이 사이트를 성공적으로
      읽어들이길 기대하지 않는다면 문제가 안된다.</p>
  </section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/suexec.xml.ko
  
  Index: suexec.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.7 -->
  
  <manualpage metafile="suexec.xml.meta">
  
    <title>suEXEC 지원</title>
  
    <summary>
      <p><strong>suEXEC</strong> 기능은 아파치가 <strong>CGI</strong>와
      <strong>SSI</strong> 프로그램을 웹서버를 실행한 사용자 ID가
      아닌 다른 사용자 ID로 실행하도록 한다. 보통 CGI나 SSI 프로그램을
      실행하면 웹서버를 실행한 사용자와 같은 사용자로 실행한다.</p>
  
      <p>이 기능을 적절히 사용하면 사용자가 직접 CGI나 SSI 프로그램을
      개발하고 실행할때 발생할 수 있는 보안위험을 상당히 줄일
      수 있다. 그러나 suEXEC가 부적절하게 설정되면 많은 문제와
      컴퓨터에 새로운 보안 허점을 만들 수 있다. 만약 setuid root
      프로그램과 이런 프로그램의 보안 문제에 생소하다면 suEXEC를
      사용하지않길 진심으로 바란다.</p>
    </summary>
  
  <section id="before"><title>시작하기 전에</title>
  
      <p>시작하기 전에 우선 아파치그룹과 이 문서의 가정을 밝힌다.</p>
  
      <p>먼저 <strong>setuid</strong>와 <strong>setgid</strong>
      기능이 가능한 유닉스류 운영체제를 사용한다고 가정한다. 모든
      명령어 예들도 같은 가정을 한다. suEXEC를 지원하는 다른 플래폼을
      사용하다면 설정이 다를 수 있다.</p>
  
      <p>두번째, 당신이 컴퓨터 보안의 기본 개념과 관리에 익숙하다고
      가정한다. 여기에는 <strong>setuid/setgid</strong> 기능과
      이들이 시스템과 보안에 미치는 여러 영향에 대한 이해가 포함된다.</p>
  
      <p>세번째, suEXEC 코드의 <strong>수정하지않은</strong>
      버전을 사용한다고 가정한다. 개발자와 여러 베타테스터들은
      suEXEC와 관련된 모든 코드를 조심스럽게 조사하고 검사했다.
      코드를 간단하게 하고 확실한 안전을 보장하기위해 모든 주의를
      기울였다. 이 코드를 수정하면 예상치못한 문제와 새로운 보안
      위험이 발생할 수 있다. 보안 프로그래밍에 대해 매우 잘 알고
      코드를 살펴보기위해 아파치그룹과 작업을 공유할 의사가 없다면
      suEXEC 코드를 수정하지않길 <strong>강력히</strong> 권한다.</p>
  
      <p>네번째이자 마지막으로, 아파치그룹은 suEXEC를 아파치
      기본설치에 포함하지 <strong>않기로</strong> 결정했다. 결국
      관리자가 주의를 기울여서 suEXEC를 설정해야 한다. suEXEC의
      여러 설정을 잘 고려한후 관리자는 일반적인 설치방법을 suEXEC를
      설치할 수 있다. suEXEC 기능을 사용하는 시스템의 보안을 책임지는
      관리자는 이 설정값들을 주의있게 살펴보고 지정해야 한다.
      이런 상세한 과정은 suEXEC를 사용할만큼 주의있고 단호한 
      사람만이 suEXEC를 사용하도록 아파치그룹이 원하기 때문이다.</p>
  
      <p>아직도 사용하길 원하는가? 그런가? 좋다. 이제 시작하자!</p>
  </section>
  
  <section id="model"><title>suEXEC 보안모델</title>
  
      <p>suEXEC를 구성하고 설치하기 전에 우리는 보안모델을 먼저
      설명한다. 이를 통해 정확히 suEXEC 안에서는 무슨 일이 일어나며
      시스템의 보안을 위해 무엇을 조심해야 할지 더 잘 이해할 수
      있다.</p>
  
      <p><strong>suEXEC</strong>는 아파치 웹서버가 부르는 setuid
      "wrapper" 프로그램을 기반으로 한다. 이 wrapper는 관리자가
      주서버와 다른 userid로 실행하도록 설정한 CGI나 SSI 프로그램에
      HTTP 요청이 오면 불린다. 이런 요청이 오면 아파치는 suEXEC
      wrapper에게 프로그램명과 프로그램을 실행할 사용자와 그룹
      ID를 제공한다.</p>
  
      <p>그러면 wrapper는 다음 과정을 통해 성공과 실패를 결정한다.
      이 조건중 하나라도 실패하면 프로그램은 실패로 기록되고 오류를
      내며 종료한다. 실패하지 않으면 과정을 계속한다:</p>
  
      <ol>
        <li>
          <strong>적절한 수의 아규먼트로 wrapper를 실행하는가?</strong>
  
          <p class="indent">
            wrapper는 적절한 수의 아규먼트가 있어야만 실행된다.
            아파치 웹서버가 이 개수를 안다. wrapper가 적절한 수의
            아규먼트를 받지못하면 해킹되었거나 아파치의 suEXEC에
            뭔가 문제가 있는 것이다.
          </p>
        </li>
  
        <li>
          <strong>wrapper를 실행하는 사용자가 시스템의 정상적인
          사용자인가?</strong> 
  
          <p class="indent">
            wrapper를 실행하는 사용자가 실제로 시스템의 사용자인지
            확인한다.
          </p>
        </li>
  
        <li>
          <strong>이 사용자가 wrapper를 실행하도록 허용되었나?</strong> 
  
          <p class="indent">
            이 사용자가 wrapper를 실행하도록 허용되었나? 오직
            한 사용자(아파치 사용자)만이 이 프로그램을 실행할
            수 있다.
          </p>
        </li>
  
        <li>
          <strong>지정한 프로그램이 안전하지않은 계층참조를 가지는가?</strong>
  
          <p class="indent">
            지정한 프로그램이 '/'로 시작하거나 뒷참조 '..'을 가지는가?
            이들을 사용할 수 없다. 지정한 프로그램은 아파치 웹공간내에
            있어야 한다.
          </p>
        </li>
  
        <li>
          <strong>지정한 사용자명이 유효한가?</strong> 
  
          <p class="indent">
            지정한 사용자가 존재하는가?
          </p>
        </li>
  
        <li>
          <strong>지정한 그룹명이 유효한가?</strong> 
  
          <p class="indent">
            지정한 그룹이 존재하는가?
          </p>
        </li>
  
        <li>
          <strong>지정한 사용자가 superuser가 <em>아닌가</em>?</strong>
          
  
          <p class="indent">
            현재 suEXEC는 'root'가 CGI/SSI 프로그램을 실행할 수
            없도록 한다.
          </p>
        </li>
  
        <li>
          <strong>지정한 userid가 최소 ID 숫자보다 <em>큰가</em>?</strong>
  
          <p class="indent">
            설정에서 최소 사용자 ID 숫자를 지정한다. 그래서 CGI/SSI
            프로그램을 실행할 수 있는 userid의 최소치를 지정할
            수 있다. "시스템용" 계정을 제외할때 유용하다.
          </p>
        </li>
  
        <li>
          <strong>지정한 그룹이 superuser 그룹이 <em>아닌가</em>?</strong> 
  
          <p class="indent">
            현재 suEXEC는 'root' 그룹이 CGI/SSI 프로그램을 실행할
            수 없도록 한다.
          </p>
        </li>
  
        <li>
          <strong>지정한 groupid가 최소 ID 숫자보다 <em>큰가</em>?</strong> 
  
          <p class="indent">
            설정에서 최소 그룹 ID 숫자를 지정한다. 그래서 CGI/SSI
            프로그램을 실행할 수 있는 groupid의 최소치를 지정할
            수 있다. "시스템용" 그룹을 제외할때 유용하다.
          </p>
        </li>
  
        <li>
          <strong>wrapper가 성공적으로 지정한 사용자와 그룹이
          될 수 있는가?</strong>
  
          <p class="indent">
            이 단계에서 프로그램은 setuid와 setgid 호출을 하여
            지정한 사용자와 그룹이 된다. 또, 그룹 접근목록은
            사용자가 해당된 모든 그룹으로 초기화된다.
          </p>
        </li>
  
        <li>
          <strong>프로그램이 있는 디렉토리가 존재하나?</strong> 
  
          <p class="indent">
            존재하지 않다면 파일이 있을 수 없다.
          </p>
        </li>
  
        <li>
          <strong>디렉토리가 아파치 웹공간 안에 있는가?</strong>
  
          <p class="indent">
            서버의 일반적인 부분을 요청할 경우 요청하는 디렉토리가
            서버의 문서 root 아래 있는가? UserDir을 요청할 경우
            요청하는 디렉토리가 사용자 문서 root 아래 있는가?
          </p>
        </li>
  
        <li>
          <strong>다른 누구도 디렉토리에 쓰기권한이 <em>없는가</em>?</strong>
  
          <p class="indent">
            디렉토리를 다른 사람에게 열어두길 원하지않는다. 오직
            소유자만이 디렉토리 내용을 변경할 수 있다.
          </p>
        </li>
  
        <li>
          <strong>지정한 프로그램이 존재하는가?</strong> 
  
          <p class="indent">
            존재하지않다면 실행할 수도 없다.
          </p>
        </li>
  
        <li>
          <strong>다른 누구도 지정한 프로그램에 쓰기권한이
          <em>없는가</em>?</strong>
  
          <p class="indent">
            소유자외 누구도 프로그램을 변경하길 원하지않는다.
          </p>
        </li>
  
        <li>
          <strong>지정한 프로그램이 setuid나 setgid가 <em>아닌가</em>?</strong>
  
          <p class="indent">
            우리는 프로그램이 다시 UID/GID를 변경하길 원하지않는다.
          </p>
        </li>
  
        <li>
          <strong>지정한 사용자/그룹이 프로그램의 사용자/그룹과 같은가?</strong>
  
          <p class="indent">
            사용자가 파일의 소유자인가?
          </p>
        </li>
  
        <li>
          <strong>안전한 동작을 위해 프로세스의 환경변수를 청소할
          수 있는가?</strong>
  
          <p class="indent">
            suEXEC는 (설정에서 정의한) 안전한 실행 PATH를 잡고,
            (이것도 설정에서 정의) 안전한 환경변수 목록에 열거된
            변수만 남기고 프로세스의 환경변수를 지운다.
          </p>
        </li>
  
        <li>
          <strong>성공적으로 지정한 프로그램을 실행할 수 있는가?</strong> 
  
          <p class="indent">
            여기서 suEXEC가 끝나고 지정한 프로그램이 시작한다.
          </p>
        </li>
      </ol>
  
      <p>이것이 suEXEC wrapper 보안모델의 표준 동작이다. 다소
      엄격하고 CGI/SSI 설계에 새로운 제한이 되지만, 보안을 염두에
      두고 한단계씩 조심스럽게 만들어졌다.</p>
  
      <p>이 보안 모델이 서버 설정에 어떤 제한을 주는지와 적절한
      suEXEC 설정으로 어떤 보안 위험을 피할 수 있는지에 대해 이
      문서의 <a href="#jabberwock">"다시 한번 조심하라"</a> 절을
      참고하라.</p>
  </section>
  
  <section id="install"><title>suEXEC 구성과 설치</title>
  
      <p>이제 재미있는 내용이 시작한다.</p>
  
      <p><strong>suEXEC 구성 옵션</strong><br />
      </p>
  
      <dl>
        <dt><code>--enable-suexec</code></dt>
  
        <dd>이 옵션은 기본적으로 설치되거나 활성화되지않는 suEXEC
        기능을 활성화한다. APACI가 suEXEC를 받아들이려면
        --enable-suexec 옵션외에 --with-suexec-xxxxx 옵션이 최소한
        한개 필요하다.</dd>
  
        <dt><code>--with-suexec-bin=<em>PATH</em></code></dt>
  
        <dd>suexec 바이너리 경로는 보안상 이유로 서버에 기록되야
        한다. 경로 기본값을 무시하려면 이 옵션을 사용한다. <em>예를
        들어</em> <code>--with-suexec-bin=/usr/sbin/suexec</code></dd>
  
        <dt><code>--with-suexec-caller=<em>UID</em></code></dt>
  
        <dd>보통 아파치를 실행하는 <a
        href="mod/mpm_common.html#user">사용자명</a>. 프로그램을
        실행할 수 있는 유일한 사용자다.</dd>
  
        <dt><code>--with-suexec-userdir=<em>DIR</em></code></dt>
  
        <dd>suEXEC 접근이 허용되는 사용자 홈디렉토리의 하위디렉토리를
        지정한다. 이 디렉토리에 있는 모든 실행파일을 사용자의
        suEXEC로 실행므로, 모든 프로그램이 "안전해야" 한다. (예를
        들어, 값에 "*"이 없는) "간단한" UserDir 지시어를 사용한다면
        같은 값을 설정해야 한다. UserDir 지시어가 passwd 파일에
        나온 사용자 홈디렉토리와 다르면 suEXEC는 정상적으로
        작동하지 않는다. 기본값은 "public_html"이다.<br />
        가상호스트들이 각각 다른 UserDir을 사용한다면 모두 한
        부모 디렉토리 안에 있도록 정의해야 하고, 그 부모 디렉토리명을
        여기 적는다. <strong>이렇게 정의하지 않으면, "~userdir"
        cgi 요청이 작동하지 않는다!</strong></dd>
  
        <dt><code>--with-suexec-docroot=<em>DIR</em></code></dt>
  
        <dd>아파치의 DocumentRoot를 정의한다. 이는 suEXEC가 사용할
        수 있는 (UserDirs을 제외한) 유일한 공간이다. 기본 디렉토리는
        --datadir 값에 "/htdocs"을 붙인 것이다. <em>예를 들어</em>
        "<code>--datadir=/home/apache</code>"로 구성했다면 suEXEC
        wrapper는 document root로 "/home/apache/htdocs" 디렉토리를
        사용한다.</dd>
  
        <dt><code>--with-suexec-uidmin=<em>UID</em></code></dt>
  
        <dd>suEXEC에서 지정가능한 사용자의 최소 UID를 정의한다.
        대부분의 시스템에서 500이나 100이 적절하다. 기본값은
        100이다.</dd>
  
        <dt><code>--with-suexec-gidmin=<em>GID</em></code></dt>
  
        <dd>suEXEC에서 지정가능한 그룹의 최소 GID를 정의한다.
        대부분의 시스템에서 100이 적절하므로 이 값이 기본값이다.</dd>
  
        <dt><code>--with-suexec-logfile=<em>FILE</em></code></dt>
  
        <dd>모든 suEXEC 작동과 오류를 (감시나 디버깅 목적에 유용한)
        기록할 로그파일명을 지정한다. 기본적으로 로그파일의 이름은
        "suexec_log"이고 표준 로그파일 디렉토리에 (--logfiledir)
        위치한다.</dd>
  
        <dt><code>--with-suexec-safepath=<em>PATH</em></code></dt>
  
        <dd>CGI 실행파일에 넘겨질 안전한 PATH 환경변수를 정의한다.
        기본값은 "/usr/local/bin:/usr/bin:/bin"이다.</dd>
      </dl>
  
      <p><strong>suEXEC 구성을 점검하라</strong><br />
       suEXEC wrapper를 컴파일하고 설치하기 전에 --layout 옵션을
      사용하여 설정을 점검할 수 있다.<br />
       출력예:</p>
  
  <example>
      suEXEC setup:<br />
              suexec binary: /usr/local/apache/sbin/suexec<br />
              document root: /usr/local/apache/share/htdocs<br />
             userdir suffix: public_html<br />
                    logfile: /usr/local/apache/var/log/suexec_log<br />
                  safe path: /usr/local/bin:/usr/bin:/bin<br />
                  caller ID: www<br />
            minimum user ID: 100<br />
           minimum group ID: 100<br />
  </example>
  
      <p><strong>suEXEC wrapper를 컴파일하고 설치하기</strong><br />
      --enable-suexec 옵션으로 suEXEC 기능을 가능하게한 경우
      "make" 명령어를 실행하면 suexec 실행파일이 (아파치와 함께)
      자동으로 만들어진다.<br />
      모든것을 컴파일한 후 "make install" 명령어를 실행하여 설치할
      수 있다. 바이너리파일 "suexec"는 --sbindir 옵션으로 지정한
      디렉토리에 설치된다. 기본 위치는
      "/usr/local/apache/sbin/suexec"이다.<br />
      설치 과정에 <strong><em>root 권한</em></strong>이 필요함을
      주의하라. wrapper가 사용자 ID를 설정하기위해서는 소유자가
      <code><em>root</em></code>이고 파일모드로 setuserid 실행비트가
      설정되야 한다.</p>
  
  </section>
  
  <section id="enable"><title>suEXEC 키고 끄기</title>
  
      <p>아파치는 시작할때 "sbin" 디렉토리에서 "suexec" 파일을
      (기본값 "/usr/local/apache/sbin/suexec") 찾는다. 아파치가
      정상적으로 구성된 suEXEC wrapper를 발견하면 error log에
      다음과 같이 출력한다:</p>
  <example>
      [notice] suEXEC mechanism enabled (wrapper: <em>/path/to/suexec</em>)
  </example>
      <p>서버 시작중에 이런 문구를 없다면 서버는 기대한 장소에서
      wrapper 프로그램을 찾지 못했거나, 실행파일이 <em>setuid
      root</em>로 설치되지않았기 때문일 것이다.</p>
  
       <p>처음으로 suEXEC 기능을 사용하고 싶고 이미 아파치 서버가
       실행중이라면, 아파치를 죽이고 다시 시작해야 한다. 간단히
       HUP이나 USR1 시그널로 재시작하는 것으로는 충분하지 않다. </p>
       <p>suEXEC를 안사용하려면 "suexec" 파일을 지운후 아파치를
       죽이고 재시작해야 한다. </p>
  </section>
  
  <section id="usage"><title>suEXEC 사용하기</title>
  
      <p><strong>가상호스트:</strong><br /> suEXEC wrapper를
      사용하는 한가지 방법은 <directive
      module="core">VirtualHost</directive> 정의에 <directive
      module="mod_suexec">SuexecUserGroup</directive> 지시어를
      사용하는 것이다. 이 지시어를 주서버 사용자 ID와 다르게
      설정하면 CGI 자원의 모든 요청이 <directive
      module="core" type="section">VirtualHost</directive>에서
      지정한 <em>User</em>와 <em>Group</em>으로 실행된다. 이
      지시어들이 <directive module="core"
      type="section">VirtualHost</directive>에 없으면 주서버
      userid를 사용한다.</p>
  
      <p><strong>사용자 디렉토리:</strong><br />
      suEXEC wrapper는 CGI 프로그램을 요청을 받은 사용자가 실행하도록
      할 수 있다. 이를 위해 실행하길 원하는 사용자 ID 앞에
      "<strong><code>~</code></strong>" 문자를 붙이면 된다. 실행을
      위해 해당 사용자는 CGI를 실행할 수 있어야 하고, 스크립트가
      위의 <a href="#model">보안 검사</a> 항목을 만족해야 한다.</p>
  </section>
  
  <section id="debug"><title>suEXEC 디버깅하기</title>
  
      <p>suEXEC wrapper는 로그 정보를 위에서 다룬 --with-suexec-logfile
      옵션으로 지정한 파일에 쓴다. wrapper를 올바로 구성하고 설치했다면
      어디서 잘못되었는지 이 로그파일와 서버의 error_log를 살펴봐라.</p>
  
  </section>
  
  <section id="jabberwock"><title>다시 한번 조심하라: 경고와 예제</title>
  
      <p><strong>주의!</strong> 이 섹션은 완전하지 않을 수 있다.
      아파치그룹의 <a
      href="http://httpd.apache.org/docs-2.1/suexec.html">온라인
      문서</a>에서 이 문서의 최신판을 참고하라.</p>
  
      <p>wrapper가 서버 설정을 제약하는 몇가지 흥미로운 점이 있다.
      suEXEC와 관련된 "버그"를 보고하기 전에 이들을 살펴보길 바란다.</p>
  
      <ul>
        <li><strong>suEXEC 제약 사항</strong></li>
  
        <li>
          디렉토리 구조 제한
  
          <p class="indent">
            보안과 효율성을 위해 모든 suexec 요청은 가상호스트의
            경우 최상위 document root 혹은 userdir 요청의 경우
            최상위 개인 document root 안에서 발생해야 한다. 예를
            들어, 가상호스트 네개를 설정했다면 가상호스트에서
            suEXEC를 이용하기위해 가상호스트의 document root를
            주 아파치 문서 계층구조 밖에 설정할 필요가 있다.
            (예제는 다음에.)
          </p>
        </li>
  
        <li>
          suEXEC의 PATH 환경변수
  
          <p class="indent">
            변경하면 위험할 수 있다.  여기에 포함하는 모든 경로가
            <strong>믿을 수 있는</strong> 디렉토리인지 확인하라. 
            이 지구상의 누군가가 그곳에 있는 트로이목마를 실행하길
            원하지 않을 것이다.
          </p>
        </li>
  
        <li>
          suEXEC 코드 수정하기
  
          <p class="indent">
            반복해서 말하지만, 당신이 무엇을 하는지 모르고 시도한다면
            <strong>큰 문제</strong>가 발생할 수 있다. 어떤 경우에도
            수정하지마라.
          </p>
        </li>
      </ul>
  
  </section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/upgrading.xml.ko
  
  Index: upgrading.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.11 -->
  <manualpage metafile="upgrading.xml.meta">
  
  <title>1.3에서 2.0으로 업그레이드</title>
  
  <summary>
    <p>우리는 기존 아파치 사용자가 업그레이드하는 것을 돕기위해
    중요한 정보를 알려주는 문서를 제공한다. 이 문서는 간단한
    요약이므로, <a href="new_features_2_0.html">새로운 기능</a>
    문서나 <code>src/CHANGES</code> 파일에서 정보를 찾아봐야
    한다.</p>
  </summary>
  <seealso><a href="new_features_2_0.html">아파치 2.0의 새로운
  기능 요약</a></seealso>
  
    <section id="compile-time">
      <title>컴파일시 구성 변화</title>
  
      <ul>
        <li>아파치는 이제 <a
        href="install.html">아파치 컴파일과 설치</a>를 위해
        <code>autoconf</code>와 <code>libtool</code> 시스템을
        사용한다. 이 시스템의 사용법은 Apache 1.3의 APACI 시스템과
        같지는 않지만 비슷하다.</li>
  
        <li>컴파일 여부를 선택할 모듈외에 Apache 2.0은 요청을
        처리하는 주요 부분을 <a href="mpm.html">다중처리 모듈
        (Multi-Processing Modules)</a> (MPM)로 옮겼다.</li>
      </ul>
    </section>
  
    <section id="run-time">
      <title>실행시 설정 변화</title>
  
      <ul>
        <li>Apache 1.3에서 서버 핵심에 있었던 많은 지시어들이
        이제는 MPM에 있다. 서버가 Apache 1.3과 최대한 비슷하게
        동작하길 바란다면 <module>prefork</module> MPM을 선택해야
        한다. 다른 MPM은 다른 지시어를 사용하여 프로세스 생성과
        요청의 처리를 조절한다.</li>
  
        <li><a href="mod/mod_proxy.html">proxy 모듈</a>은 HTTP/1.1에
        맞추어 수정되었다. 중요한 변화중 하나는 이제 프록시 접근제어가
        <code>&lt;Directory proxy:&gt;</code> 블록이 아니라
        <directive type="section" module="mod_proxy">Proxy</directive>
        블록에 위치하는 점이다.</li>
  
        <li>몇몇 모듈에서 <code>PATH_INFO</code> (진짜 경로명
        뒤에 나오는 경로 정보) 처리 방식이 변경되었다. 전에
        핸들러였지만 이제 필터로 구현되는 모듈은 더 이상
        <code>PATH_INFO</code>가 있는 요청을 받아들이지 못한다.
        <a href="mod/mod_include.html">INCLUDES</a>나 <a
        href="http://www.php.net/">PHP</a>와 같은 필터는
        core 핸들러 위에 구현되기때문에 <code>PATH_INFO</code>가
        있는 요청을 거부한다. core 핸들러가 <code>PATH_INFO</code>가
        있는 요청을 받아들이고 server-side include에서
        <code>PATH_INFO</code>를 사용하게 하려면, <directive
        module="core">AcceptPathInfo</directive> 지시어를 사용해야
        한다.</li>
  
        <li><directive module="mod_negotiation">CacheNegotiatedDocs</directive>
        지시어는 이제 아규먼트로 <code>on</code>과 <code>off</code>를
        받는다. 기존의 <directive>CacheNegotiatedDocs</directive>는
        <code>CacheNegotiatedDocs on</code>으로 수정해야 한다.</li>
  
        <li>
          <directive module="core">ErrorDocument</directive> 지시어는
          더이상 메세지를 나타내는 아규먼트 앞에 따옴표를 사용하지
          않는다. 대신 쌍따옴표로 메세지를 묶어야 한다. 예를 들어 과거
  
          <example>
            ErrorDocument 403 "Some Message
          </example>
          는 다음과 같이 수정해야 한다.
  
          <example>
            ErrorDocument 403 "Some Message"
          </example>
          두번째 아규먼트가 유효한 URL이나 경로명이 아니라면 메세지로
          간주한다.
        </li>
  
        <li><code>AccessConfig</code>와 <code>ResourceConfig</code>
        지시어는 사라졌다. 기존에 사용하던 지시어는 같은 기능을
        하는 <directive module="core">Include</directive> 지시어로
        대체할 수 있다. 과거에 설정파일에서 이 지시어들을 사용하지않고
        이 지시어들의 기본값을 사용했다면, <code>http.conf</code>에
        <code>Include conf/access.conf</code>와 <code>Include
        conf/srm.conf</code>를 추가할 필요가 있다. 아파치가 이전
        지시어와 같은 순서로 설정파일을 읽게하려면
        <directive module="core">Include</directive> 지시어를
        <code>httpd.conf</code> 끝에 두고, <code>srm.conf</code>이
        <code>access.conf</code> 앞에 나와야 한다.</li>
  
        <li><code>BindAddress</code>와 <code>Port</code> 지시어는
        사라졌다. 더 유연한 <directive module="mpm_common">Listen</directive>
        지시어가 같은 기능을 한다.</li>
  
        <li>Apache-1.3에서 <code>Port</code>는 자기참조
        URL의 포트 번호를 설정하는 일도 했다. Apache-2.0에서 이
        기능은 새로운 <directive module="core">ServerName</directive>으로
        한다. 한 지시어에 호스트명<em>과</em> 자기참조 URL을 위한
        포트 번호를 같이 설정할 수 있다.</li>
  
        <li><code>ServerType</code> 지시어는 사라졌다. 요청을
        서비스하는 방법은 이제 MPM 선택에 달렸다. 현재 inetd에서
        시작하도록 설계된 MPM은 없다.</li>
  
        <li><code>AgentLog</code>, <code>RefererLog</code>,
        <code>RefererIgnore</code> 지시어를 제공한
        <code>mod_log_agent</code>와 <code>mod_log_referer</code>
        모듈이 없어졌다. agent 로그와 referer 로그는
        <module>mod_log_config</module>의 <directive
        module="mod_log_config">CustomLog</directive> 지시어를
        사용하여 계속 제공된다.</li>
  
        <li><code>AddModule</code>과 <code>ClearModuleList</code>
        지시어는 사라졌다. 이 지시어들은 모듈을 올바른 순서로
        활성화하려고 사용했다. 새로운 Apache 2.0 API는 모듈이
        활성화되는 순서를 명시적으로 지정할 수 있어서, 이 지시어들이
        필요없게 되었다.</li>
  
        <li><code>FancyIndexing</code> 지시어가 없어졌다.
        <directive module="mod_autoindex">IndexOptions</directive>
        지시어의 <code>FancyIndexing</code> 옵션이 같은 기능을 한다.</li>
  
        <li><module>mod_negotiation</module>의 MultiViews 내용협상이
        더 엄격하게 기본파일을 찾는다. 내용협상은 <em>협상가능한</em>
        파일 중에서만 선택한다. <directive
        module="mod_mime">MultiviewsMatch</directive> 지시어를
        사용하여 이전과 같이 동작하게 할 수 있다.</li>
  
      </ul>
    </section>
  
    <section id="misc">
      <title>기타 변화</title>
  
      <ul>
        <li>Apache 1.3에서 실험적이였던 <module>mod_auth_digest</module>
        모듈이 이제 표준 모듈이 되었다.</li>
  
        <li>Apache 1.3에서 실험적이였던 <code>mod_mmap_static</code>
        모듈이 <module>mod_file_cache</module>로 대체되었다.</li>
  
        <li>배포본이 완전히 새로 구성되어 더이상 독립된 <code>src</code>
        디렉토리가 없다. 대신 소스는 주 배포본 디렉토리 아래 논리적으로
        구성되있고, 컴파일한 서버는 다른 디렉토리로 설치된다.</li>
      </ul>
    </section>
  
    <section id="third-party">
      <title>제삼자가 만든 모듈</title>
  
      <p>Apache 2.0에서 서버 API가 많이 변경되었다. Apache 1.3 API에
      맞춰진 기존 모듈을 수정없이 Apache 2.0에서 사용할 수
      <strong>없다</strong>. 자세한 정보는 <a href="developer/">개발자
      문서</a>를 참고하라.</p>
    </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/urlmapping.xml.ko
  
  Index: urlmapping.xml.ko
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR" ?>
  <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="./style/manual.ko.xsl"?>
  <!-- English revision: 1.8 -->
  
  <manualpage metafile="urlmapping.xml.meta">
  
    <title>URL을 파일시스템 위치로 대응하기</title>
  
    <summary>
      <p>이 문서는 요청의 URL을 가지고 아파치가 어떻게 서비스할 
      파일의 파일시스템상 위치를 찾는지 설명한다.</p>
    </summary>
  
  <section id="related"><title>관련된 모듈과 지시어들</title>
  
  <related>
  <modulelist>
  <module>mod_alias</module>
  <module>mod_proxy</module>
  <module>mod_rewrite</module>
  <module>mod_userdir</module>
  <module>mod_speling</module>
  <module>mod_vhost_alias</module>
  </modulelist>
  <directivelist>
  <directive module="mod_alias">Alias</directive>
  <directive module="mod_alias">AliasMatch</directive>
  <directive module="mod_speling">CheckSpelling</directive>
  <directive module="core">DocumentRoot</directive>
  <directive module="core">ErrorDocument</directive>
  <directive module="core">Options</directive>
  <directive module="mod_proxy">ProxyPass</directive>
  <directive module="mod_proxy">ProxyPassReverse</directive>
  <directive module="mod_alias">Redirect</directive>
  <directive module="mod_alias">RedirectMatch</directive>
  <directive module="mod_rewrite">RewriteCond</directive>
  <directive module="mod_rewrite">RewriteMatch</directive>
  <directive module="mod_alias">ScriptAlias</directive>
  <directive module="mod_alias">ScriptAliasMatch</directive>
  <directive module="mod_userdir">UserDir</directive>
  </directivelist>
  </related>
  </section>
  
  <section id="documentroot"><title>DocumentRoot</title>
  
      <p>요청을 받은 아파치는 어떤 파일을 서비스할지 결정하기위해
      기본적으로 요청의 URL-경로(URL에서 호스트명과 포트 뒤에
      나오는 부분)를 설정파일에서 지정한 <directive
      module="core">DocumentRoot</directive> 뒤에 붙인다. 그래서
      <directive module="core">DocumentRoot</directive> 아래있는
      파일과 디렉토리들은 웹에서 보게될 기본적인 내용이다.</p>
  </section>
  
  <section id="outside"><title>DocumentRoot 밖에 있는 파일들</title>
  
      <p>종종 파일시스템에서 <directive
      module="core">DocumentRoot</directive> 아래 있지않은 부분을
      웹에서 접근할 필요가 있다. 아파치는 이 경우 여러가지 방법을
      사용할 수 있다. 유닉스 시스템에서 심볼링크를 사용하여
      파일시스템의 다른 부분을 <directive
      module="core">DocumentRoot</directive> 아래에 둘 수 있다.
      보안을 위해 아파치는 해당 디렉토리의 <directive
      module="core">Options</directive> 설정에
      <code>FollowSymLinks</code>나
      <code>SymLinksIfOwnerMatch</code>가 있는 경우에만 심볼링크를
      따라간다.</p>
  
      <p>또, <directive module="mod_alias">Alias</directive>
      지시어는 파일시스템의 특정 부분을 웹공간에 대응한다. 예를
      들어 다음과 같다면</p>
  
  <example>Alias /docs /var/web</example>
  
      <p>URL <code>http://www.example.com/docs/dir/file.html</code>은
      <code>/var/web/dir/file.html</code>을 가지고 서비스한다.
      지정한 경로에 있는 모든 내용을 CGI 스크립트로 취급하는 것을
      제외하고는 <directive module="mod_alias">ScriptAlias</directive>
      지시어도 같은 일을 한다.</p>
  
      <p><directive module="mod_alias">AliasMatch</directive>와
      <directive module="mod_alias">ScriptAliasMatch</directive>
      지시어의 강력한 정규표현식기반 대응과 대치를 사용하여 더
      유연한 설정이 가능하다. 예를 들어,</p>
  
  <example>ScriptAliasMatch ^/~([a-zA-Z0-9]*)/cgi-bin/(.*)
        /home/$1/cgi-bin/$2</example>
  
      <p>는 <code>http://example.com/~user/cgi-bin/script.cgi</code>로의
      요청을 경로 <code>/home/user/cgi-bin/script.cgi</code>로
      대응하고, 해당 파일을 CGI 스크립트로 취급한다.</p>
  </section>
  
  <section id="user"><title>사용자 디렉토리</title>
  
      <p>유닉스 시스템은 전통적으로 특정 사용자 <em>user</em>의
      홈디렉토리를 <code>~user/</code>로 지칭한다.
      <module>mod_userdir</module> 모듈은 이 개념을 웹에까지
      확장하여, 다음과 같은 URL을 가지고 각 사용자 홈디렉토리
      안에 있는 파일을 서비스한다.</p>
  
  <example>http://www.example.com/~user/file.html</example>
  
      <p>보안상 웹에서 사용자 홈디렉토리로 직접 접근할 수 있으면
      안된다. 그래서 <directive module="mod_userdir">UserDir</directive>
      지시어는 사용자 홈디렉토리에서 웹용 파일들이 있을 디렉토리를
      지정한다. 기본 설정 <code>Userdir public_html</code>을 사용하고
      <code>/home/user/</code>가 <code>/etc/passwd</code>에 지정된
      사용자 홈디렉토리라면, 위의 URL은 파일
      <code>/home/user/public_html/file.html</code>에 대응한다.</p>
  
      <p>또, <code>Userdir</code> 지시어는 <code>/etc/passwd</code>에
      홈디렉토리의 위치가 저장되지않는 시스템을 위해 여러 다른
      형태를 사용할 수 있다.</p>
  
      <p>어떤 사람은 (보통 웹에서 <code>%7e</code>로 인코딩되는)
      "~" 기호가 이상하여 다른 방식으로 사용자 디렉토리를 나타내고
      싶어한다. 이 기능은 mod_userdir이 제공하지않는다. 그러나
      사용자 홈디렉토리가 규칙적인 방법으로 구성되있다면, <directive
      module="mod_alias">AliasMatch</directive> 지시어를 사용하여
      원하는 효과를 얻을 수 있다. 예를 들어, 다음의
      <code>AliasMatch</code> 지시어를 사용하면
      <code>http://www.example.com/upages/user/file.html</code>이
      <code>/home/user/public_html/file.html</code>에 대응한다:</p>
  
  <example>AliasMatch ^/upages/([a-zA-Z0-9]*)/?(.*)
        /home/$1/public_html/$2</example>
  </section>
  
  <section id="redirect"><title>URL 리다이렉션(Redirection)</title>
  
      <p>앞에서 설명한 설정 지시어들은 아파치가 파일시스템의 특정
      장소에 있는 내용을 클라이언트에게 보내게 만든다. 그러나
      때때로 요청한 내용이 다른 URL에 있다고 클라이언트에게 알려주어,
      클라이언트가 새로 그 URL을 요청하도록 만드는 것이 좋을 때가
      있다. 이를 <em>리다이렉션(redirection)</em>이라고 하며,
      <directive module="mod_alias">Redirect</directive> 지시어를
      사용한다. 예를 들어, <directive
      module="core">DocumentRoot</directive> 아래 <code>/foo/</code>
      디렉토리의 내용을 새로 <code>/bar/</code> 디렉토리로 옮겼다면
      다음과 같이 클라이언트가 새로운 위치를 요청하도록 한다:</p>
  
  <example>Redirect permanent /foo/
        http://www.example.com/bar/</example>
  
      <p>그러면 <code>www.example.com</code> 서버의 <code>/foo/</code>로
      시작하는 URL-경로는 <code>/foo/</code>를 <code>/bar/</code>로
      바꾼 URL로 리다이렉션된다. 클라이언트를 원래 서버외에 어떤
      다른 서버로도 리다이렉션할 수 있다.</p>
  
      <p>또, 아파치는 더 복잡한 재작성 문제를 위해
      <directive module="mod_alias">RedirectMatch</directive>
      지시어를 제공한다. 예를 들어, 다른 요청은 그대로 두고 사이트
      홈페이지에 대한 요청만을 다른 사이트로 리다이렉션하려면:</p>
  
  <example>RedirectMatch permanent ^/$
        http://www.example.com/startpage.html</example>
  
      <p>임시로 사이트의 모든 페이지를 다른 사이트의 특정 페이지로
      리다이렉션하려면:</p>
  
  <example>RedirectMatch temp .*
        http://othersite.example.com/startpage.html</example>
  </section>
  
  <section id="proxy"><title>역프록시(Reverse Proxy)</title>
  
  <p>아파치는 다른 서버에 있는 문서를 서버의 URL 공간으로 가져올
  수 있다. 이 경우 웹서버가 원격 서버에서 문서를 가져와서
  클라이언트에게 전달하는 프록시 서버와 같이 동작하기때문에 이런
  방법을 <em>역프록시(reverse proxying)</em>라고 한다. 클라이언트의
  입장에서 역프록시 서버가 문서를 보내주는 것처럼 보이므로 일반
  프록시와는 다르다.</p>
  
  <p>아래 설정에서 클라이언트가 <code>/foo/</code>에 있는 문서를
  요청하면, 서버는 <code>internal.example.com</code>의
  <code>/bar/</code> 디렉토리에서 문서를 가져와서 문서가 마치
  서버에 있었던 것처럼 클라이언트에게 보낸다.</p>
  
  <example>
  ProxyPass /foo/ http://internal.example.com/bar/<br />
  ProxyPassReverse /foo/ http://internal.example.com/bar/
  </example>
  
  <p><directive module="mod_proxy">ProxyPass</directive>는 서버가
  적절한 문서를 가져오도록 설정하며, <directive
  module="mod_proxy">ProxyPassReverse</directive> 지시어는
  <code>internal.example.com</code>이 보내는 리다이렉션을 재작성하여
  리다이렉션이 현재 서버의 적절한 디렉토리를 가리키도록 한다.
  그러나 문서 안에 있는 링크는 재작성하지 않음을 주의하라.
  <code>internal.example.com</code>에 대한 절대링크는 클라이언트가
  프록시서버가 아니라 <code>internal.example.com</code>으로 직접
  요청하게 한다.</p>
  </section>
  
  <section id="rewrite"><title>재작성 엔진 (Rewriting Engine)</title>
  
      <p>더 강력한 치환이 필요할때 <module>mod_rewrite</module>의
      재작성 엔진이 도움이 된다. 이 모듈의 지시어는 브라우저 종류나
      클라이언트의 IP 주소 등 요청의 특징을 가지고 어디에 있는
      내용을 서비스할지 결정할 수 있다. 또, mod_rewrite는 요청을
      어떻게 처리할지 결정하기위해 외부 데이터베이스 파일이나
      프로그램을 사용할 수 있다. 재작성 엔진은 위에서 다룬 세
      종류 대응, 즉, 내부 리다이렉션 (alias), 외부 리다이렉션,
      프록시, 모두를 지원한다. mod_rewrite를 사용하는 실제 예는
      <a href="misc/rewriteguide.html">URL 제작성 지침서</a>에서
      설명한다.</p>
  </section>
  
  <section id="notfound"><title>File Not Found</title>
  
      <p>결국 요청한 URL에 대응하는 파일을 파일시스템에서 찾지
      못한 경우이다. 여러 가지 이유가 있다. 어떤 경우 문서를
      다른 곳으로 옮겼기 때문일 수 있다. 이 경우 클라이언트에게
      <a href="#redirect">URL 리다이렉션</a>으로 자원의 새로운
      위치를 알려주는 방법이 제일 좋다. 그러면 자원을 옮겨도
      오래된 북마크나 링크가 계속 유효하다.</p>
  
      <p>"File Not Found" 오류의 다른 일반적인 원인은 브라우저에
      직접 혹은 HTML 링크에 URL이 잘못 입력된 경우이다. 아파치는
      <module>mod_speling</module> (맞춤법이 틀리지 않았음) 모듈로
      이와 같은 문제를 돕는다. 이 모듈을 사용하면 "File Not Found"
      오류가 발생하는 경우 비슷한 파일명을 가진 자원을 찾는다.
      만약 발견하면 mod_speling은 클라이언트를 올바른 위치로
      HTTP 리다이렉션한다. "비슷한" 파일이 여러개 있다면
      클라이언트에게 목록을 보낸다.</p>
  
      <p>mod_speling의 특히 유용한 장점은 대소문자를 구별하지않고
      파일명을 비교하는 기능이다. 그래서 유닉스 파일시스템과 URL의
      대소문자 성질을 알지못하는 사용자가 있는 시스템에 도움이
      된다. 그러나 mod_speling이 자주 URL을 고쳐야한다면, "잘못된"
      요청때마다 URL 리다이렉션과 클라이언트의 새로운 요청이
      일어나므로 서버에 부담이 된다.</p>
  
      <p>찾는 시도가 모두 실패하면 아파치는 HTTP status code 404
      (file not found) 오류페이지를 보낸다. 이 페이지의 내용은
      <directive module="core">ErrorDocument</directive> 지시어로
      조절하며, <a href="custom-error.html">사용자정의 오류 응답</a>
      문서를 참고하여 사용자정의할 수 있다.</p>
  </section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/style/lang/ko.xml
  
  Index: ko.xml
  ===================================================================
  <?xml version="1.0" encoding="EUC-KR"?>
  <!-- English revision: 1.11 -->
  <!DOCTYPE messages [ <!ENTITY nbsp "&#160;"> ]>
  
  <!--                  -->
  <!-- Language: Korean -->
  <!--                  -->
  
  <!-- Some strings might be used in other contexts, than stated in the -->
  <!-- comments...                                                      -->
  <messages lang="ko">
   <!-- Used for the moduleindex -->
   <message name="corefeatures">핵심 기능과 다중처리 모듈</message>
   <message name="othermodules">다른 모듈</message>
   <message name="obsoletemodules">이전 모듈</message>
  
   <!-- Used for the modulesynopsis and sitemap -->
   <message name="obsoleteapachemodule">이전 아파치 모듈</message>
   <message name="apachemodule">아파치 모듈</message>
   <message name="apachecore">아파치 핵심 기능</message>
   <message name="apachempmcommon">아파치 MPM 공통 지시어</message>
   <message name="apachempm">아파치 MPM</message>
  
   <!-- Used in description box for modulesynopsis -->
   <message name="description">설명</message>
   <message name="seealso">참고</message>
   <message name="topics">주제</message>
   <message name="status">상태</message>
   <message name="moduleidentifier">모듈명</message>
   <message name="sourcefile">소스파일</message>
   <message name="compatibility">지원</message>
  
   <!-- Used in manualpage -->
   <message name="relatedmodules">관련된 모듈</message>
   <message name="relateddirectives">관련된 지시어</message>
  
   <!-- Used in description box for directives -->
   <message name="syntax">문법</message>
   <message name="default">기본값</message>
   <message name="context">사용장소</message>
   <message name="override">Override 옵션</message>
   <message name="status">상태</message>
   <message name="module">모듈</message>
  
   <!-- Used in directive context lists -->
   <message name="serverconfig">주서버설정</message>
   <message name="virtualhost">가상호스트</message>
   <message name="directory">directory</message>
   <message name="htaccess">.htaccess</message>
  
   <!-- Used for directive lists -->
   <message name="directives">지시어들</message>
   <!-- the optional attribute replace-space-with takes a string.
        if present, the space between <directive name> and 'Directive'
        in directivesynopsis headings will be replaced by the given string.
        (see de.xml for an example) -->
   <message name="directive">지시어</message>
   <message name="nodirectives">이 모듈에는 지시어가 없습니다.</message>
  
   <!-- Used in summaries -->
   <message name="summary">요약</message>
  
   <!-- Used for translation notes -->
   <message name="transnote">역주;</message>
  
   <!-- Used in headers and footers -->
   <message name="apachetitle">- Apache HTTP Server</message>
   <message name="apachehttpserver">Apache HTTP Server Version 2.1</message>
   <message name="apachedocalt">[APACHE DOCUMENTATION]</message>
   <message name="search">Google 검색</message> <!-- search button -->
   <message name="index">Index</message> <!-- deprecated -->
   <message name="home">Home</message> <!-- deprecated -->
  
   <!-- breadcrumb links -->
   <message name="apache">Apache</message>
   <message name="http-server">HTTP Server</message>
   <message name="documentation">Documentation</message>
   <message name="version">Version 2.1</message>
  
   <!-- super menu -->
   <message name="modules">모듈</message>
   <message name="faq">FAQ</message>
   <message name="glossary">용어</message>
   <message name="sitemap">사이트맵</message>
  
   <!-- footer line -->
   <message name="maintainedby">Maintained by the</message>
   <message name="langavail">가능한 언어</message>
  </messages>
  
  
  
  1.1                  httpd-2.0/docs/manual/vhosts/details.xml.ko
  
  Index: details.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
  <!-- English revision: 1.4 -->
  
  <manualpage metafile="details.xml.meta">
  <parentdocument href="./">가상호스트</parentdocument>
     <title>가상호스트 찾기에 대한 자세한 설명</title>
  
  <summary>
  
      <p>가상호스트 코드는 <strong>아파치 1.3</strong>에서 거의 다시
      작성되었다. 이 문서는 아파치가 요청을 받으면 어떤 가상호스트가
      서비스할지 결정하는 방법을 설명한다. 새로운 <directive
      module="core">NameVirtualHost</directive> 지시어를 사용하여
      가상호스트 설정이 1.3 버전 이전보다 더 쉽고 안전해졌다.</p>
  
      <p>어떻게 동작하는지 이해하지않고 단지 <cite>동작하게만</cite>
      하고 싶다면, <a href="examples.html">예제들</a>을 참고하라.</p>
  
  </summary>
  
  <section id="configparsing"><title>설정파일 읽기</title>
  
      <p><code>&lt;VirtualHost&gt;</code> 설정을 제외한 설정이
      <em>주서버</em>를 만든다. <directive type="section"
      module="core">VirtualHost</directive> 섹션으로 정의한
      부분을 가상호스트라고 부른다.</p>
  
      <p><directive module="mpm_common">Listen</directive>,
      <directive module="core">ServerName</directive>,
      <directive module="core">ServerPath</directive>,
      <directive module="core">ServerAlias</directive> 지시어는
      서버 정의 어느곳에서도 사용할 수 있다. 그러나 같은 지시어가
      여러번 나오면 (그 서버에서) 마지막 지시어만이 유효하다.</p>
  
      <p>주서버 <code>Listen</code>의 기본값은 80이다. 주서버의
      <code>ServerPath</code>나 <code>ServerAlias</code>에는
      기본값은 없다. <code>ServerName</code>의 기본값은 서버의
      IP 주소이다.</p>
  
      <p>주서버의 Listen 지시어는 두가지 기능을 한다. 첫째는
      아파치가 연결할 기본 네트웍 포트를 지정하는 일이다. 둘째는
      리다이렉션할 절대 URI에 사용할 포트 번호를 지정하는 일이다.</p>
  
      <p>주서버와 달리 가상호스트의 포트는 아파치가 연결을 기다리는
      포트에 영향을 주지 <em>않는다</em>.</p>
  
      <p><code>VirtualHost</code> 지시어에 포트를 지정할 수 있다.
      포트를 지정하지않으면 주서버의 가장 최근 <code>Listen</code>
      값을 사용한다. 특별한 포트 <code>*</code>는 어떤 포트라도
      지칭하는 와일드카드이다. (DNS 검색 결과의 여러 <code>A</code>
      레코드를 포함하여) 가상호스트의 주소를 모두 총칭하여 가상호스트의
      <em>주소집합(address set)</em>이라고 부른다.</p>
  
      <p>특정 IP 주소에 대한 <directive
      module="core">NameVirtualHost</directive> 지시어가 없다면
      그 주소를 포함하는 첫번째 가상호스트를 IP기반 가상호스트로 취급한다.
      IP 주소에 와일드카드 <code>*</code>를 사용할 수도 있다.</p>
  
      <p>이름기반 가상호스트를 사용한다면 이름기반 가상호스트에
      사용할 IP 주소를 <code>NameVirtualHost</code> 지시어에
      사용해야 <em>한다</em>. 즉, 설정파일의 <code>NameVirtualHost</code>
      지시어에 이름기반 가상호스트의 호스트별명(CNAME)에 해당하는
      IP 주소를 지정해야 한다.</p>
  
      <p>특정 IP:포트 쌍에 대해 오직 한 <code>NameVirtualHost</code>
      지시어만을 사용한다면, 여러 <code>NameVirtualHost</code> 지시어와
      <code>VirtualHost</code> 지시어를 섞어서 사용할 수 있다.</p>
  
      <p><code>NameVirtualHost</code>와 <code>VirtualHost</code>
      지시어의 순서는 중요하지 않기때문에 다음 두 예는 같다 (오직
      <em>한</em> 주소집합에 대한 <code>VirtualHost</code>의
      순서가 중요하다. 아래 참고):</p>
  
  <table><tr>
  <td><example>
    NameVirtualHost 111.22.33.44<br />
    &lt;VirtualHost 111.22.33.44&gt;<br />
    # 서버 A<br />
    ...<br />
    &lt;/VirtualHost&gt;<br />
    &lt;VirtualHost 111.22.33.44&gt;<br />
    # 서버 B<br />
    ...<br />
    &lt;/VirtualHost&gt;<br />
    <br />
    NameVirtualHost 111.22.33.55<br />
    &lt;VirtualHost 111.22.33.55&gt;<br />
    # 서버 C<br />
    ...<br />
    &lt;/VirtualHost&gt;<br />
    &lt;VirtualHost 111.22.33.55&gt;<br />
    # 서버 D<br />
    ...<br />
    &lt;/VirtualHost&gt;
  </example></td>
  <td><example>
    &lt;VirtualHost 111.22.33.44&gt;<br />
    # 서버 A<br />
    &lt;/VirtualHost&gt;<br />
    &lt;VirtualHost 111.22.33.55&gt;<br />
    # 서버 C<br />
    ...<br />
    &lt;/VirtualHost&gt;<br />
    &lt;VirtualHost 111.22.33.44&gt;<br />
    # 서버 B<br />
    ...<br />
    &lt;/VirtualHost&gt;<br />
    &lt;VirtualHost 111.22.33.55&gt;<br />
    # 서버 D<br />
    ...<br />
    &lt;/VirtualHost&gt;<br />
    <br />
    NameVirtualHost 111.22.33.44<br />
    NameVirtualHost 111.22.33.55<br />
    <br />
  </example></td>
  </tr></table>
  
  
      <p>(왼쪽 설정이 더 읽기 편하다.)</p>
  
      <p><code>VirtualHost</code> 지시어를 읽을 다음, 가상호스트
      서버는 <code>VirtualHost</code> 지시어에 지정한 포트를 기본
      <code>Listen</code>으로 한다.</p>
  
      <p><code>VirtualHost</code> 지시어의 이름이 모두 같은
      주소집합에 속한다면 <code>ServerAlias</code>와 같이 취급한다
      (그러나 다른 <code>ServerAlias</code>의 영향을 받지 않는다).
      가상호스트에 추가로 사용한 <code>Listen</code>은 주소집합이
      지정한 포트에 영향을 주지 않음을 주의하라.</p>
  
      <p>시작할때 IP 주소 목록을 만들어 해쉬테이블에 추가한다.
      <code>NameVirtualHost</code> 지시어에 IP 주소를 사용하면
      목록은 그 IP 주소에 대한 모든 이름기반 가상호스트를 포함한다.
      그 주소에 대한 가상호스트가 없다면 <code>NameVirtualHost</code>
      지시어를 무시하고 로그에 오류를 기록한다. IP기반 가상호스트는
      해쉬테이블에 목록을 추가하지 않는다.</p>
  
      <p>빠른 해쉬함수를 사용하기때문에 요청시 IP 주소를 해싱하는
      부담은 거의 없다. 또 해쉬테이블은 IP 주소의 마지막 부분의
      차이에 최적화되있다.</p>
  
      <p>가상호스트에 여러 기본값이 설정된다. 특히:</p>
  
      <ol>
        <li>가상호스트에 <directive module="core">ServerAdmin</directive>,
        <directive module="core">ResourceConfig</directive>,
        <directive module="core">AccessConfig</directive>,
        <directive module="core">Timeout</directive>,
        <directive module="core">KeepAliveTimeout</directive>,
        <directive module="core">KeepAlive</directive>,
        <directive module="core">MaxKeepAliveRequests</directive>,
        <directive module="core">SendBufferSize</directive>
        지시어가 없다면 주서버에서 해당 값을 가져온다. (즉,
        주서버의 설정값을 사용한다.)</li>
  
        <li>가상호스트의 디렉토리 기본권한을 정의하는 "참조
        기본값(lookup defaults)"은 주서버의 설정과 합쳐진다.
        모듈의 디렉토리당 설정(per-directory configuration)도
        여기에 해당된다.</li>
  
        <li>각 모듈의 서버당 설정(per-server config)은 주서버의
        설정과 가상호스트의 설정을 합친다.</li>
      </ol>
  
      <p>기본적으로 주서버는 가상호스트를 만드는 "기본" 혹은 "기반"이
      된다. 그러나 설정파일에서 주서버를 정의하는 위치는 관계없다.
      마지막으로 설정을 합치기 전에 주서버의 모든 설정을 읽어들인다.
      그래서 주서버 정의가 가상호스트 정의 뒤에 나와도 가상호스트
      정의에 영향을 준다.</p>
  
      <p>주서버에 <code>ServerName</code>이 없다면 웹서버를 실행하는
      컴퓨터의 호스트명을 대신 사용한다. 주서버의
      <code>ServerName</code>을 DNS 겁색하여 얻은 IP 주소들을
      <em>주서버 주소집합</em>이라고 부른다.</p>
  
      <p>이름기반 가상호스트의 <code>ServerName</code>을 정의하지
      않으면 가상호스트를 정의하는 <code>VirtualHost</code>에서
      처음으로 나온 주소를 기본값으로 사용한다.</p>
  
      <p>특별한 <code>_default_</code> 와일트카드를 포함하는
      가상호스트는 주서버와 같은 <code>ServerName</code>을 가진다.</p>
  
  </section>
  
  <section id="hostmatching"><title>가상호스트 찾기</title>
  
      <p>서버는 아래와 같은 방법으로 어떤 가상호스트가 요청을
      처리할지 결정한다:</p>
  
      <section id="hashtable"><title>해쉬테이블 찾기</title>
  
      <p>클라이언트가 처음 연결하면 연결한 IP 주소를 내부 IP
      해쉬테이블에서 찾는다.</p>
  
      <p>IP 주소를 찾을 수 없고 클라이언트가 요청을 보낸 포트에
      해당하는 가상호스트가 있다면, <code>_default_</code> 가상호스트가
      요청을 서비스한다. <code>_default_</code> 가상호스트가
      없다면 주서버가 요청을 서비스한다.</p>
  
      <p>해쉬테이블에 IP 주소가 없지만 포트 번호가
      <code>NameVirtualHost *</code>에 해당할 수 있다. 이 경우
      이름기반 가상호스트처럼 처리한다.</p>
  
      <p>찾았다면 (목록에서 IP 주소에 해당하는 항목을 찾으면),
      IP기반 가상호스트인지 이름기반 가상호스트인지 결정한다.</p>
  
      </section>
  
      <section id="ipbased"><title>IP기반 가상호스트</title>
  
      <p>찾은 항목에 이름 목록이 없다면 IP기반 가상호스트이다.
      더 이상 작업이 필요없고, 그 가상호스트가 요청을 처리한다.</p>
  
      </section>
  
      <section id="namebased"><title>이름기반 가상호스트</title>
  
      <p>이름 목록에 한개 이상의 가상호스트 구조가 포함되면
      이름기반 가상호스트이다. 이 목록에서 가상호스트들은 설정파일의
      <code>VirtualHost</code> 순서대로 위치한다.</p>
  
      <p>목록에서 첫번째 가상호스트(설정파일에서 해당 IP 주소를
      포함하는 첫번째 가상호스트)는 가장 높은 우선순위를 가지며,
      서버명을 알 수 없거나 <code>Host:</code> 헤더가 없는 요청을
      처리한다.</p>
  
      <p>클라이언트가 <code>Host:</code> 헤더를 주면, 목록에서
      첫번째로 <code>ServerName</code>이나
      <code>ServerAlias</code>가 대응하는 가상호스트가 요청을
      서비스한다. <code>Host:</code> 헤더에 포트 번호가 나올 수
      있지만, 아파치는 항상 클라이언트가 요청을 보낸 실제 포트를
      찾는다.</p>
  
      <p>클라이언트가 <code>Host:</code> 헤더없이 HTTP/1.0 요청을
      하면 클라이언트가 어떤 서버에 연결하려는지 알 수 없기때문에
      요청의 URI에 해당하는 <code>ServerPath</code>가 있는지 찾는다.
      목록에서 제일 먼저 찾은 경로를 사용하고, 그 가상호스트가
      요청을 서비스한다.</p>
  
      <p>대응하는 가상호스트를 찾을 수 없다면, (이미 앞에 말했듯이)
      클라이언트가 연결한 IP에 대한 목록에서 일치하는 포트 번호를
      포함하는 첫번째 가상호스트가 요청을 서비스한다.</p>
  
      </section>
  
      <section id="persistent"><title>지속 연결</title>
  
      <p>IP는 위에서 설명한데로 특정 TCP/IP 세션당 <em>한번만</em>
      찾지만, 이름은 KeepAlive/지속 연결동안 <em>매</em> 요청때마다
      찾는다. 즉, 클라이언트는 지속 연결동안 여러 이름기반
      가상호스트의 페이지를 요청할 수 있다.</p>
  
      </section>
  
      <section id="absoluteURI"><title>절대 URI</title>
  
      <p>요청의 URI가 절대 URI이고 클라이언트가 보낸 요청의
      호스트명과 포트가 주서버나 특정 가상호스트에 해당하면,
      그 주서버 혹은 가상호스트는 URI 앞의 스킴/호스트명/포트
      부분을 제외한 나머지 상대 URI를 서비스한다. 해당하는
      주서버나 가상호스트가 없다면 URI를 그대로 두고 요청을
      프록시 요청으로 처리한다.</p>
  </section>
  
  <section id="observations"><title>주의</title>
  
      <ul>
        <li>이름기반 가상호스트와 IP기반 가상호스트는 서로에게
       영향을 주지 않는다. IP기반 가상호스트를 자신의 이름집합
       IP 주소외에 어떤 주소로도 접근할 수 없다. 이름기반
       가상호스트도 마찬가지다. 이름기반 가상호스트는
       <code>NameVirtualHost</code> 지시어로 정의한 주소집합의
       IP 주소를 통해서만 접근할 수 있다.</li>
  
        <li>IP기반 가상호스트는 <code>ServerAlias</code>와
        <code>ServerPath</code>를 절대로 검사하지 않는다.</li>
  
        <li>설정파일에서 이름기반 가상호스트, IP기반 가상호스트,
        <code>_default_</code> 가상호스트, <code>NameVirtualHost</code>
        지시어의 순서는 중요하지 않다. 특정 주소집합에 대한
        이름기반 가상호스트들의 순서만이 중요하다. 설정파일에서
        앞에 나오는 이름기반 가상호스트는 자신이 속한 주소집합에서
        가장 높은 우선순위를 가진다.</li>
  
        <li>보안을 위해 <code>Host:</code> 헤더에 포함된 포트
        번호는 절대로 사용하지 않는다. 아파치는 항상 클라이언트가
        요청을 보낸 실제 포트를 사용한다.</li>
  
        <li>(둘 사이를 구별할 <code>Host:</code> 헤더가 없다고
        가정하면,) <code>ServerPath</code> 지시어가 설정파일에서
        뒤에 나오는 다른 <code>ServerPath</code> 지시어의 앞부분을
        지칭하는 경우 항상 앞에 나온 지시어를 사용한다.</li>
  
        <li>두 IP기반 가상호스트가 같은 주소를 가지면, 항상
        설정파일에서 앞에 나오는 가상호스트를 사용한다. 이런 일은
        아무도 모르게 일어날 수 있다. 서버가 이런 상황을 발견하면
        오류 로그파일에 경고를 기록한다.</li>
  
        <li><code>_default_</code> 가상호스트는 요청의 IP 주소<em>와</em>
        포트 번호에 해당하는 가상호스트가 없을때만 요청을 처리한다.
        클라이언트가 요청을 보낸 포트 번호가 <code>_default_</code>
        가상호스트의 포트 번호(기본값은 <code>Listen</code>)와
        같을때만 요청을 처리한다. 어떤 포트의 요청이라도 잡기위해
        (<em>예를 들어</em>, <code>_default_:*</code>) 와일드카드
        포트를 사용할 수 있다. <code>NameVirtualHost *</code>
        가상호스트도 마찬가지다.</li>
  
        <li>주서버는 클라이언트가 연결한 IP 주소와 포트 번호에
        해당하는 (<code>_default_</code> 가상호스트를 포함하여)
        가상호스트가 없을때만 요청을 서비스한다. 즉, 주서버는
        (그 포트에 해당하는 <code>_default_</code> 가상호스트가
        없다면) 지정하지않은 주소/포트 쌍에 대한 요청만을 처리한다.</li>
  
        <li>클라이언트가 (<em>예를 들어</em>, <code>NameVirtualHost</code>
        지시어에서) 이름기반 가상호스트 주소(와 포트)에 연결한
        경우 <code>Host:</code> 헤더를 알 수 없거나 헤더가 없는
        요청을 보내면 요청은 <em>절대로</em> <code>_default_</code>
        가상호스트나 주서버에서 처리하지 않는다.</li>
  
        <li>시작할때 서버가 DNS를 의존하지 않으려면 절대로
        <code>VirtualHost</code> 지시어에 DNS 이름을 사용하지마라.
        게다가 열거한 모든 도메인의 DNS를 통제하지 않는다면
        보안상 위험도 있다. 이에 대한 <a
        href="../dns-caveats.html">정보</a>가 있다.</li>
  
        <li>각 가상호스트마다 <code>ServerName</code>를 항상
        정의해야 한다. 안그러면 가상호스트마다 DNS를 찾게 된다.</li>
        </ul>
        </section>
  
  </section>
  
  <section id="tips"><title>팁</title>
  
      <p><a href="../dns-caveats.html#tips">DNS 문제</a> 페이지의
      팁에 추가로 아래에 팁이 있다:</p>
  
      <ul>
        <li>모든 주서버 정의를 <code>VirtualHost</code> 정의 앞에
        두어라. (그러면 설정을 읽기 편하다. 안그러면 나중에 설정이
        합쳐질때 가상호스트들 사이에 섞인 정의가 모든 가상호스트에
        영향을 줄 수 있기때문에 혼란스럽다.)</li>
  
        <li>읽기 편하도록 설정에서 해당하는 <code>NameVirtualHost</code>과
        <code>VirtualHost</code> 정의들을 묶어라.</li>
  
        <li><code>ServerPath</code>가 다른 <code>ServerPath</code>의
        앞부분을 지칭하는 경우를 피하라. 피할 수 없다면 설정파일에서
        앞부분이 더 긴 (더 자세한) 가상호스트를 짧은 (덜 자세한)
        가상호스트보다 앞에 두어라. (<em>예를 들어</em>,
        "ServerPath /abc"는 "ServerPath /abc/def" 다음에 두어야
        한다.</li>
      </ul>
  
  </section>
  </manualpage>
  
  
  
  
  1.1                  httpd-2.0/docs/manual/vhosts/examples.xml.ko
  
  Index: examples.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
  <!-- English revision: 1.4 -->
  
  <manualpage metafile="examples.xml.meta">
  <parentdocument href="./">가상호스트</parentdocument>
      <title>가상호스트 예</title>
  
  <summary>
  
      <p>이 문서는 자주 문의되는 가상호스트
      질문에 답을 하려고 쓰여졌다. 상황은 <a
      href="name-based.html">이름기반</a>이나 <a
      href="ip-based.html">IP기반</a> 가상호스트를 통해 한 서버에서
      여러 웹사이트를 서비스하려는 경우이다. 한 프록시 서버 뒤에서
      여러 서버를 사용하여 사이트를 운영하는 경우를 다룬 문서도
      곧 나올 것이다.</p>
  
  </summary>
  
    <section id="purename"><title>IP 주소 한개에 여러 이름기반
      웹사이트 운영하기.</title>
  
      <p>서버에 IP 주소가 한개 있고, DNS에서 여러 주소(CNAMES)가
      이 컴퓨터를 가리킨다. 이 컴퓨터에서 <code>www.example1.com</code>과
      <code>www.example2.org</code>의 웹서버를 실행하고 싶다.</p>
  
      <note><title>Note</title><p>아파치 서버에 가상호스트 설정을
            한다고 그 호스트명에 대한 DNS 항목이 자동이로 생성되지
            않는다. <em>반드시</em> DNS에 IP 주소를 가리키는
            이름이 있어야 한다. 안그러면 아무도 웹사이트를 볼
            수 없다. 검사해보기 위해 <code>hosts</code> 파일에 항목을
            추가할 수 있지만, 이는 hosts 항목을 가진 컴퓨터에만
            반영된다.</p>
      </note>
  
      <example>
      <title>서버 설정</title>
  
      # 아파치가 포트 80을 기다린다<br />
      Listen 80<br />
      <br />
      # 모든 IP 주소에서 가상호스트 요청을 기다린다<br />
      NameVirtualHost *<br />
      <br />
      &lt;VirtualHost *&gt;<br />
      <indent>
        DocumentRoot /www/example1<br />
        ServerName www.example1.com<br />
        <br />
        # 다른 지시어들도 있다<br />
        <br />
      </indent>
      &lt;/VirtualHost&gt;<br />
      <br />
      &lt;VirtualHost *&gt;<br />
      <indent>
        DocumentRoot /www/example2<br />
        ServerName www.example2.org<br />
        <br />
        # 다른 지시어들도 있다<br />
        <br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p>별표는 모든 주소를 가리키므로, 주서버는 어떤 요청도
      서비스하지 않는다. <code>www.example1.com</code>이
      설정파일에 처음으로 나오므로 가장 높은 우선순위를 가지며,
      <cite>기본</cite>혹은 <cite>초기</cite> 서버가 된다.
      어떤 <code>ServerName</code> 지시어에도 해당되지않는 요청은
      첫번째 <code>VirtualHost</code>가 서비스한다.</p>
  
      <note>
              <title>주의</title>
  
              <p>원한다면 <code>*</code> 대신 시스템의 실제 IP
              주소를 사용할 수 있다. 이 경우
              <code>VirtualHost</code>의 아규먼트는
              <code>NameVirtualHost</code>의 아규먼트와 일치해야
              <em>한다</em>:</p>
  
              <example>
              NameVirtualHost 172.20.30.40<br />
  						<br />
              &lt;VirtualHost 172.20.30.40&gt;<br />
   		        # 생략 ...
              </example>
  
             <p>그러나 ISP에서 동적으로 IP 주소를 가져오는 등
             IP 주소를 모르는 경우에는 <code>*</code>를 사용하는
             것이 유용하다. <code>*</code>는 모든 IP 주소에
             해당하므로, IP 주소가 변경되어도 설정을 변경할
             필요가 없다.</p>
      </note>
  
      <p>거의 대부분의 이름기반 가상호스트 설정은 위와 같다.
      예외는 다른 IP 주소나 포트로 다른 내용을 서비스하려는
      경우이다.</p>
  
  	</section>
  
  	<section id="twoips"><title>여러 IP 주소에서 이름기반
      호스트.</title>
  
    	<note>
  		  <title>주의</title><p>여기서 설명한 방법은 IP 주소가
            몇개라도 적용가능하다.</p>
      </note>
  
      <p>서버는 IP 주소가 두개있다. 하나에서
      (<code>172.20.30.40</code>) "주" 서버
      <code>server.domain.com</code>을 서비스하고, 다른 하나에서
      (<code>172.20.30.50</code>) 여러 가상호스트를 서비스할
      것이다.</p>
  
      <example>
      <title>서버 설정</title>
  
      Listen 80<br />
  		<br />
      # 172.20.30.40에서 실행하는 "주"서버이다<br />
      ServerName server.domain.com<br />
      DocumentRoot /www/mainserver<br />
  		<br />
      # 다른 주소다<br />
      NameVirtualHost 172.20.30.50<br />
  		<br />
      &lt;VirtualHost 172.20.30.50&gt;<br />
      <indent>
          DocumentRoot /www/example1<br />
          ServerName www.example1.com<br />
     			<br />
          # 다른 지시어들도 있다 ...<br />
  				<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.50&gt;<br />
      <indent>
          DocumentRoot /www/example2<br />
          ServerName www.example2.org<br />
  				<br />
          # 다른 지시어들도 있다 ...<br />
  				<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p><code>172.20.30.50</code>이 아닌 주소에 대한 요청은
      주서버가 서비스한다. 호스트명 없이, 즉 <code>Host:</code>
      헤더없이 <code>172.20.30.50</code>로 요청하면
      <code>www.example1.com</code>이 서비스한다.</p>
  
  	</section>
  
  	<section id="intraextra"><title>(내부와 외부 주소와 같이)
      다른 IP 주소로 같은 내용을 서비스하기.</title>
  
      <p>서버 컴퓨터에 IP 주소가 두개 (<code>192.168.1.1</code>과
      <code>172.20.30.40</code>) 있다. 컴퓨터는 내부 (인트라넷)
      네트웍과 외부 (인터넷) 네트웍 사이에 위치한다. 네트웍 밖에서
      <code>server.example.com</code>은 외부 주소를
      (<code>172.20.30.40</code>) 의미하고, 네트웍 내부에서 같은
      이름을 내부 주소로 (<code>192.168.1.1</code>) 사용한다.</p>
  
      <p>서버는 <code>VirtualHost</code> 섹션 한개로 내부와 외부
      응답에 같은 내용을 서비스할 수 있다.</p>
  
      <example>
      <title>서버 설정</title>
  
      NameVirtualHost 192.168.1.1<br />
      NameVirtualHost 172.20.30.40<br />
  		<br />
      &lt;VirtualHost 192.168.1.1 172.20.30.40&gt;<br />
      <indent>
          DocumentRoot /www/server1<br />
          ServerName server.example.com<br />
          ServerAlias server<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p>이제 두 네트웍에서 들어온 요청을 같은
      <code>VirtualHost</code>에서 서비스한다.</p>
  
      <note>
            <title>주의:</title><p>내부 네트웍에서는 완전한 호스트명
            <code>server.example.com</code> 대신 이름
            <code>server</code>도 가능하다.</p>
  
            <p>또한 위의 예에서 IP 주소 대신 <code>*</code>을
            사용하여 서버가 모든 주소에 동일하게 동작할 수
            있다.</p>
      </note>
  
  	</section>
  
  	<section id="port"><title>여러 포트에서 서로 다른 사이트
      운영하기.</title>
  
      <p>같은 IP의 여러 포트에서 서로 다른 도메인을 서비스한다고
      가정하자. 이는 "NameVirtualHost" 태그에 포트를 정의하면
      가능하다. NameVirtualHost name:port없이 &lt;VirtualHost
      name:port&gt;만 혹은 Listen 지시어만 사용하면 안된다.</p>
  
      <example>
      <title>서버 설정</title>
  
      Listen 80<br />
      Listen 8080<br />
  		<br />
      NameVirtualHost 172.20.30.40:80<br />
      NameVirtualHost 172.20.30.40:8080<br />
  		<br />
      &lt;VirtualHost 172.20.30.40:80&gt;<br />
      <indent>
          ServerName www.example1.com<br />
          DocumentRoot /www/domain-80<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40:8080&gt;<br />
      <indent>
          ServerName www.example1.com<br />
          DocumentRoot /www/domain-8080<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40:80&gt;<br />
      <indent>
          ServerName www.example2.org<br />
          DocumentRoot /www/otherdomain-80<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40:8080&gt;<br />
      <indent>
          ServerName www.example2.org<br />
          DocumentRoot /www/otherdomain-8080<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
  	</section>
  
  	<section id="ip"><title>IP기반 가상호스트</title>
  
      <p>서버는 각각 <code>www.example1.com</code>과
      <code>www.example2.org</code>에 해당하는 두 IP 주소를
      (<code>172.20.30.40</code>과 <code>172.20.30.50</code>)
      가진다.</p>
  
      <example>
      <title>서버 설정</title>
  
      Listen 80<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      <indent>
          DocumentRoot /www/example1<br />
          ServerName www.example1.com<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.50&gt;<br />
      <indent>
          DocumentRoot /www/example2<br />
          ServerName www.example2.org<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p><code>&lt;VirtualHost&gt;</code> 지시어로 지정한 주소에
      해당하지않는 주소로 (예를 들어, <code>localhost</code>)
      요청이 들어오면 주서버가 있는 경우 주서버가 서비스한다.</p>
  
  	</section>
  
  	<section id="ipport"><title>포트기반과 ip기반이 혼합된
      가상호스트</title>
  
      <p>서버는 각각 <code>www.example1.com</code>과
      <code>www.example2.org</code>에 해당하는 두 IP 주소를
      (<code>172.20.30.40</code>과 <code>172.20.30.50</code>)
      가진다. 각 IP의 80번과 8080번 포트에 가상호스트를 돌린다.</p>
  
      <example>
      <title>서버 설정</title>
  
      Listen 172.20.30.40:80<br />
      Listen 172.20.30.40:8080<br />
      Listen 172.20.30.50:80<br />
      Listen 172.20.30.50:8080<br />
  		<br />
      &lt;VirtualHost 172.20.30.40:80&gt;<br />
      <indent>
          DocumentRoot /www/example1-80<br />
          ServerName www.example1.com<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40:8080&gt;<br />
      <indent>
          DocumentRoot /www/example1-8080<br />
          ServerName www.example1.com<br />
  		</indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.50:80&gt;<br />
      <indent>
          DocumentRoot /www/example2-80<br />
          ServerName www.example1.org<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.50:8080&gt;<br />
      <indent>
          DocumentRoot /www/example2-8080<br />
          ServerName www.example2.org<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
  	</section>
  
  	<section id="mixed"><title>이름기반과 IP기반이 혼합된
      가상호스트</title>
  
      <p>주소중 몇몇은 이름기반 가상호스트로, 다른 것은 IP기반
      가상호스트로 서비스하고 싶다.</p>
  
      <example>
      <title>서버 설정</title>
  
      Listen 80<br />
  		<br />
      NameVirtualHost 172.20.30.40<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      <indent>
          DocumentRoot /www/example1<br />
          ServerName www.example1.com<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      <indent>
          DocumentRoot /www/example2<br />
          ServerName www.example2.org<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      <indent>
          DocumentRoot /www/example3<br />
          ServerName www.example3.net<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      # IP-기반<br />
      &lt;VirtualHost 172.20.30.50&gt;<br />
      <indent>
          DocumentRoot /www/example4<br />
          ServerName www.example4.edu<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.60&gt;<br />
      <indent>
          DocumentRoot /www/example5<br />
          ServerName www.example5.gov<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
  	</section>
  
  	<section id="default"><title><code>_default_</code> 가상호스트
      사용하기</title>
  
    	<section id="defaultallports"><title>모든 포트에 대한
      <code>_default_</code> 가상호스트</title>
  
      <p>어떤 가상호스트에도 해당하지않은 IP 주소와 포트에 대한
      <em>모든</em> 요청을 처리하기.</p>
  
      <example>
      <title>서버 설정</title>
  
      &lt;VirtualHost _default_:*&gt;<br />
      <indent>
          DocumentRoot /www/default<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p>default(기본) 가상호스트의 포트로 와일드카드를 사용하여 어떤 요청도
      주서버로 못가도록 만든다.</p>
  
      <p>default 가상호스트는 절대로 이름기반 가상호스트가 사용하는
      주소/포트로의 요청을 서비스하지 않는다. 알 수 없거나
      <code>Host:</code> 헤더가 생략된 요청은 항상 최초의 이름기반
      가상호스트(설정파일에서
      주소/포트가 처음으로 나온 가상호스트)가 서비스한다.</p>
  
      <p><directive module="mod_alias">AliasMatch</directive>나
      <directive module="mod_rewrite">RewriteRule</directive>을
      사용하여 어떤 요청을 특정 페이지(혹은 스크립트)로
      재작성할(rewrite) 수 있다.</p>
      </section>
  
      <section id="defaultdifferentports"><title>여러 포트에 대한
      <code>_default_</code> 가상호스트</title>
  
      <p>위의 경우와 같지만, 서버는 여러 포트를 기다리고 80번
      포트에 대해서 추가로 <code>_default_</code> 가상호스트를
      사용하고 싶다.</p>
  
      <example>
      <title>서버 설정</title>
  
      &lt;VirtualHost _default_:80&gt;<br />
      <indent>
          DocumentRoot /www/default80<br />
          # ...<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost _default_:*&gt;<br />
      <indent>
          DocumentRoot /www/default<br />
          # ...<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p>80번 포트에 대한 default 가상호스트는 (<em>반드시</em>
      와일드카드 포트를 가진 기본 가상호스트 이전에 나와야 한다)
      지정하지않은 IP 주소로 보내진 모든 요청을 서비스한다.
      주서버는 절대로 요청을 서비스하지 못한다.</p>
      </section>
  
      <section id="defaultoneport"><title>한 포트에 대한
      <code>_default_</code> 가상호스트</title>
  
      <p>80번 포트에 대해서만 default 가상호스트를 만들고 싶다.</p>
  
      <example>
      <title>서버 설정</title>
  
      &lt;VirtualHost _default_:80&gt;<br />
      DocumentRoot /www/default<br />
      ...<br />
      &lt;/VirtualHost&gt;
      </example>
  
      <p>포트 80번에 지정하지않은 주소에 대한 요청은 기본
      가상호스트가 서비스하고, 다른 지정하지않은 주소와 포트를
      가진 요청은 주 서버가 서비스한다.</p>
      </section>
  
  	</section>
  
  	<section id="migrate"><title>이름기반 가상호스트를 IP기반
      가상호스트로 옮기기</title>
  
      <p>(<a href="#name">이름기반</a>의 첫번째 예에서) 호스트명
      <code>www.example2.org</code>에 대한 이름기반 가상호스트는
      자신의 IP 주소를 가져야 한다. 이름기반 가상호스트의 이전
      IP 주소를 캐싱하는 네임서버나 프록시와의 문제를 피하기위해
      옮기는 동안 둘 모두를 서비스하고 싶다.<br /> 방법은
      <code>VirtualHost</code> 지시어에 새 IP 주소만을
      (<code>172.20.30.50</code>) 추가하면되므로 쉽다.</p>
  
      <example>
      <title>서버 설정</title>
  
      Listen 80<br />
      ServerName www.example1.com<br />
      DocumentRoot /www/example1<br />
  		<br />
      NameVirtualHost 172.20.30.40<br />
  		<br />
      &lt;VirtualHost 172.20.30.40 172.20.30.50&gt;<br />
      <indent>
          DocumentRoot /www/example2<br />
          ServerName www.example2.org<br />
          # ...<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      <indent>
          DocumentRoot /www/example3<br />
          ServerName www.example3.net<br />
          ServerAlias *.example3.net<br />
          # ...<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p>이제 (IP기반 가상호스트를 통한) 새로운 주소와 (이름기반
      가상호스트를 통한) 이전 주소 모두 가상호스트에 접근할
      수 있다.</p>
  
  	</section>
  
  	<section id="serverpath"><title><code>ServerPath</code>
  	지시어 사용하기</title>
  
      <p>두 이름기반 가상호스트를 가진 서버가 있다. 올바른
      가상호스트를 선택하기위해 클라이언트는 올바른
      <code>Host:</code> 헤더를 보내야 한다. 오래된 HTTP/1.0
      클라이언트가 이 헤더를 보내지 못하면 아파치는 클라이언트가
      어떤 가상호스트를 보려고하는지 알 수 없다 (그래서 최초의
      가상호스트가 요청을 서비스한다). 오래된 브라우저와 가능한 호환을
      유지하기위해 최초의 가상호스트를 만들고, 여기에 이름기반
      가상호스트의 URL 접두사를 포함하는 링크 목록 페이지를
      둔다.</p>
  
      <example>
      <title>서버 설정</title>
  
      NameVirtualHost 172.20.30.40<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      <indent>
          # primary vhost<br />
          DocumentRoot /www/subdomain<br />
          RewriteEngine On<br />
          RewriteRule ^/.* /www/subdomain/index.html<br />
          # ...<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      DocumentRoot /www/subdomain/sub1<br />
      <indent>
          ServerName www.sub1.domain.tld<br />
          ServerPath /sub1/<br />
          RewriteEngine On<br />
          RewriteRule ^(/sub1/.*) /www/subdomain$1<br />
          # ...<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost 172.20.30.40&gt;<br />
      <indent>
          DocumentRoot /www/subdomain/sub2<br />
          ServerName www.sub2.domain.tld<br />
          ServerPath /sub2/<br />
          RewriteEngine On<br />
          RewriteRule ^(/sub2/.*) /www/subdomain$1<br />
          # ...<br />
      </indent>
      &lt;/VirtualHost&gt;
      </example>
  
      <p><directive module="core">ServerPath</directive> 지시어때문에
      URL <code>http://www.sub1.domain.tld/sub1/</code>에 대한
      요청은 <em>항상</em> subl-가상호스트가 서비스한다.<br />
      클라이언트가 올바른 <code>Host:</code> 헤더를 보낸다면,
      URL <code>http://www.sub1.domain.tld/</code>에 대한 요청은
      subl-가상호스트에서만 서비스한다. 만약 <code>Host:</code> 헤더를
      보내지않으면 클라이언트는 최초의 호스트에 있는 정보페이지를
      보게된다.<br /> 여기에 문제가 있음을 주의하라: 클라이언트가
      <code>Host:</code> 헤더를 보내지않으면
      <code>http://www.sub2.domain.tld/sub1/</code>에 대한 요청도
      subl-가상호스트가 서비스한다.<br />
      <directive module="mod_rewrite">RewriteRule</directive>
      지시어를 사용하여 올바른 <code>Host:</code> 헤더를 보내는
      클라이언트는 (<em>예를 들어</em>, URL 전치사가 있거나 없는)
      두 URL을 모두 사용할 수 있다.</p>
  
  	</section>
  
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/vhosts/fd-limits.xml.ko
  
  Index: fd-limits.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
  <!-- English revision: 1.8 -->
  
  <manualpage metafile="fd-limits.xml.meta">
  <parentdocument href="./">가상호스트</parentdocument>
    <title>파일기술자(file descriptor) 한계</title>
  
  <summary>
  
      <p>가상호스트를 많이 사용하고 각 가상호스트에 서로 다른
      로그파일을 지정하면, 아파치가 사용가능한 파일기술자(file
      descriptor, 흔히 <cite>파일핸들(file handle)</cite>이라고
      부름)를 다 써버릴 수 있다. 아파치가 사용하는 파일기술자의
      총 개수는 오류 로그파일당 한개, 다른 로그파일 지시어당
      한개, 추가로 내부용도로 10-20개를 더한 수다. 유닉스 운영체제는
      프로세스가 사용할 수 있는 파일기술자 개수를 제한한다. 이 한계는
      보통 64개로, 보통 이보다 큰 hard-limit까지 늘릴 수 있다.</p>
  
      <p>아파치는 이 한계를 필요한만큼 늘리려고 하지만, 실패하는
      경우가 있다:</p>
  
      <ol>
        <li>시스템이 <code>setrlimit()</code> 시스템호출을
        제공하지 않는다.</li>
  
        <li>(Solaris 2.3과 같이) 시스템에서
        <code>setrlimit(RLIMIT_NOFILE)</code> 함수가 동작하지
        않는다.</li>
  
        <li>필요한 파일기술자 개수가 hard limit 보다 많다.</li>
        
        <li>(Solaris 2) 시스템이 stdio 스트림을 256이하의
        파일기술자만을 사용하도록 제한하는 등 파일기술자에
        제약을 가한다.</li>
      </ol>
  
  	<p>이 경우 해결책은:</p>
  
      <ul>
        <li>로그파일 개수를 줄인다. <directive type="section"
        module="core">VirtualHost</directive> 섹션에서 로그파일을
        지정하지 않고 주 로그파일을 사용한다. (더 자세한 방법은
        아래 <a href="#splitlogs">로그파일 나누기</a>를 참고하라.)</li>
  
        <li>
          사용하는 시스템이 (위의) 1번째나 2번째 경우에 해당한다면,
          다음과 같은 스크립트로 아파치를 시작하기 전에 파일기술자
          한계를 늘린다.
  
          <example>
            <code>#!/bin/sh<br />
             ulimit -S -n 100<br />
             exec httpd</code>
          </example>
        </li>
      </ul>
  
  </summary>
  
  <section id="splitlogs"><title>로그파일 나누기</title>
  
  <p>여러 가상호스트가 같은 로그파일을 사용한다면 나중에 각
  가상호스트의 통계분석을 위해 로그파일을 나누고 싶을 것이다.
  이 작업은 다음과 같이 할 수 있다.</p>
  
  <p>먼저 로그 항목에 가상호스트 정보를 추가한다. 이를 위해
  <directive module="mod_log_config">LogFormat</directive>
  지시어와 <code>%v</code> 변수를 사용한다. 이 변수를 로그
  형식문자열 앞에 추가한다:</p>
  
  <example>
  LogFormat "%v %h %l %u %t \"%r\" %&gt;s %b" vhost<br />
  CustomLog logs/multiple_vhost_log vhost
  </example>
  
  <p>그러면 common 로그형식 앞에 (<directive
  module="core">ServerName</directive> 지시어에 나오는) 정규
  가상호스트를 포함하여 로그파일을 기록한다. (로그파일
  사용자정의에 관한 내용은 <directive
  module="mod_log_config">사용자정의 로그형식</directive>을
  참고하라.)</p>
  
  <p>로그파일을 (가상호스트당 한 파일씩) 나누고 싶다면 <code><a
  href="../programs/other.html">split-logfile</a></code> 프로그램을
  사용한다. 이 프로그램은 아파치 배포본의 <code>support</code>
  디렉토리에 있다.</p>
  
  <p>다음과 같이 프로그램을 실행한다:</p>
  
  <example>
  split-logfile &lt; /logs/multiple_vhost_log
  </example>
  
  <p>가상호스트 로그파일을 가지고 이 프로그램을 실행하면 로그파일에
  나오는 각 가상호스트당 파일을 하나씩 만든다. 각각의 파일명은
  <code>hostname.log</code>이다.</p>
  
  </section>
  </manualpage>
  
  
  
  
  1.1                  httpd-2.0/docs/manual/vhosts/index.xml.ko
  
  Index: index.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
  <!-- English revision: 1.10 -->
  
  <manualpage metafile="index.xml.meta">
  
     <title>아파치 가상호스트 문서</title>
  
  <summary>
  
      <p><cite>가상호스트 (Virtual Host)</cite>는 한 컴퓨터에서
      여러 웹사이트를 (예를 들어, <code>www.company1.com</code>과
      <code>www.company2.com</code>) 서비스함을 뜻한다.
      가상호스트에는 각 웹사이트마다 다른 IP 주소를 사용하는
      "<a href="ip-based.html">IP기반 (IP-based)</a>" 방식과 한
      IP 주소당 여러 이름을 가지는 "<a
      href="name-based.html">이름기반 (name-based)</a>" 방식이
      있다. 여러 사이트들이 같은 서버에서 돌고있다는 사실을 웹사용자는
      눈치채지 못한다.</p>
  
      <p>아파치는 기본으로 IP기반 가상호스트를 지원한 초창기
      서버들중 하나다. 아파치 버전 1.1 이상은 IP기반과 이름기반
      가상호스트를 모두 지원한다. 이름기반 가상호스트를
      <em>호스트기반 (host-based)</em> 또는 <em>비IP 가상호스트
      (non-IP virtual hosts)</em>라고도 부른다.</p>
  
      <p>다음은 아파치 버전 1.3 이상의 가상호스트 지원을 자세히
      설명한 문서들이다.</p>
  
  </summary>
  
  <seealso><module>mod_vhost_alias</module></seealso>
  <seealso><a href="name-based.html">이름기반 가상호스트</a></seealso>
  <seealso><a href="ip-based.html">IP기반 가상호스트</a></seealso>
  <seealso><a href="examples.html">가상호스트 예</a></seealso>
  <seealso><a href="fd-limits.html">파일기술자 한계</a></seealso>
  <seealso><a href="mass.html">대량의 가상호스트</a></seealso>
  <seealso><a href="details.html">가상호스트 찾기에 대한 자세한 설명</a></seealso>
  
  <section id="support"><title>가상호스트 지원</title>
  
      <ul>
        <li><a href="name-based.html">이름기반 가상호스트</a>
        (IP 주소당 여러 웹사이트)</li>
        <li><a href="ip-based.html">IP기반 가상호스트</a> (각
        웹사이트마다 IP 주소)</li>
        <li><a href="examples.html">일반적인 가상호스트 예</a></li>
        <li><a href="fd-limits.html">파일기술자(file descriptor)
        한계</a> (즉, <em>너무 많은 로그파일</em>)</li>
        <li><a href="mass.html">대량의 가상호스트를 동적으로
        설정하기</a></li>
        <li><a href="details.html">가상호스트 찾기에 대한 자세한
        설명</a></li>
      </ul>
  
  </section>
  
  <section id="directives"><title>설정 지시어</title>
  
      <ul>
        <li><directive type="section"
             module="core">VirtualHost</directive></li>
        <li><directive module="core">NameVirtualHost</directive></li>
        <li><directive module="core">ServerName</directive></li>
        <li><directive module="core">ServerAlias</directive></li>
        <li><directive module="core">ServerPath</directive></li>
      </ul>
  
      <p>가상호스트 설정을 테스트할때 아파치의 <code>-S</code>
      명령행 옵션이 유용하다. 즉, 다음과 같이 실행한다:</p>
  
      <example>
      /usr/local/apache2/bin/httpd -S
      </example>
  
      <p>이 명령어는 아파치가 읽은 설정파일에 대한
      정보를 출력한다. IP 주소와 서버명을 자세히 살펴보면 설정에서
      실수를 발견하는데 도움이 될 것이다. (다른 명령행 옵션들은
      <a href="../programs/httpd.html">httpd 프로그램 문서</a>를
      참고하라.)</p>
  
  </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/vhosts/ip-based.xml.ko
  
  Index: ip-based.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
  <!-- English revision: 1.6 -->
  
  <manualpage metafile="ip-based.xml.meta">
  <parentdocument href="./">가상호스트</parentdocument>
     <title>아파치 IP기반 가상호스트 지원</title>
  
  <seealso>
  <a href="name-based.html">이름기반 가상호스트 지원</a>
  </seealso>
  
  <section id="requirements"><title>시스템 요구사항</title>
  
      <p><cite>IP기반</cite>이란 말이 의미하듯이 서버는
      <strong>IP기반 가상호스트 각각에 대해 다른 IP 주소를
      가져야한다</strong>. 이는 컴퓨터를 물리적으로 여러 네트웍에
      연결하거나, 최근 운영체제에서 지원하는 가상 인터페이스를
      (자세한 내용은 시스템 문서를 참고하라. 흔히 "ip aliases"라고
      하며, 보통 "ifconfig" 명령어로 만든다) 사용하여 가능하다.</p>
  
  </section>
  
  <section id="howto"><title>아파치 설정방법</title>
  
      <p>여러 호스트를 지원하도록 아파치를 설정하는 방법은 두가지다.
      하나는 각 호스트마다 별도의 웹서버를 실행하는
      법이고, 다른 하나는 모든 가상호스트를 지원하는 서버 한개를
      실행하는 방법이다.</p>
  
      <p>언제 여러 서버를 사용하나:</p>
  
      <ul>
        <li>회사2의 사용자가 웹이외의 방법으로 회사1의 자료를 읽을
        수 없게 하는 등 보안상 구분이 필요한 경우. 이 경우
        두 서버를 각각 다른 <directive
        module="mpm_common">User</directive>, <directive
        module="mpm_common">Group</directive>, <directive
        module="mpm_common">Listen</directive>, <directive
        module="core">ServerRoot</directive> 설정으로 실행해야 한다.</li>
  
        <li>충분한 메모리가 있고, 컴퓨터의 모든 IP를 기다리기위한
        파일기술자(file descriptor) 요구사항도 만족한다. "와일드카드"나
        특정 주소를 <directive
        module="mpm_common">Listen</directive>할 수만 있다. 그래서
        어떤 이유에서건 특정 주소를 기다릴 필요가 있다면, (한
        웹서버가 한 주소를 제외한 모든 주소를 기다리고 다른 한
        웹서버가 제외한 주소를 기다릴 수 있지만) 지정한 주소
        모두를 기다려야 한다.</li>
      </ul>
  
      <p>언제 서버 한개를 사용하나:</p>
  
      <ul>
        <li>가상호스트들의 웹서버 설정을 공유할 수 있는 경우.</li>
  
        <li>컴퓨터가 매우 많은 요청을 서비스한다면 여러 서버를
        실행하기에 속도 손실이 클 수 있다.</li>
      </ul>
  
  </section>
  
  <section id="multiple"><title>여러 서버를 실행하기</title>
  
      <p>각 가상호스트별로 웹서버를 설치한다. 설정파일의
      <directive module="mpm_common">Listen</directive> 지시어에
      서버가 서비스할 IP 주소(혹은 가상호스트)를 적어준다. 예를
      들면,</p>
  
      <example>
      Listen www.smallco.com:80
      </example>
  
      <p>호스트명 보다는 IP 주소를 사용하길 바란다.
      (<a href="../dns-caveats.html">DNS 문제</a> 참고)</p>
  
  </section>
  
  <section id="single"><title>서버 하나로 가상호스트 실행하기</title>
  
      <p>이 경우 웹서버 한개로 주서버와 모든 가상호스트에 대한
      요청을 서비스한다. 설정파일의 <directive
      module="core">VirtualHost</directive> 지시어에 가상호스트마다
      다른 <directive module="core">ServerAdmin</directive>,
      <directive module="core">ServerName</directive>, <directive
      module="core">DocumentRoot</directive>, <directive
      module="core">ErrorLog</directive>, <directive
      module="mod_log_config">TransferLog</directive>,
      <directive module="mod_log_config">CustomLog</directive>
      지시어 값을 설정한다. 예를 들면,</p>
  
      <example>
      &lt;VirtualHost www.smallco.com&gt;<br />
      ServerAdmin webmaster@mail.smallco.com<br />
      DocumentRoot /groups/smallco/www<br />
      ServerName www.smallco.com<br />
      ErrorLog /groups/smallco/logs/error_log<br />
      TransferLog /groups/smallco/logs/access_log<br />
      &lt;/VirtualHost&gt;<br />
  		<br />
      &lt;VirtualHost www.baygroup.org&gt;<br />
      ServerAdmin webmaster@mail.baygroup.org<br />
      DocumentRoot /groups/baygroup/www<br />
      ServerName www.baygroup.org<br />
      ErrorLog /groups/baygroup/logs/error_log<br />
      TransferLog /groups/baygroup/logs/access_log<br />
      &lt;/VirtualHost&gt;
  		</example>
  
      <p>호스트명 보다는 IP 주소를 사용하길 바란다.
      (<a href="../dns-caveats.html">DNS 문제</a> 참고)</p>
  
      <p>VirtualHost 지시어 안에서는 프로세스 생성과 기타 몇몇 지시어를
      제외하고 거의 <strong>모든</strong> 설정지시어를 사용할
      수 있다. VirtualHost 지시어 안에서 지시어를 사용할 수 있는지
      알려면 <a href="../mod/directives.html">지시어 목록</a>에서
      <a href="../mod/directive-dict.html#Context">사용장소</a>를
      확인하라.</p>
  
      <p><a href="../suexec.html">suEXEC 프로그램</a>을
      사용한다면 VirtualHost 지시어 안에 <directive
      module="mpm_common">User</directive>와 <directive
      module="mpm_common">Group</directive>을 사용할 수 있다.</p>
  
      <p><em>보안:</em> 서버를 실행하는 사용자외에 다른 사람에게
      로그파일이 있는 디렉토리의 쓰기권한이 있다면 보안
      문제를 조심하라. 자세한 내용은 <a
      href="../misc/security_tips.html">보안 팁</a>을 참고하라.</p>
  
  </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/vhosts/mass.xml.ko
  
  Index: mass.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
  <!-- English revision: 1.5 -->
  
  <manualpage metafile="mass.xml.meta">
  <parentdocument href="./">가상호스트</parentdocument>
     <title>대량의 가상호스트를 동적으로 설정하기</title>
  
  <summary>
  
      <p>이 문서는 아파치 1.3에서 대량의 가상호스트를 효율적으로
      서비스하는 방법을 설명한다. <!--
  
                  Written by Tony Finch (fanf@demon.net) (dot@dotat.at).
  
                  Some examples were derived from Ralf S. Engleschall's document
                      http://www.engelschall.com/pw/apache/rewriteguide/
  
                  Some suggestions were made by Brian Behlendorf.
  
                  -->
      </p>
  
  </summary>
  
  <section id="motivation"><title>동기</title>
  
      <p>당신의 <code>httpd.conf</code>에 다음과 같이 서로 비슷한
      <code>&lt;VirtualHost&gt;</code> 섹션들을 많이 있다면 여기서
      설명하는 방법이 도움이 될 것이다:</p>
  
  <example>
  NameVirtualHost 111.22.33.44<br />
  &lt;VirtualHost 111.22.33.44&gt;<br />
  <indent>
      ServerName                 www.customer-1.com<br />
      DocumentRoot        /www/hosts/www.customer-1.com/docs<br />
      ScriptAlias  /cgi-bin/  /www/hosts/www.customer-1.com/cgi-bin<br />
  </indent>
  &lt;/VirtualHost&gt;<br />
  &lt;VirtualHost 111.22.33.44&gt;<br />
  <indent>
      ServerName                 www.customer-2.com<br />
      DocumentRoot        /www/hosts/www.customer-2.com/docs<br />
      ScriptAlias  /cgi-bin/  /www/hosts/www.customer-2.com/cgi-bin<br />
  </indent>
  &lt;/VirtualHost&gt;<br />
  # 바보 바보 바보<br />
  &lt;VirtualHost 111.22.33.44&gt;<br />
  <indent>
      ServerName                 www.customer-N.com<br />
      DocumentRoot        /www/hosts/www.customer-N.com/docs<br />
      ScriptAlias  /cgi-bin/  /www/hosts/www.customer-N.com/cgi-bin<br />
  </indent>
  &lt;/VirtualHost&gt;
  </example>
  
      <p>기본 개념은 정적인 <code>&lt;VirtualHost&gt;</code>
      설정 모두를 동적으로 처리하도록 대체하는 것이다.
      그러면 많은 장점이 있다:</p>
  
      <ol>
        <li>설정파일이 작아져서 아파치가 빨리 시작하고 메모리를
        적게 사용한다.</li>
  
        <li>가상호스트를 추가하기위해 파일시스템에 적당한
        디렉토리를 만들고 DNS에 항목을 추가하기만 하면된다. 즉,
        아파치를 재설정하고 재시작할 필요가 없다.</li>
      </ol>
  
      <p>단점은 각 가상호스트별로 다른 로그파일을 사용할 수 없다는
      점이다. 그러나 매우 많은 가상호스트를 사용한다면 파일기술자를
      다 써버리기때문에 서로 다른 로그파일을 사용할 수 없다. 파이프나
      fifo로 로그를 보내고, 받는 편에서 로그를 처리하여 나누는
      방법이 (통계 등을 모을 수도 있다) 더 낫다.</p>
  
  </section>
  
  <section id="overview"><title>개요</title>
  
      <p>가상호스트는 IP 주소와 HTTP 요청의 <code>Host:</code>
      헤더 정보로 정의한다. 기본적으로 대량의
      동적 가상호스트 기술은 자동으로 가상호스트 정보를 요청의
      파일경로에 포함한다. 이는 대부분 <module>mod_vhost_alias</module>를
      사용하여 쉽게 해결할 수 있지만, 아파치 1.3.6 이하를 사용한다면
      <module>mod_rewrite</module>를 사용해야 한다. 이 두 모듈
      모두 기본적으로 서버에 포함되지 않는다. 이 방법을 사용하려면
      아파치를 구성하고 컴파일할때 포함해야 한다.</p>
  
      <p>동적 가상호스트를 일반적인 가상호스트처럼 보이게하려면
      여러가지를 `속여야' 한다. 가장 중요한 것은 아파치가 자기참조
      URL 등을 만들때 사용할 서버명이다. 서버명은
      <code>ServerName</code> 지시어로 설정하며, CGI에는
      <code>SERVER_NAME</code> 환경변수로 주어진다.  실행중 실제
      서버명은 <directive
      module="core">UseCanonicalName</directive> 설정에 달렸다.
      <code>UseCanonicalName Off</code>이면 요청의 <code>Host:</code>
      헤더 내용이 서버명이 된다. <code>UseCanonicalName DNS</code>이면
      가상호스트의 IP 주소를 역DNS 검색하여 서버명을 알아낸다.
      전자는 이름기반 동적 가상호스트에서 사용하고, 후자는 IP기반
      가상호스트에서 사용한다. <code>Host:</code> 헤더가 없거나
      DNS 검색이 실패하여 아파치가 서버명을 알아내지 못하면
      <code>ServerName</code>으로 설정한 값을 대신 사용한다.</p>
  
      <p>다른 `속일' 것은 (<code>DocumentRoot</code>로 설정하며,
      CGI에는 <code>DOCUMENT_ROOT</code> 환경변수로 주어지는)
      문서루트이다. 일반적인 경우 core 모듈이 이 설정을 사용하여
      URI에 해당하는 파일명을 찾지만, 서버를 동적 가상호스팅을 할때는 다른
      모듈이 (<code>mod_vhost_alias</code>나 <code>mod_rewrite</code>)
      다른 방법으로 이런 작업을 한다. 두 모듈 모두
      <code>DOCUMENT_ROOT</code> 환경변수를 사용하지 않으므로
      CGI나 SSI 문서가 이 값을 사용한다면 잘못된 결과를 얻을 수
      있다.</p>
  
  </section>
  
  <section id="simple"><title>간단한 동적 가상호스트</title>
  
      <p>위 <a href="#motivation">동기</a> 절의 가상호스트
      설정을 <code>mod_vhost_alias</code>를 사용하여 더 일반적으로
      구현했다.</p>
  
  <example>
  # Host: 헤더에서 서버명을 알아낸다<br />
  UseCanonicalName Off<br />
  <br />
  # 첫번째 필드를 사용하여 이 로그를 가상호스트별로 나눌 수 있다<br />
  LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon<br />
  CustomLog logs/access_log vcommon<br />
  <br />
  # 요청을 처리하기위해 파일명에 서버명을 포함한다<br />
  VirtualDocumentRoot /www/hosts/%0/docs<br />
  VirtualScriptAlias  /www/hosts/%0/cgi-bin
  </example>
  
      <p>이 설정에서 <code>UseCanonicalName Off</code>를
      <code>UseCanonicalName DNS</code>로 변경하기만 하면 IP기반
      가상호스트가 된다. 가상호스트의 IP 주소를 가지고
      파일명에 추가할 서버명을 알 수 있다.</p>
  
  </section>
  
  <section id="homepages"><title>가상으로 호스트하는 홈페이지 시스템</title>
  
      <p>ISP 홈페이지 서버를 위해 위의 설정을 수정했다. 조금 더
      복잡한 설정을 사용하면 <code>www.user.isp.com</code>의 문서를
      <code>/home/user/</code>에 두는 식으로 서버명의 일부를 가지고
      파일명을 만들 수 있다. 이 설정은
      <code>cgi-bin</code>을 각 가상호스트가 따로 가지지않고
      모든 가상호스트가 같이 사용한다.</p>
  
  <example>
  # 기본적인 내용은 위와 같다. 그리고<br />
  <br />
  # 파일명에 서버명의 일부를 포함한다<br />
  VirtualDocumentRoot /www/hosts/%2/docs<br />
  <br />
  # 하나의 cgi-bin 디렉토리<br />
  ScriptAlias  /cgi-bin/  /www/std-cgi/<br />
  </example>
  
      <p><module>mod_vhost_alias</module> 문서에는 더 복잡한
      <code>VirtualDocumentRoot</code> 설정의 예가 있다.</p>
  
  </section>
  
  <section id="combinations"><title>한 서버에 여러 가상호스트
      시스템 사용하기</title>
  
      <p>더 복잡한 설정의 예로 아파치의 일반적인
      <code>&lt;VirtualHost&gt;</code> 지시어를 사용하여 여러
      가상호스트 설정의 범위를 조절할 수 있다. 예를 들어, 다음과
      같은 설정은 홈페이지 고객에 IP 주소 한개, 상업적인
      고객에게 다른 IP 주소 한개를 부여한다. 물론 이전처럼
      <code>&lt;VirtualHost&gt;</code> 설정 섹션에 모두 묶을 수도
      있다.</p>
  
  <example>
  UseCanonicalName Off<br />
  <br />
  LogFormat "%V %h %l %u %t \"%r\" %s %b" vcommon<br />
  <br />
  &lt;Directory /www/commercial&gt;<br />
  <indent>
      Options FollowSymLinks<br />
      AllowOverride All<br />
  </indent>
  &lt;/Directory&gt;<br />
  <br />
  &lt;Directory /www/homepages&gt;<br />
  <indent>
      Options FollowSymLinks<br />
      AllowOverride None<br />
  </indent>
  &lt;/Directory&gt;<br />
  <br />
  &lt;VirtualHost 111.22.33.44&gt;<br />
  <indent>
      ServerName www.commercial.isp.com<br />
      <br />
      CustomLog logs/access_log.commercial vcommon<br />
      <br />
      VirtualDocumentRoot /www/commercial/%0/docs<br />
      VirtualScriptAlias  /www/commercial/%0/cgi-bin<br />
  </indent>
  &lt;/VirtualHost&gt;<br />
  <br />
  &lt;VirtualHost 111.22.33.45&gt;<br />
  <indent>
      ServerName www.homepages.isp.com<br />
      <br />
      CustomLog logs/access_log.homepages vcommon<br />
      <br />
      VirtualDocumentRoot /www/homepages/%0/docs<br />
      ScriptAlias         /cgi-bin/ /www/std-cgi/<br />
  </indent>
  &lt;/VirtualHost&gt;
  </example>
  
  </section>
  
  <section id="ipbased"><title>더 효율적인 IP기반 가상호스트</title>
  
      <p><a href="#simple">첫번째 예</a>에서 나는 설정을 간단히
      IP기반 가상호스트로 바꿀 수 있다고 말했다. 불행히도
      그런 설정은 매 요청마다 DNS를 찾아야하므로 매우 비효율적이다.
      이름대신 IP 주소로 파일시스템을 구성하고 같은 방식으로
      로그를 수정하면 문제를 해결할 수 있다. 아파치는 서버명을
      다룰 필요가 없어지고, DNS 검색도 하지 않게 된다.</p>
  
  <example>
  # IP 주소를 역DNS 검색하여 서버명을 알아낸다<br />
  UseCanonicalName DNS<br />
  <br />
  # 로그를 나눌 수 있도록 IP 주소를 포함한다<br />
  LogFormat "%A %h %l %u %t \"%r\" %s %b" vcommon<br />
  CustomLog logs/access_log vcommon<br />
  <br />
  # 파일명에 IP 주소를 포함한다<br />
  VirtualDocumentRootIP /www/hosts/%0/docs<br />
  VirtualScriptAliasIP  /www/hosts/%0/cgi-bin<br />
  </example>
  
  </section>
  
  <section id="oldversion"><title>아파치 이전 버전 사용하기</title>
  
      <p>위 예들은 아파치 버전 1.3.6 이후에 포함된
      <code>mod_vhost_alias</code>을 사용한다.
      <code>mod_vhost_alias</code>가 없는 아파치 버전을 사용한다면
      이미 말했듯이 <code>mod_rewrite</code>를 사용하여, 단
      Host:-헤더기반 가상호스트만을, 구현할 수 있다.</p>
  
      <p>또 로그에 관하여 주의할 점이 있다. 아파치 1.3.6에서
      로그형식 지시어 <code>%V</code>가 포함되었고, 버전 1.3.0
      - 1.3.3에서 이 기능을 <code>%v</code> 옵션이 대신 했다. 그러나
      버전 1.3.4에는 이런 기능이 없다. 어떤 아파치 버전에서도
      <code>.htaccess</code> 파일에서 <code>UseCanonicalName</code>
      지시어를 사용할 수 있으므로 로그에 이상한 내용이 기록될 수 있다.
      그러므로 가장 좋은 방법은 <code>%{Host}i</code> 지시어를
      사용하여 <code>Host:</code> 헤더를 직접 로그에 남기는 것이다.
      또, 이 방법은 <code>%V</code>는 포함하지않는 <code>:port</code>를
      뒤에 추가할 수 있다.</p>
  
  </section>
  
  <section id="simple.rewrite"><title><code>mod_rewrite</code>를
      사용한 간단한 동적 가상호스트</title>
  
      <p>다음은 <a href="#simple">첫번째 예</a>와 같은 일을 하는
      <code>httpd.conf</code> 예이다. 처음 절반은 첫번째 예와
      거의 비슷하지만, 이전 버전과의 호환성과 <code>mod_rewrite</code>의
      적절한 동작을 위해 수정되었다. 나머지 절반은 실제 작업을
      하는 <code>mod_rewrite</code>를 설정한다.</p>
  
      <p>특별히 주의해야 할 사항이 있다. 기본적으로
      <code>mod_rewrite</code>는 (<code>mod_alias</code> 등) 다른
      URI 번역 모듈 이전에 실행된다. 그래서 다른 URI 번역 모듈들과
      같이 동작할 것을 고려하여 <code>mod_rewrite</code>를 설정해야 한다.
      또, 동적 가상호스트에서 <code>ScriptAlias</code>과 같은
      기능을 위해서는 특별한 작업이 필요하다.</p>
  
  <example>
  # Host: 헤더에서 서버명을 얻는다<br />
  UseCanonicalName Off<br />
  <br />
  # splittable logs<br />
  LogFormat "%{Host}i %h %l %u %t \"%r\" %s %b" vcommon<br />
  CustomLog logs/access_log vcommon<br />
  <br />
  &lt;Directory /www/hosts&gt;<br />
  <indent>
      # ScriptAlias 식으로 CGI 실행을 강제할 수 없기때문에<br />
      # 여기에 ExecCGI를 사용한다<br />
      Options FollowSymLinks ExecCGI<br />
  </indent>
  &lt;/Directory&gt;<br />
  <br />
  # 이제 어려운 부분이다<br />
  <br />
  RewriteEngine On<br />
  <br />
  # Host: 헤더에서 가져온 서버명에는 대소문자가 뒤섞여있을 수 있다<br />
  RewriteMap  lowercase  int:tolower<br />
  <br />
  ## 일반 문서를 먼저 처리한다:<br />
  # Alias /icons/ 가 동작하도록 - 다른 alias에 대해서도 반복<br />
  RewriteCond  %{REQUEST_URI}  !^/icons/<br />
  # CGI가 동작하도록<br />
  RewriteCond  %{REQUEST_URI}  !^/cgi-bin/<br />
  # 특별한 작업<br />
  RewriteRule  ^/(.*)$  /www/hosts/${lowercase:%{SERVER_NAME}}/docs/$1<br />
  <br />
  ## 이제 CGI를 처리한다 - MIME type을 강제해야 한다<br />
  RewriteCond  %{REQUEST_URI}  ^/cgi-bin/<br />
  RewriteRule  ^/(.*)$  /www/hosts/${lowercase:%{SERVER_NAME}}/cgi-bin/$1  [T=application/x-httpd-cgi]<br />
  <br />
  # 끝!
  </example>
  
  </section>
  
  <section id="homepages.rewrite"><title><code>mod_rewrite</code>를
      사용한 홈페이지 시스템</title>
  
      <p>다음은 <a href="#homepages">두번째 예</a>와 같은 일을
      한다.</p>
  
  <example>
  RewriteEngine on<br />
  <br />
  RewriteMap   lowercase  int:tolower<br />
  <br />
  # CGI가 동작하도록<br />
  RewriteCond  %{REQUEST_URI}  !^/cgi-bin/<br />
  <br />
  # RewriteRule이 동작하도록 호스트명이 올바른지 검사한다<br />
  RewriteCond  ${lowercase:%{SERVER_NAME}}  ^www\.[a-z-]+\.isp\.com$<br />
  <br />
  # 가상호스트명을 URI 앞에 붙인다<br />
  # [C]는 이 결과를 가지고 다음 재작성을 수행함을 뜻한다<br />
  RewriteRule  ^(.+)  ${lowercase:%{SERVER_NAME}}$1  [C]<br />
  <br />
  # 이제 실제 파일명을 만든다<br />
  RewriteRule  ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2<br />
  <br />
  # 전체 CGI 디렉토리를 정의한다<br />
  ScriptAlias  /cgi-bin/  /www/std-cgi/
  </example>
  
  </section>
  
  <section id="xtra-conf"><title>별도의 가상호스트 설정파일
      사용하기</title>
  
      <p>다음은 <code>mod_rewrite</code>의 고급 기능을 사용하여
      별도의 설정파일을 가지고 가상호스트의 문서루트를 알아낸다.
      더 유연하지만 더 복잡한 설정이 필요하다.</p>
  
      <p><code>vhost.map</code> 파일은 다음과 같다:</p>
  
  <example>
  www.customer-1.com  /www/customers/1<br />
  www.customer-2.com  /www/customers/2<br />
  # ...<br />
  www.customer-N.com  /www/customers/N<br />
  </example>
  
      <p><code>http.conf</code>는 다음과 같다:</p>
  
  <example>
  RewriteEngine on<br />
  <br />
  RewriteMap   lowercase  int:tolower<br />
  <br />
  # 대응파일을 정의한다<br />
  RewriteMap   vhost      txt:/www/conf/vhost.map<br />
  <br />
  # 위와 같이 alias들을 처리한다<br />
  RewriteCond  %{REQUEST_URI}               !^/icons/<br />
  RewriteCond  %{REQUEST_URI}               !^/cgi-bin/<br />
  RewriteCond  ${lowercase:%{SERVER_NAME}}  ^(.+)$<br />
  # 파일 내용을 가지고 찾는다<br />
  RewriteCond  ${vhost:%1}                  ^(/.*)$<br />
  RewriteRule  ^/(.*)$                      %1/docs/$1<br />
  <br />
  RewriteCond  %{REQUEST_URI}               ^/cgi-bin/<br />
  RewriteCond  ${lowercase:%{SERVER_NAME}}  ^(.+)$<br />
  RewriteCond  ${vhost:%1}                  ^(/.*)$<br />
  RewriteRule  ^/(.*)$                      %1/cgi-bin/$1
  </example>
  
  </section>
  </manualpage>
  
  
  
  1.1                  httpd-2.0/docs/manual/vhosts/name-based.xml.ko
  
  Index: name-based.xml.ko
  ===================================================================
  <?xml version='1.0' encoding='EUC-KR' ?>
  <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  <?xml-stylesheet type="text/xsl" href="../style/manual.ko.xsl"?>
  <!-- English revision: 1.8 -->
  
  <manualpage metafile="name-based.xml.meta">
  <parentdocument href="./">가상호스트</parentdocument>
  <title>이름기반 가상호스트 지원</title>
  
  <summary>
  
  	<p>이 문서는 이름기반 가상호스트를 사용하는 경우와 방법을
      설명한다.</p>
  
  </summary>
  
  <seealso><a href="ip-based.html">IP기반 가상호스트 지원</a></seealso>
  <seealso><a href="details.html">가상호스트 찾기에 대한 자세한 설명</a></seealso>
  <seealso><a href="mass.html">대량의 가상호스트를 동적으로 설정하기</a></seealso>
  <seealso><a href="examples.html">일반적인 가상호스트 예</a></seealso>
  <seealso><a href="examples.html#serverpath">ServerPath 설정 예</a></seealso>
  
  <section id="namevip"><title>이름기반 대 IP기반 가상호스트</title>
  
  	<p>IP기반 가상호스트는 연결한 IP 주소를 가지고 서비스할
      가상호스트를 결정한다. 그래서 각 호스트는 서로 다른 IP 주소를
      가져야 한다. 이름기반 가상호스트의 경우 서버는 클라이언트가
      HTTP 헤더로 호스트명을 알려주길 바란다. 이런 방법으로 한
      IP 주소로 여러 다른 호스트를 서비스할 수 있다.</p>
  
  	<p>이름기반 가상호스트는 DNS 서버가 각 호스트명이 올바른
      IP 주소로 대응하도록 가상호스트를 설정하고, 다른 호스트명을 구별할
      수 있도록 아파치 웹서버를 설정하기만 하면되므로 더 간단하다. 이름기반
      가상호스트는 또 여러 IP 주소가 필요없다. 그러므로 특별히
      IP기반 가상호스트를 선택할 이유가 없다면 이름기반 가상호스트를
      사용해야 한다. IP기반 가상호스트를 사용해야할 이유로는:</p>
  
  	<ul>
  		<li>이름기반 가상호스트를 지원하지않는 오래된
          클라이언트들이 있다. 이름기반 가상호스트를 사용하려면
          클라이언트가 HTTP Host 헤더를 보내야 한다. 이는
          HTTP/1.1에서는 필수이고, 최근 모든 HTTP/1.0 브라우저들도
          확장으로 지원한다. 만약 이름기반 가상호스트를 사용하면서
          오래된 클라이언트를 지원해야 한다면 이 문서 끝에 있는
          방법을 살펴봐라.</li>
  
  		<li>SSL 프로토콜의 성격상 SSL 보안서버에서 이름기반
          가상호스트를 사용할 수 없다.</li>
  
  		<li>어떤 운영체제나 네트웍 장치는 다른 IP 주소를 사용하지
          않으면 호스트를 구별하지 못하는 네트웍 사용량(bandwidth)
          관리기술을 사용한다.</li>
  	</ul>
  
  </section>
  
  <section id="using"><title>이름기반 가상호스트 사용하기</title>
  
  <related>
      <modulelist>
      <module>core</module>
      </modulelist>
  
      <directivelist>
  	<directive module="core">DocumentRoot</directive>
  	<directive module="core">NameVirtualHost</directive>
  	<directive module="core">ServerAlias</directive>
  	<directive module="core">ServerName</directive>
  	<directive module="core">ServerPath</directive>
  	<directive module="core">VirtualHost</directive>
      </directivelist>
  </related>
  
  	<p>이름기반 가상호스트를 사용하려면 서버는 연결을 받을
      IP 주소를 (아마 포트도) 정해야 한다. 이는 <directive
      module="core">NameVirtualHost</directive> 지시어로 가능하다.
      일반적으로 서버의 모든 IP 주소를 사용한다면
      <code>NameVirtualHost</code>의 아규먼트로 <code>*</code>를
      사용한다. <code>NameVirtualHost</code> 지시어에 IP 주소를
      적어주었다고 서버가 자동으로 그 IP 주소를 기다리지 않음을
      주의하라. 자세한 내용은 <a href="../bind.html">아파치가
      사용할 주소와 포트 설정하기</a>를 참고하라. 또, 여기서
      지정한 IP 주소는 서버의 네트웍 인터페이스이어야 한다.</p>
  
  	<p>다음 단계는 서비스하려는 호스트별로 <directive
      type="section" module="core">VirtualHost</directive> 블록을
      만드는 일이다. <code>&lt;VirtualHost&gt;</code> 지시어의
      아규먼트는 <code>NameVirtualHost</code> 지시어의 아규먼트(예를
      들어, IP 주소나 모든 주소를 뜻하는 <code>*</code>)와
      같아야 한다. <code>&lt;VirtualHost&gt;</code> 블록 안에는
      최소한 서비스할 호스트를 지정하는 <directive
      module="core">ServerName</directive> 지시어와 호스트의
      내용이 파일시스템 어디에 있는지를 지정하는 <directive
      module="core">DocumentRoot</directive> 지시어가 필요하다.</p>
  
    <note><title>주 호스트가 없어진다</title>
  	기존에 사용하던 웹서버에 가상호스트를 추가한다면 기존에
      사용하던 호스트에 대한 &lt;VirtualHost&gt; 블록도 추가해야
      한다. 이 블록에 포함하는 <code>ServerName</code>과
      <code>DocumentRoot</code>는 전체 <code>ServerName</code>과
      <code>DocumentRoot</code>와 같아야 한다. 설정파일에서 이
      가상호스트를 가장 먼저 적으면 기본 호스트가 된다.
    </note>
  
  	<p>예를 들어 <code>www.domain.tld</code> 도메인을 서비스하고
      있었는데 같은 IP 주소에
      <code>www.otherdomain.tld</code>란 가상호스트를 추가하고
      싶다고 가정하자. <code>httpd.conf</code>에 다음과 같이
      추가하면 된다:</p>
  
  	<example>
      NameVirtualHost *<br />
      <br />
      &lt;VirtualHost *&gt;<br />
      <indent>
      ServerName www.domain.tld<br />
      ServerAlias domain.tld *.domain.tld<br />
      DocumentRoot /www/domain<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
      <br />
      &lt;VirtualHost *&gt;<br />
      <indent>ServerName www.otherdomain.tld<br />
      DocumentRoot /www/otherdomain<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
  	</example>
  
  	<p><code>NameVirtualHost</code>와
      <code>&lt;VirtualHost&gt;</code> 지시어 둘 모두 * 대신
      직접 IP 주소를 지정할 수도 있다. 예를 들어, 이런식으로 한
      IP 주소에 여러 이름기반 가상호스트들을 돌리고, 다른 주소에
      IP기반 혹은 이름기반 가상호스트들을 돌릴 수 있다.</p>
  
  	<p>어떤 서버는 여러 이름으로 접속할 수 있길 바란다. 이는
      &lt;VirtualHost&gt; 섹션 안에 <directive
      module="core">ServerAlias</directive> 지시어를 사용하여
      가능하다. 예를 들어 위의 첫번째 &lt;VirtualHost&gt; 블록에서
      <directive module="core">ServerAlias</directive> 지시어를 사용하면
      열거한 이름으로 같은 웹사이트를 볼 수 있다:</p>
  
  	<example>
      ServerAlias domain.tld *.domain.tld
  	</example>
  
  	<p><code>domain.tld</code> 도메인에 있는 모든 호스트에 대한
      요청을 <code>www.domain.tld</code> 가상호스트가 서비스한다.
      이름을 줄때 와일드카드 문자 *와 ?를 사용할 수 있다. 물론
      <code>ServerName</code>이나 <code>ServerAlias</code>에 이름을
      적어주었다고 끝이 아니다. 먼저 이 이름들이 서버의 IP 주소로
      대응하도록 DNS 서버를 알맞게 설정해야 한다.</p>
  
  	<p>마지막으로 <code>&lt;VirtualHost&gt;</code> 안에 다른
      지시어들을 사용하여 가상호스트를 자세히 설정할 수 있다.
      대부분의 지시어를 사용할 수 있으며, 관련된 가상호스트의 설정만을
      변경한다. 어떤 지시어가 사용가능한지 알려면 지시어의 <a
      href="../mod/directive-dict.html#Context">사용장소</a>를
      확인하라. (<code>&lt;VirtualHost&gt;</code> 안이 아닌)
      <em>주서버설정</em>에서 지정한 설정 지시어는 가상호스트에
      같은 설정 지시어가 없는 경우에만 사용된다.</p>
  
  	<p>요청을 받으면 서버는 먼저 <code>NameVirtualHost</code>에서
      지정한 IP 주소인지 검사한다. 그렇다면 그 IP 주소를
      가진 <code>&lt;VirtualHost&gt;</code> 섹션들에서 요청한
      호스트명과 일치하는 <code>ServerName</code>이나
      <code>ServerAlias</code>를 찾는다. 찾으면 그 설정을 사용한다.
      적절한 가상호스트를 찾지못하면, IP 주소에 해당하는
      <strong>가상호스트들중 첫번째 것</strong>을 사용한다.</p>
  
  	<p>결과적으로 처음에 나온 가상호스트가 <em>기본</em>
      가상호스트가 된다. IP 주소가 <code>NameVirtualHost</code>
      지시어에 해당하면, <em>주서버</em>의 <code>DocumentRoot</code>는
      <strong>절대로</strong> 사용하지 않는다. 특정 가상호스트에
      해당하지않는 요청을 설정하려면
      설정을 <code>&lt;VirtualHost&gt;</code>에 담고 설정파일에서
      먼저 나오도록 하면 된다.</p>
  
  </section>
  
  <section id="compat"><title>오래된 브라우저와 호환</title>
  
      <p>이미 적었듯이 이름기반 가상호스트가 올바로 동작하기위해
      필요한 정보를 보내지않는 클라이언트가 있다. 이런 클라이언트는
      항상 요청한 IP 주소에 대해 첫번째로 나오는 가상호스트
      (<cite>최초의</cite> 이름기반 가상호스트)가
      서비스한다.</p>
  
      <note><title>얼마나 오래된 것을 말하는가?</title>
      여기서 오래되었음은 실제로 상당히 오래된 것을 뜻한다.
      오늘날 이런 브라우저를 사용할 일은 거의없다. 요즘
      브라우저는 모두 이름기반 가상호스트에 필요한 <code>Host</code>
      헤더를 보낸다.
      </note>
  
      <p>이 문제는 약간 거추장스럽지만 <directive
      module="core">ServerPath</directive> 지시어로 해결할 수 있다:</p>
  
      <p>설정 예:</p>
  
      <example>
      NameVirtualHost 111.22.33.44<br />
      <br />
      &lt;VirtualHost 111.22.33.44&gt;<br />
      <indent>
      ServerName www.domain.tld<br />
      ServerPath /domain<br />
      DocumentRoot /web/domain<br />
      </indent>
      &lt;/VirtualHost&gt;<br />
   	  </example>
  
      <p>이게 무슨 뜻인가? "<code>/domain</code>"로 시작하는
      URI에 대한 요청은 가상호스트 <code>www.domain.tld</code>가
      서비스한다.  즉, <code>Host:</code> 헤더를 보내는 클라이언트는
      <code>http://www.domain.tld/</code>만으로도 접근할 수 있지만,
      <code>http://www.domain.tld/domain/</code>으로는 모든
      클라이언트가 페이지에 접근할 수 있다.</p>
  
      <p>이를 위해 최초의 가상호스트에 있는 페이지에
      <code>http://www.domain.tld/domain/</code>으로 가는 링크를
      넣는다. 그리고 가상호스트 페이지에서는 상대링크만을
      사용한다. (예를 들어, "<code>file.html</code>",
      "<code>../icons/image.gif</code>",
      "<code>http://www.domain.tld/domain/misc/file.html</code>"이나
      "<code>/domain/misc/file.html</code>"과 같이 앞에
      <code>/domain/</code>이 붙은 링크)</p>
  
      <p>조금 규칙이 필요하지만 이 규칙을 따르면 대부분의 경우
      요즘 것이나 오래된 것이나 관계없이 모든 브라우저로 페이지를
      볼 수 있다.</p>
  
  </section>
  </manualpage>
  
  
  
  
  

Mime
View raw message