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 요소의 컨텍스트에서 가능한 모든 호스트 이름과 일치하며 강력한 와일드카드 범주에 속합니다.

강력한 와일드카드는 애플리케이션이 해당 요청이 컴퓨터에 도착하는 방법 또는 호스트 헤더에 지정한 사이트에 관계없이 하나 이상의 상대URI에 주소가 지정된 요청을 제공해야 하는 경우에 유용합니다. 이 상황에서 강력한 와일드카드를 사용하면 호스트 및/또는 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 Server API는 요청에 실패합니다. 이렇게 하면 우선 순위가 낮은 등록이 의도하지 않은 요청을 선택할 수 없습니다. 오류 시 상태 503("서비스를 사용할 수 없음")이 아닌 400("잘못된 요청")입니다. 503 반환은 서버가 오버로드되었음을 나타내는 것처럼 부하 분산 게이트웨이에 의해 실수로 해석되기 때문입니다.

범주 내에서 일치하는 등록이 발견되면 요청은 해당 등록과 연결된 요청 큐로 라우팅됩니다. 요청은 항상 범주 내에서 가장 긴 일치 UrlPrefix와 연결된 큐로 라우팅됩니다.

범주에 일치하는 항목이 없으면 HTTP Server API가 명시적 범주로 이동하고 동일한 절차를 반복합니다. 요약하면 범주를 검사하는 순서는 다음과 같습니다.

  1. 강력한 와일드카드
  2. 명시적
  3. 약한 와일드카드 IP-Bound
  4. 약한 와일드카드

범주에서 일치하는 항목이 없으면 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로 라우팅합니다. 가장 긴 전체 일치는 UrlPrefix가 아닌 UrlPrefix와 https://www.adatum.com:80/ 일치하므로 에 대한 https://www.adatum.com:80/dir/app.htm 요청을 Queue1로 https://www.adatum.com:80/dir/sna 라우팅합니다.