'server'에 해당되는 글 3건

  1. 2008/06/26 HTTP API의 오류 로깅
  2. 2006/12/07 ASP 파싱관련
  3. 2006/11/24 유용한 팁.
STUDY/윈도우2008/06/26 13:52

HTTP API의 오류 로깅

기술 자료 ID : 820729
마지막 검토 : 2007년 12월 3일 월요일
수정 : 5.2

요약
이 문서에서는 HTTP(하이퍼텍스트 전송 프로토콜) API의 오류 로깅 기능을 설명합니다.

HTTP 기반 응용 프로그램에서 발생하는 오류 중 일부는 처리를 위해 응용 프로그램으로 다시 전달되는 대신 HTTP API에서 자동으로 처리됩니다. 이 동작은 이러한 오류가 너무 많이 발생하여 이렇게 하지 않으면 이벤트 로그나 응용 프로그램 처리기에서 다룰 수 있는 범위를 초과하기 때문에 발생합니다.

아래의 항목은 HTTP API 오류 로깅의 다양한 측면에 대해 설명합니다.
HTTP API 오류 로깅 구성
레지스트리 설정은 HTTP API 로그 오류, 허용되는 최대 로그 파일 크기 및 로그 파일 위치를 제어합니다.
HTTP API 오류 로그 형식
HTTP API는 W3C(World Wide Web Consortium) 로그 파일 규칙을 준수하는 로그 파일을 만듭니다. 따라서 표준 도구를 사용하여 이 로그 파일을 구문 분석할 수 있습니다. 그러나, W3C 로그 파일과 달리 HTTP API 로그 파일에는 열 이름이 없습니다.
HTTP API가 기록하는 오류 유형
HTTP API는 다양한 일반 오류를 기록합니다.

추가 정보

HTTP API 오류 로깅 구성

HTTP \Parameters 키의 세 가지 레지스트리 값이 HTTP API 오류 로깅을 제어합니다. 이들 키는 다음 레지스트리 키에 있습니다.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
참고 이후 버전의 Microsoft Windows 운영 체제에서는 구성 값의 위치와 형식이 바뀔 수 있습니다.

레지스트리 값을 변경하고, 이들이 포함되어 있는 로그 파일과 폴더를 보거나 수정하려면 Administrator/Local System 자격 증명이 있어야 합니다.

레지스트리 값의 구성 정보는 HTTP API 드라이버가 시작될 때 읽혀집니다. 따라서 설정을 변경한 경우에 새 값을 읽으려면 드라이버를 중지했다가 다시 시작해야 합니다. 이렇게 하려면 다음 콘솔 명령을 입력하십시오.
net stop http
net start http
로그 파일의 이름을 지정하는 데 다음과 같은 명명 규칙이 사용됩니다.
httperr + sequence number + .log
예: httperr4.log
로그 파일은 ErrorLogFileTruncateSize 레지스트리 값에서 지정하는 최대 크기에 도달하면 새로 작성됩니다. 최대 크기는 1MB 이상이어야 합니다.

오류 로깅의 구성이 올바르지 않거나, HTTP API가 로그 파일에 기록하는 동안 오류가 발생하면 HTTP API는 이벤트 로깅을 사용하여 오류 로깅이 발생하지 않음을 관리자에게 알립니다.

아래의 표는 레지스트리 구성 값을 설명합니다.

레지스트리 값 설명
EnableErrorLogging TRUE로 설정하면 오류 로깅을 사용 가능하게 설정하고 FALSE로 설정하면 오류 로깅을 해제할 수 있는 DWORD. TRUE가 기본값입니다.
ErrorLogFileTruncateSize 오류 로그 파일의 최대 크기를 바이트 단위로 지정하는 DWORD. 기본값은 1MB(0x100000)입니다.

참고 기본값보다 작은 값은 지정할 수 없습니다.
ErrorLoggingDir HTTP API가 해당 로깅 파일을 저장하는 폴더를 지정하는 문자열.

HTTP API는 지정된 폴더에서 HTTPERR이라는 하위 폴더를 만들어서 여기에 로그 파일을 저장합니다. 이 하위 폴더와 로그 파일은 같은 권한 설정을 받습니다. Administrator 및 Local System 계정은 모든 권한을 갖습니다. 그 밖의 다른 사용자는 액세스할 수 없습니다.

다음은 레지스트리에서 폴더를 지정하지 않은 경우에 사용되는 기본 폴더입니다.
%SystemRoot%\System32\LogFiles

참고 ErrorLoggingDir 문자열 값은 정규화된 경로여야 합니다. 그러나, %SystemRoot%를 포함할 수도 있습니다.

HTTP API 오류 로그 형식

일반적으로 HTTP API 오류 로그 파일은 열 머리글이 없다는 점을 제외하고 W3C 오류 로그와 같은 형식을 갖고 있습니다. HTTP API 오류 로그 파일은 각 행에 하나씩 오류를 기록합니다. 필드가 특정 순서로 나타납니다. 단일 공백 문자(0x0020)가 각 필드를 이전 필드와 분리합니다. 각 필드에서 공백 문자, 탭 및 인쇄할 수 없는 제어 문자 대신 더하기 기호(0x002B)가 표시됩니다.

아래의 표는 오류 로그 레코드에서 필드와 이들 필드의 순서를 나타냅니다.

필드 설명
날짜 날짜 필드는 W3C 형식을 따릅니다. 이 필드는 UTC(Coordinated Universal Time)를 기준으로 합니다. 날짜 필드는 항상 YYYY-MM-DD 형식으로 된 10개의 문자입니다. 예를 들어, 2003년 5월 1일은 2003-05-01로 표시됩니다.
시간 시간 필드는 W3C 형식을 따릅니다. 이 필드는 UTC를 기준으로 합니다. 시간 필드는 항상 MM:HH:SS의 형식으로 된 8개의 문자입니다. 예를 들어, 오후 5시 30분(UTC)은 17:30:00으로 표시됩니다.
클라이언트 IP 주소 영향을 받는 클라이언트의 IP 주소입니다. 이 필드의 값은 IPv4 주소나 IPv6 주소 중 하나가 될 수 있습니다. 클라이언트 IP 주소가 IPv6 주소인 경우 ScopeId 필드도 주소에 포함됩니다.
클라이언트 포트 영향을 받는 클라이언트의 포트 번호입니다.
서버 IP 주소 영향을 받는 서버의 IP 주소입니다. 이 필드의 값은 IPv4 주소나 IPv6 주소 중 하나가 될 수 있습니다. 서버 IP 주소가 IPv6 주소인 경우 ScopeId 필드도 주소에 포함됩니다.
서버 포트 영향을 받는 서버의 포트 번호입니다.
프로토콜 버전 사용 중인 프로토콜의 버전입니다.

프로토콜 버전을 확인할 수 있도록 구문 분석되지 않은 연결에는 하이픈(0x002D)이 빈 필드에 대한 자리 표시자로 사용됩니다.

구문 분석된 주 버전 번호나 부 버전 번호가 10 이상인 경우에는 버전이 HTTP/?.?로 기록됩니다.
동사 마지막으로 구문 분석된 요청이 전달하는 동사 상태입니다. 알 수 없는 동사가 포함되지만, 255바이트를 초과하는 동사는 이 길이로 잘립니다. 동사를 사용할 수 없는 경우에는 하이픈(0x002D)이 빈 필드에 대한 자리 표시자로 사용됩니다.
CookedURL + 쿼리 URL과 이 URL과 연관된 쿼리는 물음표(0x3F)로 분리된 하나의 필드로 기록됩니다. 이 필드는 4096바이트의 길이 제한에서 잘립니다.

이 URL이 구문 분석("cooked")된 경우 로컬 코드 페이지 변환에서 기록되어 유니코드 필드로 처리됩니다.

이 URL이 로깅 시 구문 분석("cooked")되지 않은 경우 유니코드 변환 없이 정확하게 복사됩니다.

HTTP API가 이 URL을 구문 분석하지 못하면 하이픈(0x002D)이 빈 필드에 대한 자리 표시자로 사용됩니다.
프로토콜 상태 프로토콜 상태는 999를 초과할 수 없습니다.

요청에 대한 응답의 프로토콜 상태가 사용 가능한 경우 이 필드에 기록됩니다.

프로토콜 상태가 사용 불가능한 경우에는 하이픈(0x002D)이 빈 필드에 대한 자리 표시자로 사용됩니다.
사이트 ID 이 버전의 HTTP API에서는 사용되지 않습니다. 이 필드에는 자리 표시자 하이픈(0x002D)이 항상 나타납니다.
원인 문구 이 필드에는 기록 중인 오류의 유형을 나타내는 문자열이 나와 있습니다. 이 필드는 빈 상태로 있을 수 없습니다.
대기열 이름 이것은 요청 대기열 이름입니다.

아래의 예제 행은 HTTP API 오류 로그에서 가져온 것입니다.
2002-07-05 18:45:09 172.31.77.6 2094 172.31.77.6 80 HTTP/1.1 GET /qos/1kbfile.txt 503 ? ConnLimit 2002-07-05 19:51:59 127.0.0.1 2780 127.0.0.1 80 HTTP/1.1 GET /ThisIsMyUrl.htm 400 ? Hostname 2002-07-05 19:53:00 127.0.0.1 2894 127.0.0.1 80 HTTP/2.0 GET / 505 - Version_N/S 2002-07-05 20:06:01 172.31.77.6 64388 127.0.0.1 80 - - - - - Timer_MinBytesPerSecond

HTTP API가 기록하는 오류 유형

HTTP API는 잘못 처리된 클라이언트에 대한 오류 응답, 연결 시간 초과, 고아 요청 및 삭제된 연결을 기록합니다.

아래의 목록은 HTTP API가 기록하는 오류 유형을 나타냅니다.
클라이언트에 대한 응답 HTTP API는 클라이언트에 대한 오류 응답(예: 마지막으로 받은 요청에서 구문 분석 오류로 인해 발생한 400 오류)을 보냅니다. HTTP API는 오류 응답을 보낸 후 연결을 종료합니다.
연결 시간 초과 HTTP API가 연결 시간을 초과합니다. 연결 시간이 초과될 때까지도 요청이 계속 보류 중이면 이 요청은 오류 로그에서 연결에 대한 자세한 정보를 제공하는 데 사용됩니다.
고아 요청 대기열에 사용자 모드 프로세스로 라우팅되는 요청이 아직 남아 있을 때 프로세스가 예기치 않게 종료됩니다. HTTP API는 오류 로그에 고아 요청을 기록합니다.
특정 오류 형식은 항상 각 오류 행의 마지막 필드로 나타나는 원인 문구 문자열에서 지정됩니다. 아래의 표는 HTTP API 원인 문구를 나타냅니다.

원인 문구 설명

AppOffline "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503). 응용 프로그램 오류로 인해 응용 프로그램이 오프라인 상태가 되었기 때문에 서비스를 사용할 수 없습니다.
AppPoolTimer "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503). 응용 프로그램 풀 프로세스가 사용 중이어서 요청을 처리할 수 없기 때문에 서비스를 사용할 수 없습니다.
AppShutdown "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503). 응용 프로그램이 관리자 정책에 대한 응답으로 자동으로 종료되기 때문에 서비스를 사용할 수 없습니다.
BadRequest 요청을 처리하는 동안 구문 분석 오류가 발생했습니다.
Connection_Abandoned_By_AppPool 핸들을 닫아서 보류 중인 요청의 연결을 끊거나 예기치 않게 종료된 응용 프로그램 풀의 작업자 프로세스
Connection_Dropped 예약됨. 현재 사용되고 있지 않습니다.
ConnLimit "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503). 사이트 수준 연결 한계에 도달했거나 초과했기 때문에 서비스를 사용할 수 없습니다.
Connections_Refused 커널 NonPagedPool 메모리가 20MB 아래로 떨어지고 http.sys가 새 연결 수신을 중단했습니다.
Disabled "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503). 관리자가 응용 프로그램을 오프라인 상태로 만들었기 때문에서 서비스를 사용할 수 없습니다.
EntityTooLarge 엔터티가 허용된 최대 크기를 초과했습니다.
FieldLength 필드 길이 한계를 초과했습니다.
Forbidden 구문 분석 동안 금지된 요소나 시퀀스가 발생했습니다.
Header 머리글에서 구문 분석 오류가 발생했습니다.
Hostname 호스트 이름을 처리하는 동안 구문 분석 오류가 발생했습니다.
Internal 내부 서버 오류가 발생했습니다(HTTP 오류 500).
Invalid_CR/LF 잘못된 캐리지 리턴이나 줄 바꿈이 발생했습니다.
LengthRequired 필수 길이 값이 없습니다.
N/A "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503). 메모리 할당 실패 같은 내부 오류가 발생했기 때문에 서비스를 사용할 수 없습니다.
N/I 알 수 없는 전송 인코딩으로 인해 "구현되지 않음" 오류가 발생했거나(HTTP 오류 501), "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503).
Number 숫자를 처리하는 동안 구문 분석 오류가 발생했습니다.
Precondition 필수 전제 조건이 없습니다.
QueueFull "서비스 사용할 수 없음" 오류가 발생했습니다(HTTP 오류 503). 응용 프로그램 요청 대기열이 꽉 찼기 때문에 서비스를 사용할 수 없습니다.
RequestLength 요청 길이 한계를 초과했습니다.
Timer_AppPool 서버 응용 프로그램이 대기열에서 가져와 요청을 처리할 때까지 요청이 응용 프로그램 풀 대기열에서 너무 오랫 동안 대기했기 때문에 연결이 만료되었습니다. 이 제한 시간은 ConnectionTimeout입니다. 기본적으로 이 값은 2분으로 설정됩니다.
Timer_ConnectionIdle 연결이 만료되어 계속 유휴 상태로 있습니다. 기본 ConnectionTimeout 시간은 2분입니다.
Timer_EntityBody 요청 엔터티 본문이 도착하기 전에 연결이 만료되었습니다. 요청에 엔터티 본문이 있는 경우 HTTP API는 Timer_EntityBody 타이머를 켭니다. 처음에는 이 타이머의 제한이 ConnectionTimeout 값(보통 2분)으로 설정됩니다. 이 요청에서 다른 데이터 표시가 수신될 때마다 HTTP API는 타이머를 재설정하여 연결에 추가적인 2분(또는 ConnectionTimeout에 지정된 시간)을 더 제공합니다.
Timer_HeaderWait 요청에 대한 머리글 구문 분석을 수행하는 데 기본 제한인 2분보다 많이 소요되었기 때문에 연결이 만료되었습니다.
Timer_MinBytesPerSecond 클라이언트가 적절한 속도로 응답을 받지 못했기 때문에 연결이 만료되었습니다. 응답 전송 속도가 기본값인 240바이트/초보다 느렸습니다.
Timer_Response 예약됨. 현재 사용되고 있지 않습니다.
URL URL을 처리하는 동안 구문 분석 오류가 발생했습니다.
URL_Length URL이 허용되는 최대 크기를 초과했습니다.
Verb 동사를 처리하는 동안 구문 분석 오류가 발생했습니다.
Version_N/S 지원되지 않는 버전 오류가 발생했습니다(HTTP 오류 505).

----------------------------------------------------------------------------------------------------
출처: http://support.microsoft.com/kb/820729/ko
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 하이바네.P
STUDY/윈도우2006/12/07 13:46
‡ 오프라인 강의의 보완으로 준비된 것으로, 순수 온라인 강의는 아닙니다 ‡

이 강좌는 HTML,HTTP,인터넷에 대한 조금의 이해가 있는 사람을 대상으로
ASP의 초급과정을 설명하고 있다. 따라서 여기에 나오는 각종 객체,메소드가
전부가 아니고 개발을 위해서는 많은 노력이 뒤따라야 한다 .

ASP란 무엇인가?

한마디로 굳이 표현한다면 "도구"라고 말하고 싶다.

여기까지 오신 분들은 HTML,JAVASCRIPT등에 대해 기초적인 지식을 접하신 분들이라 여겨진다.
웹사이트를 만드는데 HTML로 부족하여 동적인 요소를 추가하기 위해 JAVASCRIPT를 활용하듯이 이런 것들로도 부족한게 있어 ASP라는 도구를 사용하는 것이다.

여기서 부족하다는 것은 서버측이 가진 데이타베이스를 활용한 웹서비스 필요성에 의해 그 도구로써 ASP가 탄생된 것이다. 데이타베이스의 기능인 데이타의 기록,수정,삭제,조회를 웹을 통해 할 수 있도록 하는 도구인 것이다.

모든 도구는 사용상의 주의점과 사용방법을 익히지 않으면 제대로 사용하지 못한다.

ASP도 마찬가지로 어떻게 사용해야 하는지, 어떤 기능들을 갖고 있는지 살펴봐야 한다.

쉽게 기존의 웹문서에 또 추가되는 테그가 생겼다고 생각하면 된다.

이것이 추가되면 일단 변하는 두 가지가 있다.

1. 웹문서의 확장자가 바뀐다.
2. 웹서버를 통해서만 결과를 볼 수 있다.


MS의 웹서버 IIS는 사용자의 페이지 요청이 있으면 먼저 확장자 체크를 한다.
확장자가 만약 .asp 면 서버는 이 문서의 파싱(해석 실행)을 asp.dll이란 라이브러리에게 맡겨 사용자 브라우저가 이해할 수 있도록 html로 변환을 시킨 다음 응답을 함으로써 사용자 브라우저의 종류가 무엇이든 간에 asp문서의 결과를 볼 수 있는 것이다.
(html문서는 이런 과정없이 요청을 받으면 그냥 내보내 준다)

그럼 ASP 특징에 대해 알아보면

Microsoft사의 WebServer인 IIS(Internet Information Server)의 세번째 버전으로
IIS 3.0에서 처음 등장하여 ASP로 불리다가 현재 IIS 5.0 즉, ASP 3.0에 이르고 있다.

첫째, ASP는 서버 스크립트언어이다
클라이언트의 요청이 있을 때 ASP는 서버측에서 실행되고 실행된 결과만 HTML로 바꾸어 클라이언트의 브라우저에 보내준다

둘째, HTML문서에 서버 스크립트(ASP)와 클라이언트 스크립트(JavaScript,VBScript)가 포함된 웹페이지라고 할 수 있다. ASP는 기존의 클라이언트 브라우저가 처리하던 HTML부분과 클라이언트 스크립트 부분은 여전히 클라이언트에게 맡기고 ASP코드가 있는 부분만 서버에서 실행된다

세째, 서버 컴포넌트(Active Server Component)를 사용할 수 있다
스크립트의 한계를 극복하고 그 기능을 엄청나게 향상시켜 주는 것이 바로 컴포넌트를 사용할 수 있다는 것이다. ASP에 내장된 것 뿐만 아니라 외부 컴포넌트도 얼마든지 사용하여 그 기능을 향상시킬 수가 있다

스크립트는 실행위치에 따라 다음과 같이 나누어진다

1) 클라이언트측 스크립트

웹서버의 부담.네트워크의 교통량 감소를 위해 개발되었고, 클라이언트 컴퓨터에서 실행
JavaScript 브라우저 호환성이 좋아 가장 많이 사용되며 넷스케이프와 썬사에 의해 개발
VBScript 비쥬얼베이직의 부분집합으로 MS사가 개발,익스플로러에서 실행된다
JScript JavaScript를 기반으로 MS사에서 개발

2) 서버측 스크립트


클라이언트측 스크립트의 반대개념으로 서버측에서 실행,결과만 클라이언트로 전송, 언어에 따른 구분이 아니라 스크립트언어의 실행위치에 따른 구분이다
VBScript 클라이언트측 스크립트언어로 개발되었으나 사용자들이 익스플로러와 넷스케이프 양대 브라우저에서 실행되는 JavaScript를 선호하여 인기를 끌지 못했다
그러나 서버측 스크립트 언어의 등장으로 각광을 받기 시작 했는데 이는 브라우저 호환성 문제가 발생하지 않기 때문이다
ASP VBScript언어를 기본 언어로 사용한다
JScript JavaScript를 기반으로 MS사에서 개발했다
PHP Personal Home Page, LInux운영체제에서 동작한다
JSP Java Server Page, JAVA를 기반으로 플랫폼 독립적이다
 

ASP의 일반적인 페이지구성은 다음과 같다.

<%

...ASP코드...

%>
->서버측에서 실행
<script language="javascript>

... 클라이언트 스크립트 코드...

</script>
->클라이언트측에서 실행
<html>
<body>

...HTML코드...
->클라이언트측에서 실행
<%

...ASP 코드...

%>
->서버측에서 실행
...HTML 코드

</body>
</html>
->클라이언트측에서 실행
 

따라서 asp문서라고 하면
1. 순수 100%의 html문서를 asp문서로 저장하는 경우
2. 기존 html문서에 ASP코드가 섞인 형태의 asp문서
3. 순수 ASP코드만 가진 asp문서


ASP의 특징

☞ 확장자가 .asp인 TEXT파일이다 HTML과 마찬가지로 일반텍스트에디터로 편집이 가능하다
☞ 파서(해석기)는 asp.dll이 담당한다 IIS등록정보에서 응용프로그램 맵핑을 살펴보기 바란다
☞ 대소문자 구분을 하지 않는다 그래도 구분하여 쓰는 습관이 좋다
☞ 웹서버를 통해 실행시켜야한다 탐색기나 브라우저에서 파일열기로는 볼 수 없다
☞ 전부 HTML로만 된 페이지도 .asp로 저장할 수 있다 웹서버의 성능이 향상되어 속도 저하는 없다고 한다. 나중에 서버측 지시태그나 asp요소가 들어올 확률이 많다.
실제로 asp로 작업시 html확장자는 거의없다고 보면 된다.
 


개발/서비스 환경

☞ 환경 준비

운영체제(OS) Web Server DataBase
Windows95,98 PWS(Personal Web Server) Access Database
Windows NT서버 IIS3.0 이상(4.0 옵션팩 설치) Access Database
SQL 서버
Windows2000프로 IIS5.0 사용자/추가 설치 Access Database
SQL 서버(퍼스널)
Windows2000서버 IIS5.0 기본 설치 Access Database
SQL 서버
Windows2003서버 IIS6.0 추가 설치 Access Database
SQL 서버

* PWS의 설치

Windows 98의 경우 시작-찾기에서 검색어를 "PWS" 찾을 위치를 "C:\"로 해서 찾아보면 PWS 폴더를 찾을 수 있다. 폴더속의 setup.exe를 더블클릭하면 설치가 시작된다.

* 없는 경우는 원본CD(메이커 시디는 처음부터 없을 수도)를 넣고 프로그램 추가/삭제에서 설치할 수 있다

* Windows2000에서는 기본설치가 되므로 '관리도구->인터넷서비스관리자'를 확인한다

* 환경설정은 사이트/가상디렉토리를 만든다 (메인에 그림강좌준비)

가상디렉토리란 사이트내에 작은 사이트를 말한다. 예로 사이트와는 다른 물리적 폴더에 있는 파일을 사이트에 편입시켜 서비스 하고자 한다면 가상디렉토리가 유용하다.

IIS에서 작업한다면 가급적 웹사이트를 만들도록 한다

IP:지정하지 않음
PORT:8000 이상 임의로
HOST HEAD: 없음
 
출처:구글의 어느곳;;
 
크리에이티브 커먼즈 라이선스
Creative Commons License
Posted by 하이바네.P
STUDY/서버전반2006/11/24 09:10

  • 깨진 한글 메일 되살리기
  • 받은 E-Mail의 한글이 깨졌을 때는 먼저 깨어진 mail을 Windows의 Clipboard로 복사한 다음 cvt8.exe을 Windows상에서 실행시킨 후 ISO2022-KR 이나 다른 메뉴들을 click하여 보면 한글이 되살아 난다. 이 software에는 되살려낸 mail을 저장하거나 edit하는 방법이 들어있지 않다. 그러나 mouse를 이용하여 mail의 전 내용을 block으로 잡은 다음 "Ctrl + C"를 하여 clipboard로 복사한 후 원하는 곳에 paste하면 된다. [Windows 3.1, Windows 95 모두 O. K.; (Software from Prof. B. Ahn's Home Page)]

  • MIME Type Problems
    1. 어떤 종류의 file들은 web server에 올려두고, 전송받아보면 format이 깨어져서 오는 수가 있다. 이것은 대다수의 경우 web server에 그 file의 MIME Type이 등록이 되어 있지 않기 때문이다. 이 문제는 아래와 같은 방법 중의 하나로 해결할 수 있다.

    2. Editing mime.types file in HTTPD
    3. 이 문제의 근본적인 해결 방법은 그 file의 MIME type을 httpd의 "conf" directory 의 mime.types file 에 mime_type/subtype 및 file_extension 을 올리는 것이다.
      예를 들어 아래한글 문서의 MIME type은 server program에 default로 등록되어 있지 않으므로, mime_type/subtype은 application/x-hwp, file_extension은 hwp로 하여
          application/x-hwp         hwp
      와 같이 등록하면 된다. 또 html문서의 mime_type/subtype은 text/html인데 file extension은 default로는 보통 html 한 가지만 등록되어 있어 *.htm file은 그냥 text file로 보여주는데,
          text/html                 html htm
      과 같이 file extension에 htm을 추가하면 제대로 HTML 문서로 보여준다.

      이와같이 mime.types file을 고친 후에 web server를 다시 가동시켜야만 수정한 것이 제대로 작동한다. 그러나 이렇게 한 후 Netscape으로 다시 test 해보아도 해당 file의 format을 제대로 인식하지 못하는 것처럼 보일 때가 있다. 이것은 server가 아니라 browser의 잘 못이다. Browser의 memory cache / disk cache (Netscape: Options ---> Network Preferences) 를 지우고 다시 test해 보면 정확히 작동할 것이다.

    4. Making .htaccess file in user account
    5. 위의 방법은 근본적인 해결책이기는 하나 mime.types file에 access할 수 없는 일반 user들은 system 관리자를 통해야 하므로 과정이 복잡하고 시간이 많이 걸릴 수 있다. 이런 때는 아래와 같이 간단히 개인 차원에서 해결할 수 있다.
      Web server가 Apache 또는 NCSA 인 경우, 자신의 account의 htdocs directory에 .htaccess 라는 이름의 file을 만들고, 거기에

      AddType mime_type/Subtype extension

      와 같이 mime type을 등록하면 된다. (physics.hallym.ac.kr, blue.hallym.ac.kr 모두 해당됨). 구체적인 예를 들면

      AddType audio/midi mid
      AddType image/cgm cgm

      와 같다. 이 방법은 httpd의 mime.types file에 직접 access 할 수 없는 개별 user들이 쓰기에 편리하고, 해당 user 한 사람의 htdocs directory 내에 있는 file에만 유효하며, httpd를 다시 가동시키지 않아도 된다.

    6. Using FTP
    7. 위의 방법을 사용할 수 없는 경우에 FTP를 이용할 수도 있다. FTP 로 불러오는 file들은 mime type 문제를 일으키지 않는다. (PC에 있는 file들이 MIME type 문제를 일으키지 않는 것도 같은 이유임.) 따라서 FTP server에 file을 올릴수 있으면 그렇게 한 다음, web문서에 link 시키거나 embed하면 된다. 그러나 공개 FTP server에 보통의 user들은 file을 올릴 수 없으므로 효과적인 방법은 못된다.

    8. Reference

    출처 : http://www.hallym.ac.kr/~physics/course/96/st96-2/tips/itips.html

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

    'STUDY > 서버전반' 카테고리의 다른 글

    XSS에 관한 기사  (0) 2006/12/08
    유용한 팁.  (0) 2006/11/24
    Posted by 하이바네.P