Request 개체의 내용을 논의할 때 연구할 컬렉션 중 하나는 ServerVariables 컬렉션입니다. 이 세트에는 페이지 요청과 함께 클라이언트에서 서버로 전송된 HTTP 헤더의 값과 요청을 수신할 때 서버 자체에서 제공한 값의 조합이 포함됩니다.
ServerVariables 컬렉션의"자체 참조" 페이지
에서 반환된 값에는
웹 서버의 세부 정보와 현재 페이지의 경로 정보가 포함되어 있습니다.이 정보는 페이지를 만드는 모든 곳에서 사용할 수 있습니다. 예를 들어, 다른 작업을 완료하기 위해 자신을 다시 호출할 수 있는 "자체 참조" 페이지를 생성하려면 다음 코드를 사용할 수 있습니다:
<FORM ACTION="<% = Request.ServerVariables("PATH_INFO") %>" METHOD= "POST ”>
HTTP “SCRIPT_NAME” 값을 사용하여 동일한 효과를 얻을 수 있습니다:
<FORM ACTION="<% = Request.ServerVariables("SCRIPT_NAME") %>" METHOD="POST">
<A> 요소를 사용하여 다른 페이지를 열려면 다음을 사용할 수 있습니다
.
<%
strFullPath = Request.ServerVariables("PATH_INFO")
'파일 이름을 제거하세요.
strPathOnly = 왼쪽(strFullPath, InStrRev(strFullPath, “/”))
strNextPage = strPathOnly & “pages/next_page.asp”
%>
...
<A HREF=”<% = strNextPage %>”>다음 페이지</A>
...
이 예제는 원본 페이지의 이름이나 위치가 변경되더라도 현재 페이지의 경로 정보가 사용되기 때문에 작동합니다(물론 분리된 대상 페이지의 이름이 변경되면 두 번째 예제는 실패합니다).
즉, 검색 엔진의 하위 세션에 대해 URL이 자동으로 구축되면 ServerVariable의 일부 값을 수집할 수 있습니다:
strFullURL = http:// & Request.ServerVariables("LOCAL_ADDR") _
& ":" & Request.ServerVariables("SERVER_PORT") _
& Request.ServerVariables("PATH_INFO")
이는 포트 번호(이 경우 표준 값 80이 아님)를 포함하는 완전한 URL을 생성합니다. 예를 들어 결과는 다음과 같습니다.
http://194.74.60.254:1768/thispath/thispage.asp
브라우저 버전 감지
ServerVariables 컬렉션의 또 다른 유용한 값은 사용자 브라우저의 사용자 에이전트 문자열입니다. "브라우저 유형 감지" 페이지(browsertype.asp)에서 ServerVariables 컬렉션의 "HTTP_USER_AGENT" 값은 사용자 에이전트 문자열을 얻는 데 사용됩니다. 일부 스크립트는 이 정보를 구문 분석하고 제조업체 이름과 브라우저 버전을 찾는 데 사용됩니다.
<%
strUA = Request.ServerVariables("HTTP_USER_AGENT")
응답."The User Agent string is <B>" & strUA & "</B> 쓰기
"
InStr(strUA, “MSIE”)이면
응답.'브라우저를 업그레이드하려면 '_'로 이동하세요.
& “<A HREF=” & Chr(34) & http://www.microsoft.com/ie/ ”_
& Chr(34) & “> http://www.microsoft.com/ie/ <A>
"
intVersion = Cint(Mid(strUA, InStr(strUA, “MSIE”) + 5, 1))
intVersion >=4이면
응답.쓰기 “Microsoft Dynamic HTML을 사용할 수 있습니다.”
종료 조건
또 다른
If InStr(strUA, “Mozilla”) 그러면
InStr(strUA, "호환;") = 0인 경우
응답.쓰기 “귀하의 브라우저는 아마도 Navigator일 것입니다.”
& “”에서 최신 버전의 Navigator를 다운로드하세요_
& “<A HREF=” & Chr(34) & http://home.netscape.com/ ”_
& “다운로드/”& Chr(34) & “> http://home.netscape.com ”_
& “/다운로드/</A>
"
intVersion = Cint(Mid(strUA, InStr(strUA, “/”) +1, 1))
intVersion ≥= 4이면
응답.쓰기 “아마도 Netscape Dynamic HTML을 사용할 수 있을 것입니다”
종료 조건
또 다른
strVersion = Mid(strUA, InStr(strUA, “호환 가능;”) + 12)
strProduct = 왼쪽(strVersion, InStr(strVersion, “ “))
응답."귀하의 브라우저는 Navigator와 호환됩니다."라고 작성하세요_
& “다음과 같은 검색 엔진을 사용하여 제조업체를 검색하세요”_
& “<A HREF=" & Chr(34) _
& “http://www.altavista.digital.com/cgi-bin/query?q=”_
&str제품_
& Chr(34) & “> http://www.altavista.com/ </A>
"
종료 조건
종료 조건
종료 조건
%>
IE 5.0과 Navigator 4.61의 검색 결과는 각각 다릅니다. 다른 제조업체의 브라우저의 경우 Alta Vista 웹 사이트에서 자동으로 제조업체 이름 검색을 시작할 수 있는 링크를 얻을 수 있습니다.
Netscape는 사용자 에이전트 문자열에 제조업체 이름을 제공하지 않으므로 브라우저가 Navigator라는 절대적 보장은 없습니다.
브라우저 언어 감지
ServerVariables 컬렉션의 또 다른 유용한 값은 "HTTP_ACCEPT_LANGUAGE"입니다. 여기에는 브라우저를 설치할 때 지정되거나 사용자의 지역 버전에 하드 코딩된 언어 코드가 포함되어 있습니다. 언어 코드의 예로는 en-us(영국, 미국), de-at(독일, 호주) 및 es-pe(스페인, 페루)가 있습니다.
언어 코드는 일반적일 수 있으며 방언 식별자를 생략할 수 있습니다. 예를 들어 Wrox 사이트에서는 많은 방문자가 en(영어)을 언어 코드로 사용합니다.
따라서 언어 코드가 감지되고 적절한 지역별 또는 언어별 버전의 페이지가 자동으로 로드됩니다.
StrLocale = Lcase(왼쪽(Request.ServerVariables("HTTP_ACCEPT_LANGUAGE"),2))
사례 strLocale 선택
사례 "en": Response.Redirect "http://uk_site.co.uk/"
사례 "de": Response.Redirect "http://de_site.co.de/"
사례 "fr": Response.Redirect "http://fr_site.co.fr/"
'...등
다른 경우: Response.Redirect “http://us_sitel.com/”
End
특정 방언을 기반으로 페이지를 선택하거나 리디렉션합니다:
strLocale = Lcase(Request.ServerVariables("HTTP_ACCEPT_LANGUAGE"))
사례 strLocale 선택
사례 "en-gb": Response.Redirect "http://uk_site.co.uk/"
사례 "en-us": Response.Redirect "http://us_site.com/"
사례 "es-pe": Response.Redirect "http://es_site2.co.pe/"
'...
다른 경우: Response.Redirect “http://us_site1.com/”
End Select
다른 유용한 ServerVariables 컬렉션 값은
ServerVariables 컬렉션의 모든 멤버에 액세스하고 이를 사용하여 ASP 페이지가 요청에 응답하는 방식을 제어할 수 있습니다. 방문자가 기본 포트 80을 사용하여 사이트에 접속했는지 또는 다른 포트를 사용하여 사이트에 접속했는지 확인할 수 있습니다. 이 예에서는 SSI(Secure Socket Layer) 액세스(및 기타 프로토콜)를 제공하는 포트 443을 통한 액세스를 찾아 적절한 페이지로 리디렉션합니다.
Request.ServerVariables("SERVER_PORT") = "443")인 경우
Response.Redirect "/securesite/default.asp" '보안 사용자
또 다른
Response.Redirect “/normalsite/default.asp” '비보안 사용자
End
브라우저가 등록되고 서버에 의해 확인되어야 하는 경우(웹 서버의 IUSER 계정으로 익명으로 액세스하도록 허용하는 대신 이 문제는 이후 장에서 자세히 설명합니다) 사용자 이름은 다음과 같습니다. 우리와 거래하는 사용자가 누구인지, 그리고 이 사용자에게 페이지를 로드할지 여부를 결정하기 위해 쿼리했습니다. 예를 들어, 다음 코드는 Administrator라는 사용자에게만 관리 링크를 표시합니다.
...
<A HREF=”dispcnfg.asp”>디스플레이 구성 변경</A>
<A HREF=”dispcolr.asp”>표시 색상 변경</A>
<A HREF=”keyboard.asp”>키보드 구성 변경</A ＞
＜%
Request.ServerVariables("AUTH_USER") _
= Ucase(Request.ServerVariables(“SERVER_NAME”)) & “Administrator” 그러면
%>
<A HREF=”allusers.asp”>모든 사용자 관리</A>
<A HREF=”usrlogon.asp”>로그온 정보 관리</A>
<%
종료 조건
%>
...
ASP는 사용자가 해당 멤버 중 하나에 액세스할 때까지 ServerVariables 컬렉션을 채우지 않습니다. 이 컬렉션의 멤버에 처음으로 액세스하면 IIS가 모든 멤버를 가져오므로 ServerVariables 컬렉션은 필요할 때만 사용해야 합니다.
기타 요청 및 응답 기술
이제 다음을 포함하여 요청 및 응답 개체를 사용하는 몇 가지 유용한 기술을 살펴보겠습니다.
· 연결 관리, 버퍼링 및 페이지 리디렉션.
· HTTP 헤더, 캐싱 및 "만료" 페이지 작업.
· 클라이언트 인증서를 활용합니다.
· 사용자 정의된 로그 파일 메시지를 만듭니다.
1. 연결 관리, 버퍼링 및 페이지 리디렉션
ASP의 매우 유용한 기능은 사용자가 한 ASP 웹 페이지에서 다른 웹 페이지(ASP 또는 HTML)로 또는 다른 소스 파일(예: ZIP 파일 또는 텍스트)로 리디렉션할 수 있도록 하는 것입니다. 파일) ). 이는 사용자에게 투명하며 실제로 작업을 수행하는 것은 브라우저입니다. Response.Redirect 메서드를 사용하여 새 웹 페이지를 로드하면 실제로 특수 HTTP 헤더가 클라이언트로 다시 전송됩니다. 이 헤더는 다음과 같습니다.
HTTP/1.1 302 개체 이동됨
Location /newpath/newpage.asp
브라우저는 이 헤더 정보를 읽고 Location 값에 따라 페이지를 로드합니다. 이는 웹 페이지에서 클라이언트 측 HTML <META> 태그를 사용하는 것과 기능적으로 동일합니다. 예:
<META HTTP-EQUIV="REFRESH" CONTENT="0;URL=/newpath/newpage.asp"
> a 문제는 서버와 사용자 사이의 프록시 서버가 새 페이지를 직접 로드하는 대신 새 페이지에 대한 링크가 포함된 자체 메시지를 제공할 수 있다는 것입니다. 그리고 브라우저는 제조업체와 버전에 따라 동일한 작업을 수행할 수 있습니다. 이로 인해 예상되는 투명성이 제거되고 오류 메시지가 계속 표시되므로 사용자가 사이트에 액세스하는 것이 더 번거로워집니다.
텍스트나 HTML과 같은 페이지 콘텐츠를 보낸 후에는 더 이상 Redirect 메서드를 사용할 수 없습니다. 그러나 "프록시 서버 영향"을 제한하는 것으로 보이는 한 가지 방법은 먼저 출력(HTTP 헤더 포함)이 클라이언트로 전송되지 않도록 하는 것입니다. ASP 2.0에서는 버퍼링을 켠 다음 Clear 메서드를 사용하여 버퍼를 지워야 합니다.
Response.Buffer = True
'적절한 페이지를 선택하기 위한 몇 가지 조건:
Request.ServerVariables("SERVER_PORT") = 1856인 경우
StrNewPage = "/newpath/this_page.asp"
또 다른
StrNewPage = "/newpath/the_other_page.asp"
종료 조건
응답.지우기
Response.Redirect strNewPage
ASP 3.0에서는 버퍼링이 기본적으로 켜져 있으므로 첫 번째 줄은 무시할 수 있지만 이는 무해하며 웹 페이지가 ASP 2.0 환경에서도 계속 작동하도록 보장합니다.
이런 종류의 HTTP 헤더 리디렉션을 사용하는 것보다는 ASP 3.0의 새로운 기능을 사용하는 것이 더 좋습니다. 이 기능을 사용하면 Server 개체의 Transfer 메서드를 통해 다른 웹 페이지를 실행하도록 변환할 수 있습니다. 이 문제에 대해서는 앞으로 더 자세히 연구하겠습니다. .
1) ASP 페이지 버퍼
앞에서 본 것처럼 ASP 3.0 페이지 버퍼는 IIS 5.0에서 기본적으로 켜져 있고 이전 버전에서는 기본적으로 꺼져 있습니다. Microsoft는 버퍼링이 IIS 5.0에서 보다 효율적인 웹 페이지 전달을 제공한다고 말하며, 이것이 바로 버퍼링의 기본 상태가 변경된 이유입니다. 대부분의 경우 이는 우리에게 아무런 영향을 미치지 않습니다. 그러나 매우 큰 웹 페이지가 있거나 ASP 또는 기타 서버 측 코드 및 구성 요소를 사용하여 만드는 데 시간이 걸리는 웹 페이지가 있는 경우 해당 부분이 완료되면 일괄적으로 클라이언트에 새로 고칠 수 있습니다
. .
... 페이지의 첫 번째 부분을 생성하는 코드
...
응답.플러시
...
... 페이지의 다음 부분을 생성하는 코드
...
응답.플러시
...
페이지가 끝나기 전 특정 시점에서 End 메서드를 호출하여 현재 모든 콘텐츠를 클라이언트에 새로 고치고 추가 처리를 중단함으로써 코드 실행을 중지하려는 경우가 있습니다.
...
... 페이지의 첫 번째 부분을 생성하는 코드
strUserName = ""이면 Response.Clear
...
... 페이지의 이 부분에 대한 새 버전을 생성하는 코드
...
다음은 기본 "응답 개체" 페이지(sow_response.asp)에서 다운로드할 수 있는 버퍼링 및 리디렉션을 보여주는 두 가지 예제 웹 페이지입니다. 첫 번째 Response.Redirect 예제 웹 페이지의 이름은 direct.asp입니다. 이는 버퍼링된 페이지에 일부 콘텐츠를 삽입하고 버퍼를 지운 다음 다른 웹 페이지로 리디렉션합니다.
For intLoop = 1 To 1000000
응답."."을 쓰세요.
다음
응답.지우기
응답.리디렉션 "show_redirect.asp"
Response.End
대상 페이지 show_response.asp는 동일한 작업을 수행하지만 리디렉션은 "응답 개체" 홈 페이지로 돌아갑니다. 이러한 페이지는 버퍼링되어 있고 리디렉션 전에 모든 출력을 지워야 하기 때문에 브라우저에 출력이 표시되지 않습니다. 그러나 발생하는 각 리디렉션은 브라우저의 상태를 관찰하여 확인할 수 있습니다. 아래 그림과 같이:
<img src=/u/info_img/2009-06/25/asp14.jpg>
"Response Object" 홈 페이지에서 "Response.Flush" 링크를 클릭하여 두 번째 샘플 웹 페이지를 엽니다. usebuffer.asp는 단순히 문자열의 각 문자를 반복하고 일정 지연을 두고 이를 클라이언트에 플러시합니다. 이는 웹 서버와 ASP를 매우 비효율적으로 사용하는 것이지만 버퍼링이 어떻게 작동하는지 보여줍니다.
<img src=/u/info_img/2009-06/25/asp15.jpg>
다음은 필수 최소 ASP 코드입니다. 각 문자를 브라우저에 별도로 새로 고치지 않으면 버퍼에 저장됩니다. 웹페이지가 완료되었습니다:
strText = “이 텍스트는 “ & _를 사용하여 브라우저에 플러시되었습니다.
"<B>응답.플러시</B>
"
intChar =1의 경우 Len(strText)으로
intWrite = 1 ~ 100000의 경우
다음
응답.쓰기 중간(strText,intChar,1)
응답.플러시
다음
2) Response.IsClientConnected 속성
IsClientConnected 속성은 ASP 2.0에 이미 존재하지만 다소 불안정합니다. 일부 출력은 정확한 결과를 반환하기 전에 클라이언트로 전송되어야 합니다. 이 문제는 ASP 3.0에서 해결되었습니다. 이제 이 속성을 자유롭게 사용할 수 있습니다.
IsClientConnected는 사용자가 여전히 서버에 연결되어 있고 ASP에서 생성된 웹 페이지를 로드하고 있는지 관찰하는 유용한 방법입니다. 사용자가 연결을 끊거나 다운로드를 중지하면 IIS에서 버퍼 내용을 삭제하므로 더 이상 웹 페이지를 만드는 데 서버 리소스를 낭비할 필요가 없습니다. 따라서 많은 리소스를 계산하거나 사용하는 데 많은 시간이 필요한 웹 페이지의 경우 브라우저가 오프라인인지 모든 단계에서 확인하는 것이 좋습니다
.
... 페이지의 첫 번째 부분을 생성하는 코드
...
Response.IsClientConnected인 경우
응답.플러시
또 다른
응답.종료
종료 조건
...
... 페이지의 다음 부분을 생성하는 코드...