Ответ 1

Ответ оказывается вызванным большей политикой Microsoft Broken по умолчанию.

Вместо того, чтобы выступать в роли веб-сервера, принимая запросы и обрабатывая их, ASP.net по умолчанию решает игнорировать большинство запросов - поскольку он думает, что пользователь не должен их делать.

Решение состоит в том, чтобы разорвать все, что связано с ASP.net, из IIS, а затем повторно добавить его правильно:

web.config

<?xml version="1.0"?>
<configuration>
    <modules runAllManagedModulesForAllRequests="true">
      <!--IISFIX: Whatever this is, it causes 405 Method Not Allowed errors on IIS when using PUT. (Microsoft broken by defult)-->
      <remove name="WebDAVModule"/>
    </modules>
    <handlers>
         <!--IISFIX: ASP.net is broken by default. By default they will not accept verbs from the client.
         First we have to rip out everything related to ASP.net-->
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit"/>
      <remove name="ExtensionlessUrlHandler-Integrated-4.0"/>
      <remove name="ExtensionlessUrlHandler-ISAPI-4.0_32bit"/>
      <remove name="SimpleHandlerFactory-ISAPI-2.0-64"/>
      <remove name="SimpleHandlerFactory-ISAPI-2.0"/>
      <remove name="SimpleHandlerFactory-Integrated"/>
      <remove name="SimpleHandlerFactory-Integrated-4.0"/>
      <remove name="SimpleHandlerFactory-ISAPI-4.0_64bit"/>
      <remove name="SimpleHandlerFactory-ISAPI-4.0_32bit"/>
         <!-- IISFIX: Now that we're ripped out everything related to ASP.net, put them back correctly.-->
      <add name="SimpleHandlerFactory-ISAPI-4.0_32bit" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0"/>
      <add name="SimpleHandlerFactory-ISAPI-4.0_64bit" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0"/>
      <add name="SimpleHandlerFactory-Integrated-4.0" path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0"/>
      <add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="*" type="System.Web.UI.SimpleHandlerFactory" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode"/>
      <add name="SimpleHandlerFactory-ISAPI-2.0" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness32" responseBufferLimit="0"/>
      <add name="SimpleHandlerFactory-ISAPI-2.0-64" path="*.ashx" verb="*" modules="IsapiModule" scriptProcessor="%windir%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv2.0,bitness64" responseBufferLimit="0"/>
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_32bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness32" responseBufferLimit="0"/>
      <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode,runtimeVersionv4.0"/>
      <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" path="*." verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="Script" preCondition="classicMode,runtimeVersionv4.0,bitness64" responseBufferLimit="0"/>

      <!--IISFIX: WebDAV is also buggy, and interferes with client requests-->
      <remove name="WebDAV"/>

    </handlers>
  </system.webServer>
</configuration>

Теперь проблема заключается в том, что веб-сайт не будет работать ни на одной машине; теперь есть жестко закодированные пути к файлам в web.config.

Почему, почему, Microsoft не может сделать все правильно.

Для полноты

Для моей собственной ссылки, вот что мне нужно добавить в web.config каждый раз, потому что по умолчанию неверны:

  <system.web>
    <httpRuntime/>
    <!-- IISFIX: By default IIS hides errors-->
    <customErrors mode="Off"/>
    <!-- IISFIX: By default IIS ignores the browser culture -->
    <globalization culture="auto" uiCulture="auto"/>
  </system.web>

  <!-- ASP.net web-sites do not support WebPageTraceListener (only ASP.net web-applications) 
  So this section doesn't work; and does nothing. 
  But if Microsoft ever fixes IIS, we will start working automagically. -->
  <system.diagnostics>
    <trace>
      <listeners>
        <add name="WebPageTraceListener" type="System.Web.WebPageTraceListener, System.Web, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
      </listeners>
    </trace>
  </system.diagnostics>

  <system.webServer>
    <!-- IISFIX: By default IIS ignores custom error pages -->
    <httpErrors existingResponse="PassThrough"/>
  </system.webServer>

Ответ 2

Я обнаружил, что удаление ссылок webDav от обработчиков и модулей в вышеупомянутом решении по-прежнему приводило к IIS 7.5, IIS 7 Windows server 2008 r2 (я никогда не тестировал IIS 8) для http-методов PUT, DELETE

Ошибка HTTP 500.21 - Внутренняя ошибка сервера Обработчик "ExtensionlessUrlHandler-Integrated-4.0" имеет плохой модуль "ManagedPipelineHandler"

Эта ошибка сервера вводит в заблуждение и также указывается для неправильных установок .net, где отсутствует обработчик, и может быть исправлено путем повторной установки .Net, но это, вероятно, не решение, если оно влияет только на запросы PUT или DELETE обработчик маршрута без удлинения (GET, POST и OPTIONS были в порядке). Я прочитал так много сообщений о включении методов put и delete в MVC и Web api, которые, казалось, утверждали, что это исправление, поэтому я несколько раз пробовал его, перезапускал IIS и т.д., Никаких изменений в ошибке.

проблема не исчезла, пока я не добавил в элемент modules runManagedModulesForWebDavRequests = "true" .

< модули runAllManagedModulesForAllRequests = "true" runManagedModulesForWebDavRequests = "true" >

http://www.iis.net/configreference/system.webserver/modules

По умолчанию runManagedModulesForWebDavRequests = "false", что означает, что любой запрос webDav перенаправляется в WebDav. Насколько я могу судить, запрос webdav - это все HTTP-запросы PUT или DELETE в отношении IIS, даже если вы удалили обработчик webdav из веб-конфигурации, и ваш орган запроса не соответствует запросу webdav. Возможно, удаление webDav также может устранить проблему, но я никогда не пробовал это; У меня есть другие сайты, работающие на том же сервере, которые зависят от него.

Ответ 3

Я нашел ответ здесь:

Ядро ASP.NET с IIS - HTTP-глагол не разрешен

Это web.config

<configuration>
<!-- To customize the asp.net core module uncomment and edit the following section. 
     For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->
<system.webServer>
    <modules>
        <remove name="WebDAVModule" />
    </modules>
    <handlers>
        <remove name="aspNetCore" />
        <remove name="WebDAV" />
        <!-- I removed the following handlers too, but these
             can probably be ignored for most installations -->
        <remove name="ExtensionlessUrlHandler-Integrated-4.0" />
        <remove name="OPTIONSVerbHandler" />
        <remove name="TRACEVerbHandler" />

        <add name="aspNetCore" 
             path="*" 
             verb="*" 
             modules="AspNetCoreModule" 
             resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" 
                arguments="%LAUNCHER_ARGS%" 
                stdoutLogEnabled="false"
                stdoutLogFile=".\logs\stdout" />
</system.webServer>

Ответ 4

Что-то, что следует отметить в этом в будущем, - это когда вы создаете код для чего-то не локального, что вы можете изменить возможные жестко кодированные учетные данные для общих учетных записей доступа. У меня была эта точная проблема в течение полутора дней и я увидел, что запрос DELETE.net, который работал с LDAP, использовал идентификатор сотрудника с жестким кодом прежнего сотрудника как UserPrincipalName. Он работал нормально, пока его идентификатор, наконец, не был удален из нашей системы, тогда все пошло не так. Снова после дня и половины мы обнаружили жестко закодированные учетные данные, используемые для целей тестирования. Простой пример, иллюстрирующий разные вещи, которые должны учитываться в разных средах тестирования.