禁用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部署站點的最新版本的文件夾，而是存儲舊版本的文件夾。 因此該站點仍處於啟動狀態，但是未使用新代碼。 我在問題中嘗試的修復成功。