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

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

处理器>

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

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

谢谢， 保罗

Answer 1

我有一个类似的问题，即 Put 和 Delete 不起作用，对我来说，Webdav 是问题所在。就我而言，我真的不需要它，所以我卸载了它，一切正常。