홈페이지>네트워크 프로그래밍 튜토리얼>ASP.NET 튜토리얼

URL 재작성(2): URL 재작성을 위한 구성 요소 사용

저자：Eve Cole 업데이트 시간：2009-06-29 23:46:44
asp.net 수준 URL 재작성 구성 요소의 원리는 실제로 BeginRequest 이벤트를 수신하고 구성에 따라 대상 URL을 결정하는 것뿐입니다. 이전에 참여한 프로젝트에서 URL Rewrite 구성 요소를 URL Rewrite 구성 요소로 사용하는 빈도가 매우 높다는 것을 알았습니다. 이는 Microsoft에서 제공하는 기능 때문일 수 있습니다.
URLRewriter를 사용하려는 경우 첫 번째 자연스러운 단계는 web.config에서 HttpModule을 구성하는 것입니다.

<http모듈>
< 추가
이름 = " ModuleRewriter "
유형 = " URLRewriter.ModuleRewriter, URLRewriter " />
</http모듈>

그런 다음 구성할 시간입니다(참고: 보다 쉬운 관리를 위해 구성을 추가 파일로 추출하려면 configPath 속성을 사용하는 것이 좋습니다).
<configSections>
< 섹션
이름 = " RewriterConfig "
유형 = " URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter " />
</configSections>
<RewriterConfig>

<규칙>

<RewriterRule>

< 찾기 > ~/tag/([w]+)/ </ 찾기 >

< SendTo > ~/Tags.aspx?Tag=$1 </ SendTo >

</RewriterRule>

</ 규칙 >
</RewriterConfig>

정규식은 일치하고 캡처할 수 있다는 놀라운 기능입니다. 위의 예에서는 LookFor 조건을 만족하는 "/tag/xxx"를 Tags.aspx 페이지로 재배치하고, xxx를 Tag QueryString 항목의 값으로 사용하여 코드에 HttpContext.Request.QueryString을 전달할 수 있도록 했습니다. . ["태그"] 값을 가져옵니다.
URLRewriter 의 기능은 대부분의 응용 프로그램에 충분하지만 저는 항상 그것을 좋아하지 않았습니다. 하지만 왜 싫냐고 묻는다면 못생긴 인마오는 말할 수 없습니다. 어쩌면 이 구성 방법의 문제일 수도 있습니다. URL Rewriter를 사용할 때 구성 섹션이 매우 긴 경우가 많습니다. 각 구성 항목에는 <RewriterRule>부터 </RewriterRule>까지 총 4줄의 코드가 필요합니다. 소규모 프로젝트에는 쉽게 수백 줄의 구성이 있을 수 있습니다. "이것은 너무 XML입니다"라고 생각했는데 왜 XML 속성을 사용하지 않습니까? 이렇게 하면 각 구성 항목이 1줄로 줄어들지만 이는 여담입니다.
따라서 현재 URL 재작성을 수행하려면 Intelligencia 에서 제작한 오픈 소스 구성 요소인 UrlRewriter.NET을 자주 사용합니다. 이 이름은 이전 이름과 매우 유사하지만 기능은 이전 이름보다 훨씬 뛰어납니다. 이 구성 요소는 사용 중인 URLRewriter와 상대적으로 유사합니다(실제로 모든 URL Rewrite 구성 요소가 비슷한 것 같습니다). 우리가 해야 할 일은 다음과 같습니다.

<configSections>
< 섹션
이름 = " 리라이터 "

 유형 = " Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler ,

Intelligencia.UrlRewriter " />
</configSections>


<리라이터>

< 다시 쓰기
url = " ^/사용자/(d+)$ "
= " ~/User.aspx?id = $1 "
처리 = " 중지 " />

< 다시 쓰기
url = " ^/사용자/(w+)$ "
= " ~/User.aspx?name=$1 "
처리 = " 중지 " />
</rewriter>


< 시스템.웹 >

<http모듈>

< 추가
이름 = " UrlRewriter "

 유형 = " Intelligencia.UrlRewriter.RewriterHttpModule,

Intelligencia.UrlRewriter " />

</http모듈>
< /system.web >
다시 쓰기 규칙의 구성 항목 <rewriter />를 주로 살펴보겠습니다. URLRewriter와 달리 UrlRewriter.NET은 내가 가장 좋아하는 규칙당 하나의 노드 방식을 사용하므로 전체 프로젝트의 규칙 다시 작성이 훨씬 간단해집니다. 그런데 process="stop"이 무슨 뜻인가요? 이것은 UrlRewriter.NET이 재작성 규칙을 처리하는 방식에 관한 것입니다. UrlRewriter.NET은 일치하는 다시 쓰기 규칙을 찾으면 여기서 멈추지 않고 계속해서 현재 요청과 일치할 수 있는 마지막 다시 쓰기 규칙이 적용됩니다. 일치 항목을 찾은 후 UrlRewriter.NET을 적용해야 하는 경우 처리 특성을 중지로 설정해야 합니다. 예를 들어, 위의 구성에서 "/User/" 뒤에 숫자가 오면 해당 사용자 ID를 사용하여 검색하고, 그렇지 않으면 현재 제공된 사용자 이름을 고려합니다.
UrlRewriter.NET이 구성이 더 간단하다면 URLRewriter에 비해 이점이 없습니다. 그러나 UrlRewriter.NET의 기능은 그 이상입니다. 방금 사용한 것은 실제로 제공되는 작업 중 하나일 뿐이며 다음과 같은 다양한 작업도 제공합니다.

  • 다시 작성
  • 하지 않는 한
  • 리디렉션
  • setstatus
  • 금지됨
  • 없음
  • 찾을
  • 수
  • 없음
  • 구현되지 않음
  • addheader
  • setcookie
  • setproperty
작업만으로는 충분하지 않습니다. UrlRewriter.NET은 조건, 변환, 기본 문서, 파서, 오류 처리기, 로거 및 기타 기능도 제공하며 전달할 수 있습니다. 복잡한 논리를 "표현"하는 표현입니다. 이것은 구성이 아니라 단순한 프로그래밍입니다! 그렇습니다. UrlRewriter.NET을 사용하면 구성을 통해 일부 요청-응답 논리를 표현할 수 있으므로 의심할 여지 없이 큰 편리함을 누릴 수 있습니다. 여기에서 UrlRewriter.NET의 모든 측면을 자세히 설명하는 것은 불가능합니다. 관심 있는 친구는 공식 웹사이트에서 제공하는 참조 자료를 통해 자세히 알아볼 수 있습니다. "이런 컴포넌트가 있다면 무엇을 더 바랄 수 있겠습니까?" 하지만 여기서는 그래도 다른 컴포넌트를 추천하고 싶습니다. 일부 특별한 경우에는 UrlRewriter.NET이 요구 사항을 충족할 수 없기 때문입니다. 음? 자체적으로 확장할 수는 없나요? 맞습니다. 하지만 먼저 이 문제를 해결하고 이 시리즈의 마지막 기사에서 이 문제를 설명하겠습니다. UrlRewriter.NET은 ASP.NET 수준에서 URL Rewriter를 제공합니다. IIS 수준에서 URL 재작성을 수행하려면 다른 방법을 사용해야 합니다. ISAPI Rewrite 는 IIS 수준에서 잘 알려진 URL Rewrite 구성 요소입니다. 안타깝게도 이는 상용 구성 요소이므로 미국 달러로 구입해야 합니다. 따라서 여기서는 또 다른 오픈 소스 제품인 IIRF(Ionic's Isapi Rewrite Filter)를 추천합니다.
URL 재작성은 IIS 수준에서 수행되므로 IIRF의 구성 방법은 UrlRewriter.NET과 다릅니다. IIRF를 사용하려면 웹 사이트의 ISAPI 필터 목록에 IsapiRewrite4.dll을 추가해야 합니다.
IIRF는 ini 파일을 통해 구성됩니다. IsapiRewrite4.ini와 IsapiRewrite4.dll은 동일한 디렉터리에 배치될 수 있습니다.
RewriteRule ^/User/(d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(w+)$ /User.aspx?name=$1 [I, L]
IIRF의 재작성 규칙은 "RewriteRule <url-pattern> <destination> [<modifiers>]"입니다. 각 부분 사이의 공백 수에는 제한이 없지만, Tab과 같은 다른 공백 문자가 아닌 공백이어야 합니다. . 말할 필요도 없이 "url-pattern"과 "destination"의 핵심은 수정자에 있습니다. IIRF에는 많은 수정자가 있습니다. 여기서는 위에서 사용한 두 가지만 소개하겠습니다. "I"는 일치가 대소문자와 무관함을 의미합니다. "L"의 기능은 UrlRewriter.NET의processing="stop"과 유사합니다. IIRF는 일치 항목이 발견되면 즉시 적용되며 검색을 계속하지 않습니다.
IIRF는 오픈 소스 구성 요소이지만 그 기능은 여전히 ​​상대적으로 강력합니다. 특히 RewriteCond(Rewrite Condition)를 결합한 후에는 더 복잡한 재작성 규칙을 구현할 수 있습니다. 예를 들어 다음 구성은 UserAgent에 Googlebot이라는 단어가 포함된 루트 디렉터리 요청을 특정 리소스에 다시 작성합니다.
RewriteCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]
마지막으로 Rewrite 두 구성요소의 차이점을 살펴보겠습니다. 분명히 가장 큰 차이점은 서로 다른 수준에서 다시 작성된다는 점입니다. 아래의 두 개략도는 두 경우에 "404 리소스를 찾을 수 없음" 요청 결과를 얻었어야 하는 "/User/jeffz"를 변경하는 방법을 설명합니다. "/사용자/이름=jeffz".
첫 번째는 ASP.NET 수준에서 UrlRewriter.NET에 의한 URL 재작성입니다.
다음은 IIS 수준에서 IIRF의 URL 재작성입니다.

이 두 구성 요소를 사용하면 URL 재작성을 구현하는 데 더 이상 다른 것이 필요하지 않다고 생각합니다.