IIS 10給予401.3訪問拒絕PUT，DELETE或PATCH的特定路徑

Question

我正在使用REST API，並且使用其本機IIS安裝在Windows 10上進行測試和原型工作。 API是用C＃編寫的。我創建了一個派生自IHttpHandler的類，並從中派生出來實現API的名詞的類。 （這使我能夠在我的基礎名詞類中共同記錄，配置，審計等）。爲了實現動詞，派生類覆蓋GET，POST等基類的函數。

無論如何，我擁有的名詞之一是用於訪問應用程序的日誌。這個路徑是/ log。其中我已經實現了GET，讀取日誌和DELETE，以清除日誌。 GET工作正常，但是，DELETE給了我一個來自IIS的401.3。如果我嘗試PUT或PATCH，我也會得到相同的401.3。 PUT和PATCH沒有在Logging類中實現，所以它們應該返回一個未實現的消息。如果我嘗試POST（沒有以與PUT和PATCH未實現完全相同的方式實現），我會得到未實現的消息。

作爲試圖縮小這種行爲的一部分，我檢查了是否有特定的動詞被請求過濾阻塞（沒有）。我檢查了Process Monitor是否在基礎路徑上捕獲文件系統訪問拒絕（它不是......事情從來沒有那麼遠）。然後，我嘗試添加另一個處理程序映射 - 與第一個完全相同，但是具有不同的路徑名稱：

<處理>

<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" > 

< /處理器>

使用郵差，如果我叫刪除/日誌中，我得到了401.3。如果我在/ foo上調用DELETE，它可以正常工作。如果我在/ log上調用PUT，我會得到401.3。如果我在/ foo上調用PUT，我會得到正確的未實現的消息。

任何人都有一個想法，爲什麼IIS應該對調用/ log路徑的動詞做額外的審查？

感謝， 保羅

Answer 1

我也有類似的問題，即PUT和DELETE不工作，它變成了對我來說是webdav的問題。在我的情況下，我並不真的需要它，所以我卸載它，一切正常。