Fatal编程技术网
  • rest/
  • Rest IIS 10拒绝对特定路径的PUT、DELETE或PATCH进行401.3访问

Rest IIS 10拒绝对特定路径的PUT、DELETE或PATCH进行401.3访问

rest iis

Rest IIS 10拒绝对特定路径的PUT、DELETE或PATCH进行401.3访问,rest,iis,handlers,httpverbs,Rest,Iis,Handlers,Httpverbs,我正在开发一个RESTAPI，并在Windows10上使用其本机IIS安装进行测试和原型工作。API是用C#编写的。我已经创建了一个派生自IHttpHandler的类，并从中派生来实现API名词的类。（这使我能够在我的基本名词类中通用化日志记录、配置、审核等）。为了实现谓词，派生类重写基类的GET、POST等函数 无论如何，我有一个名词是用来访问应用程序的日志。此操作的路径是/log。在它中，我实现了GET来读取日志，DELETE来清除日志。GET工作正常，但是，DELETE给了我一个来自IIS

我正在开发一个RESTAPI，并在Windows10上使用其本机IIS安装进行测试和原型工作。API是用C#编写的。我已经创建了一个派生自IHttpHandler的类，并从中派生来实现API名词的类。（这使我能够在我的基本名词类中通用化日志记录、配置、审核等）。为了实现谓词，派生类重写基类的GET、POST等函数

无论如何，我有一个名词是用来访问应用程序的日志。此操作的路径是/log。在它中，我实现了GET来读取日志，DELETE来清除日志。GET工作正常，但是，DELETE给了我一个来自IIS的401.3版本。如果我尝试使用PUT或PATCH，也会得到相同的401.3。PUT和PATCH未在日志类中实现，因此它们应返回一条未实现的消息。如果我尝试POST（POST的实现方式与PUT和PATCH的实现方式不完全相同），我确实会收到未实现的消息

作为试图缩小这种行为范围的一部分，我检查了是否有特定的动词被请求过滤阻止（没有）。我检查了Process Monitor是否在底层路径上捕捉到文件系统访问拒绝（这不是…事情从来没有这么严重）。然后我尝试添加另一个处理程序映射-与第一个处理程序映射完全相同，但路径名不同：

使用Postman，如果我在/log上调用DELETE，我会得到401.3。如果我在/foo上调用DELETE，它将正常工作。如果我调用PUT on/log，我会得到401.3。如果调用PUT on/foo，则会得到正确的未实现消息

有人知道为什么IIS应该对/log路径调用的动词进行额外检查吗

谢谢，
Paul

我遇到了一个类似的问题，Put和Delete不起作用，结果我发现Webdav就是问题所在。在我的情况下，我并不真的需要它，所以我卸载了它，一切正常

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