예약 추가

라우팅 데이터베이스에는 예약 목록이 포함됩니다. 예약 목록은 예약에 나열된 각 사용자에 대한 액세스 수준뿐만 아니라 네임스페이스에 대한 액세스가 허용되는 사용자로 구성됩니다. 예약이 추가되거나 삭제되면 라우팅 데이터베이스가 검색되어 액세스 권한을 확인합니다.

HTTP Server API는 사용자 ID를 확인하는 것 외에도 새 예약을 설치하기 전에 기존 예약에서 충돌을 확인합니다.

새 예약을 추가하려면

UrlPrefix의 포트 번호에 UrlPrefix의 스키마와 다른 스키마에 대한 예약 또는 등록이 있는 경우 등록이 실패합니다. HTTP 및 HTTPS는 동일한 포트에서 지원될 수 없습니다.
호스트 유형에 따라 등록에 적합한 버킷을 찾습니다(라우팅 수신 요청 섹션 참조). 나머지 단계는 이 버킷을 기준으로 합니다.
예약 중인 UrlPrefix와 일치하는 구성표, 호스트 및 포트 구성 요소가 있는 예약 항목을 선택합니다. 여기서 예약의 relativeUri와 같지 않은 가장 긴 일치하는 relativeUri을 가진 항목을 찾으세요 (즉, 부모 노드가 아닙니다). 항목이 있는 경우 해당 항목에 할당된 ACL에 따라 액세스 권한을 평가합니다.
부모 노드를 찾을 수 없는 경우, 이는 빈 relativeUri가 있는 예약이거나 예약 , 또는 루트 예약입니다. 호출자가 LocalSystem 또는 관리자 계정으로 등록된 경우에만 액세스 권한을 부여합니다.
액세스 권한이 부여된 경우 중복 예약을 확인합니다. 동일한 체계, 포트, 호스트 및 relativeUri를 사용하여 예약 항목이 있는 경우 ERROR_ALREADY_EXISTS 코드가 반환됩니다.

메모

기존 항목 업데이트는 항목을 삭제하고 새 항목을 추가하는 두 단계로 수행해야 합니다.

위의 단계가 성공하면 예약 데이터베이스에 새 예약 항목이 입력됩니다.

메모

새 항목은 지정된 ACL을 사용하여 만들어지고 부모 항목에서 ACL을 상속하지 않습니다.

다음 예제에서는 예약 프로세스를 보여 줍니다.

예약 1: https://+:80/vroot/subdir/가 관리자에 의해 사용자 A 및 사용자 C에 대해 성공하여 "+" 버킷에 입력됩니다.
예약 2: 관리자가 사용자 B에 대한 예약 https://adatum.com:80/vroot/를 성공적으로 완료했고 "명시적 호스트" 버킷에 입력되었습니다.
예약 3: 사용자 B가 사용자 C를 위해 한 예약 https://adatum.com:80/vroot/subdir/otherdir/은 예약 2로 인해 성공했습니다.
예약 4: 사용자 A가 사용자 E를 위해 한 예약 https://+:80/vroot/subdir/otherdir/은 예약 1 덕분에 성공합니다.
사용자 A가 사용자 E를 위해 만든 예약 https://adatum.com:80/vroot/subdir/otherdir/이 실패했습니다. 예약 2로 인해 액세스가 거부되었습니다.
예약 6: 관리자에 의한 사용자 A에 대한 https://+:80/vroot/subdir/ 예약이 실패했습니다. 예약이 예약 1과 충돌합니다.
사용자 A의 예약 7: https://adatum.com:80/newroot/가 사용자 A에게 실패했습니다. LocalSystem 또는 Administrator에 대한 https://adatum.com:80/ 암시적 루트 예약으로 인해 액세스가 거부되었습니다.

예약은 이전에 UrlPrefix를 등록한 프로세스에 전달된 요청의 URL 집합에 영향을 줄 수 있습니다. 예를 들어 다음 시나리오를 고려해 보세요.

피드백

이 페이지가 도움이 되었나요?