지난 시간에 우리는 ASP 에서 사용자(클라이언트) 들에게 정보를 입력받는
여러가지 방법에 대해서 생각해 보았습니다.
HTML 의 콘트롤들을 이용하여 사용자들에게 정보를 입력 받고,
그 내용을 ASP 페이지에서 확인해 보았었지요. (너무 오래되어서 다 까먹으셨다고요? ㅜ.ㅜ)
자, 그럼 오늘은 ASP 에서 주로 사용되는 개체들에 대해서 생각해 보고자 합니다.
(이것을 유식한 말로 ASP 개체 모델이라고 합니다.)
'ASP 개체 모델' 이라.. 웬지 무언가 복잡해질 것 같은 예감이 드시나요?
개념적인 이야기가 많이 나올것 같기는 하지만 너무 겁먹으실 필요는 없습니다.
지난 강좌에서 우리는 사용자들에게 여러가지의 방법으로 정보를 입력 받아
그 내용을 화면에 출력해주는 방법을 살펴 보았습니다.
입력받은 정보를 화면에 출력할 때 어떻게 했는지 혹시 기억하시나요?
네. 우리는 Response.Write 라는 함수를 사용해서 그 정보를 화면에 출력했었습니다.
Response.Write 라는 함수가 어떻게 만들어졌으며, 왜 작동하는지는 잘 모르겠지만
어쨌든 우리는 Response.Write 라는 함수를 쓰면 우리가 원하는 내용이
화면(웹브라우저)에 고스란히 출력된다는 사실을 알게 되었습니다.
우리가 만들지 않았지만 그냥 사용하기만 하면 된다고 하니.. 참 편리하지 않습니까?
그렇다면 공짜 좋아하는 우리들은 또 다른 궁금증이 생길 법도 합니다.
그렇다면 이것 이외에도 또 이용할만한 다른 기능들은 없을까? 하고 말이지요.
네. 물론 있습니다.
ASP 에서는 프로그램을 짜는 사람들이 쉽게 프로그래밍을 할 수 있게 하기 위하여
여러가지 기능들을 이미 만들어 놓고, 그것들을 사용하라고 권장하고 있습니다.
그리고 이 기능들을 종류별로 묶어서 7가지 '개체' 를 만들어 놓았습니다.
이것을 바로 'ASP 개체 모델' 이라고 부르는 것입니다.
오늘 강좌에서는 바로 그 'ASP 개체 모델' 에 대해서 살펴보고자 하는 것입니다.
ASP 에서 사용되는 7가지의 개체 모두를 한번에 자세하게 설명드리긴 어렵고요.
오늘은 어떤 개체들이 있으며, 무슨 역할을 하는지에 대해서만 살펴보도록 하겠습니다.
어떻습니까? 어디서 좀 본듯한 개체들도 있고, 생전 처음보는 개체들도 있을 법 하군요.
자, 그렇다면 이제부터 각각의 개체들에 대해서 간략하게 알아보도록 하겠습니다.
Active Server Pages 개체 모델
1.
Request 개체
Request 의 사전적인 뜻은 '요청하다, 요구하다' 입니다.
만약 어떤 클라이언트(사용자)가 웹 브라우저를 열고 주소창에 제 사이트 URL 인
'http://www.dukyoung.net' 을 입력하고 엔터를 눌렀다고 한다면 이 사용자는
제 사이트의 웹서버에 '니네 사이트 페이지를 보여줘' 라는 요청을 한 것입니다.
Request 개체는 이처럼 클라이언트가 웹서버에 전달한 정보를 검색할 때 사용되는 개체인데요.
이 개체를 이용하면 다음과 같은 작업들이 가능합니다.
1. 클라이언트가 URL 의 뒤에 추가한 정보를 저장한다. (GET 방식)
2. 클라이언트가 FORM 태그를 이용해 전달한 정보를 저장한다. (GET, POST 방식)
3. 클라이언트에서 전달한 쿠키 값을 저장한다.
4. 클라이언트에서 전달한 보안 코드를 저장한다.
5. 웹서버 자체에 대한 일반 정보(HTTP 서버 변수)를 저장할 수 있다.
3번 항목에서 쿠키라는 생소한 용어가 나왔는데.. 이것은 먹는 쿠키가 아닙니다. -_-a
여기서 말하는 쿠키란, '클라이언트에게 저장되는 특정한 정보'를 의미합니다.
일단 이정도만 알아두시고.. 자세한 내용은 나중에 자세히 다루도록 하겠습니다.
그나저나 Request 개체에 대해서 이렇게 풀어 쓰니까 좀 난해해 보이는군요.
요약하면 '클라이언트가 전달한 정보를 검색할 때 주로 사용하는 개체' 가 되겠습니다.
2.
Response 개체
Response 의 사전적인 의미는 '응답하다' 입니다. (Request 와 상대적 개념)
즉 Response 개체는 서버가 클라이언트에게 응답할 때 사용되는 개체인데요.
이 개체를 이용하여 다음과 같은 작업들을 할 수 있습니다.
1. 클라이언트로 전달되는 페이지에 정보를 추가한다.
2. 클라이언트에 쿠키를 만들기 위해 클라이언트의 웹브라우저에 정보를 전달한다.
3. 요청한 페이지가 아닌 전혀 다른 페이지로 이동(재지향)시킨다.
4. 페이지 생성과 동시에 정보를 전달할지, 생성된 다음 정보를 전달할지를 결정한다.
5. 페이지의 속성(HTML 헤더, 타입)들을 제어하고 변경한다.
결국 Response 개체라는 녀석은 '웹서버에서 클라이언트로 정보를 어떤 방식으로
보여줄지를 결정하는 개체' 라고 생각하시면 되겠습니다.
3.
Application 개체
Application(어플리케이션) 이란 상당히 개념적인 단어입니다.
굳이 말로 풀어 설명하자면 '하나의 프로그램 전체' 라고 하면 될까요?
Application 의 개념을 설명하기 위해 예를 한자기 들어보겠습니다.
제가 컴퓨터 게임인 피카츄 배구를 시작했다고 가정하겠습니다. (무지 재밌습니다.)
이렇게 게임이 새로 시작되었을 때 '게임 Application이 실행되었다' 라고 표현합니다.
열심히 게임에 몰두하고 있을 즈음, 옆에서 시큰둥하게 지켜보던 우리 형이
'저리루 가봐, 나도 하자' 라고 하면서 2인용 버튼을 클릭했습니다.
자, 그럼 퀴즈입니다. 이때 이 '게임 Application' 은 실행된 것일까요?
물론 아닙니다. 이미 게임은 진행중이므로 사용하는 인원이 한명 증가한 것 뿐이지
'게임 Application' 이 새롭게 시작된 것은 아니라는 말씀입니다.
열심히 싸우다가 결국 제가 형에게 아쉽게 지고 말았습니다.
그래서 패자는 말없이 떠나고 형은 계속 1인용 게임을 즐기고 있습니다.
자, 그렇다면 지금 이 경우 'Application이 종료되었다' 라고 말할 수 있을까요?
네, 이것도 물론 아닙니다. 아직 게임 프로그램이 종료되지 않았기 때문입니다.
저희 형이 혼자서 하던 게임을 끝내고 그 게임의 창을 완전히 종료했을 때,
그제서야 '게임 Application 이 종료' 되는 것입니다.
즉, 게임이 처음 시작되었을 때가 'Application 이 시작된 때' 이고,
창을 닫아서 게임이 완전히 종료되었을 때가 'Application 이 종료된 때' 입니다.
웹사이트에서도 이 내용은 마찬가지 방식으로 적용됩니다.
누군가가 처음 웹서버에 접근했을 때, 해당 '웹서버 Application' 이 작동하게 됩니다.
그리고 중간에 여러 사람들 - 셀 수 없이 많은 사람들 - 이 웹서버에 접근하겠지만,
이때마다 Application이 실행되는 것은 아닙니다. 처음 한번만 실행되는 것이지요.
모든 사람들이 웹서버에서 빠져나가면, 그제서야 Application이 종료가 됩니다.
(사실 바로 종료되는 것은 아닙니다만.. 일단은 그렇게 알아두셔도 됩니다.)
Application 개체는 이처럼 웹 어플리케이션이 시작하거나 종료할 때,
지정된 특정한 작업을 수행하기 위해 주로 사용되는 개체입니다.
또한 Application 개체는 어플리케이션의 모든 영역에 걸쳐 있는 특성 까닭에
해당 사이트에 접속해 있는 모든 사용자들이 접근할 수 있는 상태 정보를
- 이것을 전역 변수라고 합니다 - 저장할 때도 유용하게 사용됩니다.
4.
Session 개체
우리는 바로 위 3번 항목에서, Application 개체는 클라이언트들이 공통으로
사용하는 정보를 보관하는 역할을 하는 개체라는 사실을 알았습니다.
그렇다면 센스 있는 분들은 이런 질문을 하실 지도 모르겠습니다.
'공통으로 사용하는 정보라면 Application 개체를 이용하여 저장하면 된다고 하고...
그렇다면 방문자마다 각각 다른 정보를 저장하고 싶으면 어떻게 하지?' 라고 말이지요.
물론 좀전에 배운 Application 개체를 굳이 이용하여, 방문자가 증가할 때마다
Application 레벨의 변수(전역 변수)를 추가해 주는 방법도 있을 수 있습니다.
하지만 이 경우 방문자가 늘어날수록 어마어마한 양의 전역 변수가 쌓이게 될 것이고,
각 사용자를 위한 전역 변수를 추가하기 위해 복잡한 코드가 추가되어야 할 것이며,
사용자가 그 사이트를 떠나버리는 경우, 해당 사용자와 관련된 전역 변수를 찾아
그 변수들을 삭제해 주어야 하는 과정도 있어야할 것입니다.
(뭔지는 몰라도 하여튼.. 그렇게 해서는 안되겠구나~ 싶어지지 않나요? ^^)
그래서 ASP 에서는 '각 방문자들을 위한 개인적인 정보 저장 공간' 을 제공합니다.
이 공간을 담당하는 개체가 바로 Session 개체인 것입니다.
이 Session 개체는 매우 유용하게 사용됩니다.
여러분께서 메일이나 동호회 사이트로 가시면 가장 먼저 무엇을 하시나요?
그렇습니다. 여러분은 스스로를 증명하기 위해 가장 먼저 '로그인' 을 하게 됩니다.
이때 우리가 입력한 아이디와 정보가 서버에 있는 Session 개체에 저장되기 때문에,
페이지를 이동할 때마다 로그인 할 필요 없이, 처음 단 한번만의 로그인 만으로
해당 웹 사이트를 여러분 마음대로 돌아다닐 수 있는 것입니다.
('어라? 요즘은 Session 안쓰고 쿠키 쓰는데?' 라고 하시는 분이 계실지도 모르겠네요.
물론 그렇습니다. 하지만 이것은 Session 개체의 역할 설명을 위한 것이니까요.
'그래그래~' 하시며 고개 한번 끄덕이고 넘어가 주시면 감사하겠습니다. ^^)
5.
Server 개체
Server 개체는 '서버 상에서 특정한 작업들을 실행하는' 개체라고 할 수 있습니다.
개체의 이름에서 느껴지듯이 이 개체는, 클라이언트와는 별 상관 없이
웹서버의, 웹서버에 의한, 웹서버를 위한 작업을 하는 개체가 되겠습니다.
그렇다면 이 Server 개체는 도대체 어떤 작업들을 하는 걸까요?
Server 개체가 하는 작업들을 요약해 보면 다음과 같습니다.
1. 페이지가 너무 오래 뜨지 않는 경우를 대비, 한계 시간을 설정한다.
2. 사용자가 전달한 문자열을 HTML 형식으로 변경한다.
3. 사용자가 전달한 문자열을 올바른 URL 문자열의 형식으로 변경한다.
4. 가상 경로(URL)를 서버 컴퓨터의 실제 경로로 변경한다.
5. 다른 페이지로 이동하여 실행 경로를 변경한다.
6. CreateObject 라는 메소드를 사용하여 컴포넌트의 인스턴스를 생성한다.
무슨 뜻인지 잘 이해가 안가더라도 너무 신경쓰지 마시고 그냥 보시기 바랍니다.
여기에 대한 자세한 내용은 Server 개체를 자세하게 다룰 때 말씀드리도록 하겠습니다.
6.
ObjectContext 개체
이 개체를 말씀드리려면 '트랜잭션(Transaction)' 의 개념을 이해하셔야 하는데요.
트랜잭션이란 쉽게 말씀드리자면 '전부 아니면 전무' 의 작업 단위입니다.
(영어 좋아하시는 분들은 이것을 'All or Nothing' 이라고 하더군요.)
트랜잭션을 설명하기 위해 가장 많이 예로 사용하는 것이 바로 은행인데요.
예를 들어보면 이렇습니다. 아래의 그림을 봐 주시기 바랍니다.
제가, 저희 형에게 만원을 인터넷 뱅킹으로 보낸다고 가정해 보겠습니다.
제가 만원을 선택하고 '계좌이체' 버튼을 클릭하면, 제 계좌에서는 만원이 빠져 나가고
그 순간 저희 형 계좌에는 만원이 입금 되어야 할 것입니다.
그런데 만약 은행의 인터넷 뱅킹 시스템에 순간적으로 이상이 생기는 바람에,
제 계좌에서 만원은 나갔는데 형의 계좌에는 만원이 입금되지 않았다면 어떻게 될까요?
이러면 이제 난리나는 겁니다. (은행은 대략 낭패~!)
은행에 전화 걸고 내 돈 내놓으라고 고래고래 소리 지르겠지요.
심한 경우 그 은행을 믿지 못하게 되어, 거래 은행을 바꾸게 될지도 모릅니다.
이처럼 '반드시 동시에 이루어져야 하는 작업'의 경우에 '트랜잭션' 을 사용합니다.
제가 형에게 만원을 계좌 이체로 송금했을 때, 제 계좌에서 만원이 빠져나가고
형의 계좌에서 만원이 더해지는 일은 반드시 둘다 성공해야 하는 일입니다.
만약 도중에 문제가 생기면 모든 것이 송금 전의 원래 상태로 돌아와야 하는 것이지요.
ObjectContext 개체는 이 트랜잭션을 시작하거나 종료할 때 사용하는 개체입니다.
하지만 이 개체는 IIS 의 버전이 5.0 (Windows 2000)으로 올라가면서
그 필요성이 줄어들었고, 대부분의 사이트가 Windows 2000 이상을 사용하는
현재에는 거의 사용하지 않는 추세입니다.
7.
ASPError 개체
ASPError 개체는 에러 처리 작업을 위해 ASP 3.0 에서 추가된 개체입니다.
(따라서 Windows 2000 을 사용하는 분이라면 큰 상관이 없겠습니다만,
혹시 Windows NT 4.0 을 사용하시는 분이라면 이 개체의 사용은 불가능합니다.)
이 개체는 ASP 에서 발생한 마지막 에러에 대한 자세한 정보를 제공해 주는데요.
덕분에 우리는 ASPError 개체를 이용하여 ASP 에서 발생하는 에러 메시지를
이전보다 조금 더 정교하게 처리할 수 있게 되었습니다.
하지만 초보자인 우리들이 자주 접하게 될 개체는 아닌 까닭에,
여기서는 더 이상의 추가 설명은 생략하도록 하겠습니다.
오늘은 ASP 에서 사용되는 7가지의 개체에 대해서 알아보았습니다.
자세하게 설명드리기에는 각각의 분량이 너무 방대해서 간략하게 말씀드렸는데요.
때문에 약간 지루한 부분이나 이해가 안가는 부분도 있으셨을 거라는 생각이 듭니다.
그래서 다음 시간부터는 이 7가지의 개체 중에서 중요한 개체들을 추려서
해당 개체의 속성과 메소드 등의 정보를 세밀하게 살펴보는 시간을 가지도록 하겠습니다.
지난 시간에 우리는 7가지 ASP 개체 모델에 대해서 알아보았습니다.
Request, Response, Application, Session, Server, ObjectContext, ASPError
개체들이 바로 우리가 지난 시간에 만나본 친구들이었지요.
오늘은 이 개체들 중에서 Request 개체에 대해서 조금 자세히 알아보고자 합니다.
사실 이 Request 개체는 지금까지의 강좌 중에서도 알게 모르게 많이 사용되었지요.
(꽤 많이 사용했던 것 같은데... 전혀 모르시겠다고 한다면 곤란합니다. ㅜ.ㅜ)
ASP 를 공부하다 보면 좋건 싫건 가장 많이 접하게 되는 개체 중 하나인 Request 개체.
그럼 지금부터 한번 본격적으로 살펴보도록 하겠습니다.
Request 개체.. 많이 들어보긴 한 것 같은데 도무지 뭐하는 녀석인지 모르시겠다고요?
Request 개체가 하는 주요 업무는 클라이언트(사용자)가 서버로 정보를 보낸 다음..
'클라이언트(사용자) 웹 브라우저가 서버로 전달한 값을 검색' 하는 일이 되겠습니다.
여기서 중요한 것은 '전달한 값들의 검색을 누가 하는가' 인데요.
과연... '클라이언트' 일까요? '서버' 일까요? (대충 찍어도 확률은 50% 되겠습니다. ^^)
정답은 '서버' 입니다. 클라이언트가 보내준 정보를 서버측면에서 검색하는 것이지요.
혹시 잠시라도 '클라이언트' 라고 생각하셨던 분들은 밑의 설명을 자세히 읽어주시기 바랍니다.
이해를 돕기 위해 예를 하나 들어보겠습니다.
'나는 내 정보가 드러나는 게 싫으니까 내가 누군지 절대로 정보를 보내지 말아야지...'
이런 생각을 가지고 은밀한(?) 사이트에 주로 드나드는 K군이 있다고 가정해 보겠습니다.
이 분이 어느 날 제 사이트인 www.dukyoung.net 사이트에 접속을 시도했습니다.
그리고 사이트 초기 화면을 보았더니,
은밀한(?) 정보와는 거리가 있는 듯 싶어서,
아무 행동도 하지 않고 바로 브라우저를 닫아 버렸습니다. (역시 건전한 사이트!)
그리고는 '난 아무런 정보를 보낸 적이 없으니,
그 사이트에서는 내가 왔다 갔는지 알아차릴 수 없었을걸?' 이라고 생각하며 혼자 좋아 했습니다.
과연 그럴까요? 위의 내용은 모두 옳은 말일까요?
정답은 '아니다. 알 수 있다!' 입니다.
물론 제가 단지 이 정도로 K군의 아이디나 비밀번호 같은 민감한 정보를 알아낼 수는 없습니다.
하지만 잠깐의 접속으로 인해,
K군이 접속했던 컴퓨터의 IP 주소와 K군이 사용한 웹 브라우저가 어떤 것인지..
등등의 정보를 알 수 있습니다.
설령 K군이 자신의 정보 노출을 원하지 않았다고 하더라도 말이지요.
이렇듯, 서버는 단지 클라이언트의 접근을 통해서도 기본적인 몇몇 정보를 가져갈 수 있습니다.
당연한 이야기지만, 만약 K군이 제 사이트에서 아이디와 비밀번호를 입력한 후 로그인을 시도했다면 그 정보도 또한 서버에서 가져갈 수 있게 됩니다.
이렇듯 서버의 입장에서 봤을 때 '클라이언트들이 보내온 정보를 검색할 때 사용하는 개체'.
이것이 바로 Request 개체인 것입니다.
이 Request 개체에는 5개의 컬렉션과 1개의 속성, 1개의 메소드가 존재 합니다.
속성과 메소드라는 단어는 이전에 언급한 적이 있었지만.. 컬렉션이라는 단어가 조금 낯설군요.
컬렉션이라는 녀석은 예전에 배웠던 '배열' 과 상당히 유사하다고 생각하시면 됩니다.
컬렉션과 배열의 차이점이라면.. 배열은 '인덱스번호/데이터' 한 쌍을 사용하지만,
컬렉션은 '이름/데이터' 형식의 한 쌍을 사용한다는 점입니다.
컬렉션과 배열의 차이에 대해 이해하기 쉽도록 예를 들어보자면 다음과 같습니다.
배 열 : 배열이름(인덱스) = 데이터 ex) arrResult(0) = "김덕영"
컬렉션 : 컬렉션이름(이름) = 데이터 ex) Request.QueryString("name") = "김덕영"
좋습니다. 그러면 이제 모든 준비가 끝났습니다.
과연 Request 개체의 멤버에는 어떤 것들이 있는지 다음 표를 살펴 보도록 할까요?
Request 개체의 멤버들
1. 컬렉션(Collection)
1.1 QueryString 컬렉션
Request 개체 중에서 가장 많은 사용 빈도수를 자랑하는 컬렉션이며,
<FORM>태그 안에 있는 모든 HTML 컨트롤 요소들의 값을 저장하는 컬렉션입니다.
(이때 FORM 태그의 METHOD 는 GET 방식이어야 합니다.)
또한 URL 의 뒤에 '이름/데이터' 형식으로 전달되는 값들을 저장하는 역할도 합니다.
예를 들어 다음 URL 을 주소창에 입력했다고 가정해 보겠습니다.
http://www.dukyoung.net/test.asp?first=kim&second=dukyoung
이 경우..
Request.QueryString("first") 에는 "kim" 이라는 값이 저장되며,
Request.QueryString("second") 에는 "dukyoung" 이라는 값이 저장됩니다.
상당히 간결하고도 유용한 방법이므로 잘 기억해 두시는 것이 여러모로 좋겠습니다. ^^
1.2 FORM 컬렉션
QueryString 과 함께 가장 많이 사용되는 FORM 컬렉션은, QueryString 과 마찬가지로
<FORM>태그 안에 있는 모든 HTML 컨트롤 요소들의 값을 저장하는 컬렉션입니다.
(하지만 FORM 태그의 METHOD 는 반드시 POST 방식이어야만 합니다.)
QueryString 컬렉션처럼 주소(URL) 뒤에 '이름/데이터' 형식으로 값을 전달하여 저장하는 방식을 사용할 수 없다는 것이 QueryString 컬렉션과의 또 하나의 차이점이 되겠네요.
Request.QueryString 과 Request.Form 컬렉션에 대해서는 이전 강좌에서 언급한 적이 있었습니다. 혹시 복습을 원하신다면 다음 링크를 클릭해 주세요. (복습할래요!)
1.3 Cookies 컬렉션
이 컬렉션은 지난 시간에 잠깐 언급했던 '쿠키' 와 관련된 컬렉션입니다.
(먹는 쿠키가 아니라는 말씀은 이미 지난 시간에 드렸습니다만.. 쿨럭~)
웹서버는 클라이언트(사용자)들의 컴퓨터에 txt 파일 형식의 정보를 저장할 수 있습니다.
Request 개체의 Cookies 컬렉션은 이렇게 사용자 컴퓨터에 저장된 클라이언트의 정보를 읽어오는(누가? 서버가! 혼동하시면 안됩니다.) 역할을 담당합니다.
쿠키가 무엇인지에 대한 쉬운 예를 하나 들어보겠습니다.
여러분들이 어떤 사이트를 찾아 가서 로그인을 했다고 가정해 보겠습니다.
며칠 후 다시 그 사이트를 찾아갔을 때, 내 아이디가 이미 자동으로 입력되어 있는 현상을 혹시 겪어보신 분들이 있으신지요? (요즘 많은 사이트에서 이런 기능을 제공하지요.)
바로 이런 경우가 쿠키가 사용된 예입니다.
처음 사이트에 접근하여 로그인을 했을 때, 서버에서는 그 사용자의 아이디를 클라이언트(사용자) 컴퓨터에 저장합니다. 그리고 그 이후에 다시 그 사용자가 사이트에 들어오면 Request.Cookies 컬렉션을 이용하여 그 사용자의 아이디를 읽어오는 것입니다.
그렇다면 그 txt 파일은 어디에 있을까..? 살짝 궁금증이 생길만도 하겠네요.
그 저장 장소를 알고 싶으시면 일단 인터넷 익스플로러를 띄우시고요.
상단 메뉴 중 '도구 -> 인터넷 옵션 -> 설정 -> 파일 보기' 를 클릭하시면 됩니다.
혹시 어디인지 잘 모르시겠다면 다음 그림을 참고하시면 되겠습니다.
장소도 알았으니.. 모두들 같이 한 번 찾아 볼까요?
어떻습니까? 생각보다 많은가요? 만약 많다면 그만큼 많은 사이트에서 쿠키를 사용하여 여러분들의 컴퓨터에 정보를 저장한다고 생각하시면 됩니다.
자, 그럼 정리하겠습니다. 사용자의 컴퓨터에 저장된 쿠키 정보를 서버측에서 검색할 때 사용되는 컬렉션이 바로 Cookies 컬렉션이 되겠습니다.
1.4 ServerVariables 컬렉션
오늘 강좌의 첫 부분에서 은밀한(?) 사이트를 좋아하는 K군 이야기를 잠시 했습니다.
클라이언트(사용자)의 의사와는 상관없이 서버에서는 클라이언트의 몇몇 정보들을 알아낼 수 있다는 말씀을 드렸는데요.
바로 이 때 사용되는 개체가 종합선물세트인 'ServerVariables' 컬렉션입니다.
이 컬렉션은 클라이언트(사용자)가 서버로 값을 전달할 때 자동적으로 함께 전달되는 HTTP 헤더값들과, 웹 서버 자체의 몇 가지 환경 변수 값들을 저장합니다.
무슨 말인지 잘 모르시겠다고요? 괜찮습니다. 사실 이 ServerVariables 컬렉션은 백 번 말하는 것보다 직접 한 번 보시는 것이 이해하기가 가장 쉽거든요.
그러면 아래 버튼을 클릭하셔서 이 컬렉션내의 모든 변수를 살펴 보도록 하겠습니다.
참고로 ServerVariables 컬렉션내의 모든 변수를 살펴보는 ASP 소스는 다음과 같습니다.
[servervariables.asp]
<TABLE BORDER>
<TR>
<TD><B>Server Variable</B></TD>
<TD><B>Value</B></TD> </TR>
<% For Each strKey In Request.ServerVariables %>
<TR>
<TD><%=strKey %></TD>
<TD><%=Request.ServerVariables(strKey) %> </TD>
</TR>
<% Next %>
</TABLE>
1.5 ClientCertificate 컬렉션
가끔 어떤 사이트에 들어가보면 '인증', '보안' 어쩌구하는 사이트들을 만나실 수가 있습니다.
그 사이트들의 주소를 유심히 살펴보면 주로 'http://' 가 아닌 'https://' 로 시작하는데요.
이 사이트들은 아무나 들어오지 못하게 하기 위한 '사용자 인증 요구' 를 하게 됩니다.
이때 클라이언트의 브라우저에서는 서버로 지정된 인증 필드들을 전송하게 되는데, 이 정보들이 저장되는 콜렉션이 바로 ClientCertificate 콜렉션입니다.
무슨 말인지는 잘 모르겠지만 이름도 길고 철자도 어려운 것이.. 별로 마음에 안든다고요?
사실 이 콜렉션은 초보자들이 사용하기 힘든, 약간 전문적인 지식이 필요한 콜렉션입니다.
제가 이런 말씀을 드리는 까닭이 과연 뭘까요?
네~ 맞습니다. '따라서 이 콜렉션에 대한 설명은 생략하도록 하겠습니다.' 라는 말씀을 드리려 하는 것이지요. (알아 채셨다고요? 눈치가 참 빠르시군요! ^^)
(만약 이 콜렉션과 관련된 질문이 있으시다면 '질문과 답변' 게시판에 올려주시기 바랍니다.)
2. 속성(Property)
2.1 TotalBytes 속성
Request 개체의 TotalBytes 속성은 '클라이언트(사용자)에서 서버로 보낸 정보 안에 있는 바이트의 전체 개수에 대한 정보' 를 제공합니다.
하지만 일반적으로 서버에서는 '전체 요청 문자열이 총 몇개인데?' 보다는
'어떤 값들이 어떤 컬렉션으로 넘어왔는데?' 라는 질문이 더욱 중요하기 때문에..
이 속성은 ASP 페이지에서 사용되는 경우가 상당히 드문 편에 속하게 됩니다.
하지만 사용법은 상식 선에서 알아두는 것이 좋겠지요. 다음과 같습니다.
<%
Dim intCount
intCount = Request.TotalBytes
%>
3. 메소드(Method)
3.1 BinaryRead(count) 메소드
BinaryRead 메소드는 <FORM> 에서 POST 방식으로 정보를 전달할 때,
count 바이트 만큼의 데이터를 읽어들이는 역할을 합니다.
따라서, 이 메소드는 Request.Form 컬렉션과 부딪히는 경향이 있습니다.
만약 Request.Form 컬렉션을 참조했다면 BinaryRead 메소드는 사용할 수 없습니다.
또한 반대로 BinaryRead 메소드를 먼저 사용했다고 한다면, 짐작하시는 대로 Request.Form 컬렉션은 사용을 할 수 없게 됩니다.
이 메소드도 사용할 일이 많지는 않지만, 상식으로 사용 방법을 알아두시면 좋겠습니다.
자, 오늘은 이렇게 Request 개체에서 사용하는 멤버들에 대해 알아보았습니다.
이중에서 가장 중요한 것들을 꼽으라면 역시 QueryString 과 Form 컬렉션이 될 것 같은데요.
ASP 페이지를 작성하시다보면 이 두 컬렉션을 너무나도 자주 사용해야 하므로,
조급하게 생각하지 않으셔도 자연스럽게 친해질 수 있을거라고 생각합니다.
마지막으로 컬렉션에 대한 Tip 을 하나 드리자면...
Request 개체에는 특수 기능이 있는 까닭에, 컬렉션의 이름은 모두 생략 가능합니다.
예를 들어서, Request.QueryString("count") 를 Request("count") 로 사용할 수 있으며,
마찬가지로 Request.Form("count") 도 Request("count") 로 사용 가능합니다.
자, 그럼 여기서 이 질문이 안나올 수 없겠죠?
방금의 경우처럼 Request.QueryString("count"), Request.Form("count") 에 각각 다른 값이 있는데 Request("count") 라고 사용했을 경우, 어떻게 될까요?
정답은! 'QueryString 컬렉션에 있는 값이 우선권을 가진다.' 입니다.
Request("count") 라고 했을 경우 Request 개체는 자체적인 우선 순위를 적용하여,
QueryString > Form > Cookies > ClientCertificate > ServerVariables
의 순서대로 검색을 하게 됩니다. 따라서 QueryString 안에 있는 값으로 인식하게 됩니다.
지난 강좌에서도 말씀드렸지만, Request("count") 라는 방식은 사용하기에 편할지는 몰라도
경우에 따라 값이 모호해질 수 있기 때문에, 부득이한 상황이 아니라면 반드시 Request.QueryString 처럼 컬렉션을 명시해주는 코딩 습관을 들이시는 것이 좋습니다.
