UrlPrefix 문자열
HTTP Server API에서 UrlPrefix URL 네임스페이스의 섹션을 지정하는 정식 형식의 와이드 문자(UTF-16) 유니코드 문자열입니다. 사용자 계정에 대한 URL 네임스페이스 섹션을 예약하거나 프로세스에 대한 URL 네임스페이스의 섹션을 등록하는 데 사용됩니다.
UrlPrefix 형식
UrlPrefix에는 다음 구문이 있습니다.
"scheme://host:port/relativeURI"
UrlPrefix의 구성표, 호스트 및 포트 요소는 존재해야 하며 비어 있지 않아야 하며 다음 규칙을 준수해야 합니다.
-
체계
-
모두 소문자로 된 http 또는 https여야 합니다.
-
호스트
-
정규화된 도메인 이름, IPv4 또는 IPv6 리터럴 문자열 또는 와일드카드여야 합니다. 소문자여야 하는 체계와 달리 호스트 부분은 대/소문자를 구분하지 않습니다. 호스트 부분을 지정하는 방법에 따라 UrlPrefix는 다음 네 가지 라우팅 범주 중 하나에 속합니다. 이 범주는 아래에 자세히 설명되어 있습니다.
- 강력한 와일드카드
- 명시적
- IP 바인딩된 약한 와일드카드
- 약한 와일드카드
-
포트
-
0으로 시작하지 않고 유효한 TCP 포트 번호(1~65,535)를 나타내는 10진수 숫자 문자열입니다. 이 값은 와일드카드일 수 없습니다.
-
relativeURI
-
relativeURI 요소는 선택 사항이지만 존재할 경우 항상 슬래시 문자("/")를 따라야 합니다. 구성표, 호스트 및 포트 값을 기준으로 지정된 컴퓨터 네임스페이스 내의 하위 트리를 나타내는 접두사 문자열입니다. 소문자여야 하는 체계와 달리 relativeURI 부분은 대/소문자를 구분하지 않습니다.
올바르게 구성된 UrlPrefixes의 예는 다음과 같습니다.
https://www.adatum.com:80/vroot/
https://adatum.com:443/secure/database/
https://+:80/vroot/
Host-Specifier 범주
HTTP Server API는 유연성과 사용 편의성을 위해 호스트를 지정하는 네 가지 방법을 지원합니다. 4개의 호스트 지정자 범주는 우선 순위에 따라 아래에 나열됩니다.
-
강력한 와일드카드(더하기 기호)
-
UrlPrefix의 호스트 요소가 단일 더하기 기호(+)로 구성된 경우 UrlPrefix는 구성표, 포트 및 relativeURI 요소의 컨텍스트에서 가능한 모든 호스트 이름과 일치하며 강력한 와일드카드 범주에 속합니다.
강력한 와일드카드는 해당 요청이 컴퓨터에 도착하는 방법 또는 호스트 헤더에 지정한 사이트에 관계없이 애플리케이션이 하나 이상의 relativeURI에 주소가 지정된 요청을 처리해야 하는 경우에 유용합니다. 이 상황에서 강력한 와일드카드를 사용하면 호스트 및/또는 IP 주소의 전체 목록을 지정할 필요가 없습니다.
-
명시적
-
호스트 요소의 정규화된 도메인 이름과 같은 명시적 호스트 이름은 명시적 범주에 UrlPrefix를 배치합니다. 이러한 종류의 호스트 요소는 들어오는 요청의 호스트 헤더와 직접 일치합니다.
명시적 호스트 사양은 요청이 전달된 사이트에 따라 다른 콘텐츠를 제공하는 웹 서버와 같은 다중 사이트 애플리케이션에 유용합니다.
-
IP 바인딩된 약한 와일드카드
-
IP 주소가 호스트 요소로 표시되면 UrlPrefix는 IP 바인딩 약한 와일드카드 범주에 속합니다. 이러한 종류의 UrlPrefix는 지정된 스키마, 포트 및 relativeURI를 사용하여 지정된 IP 인터페이스의 호스트 이름과 일치하며, 강력한 와일드카드 또는 명시적 UrlPrefix와 아직 일치하지 않습니다. IP 주소는 호스트 요소의 두 가지 양식 중 하나를 사용합니다.
-
IPv4 리터럴 문자열
-
IPv4 리터럴은 각각 0-255 범위(예: 192.168.0.0) 범위의 4개의 점선 소수점 숫자로 구성됩니다.
-
IPv6 리터럴 문자열
-
IPv6 리터럴 문자열은 대괄호로 묶고 콜론으로 구분된 16진수 숫자를 포함합니다. 예: [::1] 또는 [3ffe:ffff::6ECB:0101].
IP 바인딩된 약한 와일드카드 호스트 지정자는 들어오는 요청에서 가져온 경로에 따라 제공하는 콘텐츠를 다양하게 하는 애플리케이션을 위한 것입니다. 보안을 적용하기 위해 IP 바인딩된 약한 와일드카드 호스트 지정자를 사용하지 마세요.
-
-
약한 와일드카드(별표)
-
별표(*)가 호스트 요소로 표시되면 UrlPrefix는 약한 와일드카드 범주에 속합니다. 이러한 종류의 UrlPrefix는 강력한 와일드카드, 명시적 또는 IP 바인딩된 약한 와일드카드 UrlPrefix와 아직 일치하지 않은 지정된 체계, 포트 및 relativeURI와 연결된 호스트 이름과 일치합니다.
이 호스트 사양은 경우에 따라 기본 catch-all로 사용하거나 많은 UrlPrefixes를 사용하지 않고 URL 네임스페이스의 큰 섹션을 지정하는 데 사용할 수 있습니다.
예약 및 등록 중 UrlPrefix 충돌 검색
예약 및 등록을 위해 UrlPrefix의 네 가지 범주는 서로 참조 없이 개별적으로 처리됩니다. 서로 다른 범주에 있는 한 충돌하는 UrlPrefixes를 등록할 수 있습니다. 동일한 범주 내에서만 충돌이 발생하면 예약 시도가 실패합니다.
예를 들어 서로 다른 범주에 속하기 때문에 명시적 UrlPrefix https://www.adatum.com:80/vroot/
충돌하는 강력한 와일드카드 UrlPrefix https://+:80/vroot/
모두 예약할 수 있습니다. 그러나 다른 사용자에게 https://+:80/vroot/ 예약하려는 후속 시도는 자체 범주의 기존 예약과 충돌하기 때문에 실패합니다.
라우팅 동작
들어오는 HTTP 요청을 라우팅할 때 HTTP Server API는 강력한 와일드카드 범주로 시작하고 들어오는 URL을 해당 범주의 등록된 Url과 예약된 UrlPrefixes 모두와 비교합니다.
들어오는 URL이 예약과 일치하지만 등록이 아닌 경우 HTTP 서버 API가 요청에 실패합니다. 이렇게 하면 우선 순위가 낮은 등록이 의도하지 않은 요청을 선택할 수 없게 됩니다. 오류 상태는 503("서비스를 사용할 수 없음")이 아닌 400("잘못된 요청")입니다. 503 반환은 때때로 부하 분산 게이트웨이에서 서버가 오버로드되었음을 나타내는 것으로 잘못 해석되기 때문입니다.
범주 내에서 일치하는 등록이 발견되면 요청이 해당 등록과 연결된 요청 큐로 라우팅됩니다. 요청은 항상 범주 내에서 가장 긴 일치 UrlPrefix와 연결된 큐로 라우팅됩니다.
범주에 일치하는 항목이 없으면 HTTP Server API가 명시적 범주로 이동하고 동일한 절차를 반복합니다. 요약하면 범주를 검사하는 순서는 다음과 같습니다.
- 강력한 와일드카드
- 명시적
- 약한 와일드카드 IP-Bound
- 약한 와일드카드
범주에 일치하는 항목이 없으면 HTTP Server API는 상태 코드가 400인 응답을 보내 요청을 라우팅할 수 없음을 나타냅니다.
가장 긴 일치 규칙
각 UrlPrefix 범주 내에서 HTTP Server API는 가장 긴 일치 UrlPrefix와 연결된 큐에 요청을 라우팅합니다. 예를 들어 다음 두 개의 UrlPrefixe가 다른 큐에 등록되어 있다고 가정합니다.
Queue1 https://www.adatum.com:80/
Queue2 https://www.adatum.com:80/dir/sna/
HTTP Server API는 https://www.adatum.com:80/default.htm
요청을 Queue1로 라우팅하고 https://www.adatum.com:80/dir/sna/snadefault.htm
요청은 Queue2로 라우팅합니다. 가장 긴 전체 일치는 https://www.adatum.com:80/dir/sna
UrlPrefix가 아닌 https://www.adatum.com:80/
UrlPrefix와 일치하므로 https://www.adatum.com:80/dir/app.htm
요청을 Queue1로 라우팅합니다.