이전 기사에서는 URL 재작성의 몇 가지 주요 측면에 대해 설명했습니다. 이 시리즈의 마지막 기사에서는 다양한 URL 재작성 수준의 세부 사항과 특징에 대해 논의할 것입니다.
이론적으로 C 또는 C++로 작성된 IIS 수준 URL 재작성은 관리 코드로 작성된 ASP.NET 수준 URL 재작성보다 성능이 더 높습니다. 하지만 대부분의 경우 이 부분의 차이는 미미하며, 이 성능이 성능 병목 현상이 되는 것은 거의 불가능하다고 생각합니다. 따라서 선택한 URL 재작성 수준은 일반적으로 애플리케이션의 성능 요구 사항에 따라 결정되지 않습니다. 그렇다면 어떤 수준의 URL 재작성을 사용해야 합니까? 다양한 수준의 URL 재작성을 사용한 후에는 무엇에 주의해야 합니까? 저는 제 개인적인 견해를 이야기하려고 왔습니다.
현재의 URL 재작성 구성 요소가 기능 측면에서 대부분의 응용 프로그램을 충족할 수 있지만 어느 시점에서는 여전히 몇 가지 특별한 기능이 필요합니다. 예를 들어, 현재 URL 재작성 구성 요소로는 도메인 이름을 기반으로 한 URL 재작성을 달성하기가 쉽지 않습니다. 상용 ISAPI Rewrite는 현재 이를 지원할 수 있지만, 불행하게도 오픈 소스 UrlRewriter.NET 및 IIRF는 이와 관련하여 기능이 부족합니다. 사이트를 기준으로 요청한 경로를 기준으로 모두 일치하며, 요청한 도메인 이름을 일치 조건으로 사용할 수 없습니다. 이를 위해서는 URL 재작성 구성요소를 확장해야 합니다. 대부분의 .NET 개발자에게는 관리되는 코드가 당연히 개발을 위한 첫 번째 선택입니다. 이때 ASP.NET 수준 URL 재작성 재작성 구성 요소를 선택해야 할 수도 있습니다. 그러나 ASP.NET 수준의 UrlRewriter.NET이든 IIS 수준의 IIRF이든 인터넷에서 많은 확장 예제를 찾을 수 있습니다.
그러나 실제로 위의 기능을 달성하려면 두 단계로 수행할 수도 있습니다. 먼저 IIS 수준에서 URL 재작성을 위해 IIRF를 사용한 다음 ASP.NET 수준에서 추가로 URL 재작성을 사용합니다. 예를 들어, 이제 " http://jeffz.domain.com/articles "를 "/ArticleList.aspx?owner=jeffz"로 다시 작성하려면 먼저 IIRF가 다시 작성을 목적으로 첫 번째 URL 재작성을 수행하도록 할 수 있습니다. " /articles"는 "/ArticleList.aspx"로 다시 작성됩니다.
RewriteRule ^/Articles$ /ArticleList.aspx [I, L, U]
이러한 방식으로 ASP.NET 엔진은 /ArticleList.aspx에 대한 요청을 직접 수신합니다. 그런 다음 ASP.NET 내에서 두 번째 URL 재작성을 수행할 수 있습니다(편의를 위해 여전히 Global.asax에 작성하고 프로젝트에서 추가 HttpModule을 사용하는 것이 좋습니다).
protected void Application_BeginRequest( 객체 전송자, EventArgs e)
{
HttpContext 컨텍스트 = HttpContext .Current;
문자열 호스트 = context.Request.Url.Host;
문자열 소유자 = 호스트.Substring(0, 호스트.IndexOf( '.' ));
context.RewritePath(context.Request.RawUrl + "?owner=" + 소유자);
}
2번의 URL 재작성 후에 우리가 원하는 효과를 얻었습니다. (실제 프로젝트에서는 Query String이 있는지 등을 판단해야 하기 때문에 위 코드를 직접 사용할 수 없습니다.)
또한 ASP.NET 수준 URL 재작성은 ASP.NET에서만 작동할 수 있습니다(당연한 사실입니다). URL 재작성이 PHP, RoR 등과 같은 다른 서버 기술을 지원하도록 하려면 IIS 수준 URL 재작성만 사용할 수 있습니다. (또는 서버 기술에서 제공하는 다른 URL 재작성 기능).
일부 특수 문자는 URL에 표시되는 것이 허용되지 않거나, 일단 URL에 표시되면 요청의 의미가 변경됩니다. 예를 들어 검색 페이지에서 URL 재작성을 수행하고 "/Search/xxx"를 "/Search.aspx?xxx"로 다시 작성한 다음 물음표 뒤의 문자열을 기반으로 사용자가 제공한 키워드를 가져와야 합니다. UrlRewriter.NET을 사용하는 경우 다음 구성을
사용 합니다 .
< 다시 쓰기 url = " ^/검색/(.+)$ " = " ~/Search.aspx?$1 " 처리 = " 중지 " />
</ rewriter >
일반적인 상황에서는 이 URL 재작성이 정상적으로 작동합니다. 그러나 사용자가 "%"를 키워드로 사용하면 상황이 달라집니다. 다음과 같은 오류 페이지 프롬프트가 표시되기 때문입니다.
이는 URL에 "%"가 허용되지 않기 때문입니다. 다양한 웹사이트로 이동하여 "ABC%25DEF"("%25" 다음에 "%"가 옴)와 같은 일부 경로를 요청해 보면 대부분 "400 잘못된 요청" 오류를 발견하게 됩니다. 그러나 쿼리 문자열에 "%"를 넣는 것은 합법적입니다. 예, 쿼리 문자열에 키워드를 다시 작성하지 않았습니까? 왜 아직도 작동하지 않나요? 이는 ASP.NET이 실행되는 방식에 의해서도 결정됩니다.
잘못된 요청은 위 그림의 3단계, 즉 아직 초기화되는 동안에 결정됩니다. URL 재작성은 4단계의 BeginRequest 이벤트에서만 발생합니다. 요청에 불법 문자가 포함되어 있으면 URL 재작성을 전혀 수행할 수 없습니다.
그렇다면 이 문제를 어떻게 처리해야 할까요? 일반적인 상황에서는 클라이언트에서 %를 제거하면 큰 문제가 되지 않지만(일부 사이트에서는 이 작업을 수행함) 이를 유지해야 하는 경우 어떻게 해야 합니까? 그런 다음 쿼리 문자열을 사용하여 매개변수를 전달하거나 IIS 수준 URL 재작성을 사용할 수도 있습니다. IIRF를 예로 들면 다음과 같습니다.
RewriteRule ^/Search/(.+)$ /Search.aspx?$1 [I, L, U]
요청이 IIS로 전송될 때(1단계), 어떤 ISAPI를 처리해야 하는지 선택한 후 실행 초과(2단계) 이전에 URL 재작성이 발생했습니다. URL 재작성 후 주소의 "%"가 쿼리 문자열로 전송되었으며 처리를 위해 ASP.NET으로 넘겨지면 당연히 합법적입니다.
마지막으로 오류 페이지 구성에 대해 살펴보겠습니다. 예를 들어, 일반적으로 애플리케이션에 대해 404 오류 페이지를 구성하여 사용자가 존재하지 않는 리소스에 액세스할 때 기본 오류 프롬프트 대신 특정 페이지를 표시할 수 있습니다. 그러나 이 시점에서는 다른 방법을 사용하여 다양한 수준의 URL 재작성을 구성해야 합니다.
ASP.NET 수준 URL 재작성을 사용하는 경우 일반적으로 IIS에 와일드카드 매핑을 설정하여 모든 요청(html, jpg 등 포함)이 ASP.NET에서 처리되도록 합니다. 존재하지 않는 리소스를 요청하면 ASP.NET에서 404 오류가 발생하므로 web.config에서 404 오류 페이지를 구성해야
합니다 . 모드 = " 켜짐 " defaultRedirect = " GenericErrorPage.htm " >
< 오류 statusCode = " 404 " 리디렉션 = " FileNotFound.htm " />
</ customErrors >
IIS 수준 Url Rewrite를 사용하는 경우 와일드카드 매핑을 구성하지 않습니다. 즉, ASP.NET 엔진은 Rewrite 이후의 주소가 aspx(또는 ASP.NET ISAPI에서 처리되어야 하는 다른 항목)인 경우에만 작동을 시작합니다. 사용자가 존재하지 않는 리소스를 요청하면 IIS에서 404 오류가 발생합니다. 이때 IIS에서 404 오류 페이지를 구성해야 합니다.
지금까지 URL 재작성 주제에 대해 논의했습니다. 실제 개발에서는 다양한 상황에 직면하게 되겠지만, URL Rewrite 방법의 핵심을 이해하고 프로그램이 실행되는 방식에 따라 생각한다면 일반적으로 어려운 문제에 직면하지 않을 것이라고 믿습니다.