로 루슬란 야쿠셰프
설명서의 이 섹션은 IIS 7용 URL 다시 쓰기 모듈 버전 2.0에 적용됩니다.
이 문서에서는 URL 다시 쓰기 모듈 2.0 기능에 대한 개요를 제공하고 이 버전에서 사용되는 새로운 구성 개념을 설명합니다. URL 다시 쓰기 모듈 1.1 구성에 대한 자세한 내용은 URL 다시 쓰기 모듈 구성 참조를 참조하세요.
목차
- 기능 개요
- 아웃바운드 규칙 개요
- 아웃바운드 규칙 구성
- 다시 쓰기 규칙에서 응답 헤더에 액세스
- 요청 헤더 및 서버 변수 설정
- 응답 헤더 설정
- 다시 쓰기 규칙에서 백 참조 사용
- IIS 로그에 다시 작성된 URL 로깅
기능 개요
IIS용 Microsoft URL 다시 쓰기 모듈 2.0은 버전 1.1의 모든 기능을 포함하고 응답 헤더 및 콘텐츠 다시 쓰기에 대한 지원을 추가하는 증분 릴리스입니다. 이 모듈은 정규식 또는 와일드카드 패턴을 HTTP 응답에 적용하여 아웃바운드 다시 쓰기 규칙으로 표현된 재작성 논리에 따라 콘텐츠 부분을 찾아서 바꿉니다. 보다 구체적으로 모듈을 사용하여 다음을 수행할 수 있습니다.
- 응답 HTML의 웹 애플리케이션에서 생성된 URL을 보다 사용자에게 친숙하고 검색 엔진에 친숙한 URL로 바꿉다.
- 역방향 프록시 뒤에 있는 웹 애플리케이션에서 생성된 HTML 태그의 링크를 수정합니다.
- 기존 응답 HTTP 헤더를 수정하고 새 응답 HTTP 헤더를 설정합니다.
- JavaScript, CSS, RSS 등을 비롯한 HTTP 응답의 콘텐츠를 수정합니다.
Warning
응답 헤더 또는 응답 콘텐츠가 아웃바운드 다시 쓰기 규칙에 의해 수정되는 경우 응답에 삽입되는 텍스트에 클라이언트 쪽 실행 코드가 포함되어 있지 않아 사이트 간 스크립팅 취약성이 발생할 수 있도록 주의해야 합니다. 이는 다시 쓰기 규칙이 HTTP 헤더 또는 쿼리 문자열과 같은 신뢰할 수 없는 데이터를 사용하여 HTTP 응답에 삽입될 문자열을 빌드하는 경우에 특히 중요합니다. 이러한 경우 대체 문자열은 HtmlEncode 함수를 사용하여 HTML로 인코딩되어야 합니다. 예를 들면 다음과 같습니다.
<action type="Rewrite" value="{HtmlEncode:{HTTP_REFERER}}" />
아웃바운드 규칙 개요
응답 다시 쓰기에 사용되는 기본 구성 개념은 아웃바운드 규칙의 개념입니다. 아웃바운드 규칙은 응답 콘텐츠를 비교하거나 일치시킬 내용과 비교에 성공한 경우 수행할 작업의 논리를 표현하는 데 사용됩니다.
개념적으로 아웃바운드 규칙은 다음 부분으로 구성됩니다.
- 사전 조건 - 선택적 사전 조건은 규칙 평가가 시작되기 전에 요청 메타데이터를 검사 데 사용됩니다. 사전 조건은 요청 메타데이터에 대한 몇 가지 조건부 검사 구성될 수 있으며 이미지 또는 비디오 파일과 같이 다시 작성해서는 안 되는 응답을 필터링하는 데 사용할 수 있습니다.
- 태그 필터 - 태그 필터는 잘 알려진 태그 또는 사용자 지정 정의 태그 집합에 대한 응답 내에서 검색 범위를 좁히는 데 사용됩니다. 태그 필터를 사용하면 전체 응답 콘텐츠를 패턴과 일치시키는 것이 아니라 지정된 태그의 콘텐츠만 규칙 패턴과 일치합니다.
- 패턴 – 규칙 패턴은 응답 콘텐츠 내에서 검색하는 데 사용할 정규식 또는 야생카드 패턴을 지정하는 데 사용됩니다.
- 조건 – 선택적 조건 컬렉션은 응답 콘텐츠 내에서 패턴 일치가 발견된 경우 수행할 추가 논리 작업을 지정하는 데 사용됩니다. 조건 내에서 HTTP 헤더 또는 서버 변수의 특정 값에 대해 검사 수 있습니다.
- 작업 – 패턴 일치가 발견되고 모든 규칙 조건이 성공적으로 평가된 경우 수행할 작업을 지정하는 데 사용됩니다.
규칙 실행
아웃바운드 규칙을 실행하는 프로세스는 인바운드 규칙에 사용되는 프로세스와 다릅니다. 인바운드 규칙 집합은 입력이 단일 요청 URL 문자열이기 때문에 요청당 한 번만 평가됩니다. 아웃바운드 규칙 집합은 HTTP 응답 콘텐츠 내의 여러 위치에서 적용되므로 응답당 여러 번 평가될 수 있습니다. 예를 들어 아래와 같은 규칙 집합이 있는 경우:
규칙 1: 태그 및 <img> 태그에 <> 적용됩니다.
규칙 2: 태그에 <> 적용
HTML 응답에는 다음 태그가 포함됩니다.
<a href="/default.aspx"><img src="/logo.jpg" />Home Page</a>
그런 다음 URL 다시 쓰기 모듈 2.0은 규칙 1을 "/default.aspx" 문자열에 대해 평가합니다. 규칙이 성공적으로 실행된 경우 규칙 1의 출력이 Rule2에 제공됩니다. 규칙 2가 성공적으로 실행된 경우 규칙 2의 출력을 사용하여 응답의 태그에 있는 <> href 특성의 내용을 대체합니다.
URL 다시 쓰기 모듈 2.0 이후에는 Rule1을 "/logo.jpg" 문자열에 대해 평가합니다. 규칙이 성공적으로 실행된 경우 해당 출력은 응답의 img> 태그에 있는 <src 특성의 콘텐츠를 바꾸는 데 사용됩니다.
규칙 상속
규칙이 여러 구성 수준에서 정의된 경우 URL 다시 쓰기 모듈은 부모 구성 수준의 분산 규칙과 현재 구성 수준의 규칙을 포함하는 규칙 집합을 평가합니다. 평가는 부모-자식 순서로 수행됩니다. 즉, 부모 규칙이 먼저 평가되고 마지막 자식 수준에서 정의된 규칙이 마지막으로 평가됩니다.
아웃바운드 규칙 구성
Pre-conditions 컬렉션
사전 조건은 응답 콘텐츠에 대해 규칙을 평가해야 하는 경우 검사 데 사용됩니다. 사전 조건 컬렉션은 preConditions> 섹션 내에서 <명명된 컬렉션으로 정의되며 하나 이상의 사전 조건 검사 포함할 수 있습니다. 아웃바운드 규칙은 이름별로 사전 조건 컬렉션을 참조합니다.
사전 조건 컬렉션에는 조건 평가 방법을 제어하는 logicalGrouping이라는 특성이 있습니다. 다음과 같은 경우 사전 조건 컬렉션이 true로 평가됩니다.
- logicalGrouping="MatchAll"이 사용된 경우 내의 모든 사전 조건이 true로 평가되었습니다.
- logicalGrouping="MatchAny"가 사용된 경우 사전 조건 중 하나 이상이 true로 평가되었습니다.
다음 속성을 지정하여 사전 조건을 정의합니다.
- 입력 문자열 - 조건 전 입력은 조건 평가에 대한 입력으로 사용할 항목을 지정합니다. 사전 조건 입력은 이전의 사전 조건 패턴에 대한 서버 변수 및 백 참조를 포함할 수 있는 임의의 문자열입니다.
- 패턴 - 정규식 구문을 사용하거나 wild카드 구문을 사용하여 조건부 패턴을 지정할 수 있습니다. 사전 조건에서 사용할 패턴의 형식은 사전 조건 컬렉션에 대해 정의된 patternSyntax 플래그의 값에 따라 달라집니다.
또한 negate 특성을 사용하여 사전 조건 평가의 결과를 부정할 수 있습니다.
응답 콘텐츠 형식이 텍스트/html인 경우 검사 사전 조건의 예입니다.
<preConditions>
<preCondition name="IsHTML">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>
</preConditions>
태그 필터
태그 필터는 응답 콘텐츠 내의 검색 범위를 잘 알려진 HTML 태그 또는 사용자 지정 HTML 태그 집합으로 좁히는 데 사용됩니다. 다시 쓰기 규칙이 태그 필터를 사용하는 경우 전체 응답과 규칙 패턴을 일치시키는 대신 URL 다시 쓰기 모듈 2.0은 규칙의 태그 필터에 나열된 HTML 태그를 찾은 다음 해당 태그의 URL 특성 콘텐츠를 가져와 규칙 패턴에 따라 평가합니다. 태그 필터는 아웃바운드 규칙의 match> 요소에 대한 <filterByTags 특성 내에 지정됩니다. 예시:
<match filterByTags="A" pattern="^/(article\.aspx.*)" />
HTTP 응답에 다음과 같은 앵커 태그가 포함된 경우:
<a href="/article.aspx?id=1">link</a>
그런 다음, "/article.aspx?id=1" 문자열에 대해 다시 쓰기 규칙 패턴이 평가됩니다.
미리 정의된 태그
URL 다시 쓰기 모듈 2.0에는 아웃바운드 규칙과 함께 사용할 수 있는 미리 정의된 태그 집합이 포함되어 있습니다. 아래 표에는 모든 미리 정의된 태그와 해당 값이 아웃바운드 규칙 패턴의 입력으로 사용되는 특성이 나열되어 있습니다.
| 태그 | 특성 |
|---|---|
| A | href |
| 지역 | href |
| Base | href |
| 양식 | 작업 |
| Frame | src, longdesc |
| Head | profile |
| IFrame | src, longdesc |
| 이미지 | src, longdesc, usemap |
| 입력 | src, usemap |
| 링크 | href |
| 스크립트 | src |
사용자 지정 태그
미리 정의된 태그 컬렉션에 포함되지 않은 태그 특성 내에서 다시 작성해야 하는 경우 사용자 지정 태그 컬렉션을 사용하여 태그 이름과 다시 작성해야 하는 해당 특성을 지정할 수 있습니다. 사용자 지정 태그 컬렉션은 customTags 섹션 내에서 명명된 <컬렉션으로 정의됩니다> . 아웃바운드 규칙은 이름으로 사용자 지정 태그 컬렉션을 참조합니다.
다음 예제에서는 사용자 지정 태그 컬렉션의 정의를 보여 줍니다.
<customTags>
<tags name="My Tags">
<tag name="item" attribute="src" />
<tag name="element" attribute="src" />
</tags>
</customTags>
이 사용자 지정 태그 컬렉션은 아래 예제와 같이 아웃바운드 규칙에서 참조할 수 있습니다.
<match filterByTags="A, CustomTags" customTags="My Tags" pattern="^/(article\.aspx.*)" />
규칙 패턴
규칙 패턴은 규칙 입력 문자열을 일치시킬 항목을 지정하는 데 사용됩니다. 규칙 입력은 규칙 구성에 따라 다릅니다.
- 규칙이 태그 필터를 사용하는 경우 특성이 일치하는 태그의 콘텐츠가 패턴 일치에 대한 입력으로 전달됩니다.
- 규칙이 태그 필터를 사용하지 않는 경우 전체 응답 콘텐츠가 패턴 일치에 대한 입력으로 전달됩니다.
패턴은 다시 쓰기 규칙의 일치> 요소 내에 <지정됩니다.
전체 응답 패턴 일치
filterByTags 특성이 규칙의 일치 요소에 지정되지 않은 경우 패턴이 전체 응답 콘텐츠에 적용됩니다. 전체 응답 콘텐츠에 대한 정규식 패턴 평가는 CPU 집약적인 작업이며 웹 애플리케이션의 성능에 영향을 줄 수 있습니다. 전체 응답 패턴 일치로 인해 발생하는 성능 오버헤드를 줄이기 위한 몇 가지 옵션이 있습니다.
IIS 사용자 모드 캐싱을 사용하고 outboundRules 요소의 <rewriteBeforeCache 특성을 true로 설정합니다.>
<outboundRules rewriteBeforeCache="true">청크 분할 전송 인코딩이 응답에 사용되는 경우 이 설정을 사용하면 안 됩니다.
규칙의 match 요소에 대한 occurrences 특성을 사용합니다. 예를 들어 규칙을 사용하여 일부 HTML 조각을 헤드 요소에 <삽입하고 해당 규칙에 닫는 태그인 </head>를 검색하는 패턴이 있는 경우 occurrences="1"을 설정할 수> 있습니다. 그러면 다시 쓰기 모듈에 /head> 태그가 발견된 후 응답의 re기본der 검색을 <중지하도록 지시합니다.
<match pattern="</head>" occurrences="1" />
규칙 패턴 구문
규칙 패턴 구문은 규칙의 patternSyntax 특성을 사용하여 지정할 수 있습니다. 이 특성은 다음 옵션 중 하나로 설정할 수 있습니다.
ECMAScript – Perl compatible(ECMAScript 표준 규격) 정규식 구문입니다. 모든 규칙에 대한 기본 옵션입니다. 패턴 형식의 예입니다. "^([_0-9a-zA-Z-]+/)? (wp-.*)"
Wild카드 – IIS HTTP 리디렉션 모듈에 사용되는 wild카드 구문입니다. 다음은 "/Scripts/*.js" 형식의 패턴 예제입니다. 여기서 별표("*")는 "임의의 수의 문자를 일치시키고 백 참조로 캡처"를 의미합니다. 규칙에 태그 필터가 없는 경우 wild카드 패턴 형식을 사용할 수 없습니다.
ExactMatch - 입력 문자열 내에서 정확한 문자열 검색이 수행됩니다.
patternSyntax 특성의 범위는 규칙별로 적용됩니다. 즉, 현재 규칙의 패턴 및 해당 규칙의 조건 내에서 사용되는 모든 패턴에 적용됩니다.
규칙 패턴 속성
일치> 요소의 부정 특성을 사용하여 패턴을 부정할 <수 있습니다. 이 특성을 사용하면 입력 문자열이 지정된 패턴과 일치하지 않는 경우에만 규칙 작업이 수행됩니다.
기본적으로 대/소문자를 구분하지 않는 패턴 일치가 사용됩니다. 대/소문자 구분을 사용하도록 설정하려면 규칙의 match> 요소에 대한 <ignoreCase 특성을 사용할 수 있습니다.
규칙 조건
규칙 조건을 사용하면 규칙 평가를 위한 추가 논리를 정의할 수 있습니다. 이 논리는 현재 입력 문자열 이외의 입력을 기반으로 할 수 있습니다. 모든 규칙에는 0개 이상의 조건이 있을 수 있습니다. 규칙 패턴 일치가 성공하면 규칙 조건이 평가됩니다.
조건은 다시 쓰기 규칙의 조건> 컬렉션 내에서 <정의됩니다. 이 컬렉션에는 조건 평가 방법을 제어하는 logicalGrouping이라는 특성이 있습니다. 규칙에 조건이 있는 경우 규칙 패턴이 일치하는 경우에만 규칙 동작이 수행됩니다.
- logicalGrouping="MatchAll"이 사용된 경우 모든 조건이 true로 평가되었습니다.
- logicalGrouping="MatchAny"가 사용된 경우 하나 이상의 조건이 true로 평가되었습니다.
조건은 다음 속성을 지정하여 정의됩니다.
입력 문자열 - 조건 입력은 조건 평가에 대한 입력으로 사용할 항목을 지정합니다. 조건 입력은 이전 조건 패턴 및/또는 규칙 패턴에 대한 서버 변수 및 백 참조를 포함할 수 있는 임의의 문자열입니다.
패턴 – 조건 입력에서 찾을 패턴입니다. 정규식 구문을 사용하거나 wild카드 구문을 사용하여 패턴을 지정할 수 있습니다. 조건에서 사용할 패턴의 형식은 이 조건이 속한 규칙에 대해 정의된 patternSyntax 플래그의 값에 따라 달라집니다. 이 조건 형식에는 패턴 일치를 제어하는 두 가지 관련 특성이 있습니다.
- 패턴 – 이 특성을 사용하여 실제 패턴을 지정합니다.
- ignoreCase – 이 특성을 사용하여 조건에 대한 패턴 일치가 대/소문자를 구분해야 하는지 또는 대/소문자를 구분하지 않아야 하는지를 제어합니다.
규칙 작업
입력 문자열이 규칙 패턴과 일치하고 조건 평가가 성공하면 다시 쓰기 규칙 작업이 수행됩니다(규칙 구성에 따라 일치하는 모든 조건 또는 일치하는 조건 중 하나 이상). 두 가지 유형의 작업을 사용할 수 있으며 작업> 구성 요소의 <"type" 특성을 사용하여 규칙이 수행해야 하는 작업을 지정할 수 있습니다. 다음 섹션에서는 다양한 작업 유형 및 특정 작업 유형과 관련된 구성 옵션에 대해 설명합니다.
다시 쓰기 작업
다시 쓰기 작업은 현재 규칙 입력 문자열을 대체 문자열로 바꿉니다. 대체 문자열은 규칙의 작업> 요소 값 <특성 내에 지정됩니다. 대체 문자열은 다음을 포함할 수 있는 자유 형식 문자열입니다.
- 조건 및 규칙 패턴에 대한 백 참조입니다. (자세한 내용은 백 참조를 사용하는 방법에 대한 섹션을 참조하세요.)
- 서버 변수. (자세한 내용은 서버 변수를 사용하는 방법에 대한 섹션을 참조하세요.)
없음 작업
아무 작업도 수행해서는 안 되도록 지정하는 데는 아무 작업도 사용되지 않습니다.
다시 쓰기 규칙에서 응답 헤더 액세스
모든 응답 HTTP 헤더의 내용은 서버 변수에 액세스하는 것과 동일한 구문을 사용하지만 특별한 명명 규칙을 사용하여 다시 쓰기 규칙 내에서 가져올 수 있습니다. 서버 변수가 "RESPONSE_"로 시작하는 경우 다음 명명 규칙을 사용하여 이름이 결정되는 HTTP 응답 헤더의 콘텐츠를 저장합니다.
- 이름의 모든 밑줄("_") 기호는 대시 기호("-")로 변환됩니다.
- "RESPONSE_" 접두사는 제거됩니다.
예를 들어 다음 사전 조건은 콘텐츠 형식 헤더의 콘텐츠를 평가하는 데 사용됩니다.
<preCondition name="IsHTML">
<add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
</preCondition>
요청 헤더 및 서버 변수 설정
URL 재작성 모듈 2.0의 인바운드 다시 쓰기 규칙을 사용하여 요청 헤더 및 서버 변수를 설정할 수 있습니다.
허용되는 서버 변수 목록
전역 다시 쓰기 규칙을 사용하여 모든 요청 헤더 및 서버 변수를 설정하고 기존 변수를 덮어쓸 수 있습니다. 분산 재작성 규칙은 허용된 서버 변수 allowedServerVariables에 대해 허용된 목록에 정의된 요청 헤더 및 서버 변수 <만 설정/덮어쓸 수 있습니다>. 분산 재작성 규칙이 allowedServerVariables 컬렉션에 <나열되지 않은 서버 변수 또는 HTTP 헤더를> 설정하려고 하면 URL 다시 쓰기 모듈에서 런타임 오류가 생성됩니다. allowedServerVariables> 컬렉션은 <기본적으로 applicationHost.config 파일에 저장되며 IIS 서버 관리자만 수정할 수 있습니다.
인바운드 다시 쓰기 규칙을 사용하여 요청 헤더 및 서버 변수 설정
규칙 요소 <serverVariables> 는 설정할 서버 변수 및 http 헤더의 컬렉션을 정의하는 데 사용됩니다. 규칙 패턴이 일치하고 조건 평가가 성공한 경우에만 설정됩니다(규칙 구성에 따라 일치하는 모든 조건 또는 하나 이상의 일치하는 조건). serverVariables 컬렉션의 <각 항목은> 다음으로 구성됩니다.
이름 - 설정할 서버 변수의 이름을 지정합니다.
값 - 서버 변수의 값을 지정합니다. 값은 다음을 포함할 수 있는 자유 형식 문자열입니다.
- 조건 및 규칙 패턴에 대한 백 참조입니다. (자세한 내용은 백 참조를 사용하는 방법에 대한 섹션을 참조하세요.)
- 서버 변수. (자세한 내용은 서버 변수를 사용하는 방법에 대한 섹션을 참조하세요.)
Replace 플래그 - 서버 변수 값이 이미 있는 경우 덮어쓸지 여부를 지정합니다. 기본적으로 바꾸기 기능은 사용하도록 설정됩니다.
다음 예제 규칙은 요청된 URL을 다시 작성하고 이름 X_REQUESTED_URL_PATH 서버 변수도 설정합니다.
<rule name="Rewrite to index.php" stopProcessing="true">
<match url="(.*)\.htm$" />
<serverVariables>
<set name="X_REQUESTED_URL_PATH" value="{R:1}" />
</serverVariables>
<action type="Rewrite" url="index.php?path={R:1}" />
</rule>
참고: 위의 예제가 작동하려면 allowedServerVariables> 컬렉션에 <X_REQUESTED_URL_PATH 추가해야 합니다.
<rewrite>
<allowedServerVariables>
<add name="X_REQUESTED_URL_PATH" />
</allowedServerVariables>
</rewrite>
요청 헤더에 대한 참고 사항
요청 헤더는 서버 변수와 동일한 메커니즘을 사용하지만 특별한 명명 규칙을 사용하여 설정됩니다. serverVariables> 컬렉션의 <서버 변수 이름이 "HTTP_"로 시작하는 경우 다음 명명 규칙에 따라 HTTP 요청 헤더가 설정됩니다.
- 이름의 모든 밑줄("_") 기호는 대시 기호("-")로 변환됩니다.
- 모든 문자는 소문자로 변환됩니다.
- "HTTP_" 접두사는 제거됩니다.
예를 들어 다음 구성은 요청에 대한 사용자 지정 x-original-host 헤더를 설정하는 데 사용됩니다.
<set name="HTTP_X_ORIGINAL_HOST" value="{HTTP_HOST}" />
응답 헤더 설정
URL 다시 쓰기 모듈 2.0의 아웃바운드 다시 쓰기 규칙을 사용하여 새 응답을 설정하거나 기존 응답 HTTP 헤더를 수정할 수 있습니다. 응답 HTTP 헤더는 서버 변수와 동일한 구문을 사용하고 다시 쓰기 규칙에서 응답 헤더 액세스에 설명된 대로 명명 규칙을 사용하여 아웃바운드 규칙 내에서 액세스합니다.
아웃바운드 다시 쓰기 규칙의 match> 요소에 <대한 serverVariable 특성에 값이 있으면 이 다시 쓰기 규칙이 해당 응답 헤더의 콘텐츠에서 작동한다는 것을 나타냅니다. 예를 들어 다음 규칙은 응답 헤더 "x-custom-header"를 설정합니다.
<outboundRules>
<rule name="Set Custom Header">
<match serverVariable="RESPONSE_X_Custom_Header" pattern="^$" />
<action type="Rewrite" value="Something" />
</rule>
</outboundRules>
다시 쓰기 규칙의 패턴은 지정된 응답 헤더의 내용에 적용되며 규칙의 패턴 및 선택적 조건이 성공적으로 평가되면 해당 응답 헤더의 값을 다시 작성합니다.
정규식 패턴과 재작성 규칙 내의 기존 요청 및 응답 헤더에 쉽게 액세스하면 응답 HTTP 헤더를 다시 쓰기 위한 논리를 정의할 때 많은 유연성을 제공합니다. 예를 들어 다음 다시 쓰기 규칙을 사용하여 리디렉션 응답에서 Location 헤더의 콘텐츠를 수정할 수 있습니다.
<outboundRules>
<!-- This rule changes the ___domain in the HTTP ___location header for redirection responses -->
<rule name="Change Location Header">
<match serverVariable="RESPONSE_LOCATION" pattern="^http://[^/]+/(.*)" />
<conditions>
<add input="{RESPONSE_STATUS}" pattern="^301" />
</conditions>
<action type="Rewrite" value="http://{HTTP_HOST}/{R:1}"/>
</rule>
</outboundRules>
다시 쓰기 규칙에서 백 참조 사용
규칙 또는 조건 입력의 일부는 백 참조에서 캡처될 수 있습니다. 그런 다음 규칙 작업 내에서 대체 URL을 생성하거나 규칙 조건에 대한 입력 문자열을 생성하는 데 사용할 수 있습니다.
백 참조는 규칙에 사용되는 패턴 구문의 종류에 따라 다른 방식으로 생성됩니다. ECMAScript 패턴 구문을 사용하는 경우 백 참조를 캡처해야 하는 패턴 부분에 괄호를 배치하여 백 참조를 만들 수 있습니다. 예를 들어 패턴([0-9]+)/([a-z]+).html 07 및 아티클을 이 문자열 07/article.html 백 참조로 캡처합니다. "Wild카드" 패턴 구문을 사용하면 패턴에서 별표 기호(*)를 사용할 때 항상 백 참조가 만들어집니다.
백 참조 사용은 캡처하는 데 사용된 패턴 구문과 관계없이 동일합니다. 다시 쓰기 규칙 내의 다음 위치에서 백 참조를 사용할 수 있습니다.
In condition 입력 문자열
규칙 작업에서 특히 다음을 수행합니다.
- 인바운드 규칙에서 다시 쓰기 및 리디렉션 작업의 URL 특성
- 아웃바운드 규칙에서 다시 쓰기 작업의 값 특성
- 상태 CustomResponse 작업의Line 및 responseLine
다시 쓰기 맵에 대한 키 매개 변수
조건 패턴에 대한 백 참조는 N이 0에서 9까지인 {C:N}으로 식별됩니다. 규칙 패턴에 대한 백 참조는 N이 0에서 9인 {R:N}으로 식별됩니다. {R:0} 및 {C:0}의 두 가지 백 참조 형식에는 일치하는 문자열이 포함됩니다.
이 패턴의 예는 다음과 같습니다.
^(www\.)(.*)$
문자열 www.foo.com 의 경우 백 참조는 다음과 같이 인덱싱됩니다.
{C:0} - www.foo.com
{C:1} - www.
{C:2} - foo.com
여러 조건에서 캡처 그룹 추적
기본적으로 규칙 작업 내에서 규칙 패턴 및 해당 규칙의 마지막 일치 조건에 대한 백 참조를 사용할 수 있습니다. 예를 들어 다음 규칙에서 다음을 수행합니다.
<rule name="Back-references with trackAllCaptures set to false">
<match url="^article\.aspx" >
<conditions>
<add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
<add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />
</conditions>
<action type="Rewrite" url="article.aspx/{C:1}" /> <!-- rewrite action uses back-references to the last matched condition -->
</rule>
백 참조 {C:1}은(는) 항상 두 번째 조건의 캡처 그룹 값을 포함하며 이는 쿼리 문자열 매개 변수 p2의 값입니다. p1 값은 백 참조로 사용할 수 없습니다.
URL 다시 쓰기 모듈 2.0에서는 캡처 그룹을 인덱싱하는 방법을 변경할 수 있습니다. 조건> 컬렉션에서 <trackAllCaptures 설정을 사용하도록 설정하면 캡처 그룹이 백 참조를 통해 사용할 수 있도록 일치하는 모든 조건을 형성합니다. 예를 들어 다음 규칙에서 다음을 수행합니다.
<rule name="Back-references with trackAllCaptures set to true">
<match url="^article\.aspx" >
<conditions trackAllCaptures="true">
<add input="{QUERY_STRING}" pattern="p1=([0-9]+)" />
<add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />
</conditions>
<action type="Rewrite" url="article.aspx/{C:1}/{C:2}" /> <!-- rewrite action uses back-references to both conditions -->
</rule>
백 참조 {C:1}에는 첫 번째 조건의 캡처 그룹 값이 포함되며, 백 참조 {C:2}에는 두 번째 조건의 캡처 그룹 값이 포함됩니다.
trackAllCaptures가 true로 설정되면 조건 캡처 백 참조는 {C:N}으로 식별됩니다. 여기서 N은 0에서 모든 규칙의 조건에 걸쳐 총 캡처 그룹 수입니다. {C:0}은(는) 일치하는 첫 번째 조건의 일치하는 문자열 전체를 포함합니다. 예를 들어 다음과 같은 두 가지 조건이 있습니다.
<conditions trackAllCaptures="true">
<add input="{REQUEST_URI}" pattern="^/([a-zA-Z]+)/([0-9]+)/$" />
<add input="{QUERY_STRING}" pattern="p2=([a-z]+)" />
</conditions>
{REQUEST_URI}에 "/article/23/"이 포함되어 있고 {QUERY_STRING}에 "p1=123&p2=abc"가 포함된 경우 조건 백 참조는 다음과 같이 인덱싱됩니다.
{C:0} - "/article/23/"
{C:1} - "article"
{C:2} - "23"
{C:3} - "abc"
IIS 로그에 다시 쓴 URL 로깅
HTTP 클라이언트에서 요청한 원래 URL을 로깅하는 대신 IIS 로그 파일에 다시 작성된 URL을 기록하도록 분산 인바운드 다시 쓰기 규칙을 구성할 수 있습니다. 다시 작성된 URL 로깅을 사용하도록 설정하려면 규칙 <> 작업 요소의 logRewrittenUrl 특성을 사용합니다( 예:
<rule name="set server variables">
<match url="^article/(\d+)$" />
<action type="Rewrite" url="article.aspx?id={R:1}" logRewrittenUrl="true" />
</rule>