들어오는 요청 라우팅

HTTP 서버 API는 들어오는 요청을 수신하는 애플리케이션을 결정하기 위해 라우팅 데이터베이스를 유지 관리합니다. 라우팅 테이블은 예약 데이터베이스에서 빌드되며 예약 항목과 현재 등록을 포함합니다. 등록 또는 예약이 수행되면 다음과 같이 호스트 유형에 해당하는 라우팅 데이터베이스 버킷에 배치됩니다.

• + : 포트 등록은 "강력한 와일드카드" 버킷에 배치됩니다.

• host : 포트 등록이 "명시적" 버킷에 배치됩니다.

• IP: 포트 등록은 "IP 바인딩된 약한 와일드카드" 버킷에 배치됩니다.

• * : 포트 등록이 "약한 와일드카드" 버킷에 배치됩니다.

이러한 단계는 들어오는 HTTP 요청이 처리되는 순서도 참조합니다. 먼저 강력한 와일드카드 예약을 선택한 다음 명시적 예약을 확인한 다음 IP 바인딩된 약한 와일드카드와 약한 와일드카드를 확인합니다. 일치하는 항목이 발견되면 나머지 버킷의 등록을 찾을 수 없도록 검색이 중지됩니다.

HTTP Server API 라우팅 알고리즘은 강력한 와일드카드 버킷부터 시작하여 약한 와일드카드 버킷으로 끝나는 라우팅 데이터베이스의 등록 항목과 예약 항목을 모두 검색하여 UrlPrefix 에 가장 적합한 항목을 찾습니다. 버킷 내에서 가장 일치하는 항목은 UrlPrefix의 상대 URI 부분에서 가장 긴 일치 항목입니다(URL의 호스트, 포트 및 구성표 부분에 대한 정확한 일치를 가정). 버킷에서 일치 항목이 발견되면 라우팅 알고리즘은 검색을 중지하고 우선 순위가 낮은 버킷을 모두 건너뜁니다.

예를 들어 버킷 유형에 따라 우선 순위의 내림차순으로 나열된 다음 등록을 고려합니다.

• 등록: https://+:80/vroot/ 애플리케이션 1에서 등록됨

• 등록: https://adatum.com:80/ 애플리케이션 2에 의해 등록됨

• 등록: https://\*:80/ 애플리케이션 3에 의해 등록됨

에 대한 https://adatum.com:80/vroot/subdir/file.htm/ 들어오는 요청이 애플리케이션 1로 전달됩니다. 에 대한 https://adatum.com:80/default.htm/ 들어오는 요청이 애플리케이션 2로 전달됩니다. 에 대한 https://otheradatum.com:80/file.htm/ 들어오는 요청이 애플리케이션 3으로 전달됩니다.

가장 일치하는 항목이 예약 항목인 경우 요청을 수신해야 하는 애플리케이션이 실행되고 있지 않음을 의미합니다. 예를 들어 다음 등록 및 예약을 고려합니다.

• 등록: https://\*:80/vroot/ 애플리케이션 1, 사용자 A에 의해 등록됨

• 예약: https://adatum.com:80/ 사용자 B용으로 예약되었습니다.

에 대한 https://adatum.com:80/vroot/file.htm/ 들어오는 요청은 가장 일치하는 항목이 사용자 B에 대한 예약 항목으로 이어지므로 애플리케이션 1에 전달되지 않습니다. 우선 순위 규칙이 이 경우 우선 순위가 더 높은 예약에 적용됩니다. 수신된 URL에 대한 서비스 요청에 권한이 부여되고 등록된 프로세스가 활성 상태이면 요청이 400 상태 코드(잘못된 요청)로 거부됩니다.