REST API에서 작업 중이며 기본 IIS 설치로 Windows 10에서 테스트 및 프로토 타입 작업을 수행하고 있습니다. API는 C#으로 작성되었습니다. IHttpHandler에서 파생 된 클래스를 만들고 API의 명사에 대한 클래스를 구현하는 클래스에서 파생되었습니다. (기본 기본 클래스에서 로깅, 설정, 감사 등을 공통화 할 수 있습니다.) 동사를 구현하기 위해 파생 클래스는 기본 클래스의 GET, POST 등의 함수를 재정의합니다.IIS 10에서 특정 경로에 대해 PUT, DELETE 또는 PATCH에 대해 401.3 액세스가 거부되었습니다.
어쨌든 명사 중 하나는 응용 프로그램의 로그에 액세스하는 것입니다. 이 경로는/log입니다. 그것에서 로그를 읽으려면 GET을 구현하고, 로그를 지우려면 DELETE를 구현했습니다. GET 잘 작동하지만 DELETE는 IIS에서 401.3을 제공합니다. PUT 또는 PATCH를 시도해도 같은 401.3을 얻습니다. PUT 및 PATCH는 Logging 클래스에서 구현되지 않으므로 구현되지 않은 메시지를 반환해야합니다. POST (PUT 및 PATCH가 구현되지 않은 것과 정확히 동일한 방식으로 구현되지 않음)를 시도하면 구현되지 않은 메시지가 표시됩니다.
이 동작 범위를 좁히기 위해 요청 필터링에 의해 차단되는 특정 동사가 있는지 여부를 확인했습니다. 나는 Process Monitor가 기본 경로에서 파일 시스템 액세스 거부를 포착하고 있는지 확인했다. (결코 그런 것은 없었습니다.) 다음으로 다른 처리기 매핑을 추가하려고했습니다. 첫 번째와 정확히 같지만 다른 경로를 사용했습니다. 이름 : 나는/로그에서 삭제를 호출하는 경우, I는 401.3를 얻을 우체부를 사용
< 핸들러 >
<add name="BLOBRepoLog" path="log" verb="*" type="BLOBRepoService.Log" resourceType="Unspecified" preCondition="integratedMode" >
<add name="BLOBRepoLogSanityCheck" path="foo" verb="*" type="BLOBRepoService.Log" resourceType="Unspecified" preCondition="integratedMode" >
</핸들러 >
./foo에서 DELETE를 호출하면 올바르게 작동합니다. PUT을/log에 호출하면 401.3을 얻습니다./foo에서 PUT을 호출하면 올바른 구현되지 않은 메시지가 표시됩니다.
누구나 IIS가/log 경로라는 동사에 대한 추가 조사를해야하는 이유는 누구나 알 수 있습니까?
덕분에, 폴