HTTP 서버 API는 라우팅 데이터베이스를 사용하여 등록하는 동안 액세스 검사를 적용합니다. UrlPrefix 등록은 네임스페이스에 등록하는 사용자에게 액세스 권한이 있는지 확인하기 위해 일련의 액세스 검사를 통과해야 합니다. HttpAddUrl 함수를 사용하여 새 등록을 추가합니다.
새로운 등록을 HttpAddUrl로 추가하려면
- UrlPrefix의 포트 번호에 UrlPrefix의 스키마와 다른 스키마에 대한 예약 또는 등록이 있는 경우 등록이 실패합니다. HTTP 및 HTTPS는 동일한 포트에서 지원될 수 없습니다.
- 등록은 등록에 적합한 버킷에 슬롯됩니다. 버킷은 들어오는 요청 라우팅 섹션에 설명된 대로 URL의 호스트 유형을 기반으로 합니다. 다음 단계는 이 특정 버킷을 기준으로 합니다.
- 중복 등록 항목이 있는 경우 오류 코드를 반환합니다.
- UrlPrefix와 동일한 스키마, 호스트 및 포트 구성 요소를 가진 예약 항목을 선택합니다. 이들 항목 중에서 가장 긴 relativeUri 일치하는 항목을 찾습니다. 항목이 있는 경우 해당 항목과 연결된 ACL에 따라 사용 권한을 확인하고 성공을 반환합니다. 항목이 없으면 ERROR_ALREADY_EXISTS 코드를 반환합니다.
다음 예제에서는 라우팅 데이터베이스에 등록을 설치하는 프로세스를 보여 줍니다. 예약 1과 2는 라우팅 데이터베이스에 있습니다.
- 예약 1: 사용자 A 및 사용자 C에 대한
https://+:80/vroot/subdir/. 이 예약은 "+" 버킷에 배치됩니다. - 예약 2: 사용자 B에 대한
https://adatum.com:80/vroot/. 이 예약은 "명시적 호스트" 버킷에 배치됩니다. - 사용자 B의 등록
https://+:80/vroot/subdir/가 예약 1로 인해 실패합니다. - 등록: 사용자 B에 의한
https://adatum.com:80/vroot/subdir/가 예약 2로 인해 성공했습니다. - 등록: 구체적인 예약 2로 인해 사용자 C의
https://adatum.com:80/vroot/subdir/등록이 실패했습니다. 강력한 와일드카드 예약은 명시적 예약 또는 등록 컨텍스트 내에서 의미가 없습니다. - 사용자 A의
https://+:80/vroot/subdir/등록은 예약 1로 인해 성공합니다. - 등록: 사용자 B의
https://adatum.com:80/vroot/anotherdir/은 예약 2로 인해 성공했습니다.
등록에 대한 액세스 확인에는 위임 권한에 대한 검사가 포함되지 않습니다. 예약을 기반으로 하는 액세스 검사는 없습니다(httpRemoveUrl참조). 등록을 삭제하기 위한 유일한 요구 사항은 호출 프로세스가 등록을 만들었어야 한다는 것입니다.