WebKnight 2.0 세번째 이야기..

여태 쓴 두개의 WebKnight 2.0 이야기는 어째서 도입을 해야하는가? 도입했을때 기대할 수 있는 값은? 이것이 주제였다면, 이번 글에서는 기존의 기대 효과 같은 부분이 아닌, 실무적인 부분, 바로 어떻게 해야 "장애가 덜 발생하는 세팅 값을 가질 수 있는가?"이다.

 대부분의 경우 테스트 서버나 실서버에 설치를 마친 후에 IIS를 재시작한다. 이 작업 후, 정말 매우 많이 운이 좋다면, WebKnight를 설치했음에도 불구하고 잘 뜨는 것을 볼 수 있을 것이다. 그러나, 대부분의 경우 두세 페이지만 클릭해보면 바로 필터링 되었다는 메시지가 뜬다. 심각한 경우에는 아예 첫페이지부터 필터링에 걸렸다고 나온다. 이런 문제의 절반 이상의 문제는 바로 한글 사용에 기인한다. 이와 관련된 옵션은 다음 두가지이다.

1. High Bit Shellcode
2. RFC Compliant *

  일단 위에 지적한 두개의 옵션은 WebKnight 1.3의 경우 3군데 정도, WebKnight 2.0의 경우 8군데 정도가 있다(기억에 의존해서 쓰는 것이므로 정확한 갯수를 틀려도 양해 바랍니다). 이러한 옵션은 많을수록 세부적인 조정이 가능하나, 이걸 사용해야하는 사람의 입장에서는 약간의 문제가 있다. 위 옵션은 단순히 주소 표시줄에 나오는 Querystring부분 뿐만 아니라 Cookie나 글을 올리는 헤더의 POST나 GET부분에 있을 수도 있다. 한마디로 HTTP라는 프로토콜을 쓸 때 이 HTTP라는 프로토콜을 구성하고 있는 모든 부분에 다 적용 할 수 있다는 소리이다.

실제 위 두개의 옵션에 대해서 자세히 알아보자.

 HighBitShellcode : 문자를 ASCII로 봤을 때 127보다 큰 값을 지칭한다. 즉, 기본을 벗어나는 특수문자, 영어가 아닌 모든 문자가 이 범위 안에 들어온다. 물론 한글이라고 예외는 아니다. 유니코드를 사용한다면 이 부분 역시 꺼야한다.

 RFC Compliant : RFC에 적합한가 여부를 따지는 옵션이다. 이러한 부분은 그냥 관과하기 쉽지만, 우리가 사용하는 모든 브라우저는 특정한 룰에 의해서 만들어진다. 이러한 룰의 집합으로 만들어진 표준안이 바로 RFC 문서이다. RFC의 대부분의 기반 문서는 2바이트 문자권이 아닌 영문자권에서 만들어진다. 따라서 불행하게도 대부분의 RFC에는 2바이트 문자권에 대한 언급이 거의 없다. 설령 있다 하더라도, 이는 확장된 부분에 속하기 때문에 초기 버전을 따르는 경우에는 역시 문제가 된다.

 일단 이 두개의 옵션에 대해서 이야기를 해봤다. 하지만, WebKnight 2.0에서는 이 두 옵션을 다 제거하고 적용하여도 대부분의 경우 문제가 발생한다. 이는 WebKnight 2.0에 추가된 옵션으로 Unicode를 허용으로 바꿔도 문제가 된다.

 WebKnight 2.0의 사용시 로그를 보면 HTTP 1.1까지만 로그가 남고 이 이후의 어떤 부분에 의해 로그가 남는지에 구체적인 로그 내용이 남지 않는다. 그리고 실제 동작은 필터링이 됐다 말았다한다. 이 부분은 현재 HTTP 1.1을 사용하면서 한글이 들어간 경우에 주로 발생되는 것으로 보여지고 있다. 즉, HTTP 1.1을 사용하지 않는 클라이언트는 사용하지 않는데 별 문제가 없다. (즉, IE 6.0은 정상 동작한다)

참고

1. IE 7.0부터 HTTP 1.1을 사용하고, IE6.0까지는 HTTP 1.0을 쓰더군요. Firefox는 테스트 안해봤습니다.
2. 한글 문제 때문에 WebKnight 2.0보다는 WebKnight 1.3버전을 사용하시는 것이 좋습니다. 다만, 1.3을 그대로 사용하시는 경우 필터링 부분을 강화해주셔야 합니다.

RFC Compliant의 참고 문서

1. http://www.ietf.org/rfc/rfc2145.txt
2. http://www.ietf.org/rfc/rfc2616.txt