archive-de.com » DE » K » KW-BERLIN.DE

Total: 256

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • 서버와 지원 프로그램 - Apache HTTP Server
    프로그램들이다 목록 httpd 아파치 하이퍼텍스트 전송 프로토콜 서버 apachectl 아파치 웹서버 조절 인터페이스 ab 아파치 웹서버 성능검사 도구 apxs 아파치 확장 도구 APache eXtenSion tool configure 소스 트리를 구성한다 dbmmanage basic authentication에 사용할 DBM 형식의 사용자 인증파일을 만들고 수정한다 htcacheclean 디스크 캐쉬를 청소한다 htdigest digest authentication에 사용할 사용자 인증파일을 만들고 수정한다 htpasswd basic authentication에 사용할 사용자 인증파일을 만들고 수정한다 logresolve 아파치 로그파일의 IP 주소를 호스트명으로 변환한다 rotatelogs 서버를 죽이지않고 아파치

    Original URL path: http://xserve.kw-berlin.de/manual/ko/programs/ (2016-02-16)
    Open archived version from archive


  • 주소와 포트 지정 (Binding) - Apache HTTP Server
    지정할 수도 있다 서버는 열거한 주소와 포트로 요청이 들어오면 응답한다 예를 들어 서버가 80번과 8000번 포트 모두에서 연결을 받도록 하려면 Listen 80 Listen 8000 서버가 지정한 두 인터페이스와 포트에서 연결을 기다리도록 하려면 Listen 192 0 2 1 80 Listen 192 0 2 5 8000 IPv6 주소는 다음과 같이 대괄호로 묶어야 한다 Listen 2001 db8 a00 20ff fea7 ccea 80 IPv6에서 특별히 고려할 점 IPv6를 구현한 플래폼이 늘고 있고 APR이 이들 플래폼 대부분에서 IPv6를 지원하기때문에 아파치는 IPv6 소켓을 할당하여 IPv6로 받은 요청을 처리할 수 있다 아파치 관리자에게 복잡한 부분은 IPv6 소켓이 IPv4 연결과 IPv6 연결을 모두 처리할 수 있느냐는 점이다 대부분의 플래폼에서는 IPv4 대응 mapped IPv6 주소를 사용하여 IPv6 소켓에서 IPv4 연결을 받지만 FreeBSD와 NetBSD와 OpenBSD은 시스템전체 정책때문에 기본적으로 허용하지 않는다 그러나 기본적으로 허용하지않는 시스템이라도 아파치를 위해 특별한 설정 파라미터로 변경할 수 있다 반면 리눅스와 Tru64 같은 일부 플래폼에서 IPv4와 IPv6을 모두 처리하려면 대응 주소를 사용해야만 한다 아파치가 최소한의 소켓을 사용하여 IPv4 연결과 IPv6 연결을 모두 받도록하려면 IPv4 대응 IPv6 주소를 사용하고 configure 옵션 enable v4 mapped 를 지정한다 enable v4 mapped 는 FreeBSD NetBSD OpenBSD를 제외한 모든 플래폼에서 기본값이고 아마도 당신의 아파치도 마찬가지일 것이다 플래폼과 APR의 지원여부와 관계없이 아파치가 IPv4 연결만을 받도록하려면 다음 예제와 같이 모든 Listen 지시어에 IPv4 주소를

    Original URL path: http://xserve.kw-berlin.de/manual/ko/bind.html (2016-02-16)
    Open archived version from archive

  • 설정파일 - Apache HTTP Server
    mime 문서타입을 담은 파일도 읽는다 파일명은 TypesConfig 지시어로 설정하고 기본값은 mime types 이다 설정파일 문법 아파치 설정파일은 한줄에 한 지시어를 사용한다 줄 마지막 문자가 백슬래쉬 이면 지시어가 다음 줄에서 계속됨을 뜻한다 이 경우 백슬래쉬 뒤에 어떤 문자나 공백도 나오면 안된다 설정파일의 지시어는 대소문자를 구별하지 않지만 지시어의 아규먼트는 대소문자를 구별하는 경우가 있다 해쉬문자 로 시작하는 줄은 주석으로 무시한다 주석을 설정 지시어와 같은 줄에 사용할 수 없다 빈줄과 지시어 앞에 나오는 공백은 무시하므로 간결하게 보이도록 지시어를 줄들임할 indent 수 있다 apachectl configtest 나 t 명령행 옵션을 사용하여 아파치를 실행하지 않고도 설정파일의 문법 오류를 검사할 수 있다 모듈 관련된 모듈 관련된 지시어 mod so IfModule LoadModule 아파치는 모듈화된 서버다 이는 매우 기본적인 기능만이 서버 핵심에 포함되있음을 뜻한다 아파치는 모듈 을 읽어들여서 기능을 확장한다 기본적으로 컴파일하면 서버에 base 모듈들이 포함된다 서버를 동적으로 읽어들이는 모듈을 사용할 수 있게 컴파일하였다면 모듈을 따로 컴파일하여 아무때나 LoadModule 지시어로 추가할 수 있다 그렇지 않으면 모듈을 추가하거나 빼기위해 아파치를 다시 컴파일해야 한다 설정 지시어를 IfModule 블록으로 감싸서 특정 모듈이 있는 경우에만 선택적으로 처리할 수 있다 현재 서버에 어떤 모듈이 컴파일되있는지 보려면 l 명령행 옵션을 사용한다 지시어 적용범위 관련된 모듈 관련된 지시어 Directory DirectoryMatch Files FilesMatch Location LocationMatch VirtualHost 주설정파일에 있는 지시어는 서버 전체에 적용된다 지시어가 서버의 일부에만 적용되게 하려면 지시어를 Directory DirectoryMatch Files FilesMatch Location LocationMatch 섹션 안에 두어야한다 이 섹션들은 그들이 감싸는 지시어의 적용범위를 파일시스템이나 URL의 특정 위치로 한정한다 또 서로 겹쳐서 사용할 수 있기때문에 매우 세밀한 설정이 가능하다 아파치는 여러 다른 웹사이트를 동시에 서비스하는 능력이 있다 이를 가상호스트 라고 한다 지시어를 VirtualHost 섹션 안에 두어 특정 웹사이트에만 지시어를 적용할 수 있다 지시어는 대부분 어떤 섹션에 나와도 되지만 어떤 지시어는 특정 장소에서 의미가 없다 예를 들어 프로세스 생성을 조절하는 지시어는 주서버설정 장소에서만 사용할 수 있다 지시어가 어떤 섹션에 위치할 수 있는지 알려면 지시어의 사용장소 를 확인하라 더 자세한 정보는 어떻게 Directory Location Files 섹션이 동작하나 를 참고하라 htaccess 파일

    Original URL path: http://xserve.kw-berlin.de/manual/ko/configuring.html (2016-02-16)
    Open archived version from archive

  • 섹션 설정 - Apache HTTP Server
    어떤 디렉토리에 있는지 관계없이 지정한 이름을 가진 파일에 적용된다 설정파일의 주설정부분에 있는 다음 설정을 예로 들면 장소와 관계없이 private html 이란 이름을 한 파일의 접근을 거부한다 Files private html Order allow deny Deny from all Files 파일시스템의 특정 부분에 있는 파일을 지칭하기위해 Files 와 Directory 섹션을 같이 사용한다 다음 설정을 예로 들면 var web dir1 private html var web dir1 subdir2 private html var web dir1 subdir3 private html 같이 var web dir1 디렉토리 아래에 있는 이름이 private html 인 파일의 접근을 거부한다 Directory var web dir1 Files private html Order allow deny Deny from all Files Directory 웹공간 섹션 Location 지시어와 이에 해당하는 정규표현식을 사용하는 지시어는 반대로 특정 웹공간의 설정을 바꾼다 다음 설정을 예로 들면 private으로 시작하는 URL 경로의 접근이 거부된다 여기에는 http yoursite example com private http yoursite example com private123 http yoursite example com private dir file html 같이 private 문자열로 시작하는 요청이 해당된다 Location private Order Allow Deny Deny from all Location Location 지시어는 파일시스템에 대응할 필요가 없다 다음 예는 어떻게 특정 URL을 mod status 가 제공하는 아파치 내부 핸들러로 대응시키는지를 보여준다 파일시스템에 server status 라는 파일은 필요없다 Location server status SetHandler server status Location 와일드카드와 정규표현식 Directory Files Location 지시어에서 C 표준 파이브러리의 fnmatch 와 같은 쉘에서 사용하는 와일드카드 문자를 사용할 수 있다 문자는 어떤 문자열이라도 나타내고 문자는 어떤 문자 한개를 나타내며 seq 는 seq 중에 한 문자를 나타낸다 어떤 와일드카드도 문자를 나타내지는 못한다 그래서 이 문자는 직접 사용해야 한다 더 유연한 설정이 필요하면 perl호환 정규표현식 을 사용하는 DirectoryMatch FilesMatch LocationMatch 를 사용할 수 있다 그러나 아래 설정의 결합에 관한 절에서 정규표현식 섹션을 사용하면 지시어가 적용되는 방법이 어떻게 변하는지 살펴봐라 모든 사용자 디렉토리 설정을 변경하는 비정규표현식 와일드카드 섹션은 다음과 같다 Directory home public html Options Indexes Directory 정규표현식 섹션을 사용하여 한번에 여러 종류의 그림파일에 대한 접근을 거부할 수 있다 FilesMatch i gif jpe g png Order allow deny Deny from all FilesMatch 무엇을 사용하나 파일시스템 섹션과 웹공간 섹션 중 하나를 선택하는 것은 실제로 매우 쉽다 파일시스템에 있는 객체에 지시어를 적용할때는 항상 Directory 나 Files 를 사용한다 데이타베이스에서 생성한 웹페이지와 같이 파일시스템에 있지 않는 객체에 지시어를 적용할때는 Location 을 사용한다 파일시스템에 있는 객체의 접근을 제한하기위해 Location 을 사용하면 절대 안된다 여러 다른 웹공간 장소 URL 가 같은 파일시스템 장소에 대응될 수 있으므로 걸어둔 제한을 우회할 수 있기 때문이다 다음 설정의 예를 살펴보자 Location dir Order allow deny Deny from all Location 이 설정은 http yoursite example com dir 을 요청한다면 잘 작동한다 그러나 대소문자를 구별하지않는 파일시스템을 사용한다면 어떻게되나 http yoursite example com DIR 을 요청하여 쉽게 제한을 우회할 수 있다 반대로 Directory 지시어는 어떻게 요청하였는지 관계없이 그 장소에서 서비스되는 내용에 적용된다 예외는 파일시스템 링크를 사용하는 경우다 심볼링크를 사용하여 한 디렉토리를 파일시스템의 여러 장소에 둘 수 있다 Directory 지시어는 심볼링크를 따라간다 그러므로 높은 수준의 보안을 위해서는 적절한 Options 지시어를 사용하여 심볼링크를 무시해야 한다 아마도 당신은 대소문자를 구별하는 파일시스템을 사용하므로 이런 일이 일어나지 않는다고 생각할지도 모른다 그러나 다른 방법으로도 여러 웹공간 위치가 한 파일시스템 위치에 대응될 수 있음을 기억하라 그래서 가능하면 항상 파일시스템 섹션을 사용해야 한다 그러나 이 규칙에 예외가 하나 있다 설정 제한을 Location 섹션에 두면 이

    Original URL path: http://xserve.kw-berlin.de/manual/ko/sections.html (2016-02-16)
    Open archived version from archive

  • 내용협상 (Content Negotiation) - Apache HTTP Server
    알고리즘은 아래서 자세히 설명한다 이 알고리즘을 사용하면 아파치는 더 나은 결과를 얻기위해 종종 특정 범위의 품질계수 quality factor 를 조작한다 아파치가 품질계수를 조작하는 방법은 아래서 자세히 설명한다 자연스러운 Transparent 내용협상 은 브라우저가 RFC 2295에 정의된 방법으로 요청할 경우에만 사용한다 이 협상방법은 최적의 변형을 결정할 권한을 브라우저에게 부여한다 그래서 결과는 브라우저의 알고리즘에 달렸다 자연스러운 협상과정중에 브라우저는 아파치에게 RFC 2296에 정의된 원격 변형선택 알고리즘 remote variant selection algorithm 을 요청할 수 있다 협상의 범위 범위 설명 Media Type 브라우저는 Accept 헤더로 선호를 나타낸다 각 항목은 품질계수를 가질 수 있다 변형의 설명도 품질계수를 qs 파라미터 가질 수 있다 Language 브라우저는 Accept Language 헤더로 선호를 나타낸다 각 항목은 품질계수를 가질 수 있다 변형은 여러 언어를 가질 혹은 아무 언어도 없을 수 있다 Encoding 브라우저는 Accept Encoding 헤더로 선호를 나타낸다 각 항목은 품질계수를 가질 수 있다 Charset 브라우저는 Accept Charset 헤더로 선호를 나타낸다 각 항목은 품질계수를 가질 수 있다 변형은 media type의 파라미터로 문자집합을 나타낼 수 있다 아파치 협상 알고리즘 아파치는 브라우저에게 보낼 최적의 변형을 있다면 선택하기위해 아래 알고리즘을 사용한다 이 알고리즘은 변경할 수 없다 다음와 같이 동작한다 먼저 협상의 각 범위에 대해 해당하는 Accept 헤더를 검사하고 각 변형에 품질값을 매긴다 어떤 범위의 Accept 헤더가 받아들이지 않는 변형은 후보에서 제외한다 어떤 변형도 남지않으면 4 단계로 간다 후보에서 하나씩 제외하여 최적의 변형을 찾는다 다음 각 검사는 순서대로 일어난다 각 검사에서 선택되지않은 변형은 제외된다 각 검사후 한 변형만 남으면 이를 최적의 변형으로 선택하고 3 단계로 간다 여러 변형이 남으면 다음 검사를 진행한다 Accept 헤더의 품질계수와 변형의 media type에 대한 품질값을 곱하여 가장 높은 값을 가진 변형을 선택한다 가장 높은 언어 language 품질계수를 가진 변형을 선택한다 Accept Language 헤더에 있다면 나온 언어의 순서 혹은 LanguagePriority 지시어에 있다면 나온 언어의 순서를 가지고 가장 적합한 언어를 가진 변형을 선택한다 가장 높은 text html media type의 버전을 나타내는 level media 파라미터를 가진 변형을 선택한다 Accept Charset 헤더를 가지고 가장 적합한 charset media 파라미터를 가진 변형을 찾는다 헤더가 없다면 ISO 8859 1 문자집합을 가장 선호한다 text media type을 가지지만 명시적으로 특정 문자집합과 연결되지않은 변형은 ISO 8859 1로 가정한다 ISO 8859 1이 아닌 charset media 파라미터를 가진 변형들을 선택한다 그런 변형이 없다면 대신 모든 변형을 선택한다 가장 적합한 인코딩을 가진 변형을 선택한다 user agent에 적합한 인코딩을 가진 변형이 있다면 그 변형만을 선택한다 그렇지않고 인코딩된 변형과 인코딩안된 변형이 같이 있다면 인코딩안됨 변형만을 선택한다 변형이 모두 인코딩되었거나 모두 인코딩안된 경우 모든 변형을 선택한다 content length가 가장 적은 변형을 선택한다 남은 것중 첫번재 변형을 선택한다 이는 type map 파일의 앞에 나왔거나 디렉토리에서 변형을 읽은 경우 파일명을 ASCII 코드 순서로 하여 앞에 나오는 것이다 이제 알고리즘이 최적의 변형을 선택했다 이것을 응답으로 보낸다 HTTP 응답 헤더 Vary 는 협상의 범위를 나타내게 된다 브라우저와 캐쉬는 자원을 캐쉬할때 이 정보를 사용할 수 있다 끝 이 단계에 도달했다면 모두 브라우저가 받지못하기 때문에 어떤 변형도 선택이 안된 경우다 No acceptable representation 를 뜻하는 상태 406과 내용으로 사용가능한 변형의 목록을 담은 HTML 문서를 응답을 보낸다 또 HTML Vary 헤더는 변형의 범위를 나타낸다 품질계수 조작하기 아파치는 종종 위의 아파치 협상 알고리즘을 엄격히 지키지않고 품질계수를 변경한다 이유는 완전하고 정확한 정보를 보내지않는 브라우저에게 알고리즘의 더 나은 결과를 보내기 위해서다 널리 쓰이는 브라우저중 일부는 자주 잘못된 변형을

    Original URL path: http://xserve.kw-berlin.de/manual/ko/content-negotiation.html (2016-02-16)
    Open archived version from archive

  • 동적공유객체 (DSO) 지원 - Apache HTTP Server
    install 공유 모듈을 나중에 사용하기위해 아파치를 구성하는 경우 configure enable so make install 제삼자가 만든 아파치 모듈을 컴파일하고 설치하는 경우 apxs 를 사용하여 아파치 소스 트리 밖에서 mod foo c 를 DSO mod foo so 로 cd path to 3rdparty apxs c mod foo c apxs i a n foo mod foo la 모든 경우 일단 공유 모듈이 컴파일되면 httpd conf 에 LoadModule 지시어를 사용하여 아파치가 그 모듈을 읽어들이게 만든다 배경지식 현대적인 유닉스류에는 동적공유객체 DSO 의 동적 링킹 로딩 dynamic linking loading 이라고 하여 특별한 형식의 실행코드 조각을 만들어 실행중인 실행프로그램의 주소공간에 읽어들이는 멋진 기능이 있다 보통 두가지 방법으로 읽어들일 수 있다 하나는 실행프로그램이 시작할때 ld so 라는 시스템 프로그램이 자동으로 읽어들이는 경우고 다른 하나는 실행중인 프로그램이 dlopen dlsym 시스템호출로 유닉스 로더 loader 의 시스템 인터페이스을 사용하여 직접 읽어들이는 경우다 첫번째 경우 DSO를 보통 공유라이브러리 shared libraries 혹은 DSO 라이브러리 라고 부르며 파일은 libfoo so 나 libfoo so 1 2 같은 이름을 가진다 이들은 시스템 디렉토리 보통 usr lib 에 있고 컴파일시 링커 명령어에 lfoo 를 주어 실행파일과 연결한다 이렇게 직접 써준 라이브러리는 실행파일에 참조되여서 프로그램이 시작할때 링커 옵션 R 로 직접 지정한 경로 환경변수 LD LIBRARY PATH 로 지정한 경로 혹은 usr lib 에서 유닉스 로더가 libfoo so 를 찾을 수 있다 그러면 실행프로그램의 아직 못찾은 unresolved 심볼 symbol 을 DSO에서 찾게된다 DSO는 보통 실행프로그램의 심볼을 찾지않기 때문에 DSO가 재사용가능한 일반적인 코드 라이브러리이므로 찾기는 여기서 끝난다 유닉스 로더가 심볼 찾기를 완전히 담당하므로 실행프로그램이 직접 DSO에서 심볼을 찾을 필요가 없다 사실 ld so 를 부르는 코드는 정적이 아닌 모든 실행프로그램에 링크되는 실행시 시작코드의 일부다 공통된 라이브러리 코드를 동적으로 읽어들이는 장점은 명확하다 라이브러리 코드가 모든 프로그램에 중복해서 저장되는 대신 libc so 와 같은 시스템 라이브러리에 한번만 저장되기 때문에 디스크 공간이 절약된다 두번째 경우 DSO를 보통 공유객체 shared objects 혹은 DSO 파일 이라고 부르고 규칙상 이름은 foo so 이지만 파일의 확장자는 자유롭다 이 파일들은 보통 프로그램 자체 디렉토리에 위치하고 실행프로그램에 자동으로 연결되지 않는다 대신 실행프로그램은 실행시 dlopen 을 사용하여 DSO를 주소공간에 직접 읽어들여야 한다 이때 실행프로그램은 DSO에서 심볼을 찾지 않는다 대신 앞에서 본 유닉스 로더는 자동으로 실행파일과 실행파일이 이미 읽어들인 DSO 라이브러리 특히 항상 존재하는 libc so 의 모든 심볼 에서 DSO의 아직 못찾은 심볼을 찾는다 그래서 DSO는 마치 처음부터 실행프로그램에 정적으로 링크된것과 같이 실행파일의 심볼을 알게된다 DSO의 API를 이용하기위해서 마지막으로 실행프로그램은 dlsym 으로 DSO에서 특정 심볼을 찾아서 앞으로 사용하기위해 디스패치 dispatch 표 등 에 저장한다 다른 말로 실행프로그램은 사용할 모든 실볼을 직접 찾아야한다 이런 구조의 장점은 프로그램의 일부를 프로그램이 필요할때까지 읽어들이지 않아도 그래서 메모리를 낭비하지 않게 된다는 점이다 기본 프로그램의 기능을 확장하기위해 필요한 경우 이 부분을 동적으로 읽어들일 수 있다 이런 DSO 구조가 자연스럽게 보이지만 최소한 어려운 점이 한가지있다 프로그램을 확장하기위해 DSO를 사용할때 DSO가 실행프로그램의 심볼을 찾는 일이다 왜 DSO가 실행프로그램의 심볼을 역으로 찾는 것 은 라이브러리는 자신을 사용하는 프로그램에 대해 모른다는 라이브러리 설계에 반하며 모든 플래폼에서 지원되지않고 표준화되지도 않았기 때문이다 실제로 실행파일의 전역심볼 global symbol 은 보통 익스포트 export 되지 않기때문에 DSO가 사용할 수 없다 DSO를 사용하여 실행중 프로그램을 확장하려면 링커에게 모든 전역심볼을 익스포트하도록 강제하는 것이 주된 해결책이다 공유라이브러리는 DSO 방식의 설계원칙대로 전형적이기때문에 운영체제가 제공하는 거의 모든 종류의 라이브러리가 사용한다

    Original URL path: http://xserve.kw-berlin.de/manual/ko/dso.html (2016-02-16)
    Open archived version from archive

  • 아파치의 환경변수 - Apache HTTP Server
    표준 정보를 가진 변수가 CGI 스크립트로 넘어간다 더 자세한 내용은 CGI 투토리얼 을 참고하라 SSI 페이지 mod include의 INCLUDES 필터가 처리하는 서버파싱 SSI 문서는 echo 요소를 사용하여 환경변수를 출력할 수 있고 환경변수를 사용하여 요청의 특징에 따라 흐름제어 요소로 페이지의 일부를 변경할 수 있다 아파치는 또 SSI 문서에게 위에서 설명한 표준 CGI 환경변수를 제공한다 더 자세한 내용은 SSI 투토리얼 을 참고하라 접근제어 allow from env 과 deny from env 지시어를 사용하여 환경변수 값에 따라 서버로의 접근을 조절할 수 있다 SetEnvIf 와 같이 사용하면 클라이언트의 특징에 따라 자유롭게 서버로의 접근을 제어할 수 있다 예를 들어 특정 브라우저의 User Agent 접근을 거부할 수 있다 조건부 로그 LogFormat 의 e 옵션을 사용하여 환경변수를 접근 로그에 기록할 수 있다 또 CustomLog 지시어의 조건부 형식을 사용하면 환경변수의 상황에 따라 요청을 로그할지 여부를 결정할 수 있다 SetEnvIf 와 같이 사용하여 어떤 요청을 로그할지 자유롭게 결정할 수 있다 예를 들어 파일명이 gif 로 끝나는 요청은 로그하지 않거나 외부 네트웍에 있는 클라이언트의 요청만을 로그할 수 있다 조건부 응답 헤더 Header 지시어는 클라이언트에게 응답을 보낼때 환경변수의 유무에 따라 어떤 HTTP 헤더를 포함할지 결정할 수 있다 예를 들어 클라이언트의 요청에 특정 헤더가 있는 경우에만 어떤 응답 헤더를 보낼 수 있다 외부 필터 실행하기 mod ext filter 의 ExtFilterDefine 지시어로 설정한 외부 필터를 disableenv 와 enableenv 옵션을 사용하여 환경변수에 따라 선택적으로 실행할 수 있다 URL 재작성 Rewriting RewriteCond 의 TestString 에 ENV 형식을 사용하면 mod rewrite의 재작성 엔진이 환경변수에 따라 다르게 행동한다 mod rewrite에서 앞에 ENV 를 붙이지않고 접근하는 변수는 실제 환경변수가 아님을 주의하라 그들은 다른 모듈에서 읽을 수 없는 mod rewrite에 한정된 변수다 특별한 목적의 환경변수 클라이언트와 원활한 동작하기위해 아파치는 특별한 클라이언트에 대해 자신의 행동을 수정한다 보통 BrowserMatch 에서 환경변수를 정의하여 이런 문제를 해결한다 그러나 SetEnv 와 PassEnv 로도 가능하다 downgrade 1 0 요청이 이후 버전을 사용하더라도 HTTP 1 0 요청으로 처리한다 force gzip DEFLATE 필터를 사용할때 이 환경변수는 브라우저의 accept encoding 설정을 무시하고 무조건 압축된 결과를 보낸다 force no vary 응답을 클라이언트에게 보내기 전에 응답 헤더에서 Vary 필드를 뺀다 어떤 클라이언트는 이 필드를 제대로 해석하지 못한다 이 변수는 이런 문제를 해결한다 또한 이 변수는 force response 1 0 을 가정한다 force response 1 0 HTTP 1 0 요청을 하는 클라이언트에게 HTTP 1 0 응답을 강제한다 원래 AOL 프록시에 문제가 있어서 만들어졌다 어떤 HTTP 1 0 클라이언트는 HTTP 1 1 응답을 받으면 제대로 동작하지 않으므로 이 문제를 해결하기위해 사용한다 gzip only text html 값이 1 이면 text html 이 아닌 content type에 대해 mod deflate 의 DEFLATE 출력필터를 사용하지 않는다 gzip 뿐만 아니라 identity 가 아닌 모든 인코딩의 정적으로 압축한 파일의 경우에도 mod negotiation 은 이 변수를 참고한다 no gzip 이 옵션을 설정하면 mod deflate 의 DEFLATE 필터를 사용하지 않고 mod negotiation 은 인코딩된 자원을 보내지 않는다 nokeepalive KeepAlive 를 무시한다 prefer language 이 변수는 mod negotiation 의 행동에 영향을 미친다 변수가 en ja x klingon 등 언어태그를 담고있다면 mod negotiation 는 그 언어로 된 변형을 보내길 시도한다 그런 변형이 없다면 일반적인 협상 과정을 시작한다 redirect carefully 서버가 더 조심히 클라이언트에게 리다이렉션을 보낸다 보통 리다이렉션을 처리하는데 문제가 있는 클라이언트을 위해 사용한다 원래 Microsoft의 WebFolders 소프트웨어가 DAV 메써드를 통해 디렉토리 자원의 리다이렉션을

    Original URL path: http://xserve.kw-berlin.de/manual/ko/env.html (2016-02-16)
    Open archived version from archive

  • 로그파일 - Apache HTTP Server
    identd 가 제공할 클라이언트의 RFC 1413 신원이다 이 정보는 매우 믿을 수 없기때문에 긴밀히 관리되는 내부 네트웍이 아니라면 절대로 이 정보를 사용하면 안된다 IdentityCheck 가 On 이 아니라면 아파치 웹서버는 이 정보를 알아보려고 시도하지도 않는다 frank u 이는 HTTP 인증으로 알아낸 문서를 요청한 사용자의 userid이다 보통 이 값은 CGI 스크립트에게 REMOTE USER 환경변수로 넘겨진다 요청의 상태코드가 401이라면 아래 참고 사용자가 아직 인증을 거치지 않았으므로 이 값을 믿으면 안된다 문서를 암호로 보호하지 않는다면 이 항목은 이전 항목과 같이 이다 10 Oct 2000 13 55 36 0700 t 서버가 요청처리를 마친 시간 형식은 day month year hour minute second zone day 숫자 2개 month 숫자 3개 year 숫자 4개 hour 숫자 2개 minute 숫자 2개 second 숫자 2개 zone 숫자 4개 로그 형식문자열에 format t 를 사용하여 다른 형식으로 시간을 출력할 수 있다 format 은 C 표준 라이브러리의 strftime 3 과 같다 GET apache pb gif HTTP 1 0 r 클라이언트의 요청줄이 쌍따옴표로 묶여있다 요청줄은 매우 유용한 정보를 담고 있다 첫째 클라이언트가 사용한 메써드는 GET 이다 둘째 클라이언트는 자원 apache pb gif 를 요청한다 세번째 클라이언트는 HTTP 1 0 프로토콜을 사용한다 요청줄의 여러 부분을 따로 로그할 수도 있다 예를 들어 형식문자열 m U q H 은 r 과 똑같이 메써드 경로 질의문자열 프로토콜을 로그한다 200 s 이는 서버가 클라이언트에게 보내는 상태코드이다 이 정보는 2로 시작하는 코드 요청이 성공하였는지 4로 시작하는 코드 클라이언트에 오류가 있는지 5로 시작하는 코드 서버에 오류가 있는지 알려주므로 매우 중요하다 상태코드의 전체 목록은 HTTP 규약 RFC2616 section 10 에서 찾을 수 있다 2326 b 마지막 항목은 응답 헤더를 제외하고 클라이언트에게 보내는 내용의 크기를 나타낸다 클라이언트에게 보내는 내용이 없다면 이 값은 이다 내용이 없는 경우 0 을 로그하려면 대신 B 를 사용한다 Combined 로그 형식 자주 사용되는 다른 형식문자열은 결합된로그형식 Combined Log Format 이다 다음과 같이 사용한다 LogFormat h l u t r s b Referer i User agent i combined CustomLog log access log combined 이 형식은 두 항목을 더 추가한 것을 제외하고는 Common 로그 형식과 완전히 같다 추가된 항목들은 퍼센트 지시어 header i 를 사용한다 여기서 header 자리에 HTTP 요청 헤더 이름이 나올 수 있다 이 형식의 접근 로그는 다음과 같다 127 0 0 1 frank 10 Oct 2000 13 55 36 0700 GET apache pb gif HTTP 1 0 200 2326 http www example com start html Mozilla 4 08 en Win98 I Nav 추가된 항목은 http www example com start html Referer i Referer 맞춤법 틀리지않았음 HTTP 요청 헤더 클라이언트가 참조했다고 서버에게 알린 사이트이다 즉 apache pb gif 를 링크하였거나 포함한 사이트이다 Mozilla 4 08 en Win98 I Nav User agent i User Agent HTTP 요청 헤더 클라이언트 브라우저가 자신에 대해 알리는 식별정보이다 여러 접근 로그 설정파일에 여러 CustomLog 지시어를 사용하면 접근 로그가 여러개 만들어진다 예를 들어 다음 설정은 세가지 접근 로그를 만든다 첫번째는 기본 CLF 정보를 기록하고 두번째와 세번째는 referer와 브라우저 정보를 기록한다 마지막 두 CustomLog 줄은 어떻게 이전 ReferLog 와 AgentLog 지시어의 기능을 흉내낼 수 있는지 보여준다 LogFormat h l u t r s b common CustomLog logs access log common CustomLog logs referer log Referer i U CustomLog logs agent log User agent

    Original URL path: http://xserve.kw-berlin.de/manual/ko/logs.html (2016-02-16)
    Open archived version from archive



  •