禁用webdav后，为什么在本地工作的WebApi的DELETE请求上出现405方法不允许错误？

Question

当我调用WebApi DELETE端点时，我收到一条405错误，提示“请求的资源不支持http方法'DELETE'”。 此问题仅发生在我们的暂存环境中，并且在本地一切正常。

我知道与SE相关的问题很多，但相信我已经尝试了所有标准解决方案，包括：

1）确认我的参数名称与我的webapiconfig路由设置匹配： config.Routes.MapHttpRoute("Default", "api/{controller}/{id}", new {id = RouteParameter.Optional}); 是路由配置， public HttpActionResult Delete(int id)是控制器方法签名。

2）在我的Web.config <handlers>尝试verb =“ *”和verb =“ GET，HEAD，POST，DEBUG，PUT，DELETE”进行URL路由。

3）在我的Web.config中，将<remove name="WebDAVModule"/>到<modules runAllManagedModulesForAllRequests="true">并将<remove name="WebDAV"/>到<handlers> 。 （我通读了这篇文章，并尝试复制此处发布的解决方案以及SE上的几种变体）。

进行调用没有涉及Javascript，因此排除了解决此问题的其他常见解决方案。 现在是我的web.config文件的system.webServer部分。 有什么想法吗？

<system.webServer> <validation validateIntegratedModeConfiguration="false" /> <modules runAllManagedModulesForAllRequests="true"> <remove name="WebDAVModule"/> </modules> <handlers> <remove name="WebDAV" /> <remove name="OPTIONSVerbHandler" /> <remove name="TRACEVerbHandler" /> <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" /> <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" /> <remove name="ExtensionlessUrlHandler-Integrated-4.0" /> <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\\Microsoft.NET\\Framework\\v4.0.30319\\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0" /> <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" modules="IsapiModule" scriptProcessor="%windir%\\Microsoft.NET\\Framework64\\v4.0.30319\\aspnet_isapi.dll" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0" /> <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" /> </handlers> </system.webServer>

Answer 1

因此，为了后人的缘故-问题实际上是登台计算机和生产计算机上的IIS配置。 IIS指向的文件路径不是Octopus部署站点的最新版本的文件夹，而是存储旧版本的文件夹。 因此该站点仍处于启动状态，但是未使用新代码。 我在问题中尝试的修复成功。