남정현의 Windows Azure 블로그

이 글은 http://www.boutell.com/newfaq/misc/urllength.html 의 내용을 인용하여 서술한 것으로 2006년 이후로 바뀐 내용들이 반영되어있지 않은 것들이 많습니다. 덧붙일 의견이 있으시면 언제든 말씀해주시면 반영하겠습니다. :-)

http://www.w3.org/Protocols/rfc2616/rfc2616.html 에서 설명하는 사양에도 최대 URL 길이에 대한 내용은 언급이 되어있지 않습니다. 하지만 웹 개발을 하면서 누구나 한번즈음은 이런 부분에 대해서 고민을 하게 될 때가 있는데, 그러한 고민을 풀어줄만한 아티클이 있어 소개해 봅니다.

Browser Case No. 1: Microsoft Internet Explorer

http://support.microsoft.com/kb/q208427/ 에서 언급한 것 처럼 Microsoft Internet Explorer는 내부 WININET 헤더 파일 상의 정의를 충실히 따릅니다. URL이 가질 수 있는 최대 길이는 2083자이고, 이 중 프로토콜, 서버 이름 등을 제외한 순수 경로가 2048자까지 허용이 됩니다. 이 글을 작성했던 분의 테스트 결과에 따르면 URL 길이가 긴 경우 브라우저 차원에서 오류 페이지를 띄운다는 것으로 결과가 나왔다고 합니다.

Browser Case No. 2: Firefox

버전 1.5.x의 경우 시각적으로 주소 표시줄은 65536번째 글자 이후로는 주소를 더 표시하지 못한다고 합니다. 그러나 논리적으로 십만글자 이상의 URL도 정상적으로 처리하는 것으로 보이며, 현재 출시되는 Firefox의 경우 이러한 제약이 거의 없지 않겠는가 하는 예상을 해봅니다.

Browser Case No. 3: Safari

적어도 8만자까지는 잘 동작한다고 합니다. :-)

Browser Case No. 4: Opera

긴 URL에 관해서는 종결자라고 해도 틀림없겠네요. 무려 19만자까지, 그것도 인라인 편집이 아닌 여러 행 편집이 가능한 컨트롤로 확장까지 가능하다고 합니다. >_<

Web Server Case No. 1: Apache

기본적으로 약 4000자까지는 허용하지만 그 이후부터는 413 Entity too large 오류가 발생한다고 합니다. 그러나 근래 개발되는 RHEL 기반에서의 Apache는 문서 상으로 약 8000자 이상까지 지원한다고 합니다.

Web Server Case No. 2: Microsoft Internet Information Services (IIS)

기본적으로 16384자까지 지원하며 이는 Microsoft Internet Explorer의 경우와는 상반되는 동작입니다. 게다가 설정도 가능합니다. 특별한 제약은 없겠지만 너무 긴 URL을 받아들이는건 상식적이지 않겠지요.

Web Server Case No. 2-1: ASP.NET

웹 서버 이야기는 아닙니다만 IIS에서 독자적인 처리 규정을 가지고 있는 서버 기반 처리 엔진에 대한 이야기를 하나 하자면, ASP.NET의 이야기를 해야 할 것 같습니다. ASP.NET 3.5 SP1 (내부 ASP.NET 2.0) 까지는 Windows의 시스템 상수 _MAX_PATH가 정의하는 범위 만큼의 URL만을 IIS의 설정과는 관계없이 받아들일 수 있었지만 ASP.NET 4.0부터는 Web.config 파일의 httpRuntime 요소의 maxQueryStringLength 속성에 의하여 확장이 가능합니다.

Web Server Case No. 3: Perl의 HTTP::Daemon

기본적으로 8000자까지 지원합니다. POST 메서드로 수신하게 되는 데이터를 제외하고 순수 HTTP 헤더는 16384바이트까지 지원하며 이 중 헤더에 들어있을 URL에도 이러한 제약이 적용됩니다. 즉, 헤더에 전달되는 내용과의 상관관계도 감안해야하므로 헤더의 양이 많은 경우 8000자보다 안되게 지원이 될 수도 있습니다. 보통은 8000자 이상의 URL로 요청을 하는 경우 413 오류가 발생합니다. 이러한 제약을 넘기위해서 Daemon.pm 파일 내의 16x1024라는 모든 표현식을 더 큰 값으로 수정하면 됩니다. 물론, 이런 동작을 하는 경우 당연한 이야기이지만 Denial of Service (DoS) 공격에 취약해질 수 밖에 없겠지요.

결론

이 글에서는 단순히 fact에 대해서만 살펴보았습니다. 기본적으로 URL이 필요 이상으로 길다고 하는 것 (그 기준이 정확하지는 않지만 상식적인 범위를 벗어나는, 가령 100글자 이상)은 정상적인 상황이 아닐 것입니다. 이 정도로 긴 URL을 보내야 한다면, 대개는 Query String이 그 원인일 것이므로, GET 방식 대신 POST 방식의 전송을 고려해보실 수 있습니다. 하지만 긴 URL을 유지해야 할 필요가 있다면 제가 원본으로 참조한 글의 끝자락에 있는 "The Bookmark Problem" 섹션을 참고하시기 바랍니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

최근 Microsoft 제품군이 새롭게 발표되면서, IIS 6.0과 같이 오래된 웹 서버에는 등록되지 않은 새로운 유형의 MIME Type으로 인해서 호환성에 문제가 발생하는 경우가 자주 있습니다. 특히 IIS 6.0의 경우는 의도된 동작 (By Design)임을 설명하는 기술 문서 (http://support.microsoft.com/kb/326965/ko)로 이에 대한 해명을 하기도 하였습니다.

IIS 6.0 뿐만 아니라, 최근에는 실버라이트 컨텐츠를 개인 웹 호스팅 계정에 올려서 테스트하시는 분들도 많이 계신데요, 단순히 실버라이트 컨텐츠를 재생하기 위함이라면 필요가 없겠지만, 실버라이트 컨텐츠와 상호작용하는 기능을 구현할 때에는 반드시 MIME 설정이 웹 서버에 올바르게 구현되어있어야 합니다.

아래는 Microsoft가 근래에 들어서 발표한 최신 기술에서 사용하는 파일 형식들의 MIME Type 목록들을 정리한 것입니다. 아래의 목록을 참조하여 IIS 6.0이나 Apache 등의 웹 서버에서 설정을 변경할 수 있습니다.

아래는 Apache 기반의 웹 호스팅에서 서버의 설정을 변경하지 않고 손쉽게 MIME 형식을 추가할 수 있는 .htaccess 파일입니다. 다른 .htaccess 파일이 있을 경우 적당한 위치에 파일을 병합하시고, 다른 응용프로그램을 사용하지 않고 있는 경우 이 파일을 그대로 업로드하면 곧바로 반영됩니다.

.htaccess

IIS 7.x (Windows Vista 및 Server 2008 이상)에서는 위의 형식들 중 상당수가 이미 기본으로 등록되어있으므로 IIS 7.x 이상의 웹 응용프로그램 서버를 사용하고 있을 경우에는 문제가 되지 않습니다. 자체적인 웹 서버를 구현하고 있을 경우 (예를 들어 WCF나 .NET Framework based HTTP Listener 같은 경우) MIME Type에 대해서 올바른 처리가 추가 구현되어있어야 합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

웹 사이트에 한국어 검색 기능과 함께 한국어 인덱싱 기능을 추가하기 위하여 여러가지 라이브러리를 찾아보던 중, 자바 기반으로 작성된 한국어 형태소 분석기 라이브러리를 발견하였습니다. (http://cafe.naver.com/korlucene) Apache Lucene 위에서 실행될 수 있도록 만든 라이브러리였고 저는 이 라이브러리의 코드 중 일부를 발췌하여 J#으로 포팅하려는 계획을 세웠습니다.

그러나, 현재 배포되는 J# 2.0 Second Edition까지도 Generic을 선언하지 못한다는(!) 중대한 결점을 알게 되었고, 같은 기능을 하는 C# 코드를 작성하기 위하여 시도해보았지만 Java의 Iterator와 .NET의 IEnumerator 인터페이스의 미묘한 의미차이 때문에 포팅 중에 많은 시간을 들이게 되어 결국 더 진척시키지 못했습니다.

그리고 마지막으로 택한 방법인 IKVM을 이용한 컨버젼에서 매우 만족스러운 결과를 얻게 되어 글을 올려봅니다. IKVM은 현재 JDK 1.6 버전에 대응되는, .NET Framework 위에서 구동되는 자체 Java Virtual Machine과 함께, Java Compiler에 의하여 만들어진 Java Byte Code를 MSIL로 변환하는 기술, 그리고 JDK 1.6 라이브러리에 대응되는 OpenJDK로 구성된 소프트웨어 개발 도구입니다. Apache Lucene 라이브러리 전체와 한국어 형태소 분석 라이브러리를 포함하여 모두 IKVM을 통하여 가져오는 데에 성공하였습니다.

제가 작업한 절차는 다음과 같습니다.

• http://www.ikvm.net/index.html 에서 IKVM.NET 런타임을 다운로드 받습니다. x86 버전과 x64 버전이 모두 제공되며, 이 글을 작성하는 현 시점에서 0.40 버전이 릴리즈되었습니다.
• http://www.apache.org/dyn/closer.cgi/lucene/java/ 에서 Java 버전의 Lucene을 다운로드하여, 이 중에서 lucene-core-x.x.x.jar 파일을 가져왔습니다.
• http://cafe.naver.com/korlucene 에서 한국어 형태소 분석기 JAR 파일을 다운로드하였습니다.
• ikvmc 도구를 통하여 다음과 같이 명령어를 지정하여 대응되는 DLL 파일을 생성하였습니다.
  ikvmc -target:library [형태소 분석기 JAR 파일] [Lucene Core JAR 파일]
• 위와 같이 명령을 지정하여 나타나는 결과 DLL 파일을 다음의 DLL들과 같이 프로젝트에 참조 추가합니다. - 또는 - IKVM 관련 DLL을 모두 GAC에 등록해도 됩니다.
• IKVM.OpenJDK.Core.dll
• IKVM.OpenJDK.Misc.dll
• IKVM.OpenJDK.Security.dll
• IKVM.OpenJDK.SwingAWT.dll
• IVKM.OpenJDK.Text.dll
• IKVM.OpenJDK.Util.dll
• IKVM.OpenJDK.XML.dll
• IKVM.Runtime.dll
• org.apache.lucene.analysis.kr 네임스페이스의 클래스들을 활용하여 작업을 실행할 수 있었습니다.

여기서 주목할만한 부분은, ikvmc가 단순히 대응되는 코드만을 작성하는 것이 아니라, JAR 파일 내부에 포함된 리소스 파일에 대한 정보도 닷넷 프레임워크 리소스로 변환하여 저장하고 여기에 대응되는 코드도 자동으로 맞추어주기 때문에 IKVM을 위하여 자바 프로그램을 다시 수정하는 작업은 필요하지 않습니다.

위와 같은 방법을 통하여 기존에 작성한 Java Code들을 손쉽게 .NET Framework 안으로 통합할 수 있습니다. 그리고 ikvmstub을 이용하면 Java Code에서 .NET Framework의 핵심 라이브러리들을 자유롭게 활용할 수도 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

The Code Project Open License (CPOL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Common Development and Distribution License (CDDL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Microsoft Public License (Ms-PL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Mozilla Public License 1.1 (MPL 1.1)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Common Public License Version 1.0 (CPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Eclipse Public License 1.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The MIT License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The BSD License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Apache License, Version 2.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Creative Commons Attribution-ShareAlike 2.5 License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**
* 라이센스 전파 여부: 예**

The zlib/libpng License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

공개 커뮤니티에 대한 공헌 (라이센스 아님)

* 저작권 보호: 아니오**
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The GNU Lesser General Public License (LGPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 예**

The GNU General Public License (GPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**
* 라이센스 전파 여부: 예**

노트: ** 기호가 붙은 항목은 라이센스 선택 시 고려해야 할 주의 사항입니다.
출처: http://www.codeproject.com/info/Licenses.aspx

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Mono와 상관은 없습니다만 PHP Setup for IIS를 이용해서 Windows 기반의 PHP 웹 사이트를 운영하고자 하시는 분들에게는 분명히 도움이 되리라 생각하고 글을 씁니다. PHP Setup for IIS는 http://okstart.pe.kr - 또는 - http://www.apmsetup.com/ 에서 받으실 수 있으며 Windows NT 4.x Server Family, 2000 Server Family, Server 2003 Family에서 사용할 수 있습니다. (Windows 9x 및 Windows NT 4.x, Windows 2000 Professional의 Personal Web Server와는 호환되지 않습니다.)

rkttu.com은 현재 Windows Server 2003의 IIS 6.0을 서버로 사용하며 PHP Setup for IIS를 사용하여 PHP에 관한 지원을 추가하였습니다.

하지만 실제로 몇몇 PHP 웹 어플리케이션들은 호환성 문제로 인하여 전혀 예상하지 못하거나 기대하지 않았던 불편을 초래하기도 합니다. 이 글을 통하여 조금이나마 도움이 되시기를 바라며 글을 올립니다.

1. 흔히 발생하는 퍼미션 문제

기존의 유닉스나 리눅스 계열 운영 체제에서는 세 자리의 숫자로 퍼미션에 관한 모든 설정을 제어할 수 있습니다. 하지만 Windows NT의 보안 체계는 이보다 훨씬 복잡한 구조를 나타냅니다. 따라서, 기존에 널리 사용되넌 chmod 명령어나 FTP를 통한 퍼미션 조정은 불가합니다.

Windows NT 계열의 운영 체제에서는 접근의 주체가 사용자라는 단위에 의하여 발생됩니다. 따라서, IIS도 합당한 사용자 계정을 획득한 상황에서 파일을 읽거나 쓰는 작업을 처리하게 되어있습니다. 이러한 계정은 시스템 계정으로, [IUSR_컴퓨터이름]과 같은 형태로 미리 만들어집니다.

특별히 IIS의 관리 콘솔을 이용하여 디렉터리에 접근하는 사용자의 권한을 다른 계정으로 주지 않았다면 [IUSR_컴퓨터이름] 계정에 대한 권한 할당을 해주는 것이 퍼미션 할당 작업에 해당됩니다.

퍼미션 할당 작업은 컨텐츠가 저장된 디렉터리를 탐색기로 열고, 해당 개체를 오른쪽 버튼으로 클릭하고 "속성" 또는 "등록 정보" 메뉴를 선택하면 나타나는 세부 사항 대화 상자의 "보안" 탭을 통해 조절할 수 있습니다.

2. PHP.INI에 설정된 임시 디렉터리에 관하여.

PHP.INI 파일에 파일 업로드 및 세션 처리를 위한 임시 디렉터리 관련 설정이 있습니다. 여기에 명시된 디렉터리는 반드시 Everyone (그룹)에 대해 모든 권한 할당을 해주어야 합니다.

3. IIS 6.0의 웹 서비스 확장에 대하여.

IIS 5.0과 6.0의 보안상의 차이점 중 가장 눈에 띄는 것은 ISAPI 및 CGI에 대한 보안 설정이 구체화되었다는 점입니다. 즉, IIS 6.0에서는 사용하려는 ISAPI DLL이나 CGI EXE는 반드시 웹 서비스 확장 섹션에 등록되어야 한다는 의미입니다. 여기에 등록하지 않고 웹 사이트 또는 특정 디렉터리의 응용프로그램 풀 구성에만 등록할 경우 동작하지 않게 됩니다.

4. PHP 기반 응용프로그램들은 항상 별도의 응용프로그램으로 독립시켜줄것.

PHP 기반 응용프로그램이 저장된 디렉터리 개체의 등록 정보를 IIS 관리자에서 살펴보면 디렉터리 탭이 있는데 그곳의 응용프로그램 설정 섹션을 살펴보면 기본값은 만들어져 있지 않은 것으로 되어있습니다. 좌측의 만들기 버튼을 눌러서 별도로 분리를 시키고, 반드시 실행 권한에는 "스크립트 전용"을 선택해 주셔야 합니다. 그리고 당연한 이야기이지만 "구성" 버튼을 눌러서 php 확장자에 대하여 php-cgi.exe 엔진을 연결시켜주어야 합니다.

5. 필요한 곳에서만 PHP 해석기 엔진을 사용하기

위의 4번과 같이 PHP 응용프로그램들을 따로 독립시켜두면 필요한 곳에서만 PHP 엔진을 호출하도록 구분할 수 있습니다. 이렇게 하여 성능을 최대한 발휘할 수 있도록 하는 것도 가능합니다.

6. 기본 문서에 유의할 것

IIS는 Apache와 달리 Default 라는 단어의 페이지가 미리 지정되어있습니다. 그래서 기본 문서에 index.html과 index.php 파일을 추가해 주는 것을 잊지 말아야 하겠습니다. 또한, 우선 순위를 높게 잡아주어 빨리 찾도록 해주는 것도 중요합니다.

7. 제로보드와 태터툴즈의 로그인 문제

제로보드와 태터툴즈만의 문제는 아닐 것입니다. 비슷하게 활용할 수 있는 곳이 적지 않을 것이라 보고 공통의 코드 두 줄을 알려드립니다. 이 코드 두 줄을 필요한 곳에 적절히 배치하는 것이 중요하리라 생각됩니다. 태터툴즈 구버전 (0.x) 사용자 계서는 7.2 섹션을 꼭 참고하십시오.

7.1. 제로보드의 로그인 문제 해결

제로보드의 로그인 문제를 해결하기 위해서는 lib.php 파일에서 다음의 섹션을 찾으셔야 합니다.

/*******************************************************************************

* 에러 리포팅 설정과 register_globals_on일때 변수 재 정의

******************************************************************************/

@error_reporting(E_ALL ^ E_NOTICE);

@extract($HTTP_GET_VARS);

@extract($HTTP_POST_VARS);

@extract($HTTP_SERVER_VARS);

@extract($HTTP_ENV_VARS);

위와 같은 섹션의 바로 밑 부분에 아래의 코드를 집어넣어 주십시오.

$_QU = ($QUERY_STRING) ? "?" : "" ;

$REQUEST_URI = "$PHP_SELF"."$_QU"."$QUERY_STRING";

7.2. 태터툴즈의 로그인 문제 해결

태터툴즈의 클래식 버전은 이런 사항을 해결하였습니다. 따라서 이 내용을 적용할 필요는 없습니다. 하지만 아직 구 버전을 사용하고 계실 경우 아래의 지시 사항대로 따라하여 주십시오. 태터툴즈의 정식 브랜치들은 이 글이 작성된 현 시점까지도 IIS에서 실행되지 않으니 참고하여 주십시오.

태터툴즈의 로그인 문제를 해결하시기 위해서는 inc_function.php 파일을 열고 다음의 섹션을 찾아주십시오.

reset($HTTP_SERVER_VARS);

while (list($key, $val) = each($HTTP_SERVER_VARS)) {

$$key = $val;

}

바로 밑에 두 줄의 코드를 집어넣습니다.

$_QU = ($QUERY_STRING) ? "?" : "" ;

$REQUEST_URI = "$PHP_SELF"."$_QU"."$QUERY_STRING";

두 곳 모두 같은 코드를 집어넣었습니다. 로그인 문제가 발생하는 PHP 프로그램에는 위와 같은 방법을 사용하여 해결이 가능할 것이라 봅니다.

8. 일부 Perl 프로그램들의 파일 입/출력 문제

IIS에서는 Active Perl을 사용하여 Perl 웹 프로그램들을 구동할 수 있습니다. 하지만 문제점이 있는데, 유닉스나 리눅스와는 달리 Windows NT는 심볼릭 링크의 개념이 없습니다. 그에 따라서 파일 액세스를 하기 위하여 파일 핸들을 열어놓으면 다른 프로세스가 접근할 수 없게 됩니다. 즉, 다중 사용자 접속에 취약하게 됩니다.

이 점을 고치기 위하여 직접 Win32 API를 핸들링하여 Shared Mode로 열도록 고쳐도 되겠습니다만 많은 노력이 필요할 것입니다. 이 점에 대한 마땅한 해결책은 아직까지 없는듯 합니다.

9. MBSA (Microsoft Baseline Security Analyzer)의 검진 보고서에서 조심해야 할 것

최근에 경험한 사실 한 가지가 있습니다. MBSA 라는 유틸리티는 Microsoft사가 Technet을 통하여 무료로 배포하는 보안 점검 유틸리티입니다. 군더더기 없는 정확한 핫픽스만을 설치할 수 있어서 자주 애용하고 있는 유틸리티이기도 합니다. 최근에 저는 이 유틸리티를 사용하면서 한 가지 실수를 저질렀습니다. 그것은 다름이 아니라 IIS와 연관성이 있는(?) World Wide Web Publishing Service 라는 이름의 서비스에 대한 보고서였습니다. MBSA는 이것을 그닥 필요없는 서비스이기 때문에 꺼도 좋다고 이야기를 하고 있습니다만 이대로 시행하였다가 낭패를 봤습니다. CGI 기반으로 연결된 PHP 해석기가 동작하지 않기 시작하였습니다. 하는 수 없이 원래대로 복구를 하고 IIS를 재시작하니 그제서야 제자리를 찾았습니다. 이 점에 대해서 다른 의견이 있으시면 듣고 싶습니다. ^^

서버 관리자 여러분들께서는 많은 도움이 되셨기를 바랍니다.

남정현(junghyun0816) http://rkttu.com

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.