我正在开发一个REST API，并在Windows 10上使用其本机IIS安装进行测试和原型工作。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" >
<处理程序>
使用Postman，如果我在/log上调用DELETE，我会得到401.3。如果我在/foo上调用DELETE，它就能正常工作。如果我在/log上调用PUT，我会得到401.3。如果我在/foo上调用PUT，我会得到正确的未实现消息。
有人知道为什么IIS应该对/log路径调用的动词进行额外的审查吗？
谢谢，Paul
我遇到了一个类似的问题，Put和Delete不起作用，结果发现Webdav就是问题所在。就我而言，我其实并不需要它，所以我卸载了它，一切都正常了。