Freigeben über


Problembehandlung für Web-API2-Apps, die in Visual Studio funktionieren und auf einem IIS-Produktionsserver fehlschlagen

In diesem Dokument wird erläutert, wie Sie Probleme mit Web-API2-Apps beheben können, die auf einem IIS-Produktionsserver bereitgestellt werden. Es behebt allgemeine HTTP 405- und 501-Fehler.

In diesem Lernprogramm verwendete Software

Web-API-Apps verwenden in der Regel mehrere HTTP-Verben: GET, POST, PUT, DELETE und manchmal PATCH. Das heißt, Entwickler können sich in Situationen befinden, in denen diese HTTP-Methoden von einem anderen IIS-Modul auf ihrem Produktions-IIS-Server implementiert werden. Dadurch kann es vorkommen, dass ein Web-API-Controller, der in Visual Studio oder auf einem Entwicklungsserver ordnungsgemäß funktioniert, einen HTTP 405-Fehler zurückgibt, wenn er auf einem Produktions-IIS-Server zum Einsatz kommt.

Ursachen für HTTP 405-Fehler

Der erste Schritt zum Erlernen der Problembehandlung von HTTP 405-Fehlern besteht darin, zu verstehen, was ein HTTP 405-Fehler tatsächlich bedeutet. Das primäre Verwaltungsdokument für HTTP ist RFC 2616, das den HTTP 405-Statuscode als "Nicht zulässig" definiert, und beschreibt diesen Statuscode weiter als Situation, in der "die in der Request-Line angegebene Methode für die vom Anforderungs-URI identifizierte Ressource nicht zulässig ist." Mit anderen Worten, das HTTP-Verb ist für die spezifische URL, die ein HTTP-Client angefordert hat, nicht zulässig.

Im Folgenden werden einige der am häufigsten verwendeten HTTP-Methoden beschrieben, die in RFC 2616, RFC 4918 und RFC 5789 definiert sind:

HTTP-Methode Beschreibung
GET Diese Methode wird zum Abrufen von Daten aus einem URI verwendet und ist wahrscheinlich die am häufigsten verwendete HTTP-Methode.
HEAD Diese Methode ähnelt der GET-Methode, mit der Ausnahme, dass sie die Daten nicht tatsächlich aus dem Anforderungs-URI abruft – sie ruft einfach den HTTP-Status ab.
POST Diese Methode wird in der Regel verwendet, um neue Daten an den URI zu senden. POST wird häufig zum Senden von Formulardaten verwendet.
PUT Diese Methode wird in der Regel verwendet, um Rohdaten an den URI zu senden. PUT wird häufig verwendet, um JSON- oder XML-Daten an Web-API-Anwendungen zu übermitteln.
DELETE Diese Methode wird verwendet, um Daten aus einem URI zu entfernen.
OPTIONEN Diese Methode wird in der Regel verwendet, um die Liste der HTTP-Methoden abzurufen, die für einen URI unterstützt werden.
KOPIEREN VERSCHIEBEN Diese beiden Methoden werden mit WebDAV verwendet, und ihr Zweck ist selbsterklärend.
MKCOL Diese Methode wird mit WebDAV verwendet und zum Erstellen einer Sammlung (z. B. eines Verzeichnisses) am angegebenen URI verwendet.
PROPFIND PROPPATCH Diese beiden Methoden werden mit WebDAV verwendet, und sie werden verwendet, um Eigenschaften für einen URI abzufragen oder festzulegen.
SPERREN ENTSCHPERREN Diese beiden Methoden werden mit WebDAV verwendet, und sie werden verwendet, um die durch den Anforderungs-URI beim Erstellen identifizierte Ressource zu sperren/zu entsperren.
Patch Diese Methode wird verwendet, um eine vorhandene HTTP-Ressource zu ändern.

Wenn eine dieser HTTP-Methoden für die Verwendung auf dem Server konfiguriert ist, antwortet der Server mit dem HTTP-Status und anderen Daten, die für die Anforderung geeignet sind. (Eine GET-Methode kann z. B. eine HTTP 200 OK-Antwort empfangen, und eine PUT-Methode empfängt möglicherweise eine HTTP 201 Created Response.)

Wenn die HTTP-Methode nicht für die Verwendung auf dem Server konfiguriert ist, antwortet der Server mit einem HTTP 501 Not Implemented-Fehler .

Wenn jedoch eine HTTP-Methode für die Verwendung auf dem Server konfiguriert ist, aber für einen bestimmten URI deaktiviert wurde, antwortet der Server mit einem HTTP 405-Methode nicht zulässigen Fehler.

HTTP 405-Beispielfehler

Das folgende Beispiel für HTTP-Anforderung und -Antwort veranschaulicht eine Situation, in der ein HTTP-Client versucht, einen PUT-Wert auf eine Web-API-App auf einem Webserver zu setzen, und der Server gibt einen HTTP-Fehler zurück, der besagt, dass die PUT-Methode nicht zulässig ist:

HTTP-Anforderung:

PUT /api/values/1 HTTP/1.1
Content-type: application/json
Host: localhost
Accept: */*
Content-Length: 12

"Some Value"

HTTP-Antwort:

HTTP/1.1 405 Method Not Allowed
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
Date: Wed, 15 May 2013 02:38:57 GMT
Content-Length: 72

{"Message":"The requested resource does not support http method 'PUT'."}

In diesem Beispiel hat der HTTP-Client eine gültige JSON-Anforderung an die URL für eine Web-API-Anwendung auf einem Webserver gesendet, aber der Server hat eine HTTP 405-Fehlermeldung zurückgegeben, die angibt, dass die PUT-Methode für die URL nicht zulässig war. Wenn der Anforderungs-URI dagegen nicht mit einer Route für die Web-API-Anwendung übereinstimmt, gibt der Server einen HTTP 404 Not Found-Fehler zurück.

Beheben von HTTP 405-Fehlern

Es gibt mehrere Gründe, warum ein bestimmtes HTTP-Verb möglicherweise nicht zulässig ist, aber es gibt ein primäres Szenario, das die führende Ursache für diesen Fehler in IIS ist: Mehrere Handler werden für dasselbe Verb/die gleiche Methode definiert, und einer der Handler blockiert den erwarteten Handler für die Verarbeitung der Anforderung. IIS verarbeitet Handler vom ersten bis zum letzten basierend auf den Handler-Einträgen in den Dateien applicationHost.config und web.config, wobei die erste übereinstimmende Kombination aus Pfad, Verb, Ressource usw. verwendet wird, um die Anforderung zu bearbeiten.

Das folgende Beispiel ist ein Auszug aus einer applicationHost.config Datei für einen IIS-Server, der einen HTTP 405-Fehler zurückgegeben hat, wenn die PUT-Methode zum Senden von Daten an eine Webanwendung verwendet wurde. In diesem Auszug werden mehrere HTTP-Handler definiert, und jeder Handler verfügt über einen anderen Satz von HTTP-Methoden, für die er konfiguriert ist . Der letzte Eintrag in der Liste ist der statische Inhaltshandler, der standardhandler ist, der verwendet wird, nachdem die anderen Handler die Anforderung untersucht haben:

<handlers accessPolicy="Read, Script">
   <add name="WebDAV"
      path="*"
      verb="PROPFIND,PROPPATCH,MKCOL,PUT,COPY,DELETE,MOVE,LOCK,UNLOCK"
      modules="WebDAVModule"
      resourceType="Unspecified"
      requireAccess="None" />
   <add name="ISAPI-dll"
      path="*.dll"
      verb="*"
      modules="IsapiModule"
      resourceType="File"
      requireAccess="Execute"
      allowPathInfo="true" />
   <add name="ExtensionlessUrlHandler-ISAPI-4.0_64bit"
      path="*."
      verb="GET,HEAD,POST,DEBUG"
      modules="IsapiModule"
      scriptProcessor="%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll"
      preCondition="classicMode,runtimeVersionv4.0,bitness64"
      responseBufferLimit="0" />

   <!-- Additional handlers will be defined here. -->

   <add name="StaticFile"
      path="*"
      verb="*"
      modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule"
      resourceType="Either"
      requireAccess="Read" />
</handlers>

Im vorherigen Beispiel sind der WebDAV-Handler und der Erweiterungslose URL-Handler für ASP.NET (der für die Web-API verwendet wird) eindeutig für separate Listen von HTTP-Methoden definiert. Beachten Sie, dass der ISAPI-DLL-Handler für alle HTTP-Methoden konfiguriert ist, obwohl diese Konfiguration nicht notwendigerweise einen Fehler verursacht. Konfigurationseinstellungen wie diese müssen jedoch beim Beheben von HTTP 405-Fehlern berücksichtigt werden.

Im vorherigen Beispiel war der ISAPI-DLL-Handler nicht das Problem; Tatsächlich wurde das Problem in der dateiapplicationHost.config für den IIS-Server nicht definiert – das Problem wurde durch einen Eintrag verursacht, der in der web.config Datei vorgenommen wurde, als die Webanwendung in Visual Studio erstellt wurde. Der folgende Auszug aus der web.config Datei der Anwendung zeigt den Speicherort des Problems:

<handlers accessPolicy="Read, Script">
   <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
   <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" />
</handlers>

In diesem Auszug wird der Erweiterungslose URL-Handler für ASP.NET neu definiert, um zusätzliche HTTP-Methoden einzuschließen, die mit der Webanwendung verwendet werden. Da jedoch ein ähnlicher Satz von HTTP-Methoden für den WebDAV-Handler definiert ist, tritt ein Konflikt auf. In diesem speziellen Fall wird der WebDAV-Handler von IIS definiert und geladen, obwohl WebDAV für die Website deaktiviert ist, die die Webanwendung enthält. Während der Verarbeitung einer HTTP PUT-Anforderung ruft IIS das WebDAV-Modul auf, da es für das PUT-Verb definiert ist. Wenn das WebDAV-Modul aufgerufen wird, überprüft es seine Konfiguration und sieht, dass es deaktiviert ist, sodass ein HTTP 405-Methode nicht zulässiger Fehler für jede Anforderung zurückgegeben wird, die einer WebDAV-Anforderung ähnelt. Um dieses Problem zu beheben, sollten Sie WebDAV aus der Liste der HTTP-Module für die Website entfernen, auf der Ihre Web-API-Anwendung definiert ist. Das folgende Beispiel zeigt, wie das aussehen könnte:

<handlers accessPolicy="Read, Script">
   <remove name="WebDAV" />
   <remove name="ExtensionlessUrlHandler-ISAPI-4.0_64bit" />
   <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" />
</handlers>

Dieses Szenario tritt häufig auf, nachdem eine Anwendung von einer Entwicklungsumgebung in einer IIS-Produktionsumgebung veröffentlicht wurde, und dies tritt auf, da sich die Liste der Handler/Module zwischen Ihrer Entwicklungs- und Produktionsumgebung unterscheidet. Wenn Sie beispielsweise Visual Studio 2012 oder höher zum Entwickeln einer Webanwendung verwenden, ist IIS Express der Standardwebserver zum Testen. Dieser Entwicklungswebserver ist eine verkleinerte Version der vollständigen IIS-Funktionalität, die in einem Serverprodukt enthalten ist, und dieser Entwicklungswebserver enthält einige Änderungen, die für Entwicklungsszenarien hinzugefügt wurden. Beispielsweise wird das WebDAV-Modul häufig auf einem Produktionswebserver installiert, auf dem die Vollversion von IIS ausgeführt wird, obwohl es möglicherweise nicht verwendet wird. Die Entwicklungsversion von IIS (IIS Express) installiert das WebDAV-Modul, aber die Einträge für das WebDAV-Modul werden absichtlich auskommentiert, sodass das WebDAV-Modul niemals in IIS Express geladen wird, es sei denn, Sie ändern ihre IIS Express-Konfigurationseinstellungen speziell, um Ihrer IIS Express-Installation WebDAV-Funktionen hinzuzufügen. Daher funktioniert Ihre Webanwendung möglicherweise ordnungsgemäß auf Ihrem Entwicklungscomputer, aber möglicherweise treten HTTP 405-Fehler auf, wenn Sie Ihre Webanwendung auf Ihrem IIS-Produktionswebserver veröffentlichen.

HTTP 501-Fehler

  • Gibt an, dass die spezifische Funktionalität nicht auf dem Server implementiert wurde.
  • Bedeutet in der Regel, dass in Ihren IIS-Einstellungen kein Handler definiert ist, der der HTTP-Anforderung entspricht:
    • Gibt wahrscheinlich an, dass etwas in IIS nicht ordnungsgemäß installiert wurde.
    • Die IIS-Einstellungen wurden geändert, sodass keine Handler definiert sind, die die spezifische HTTP-Methode unterstützen.

Um dieses Problem zu beheben, müssen Sie jede Anwendung neu installieren, die versucht, eine HTTP-Methode zu verwenden, für die keine entsprechenden Modul- oder Handlerdefinitionen vorhanden sind.

Zusammenfassung

HTTP 405-Fehler werden verursacht, wenn eine HTTP-Methode von einem Webserver für eine angeforderte URL nicht zulässig ist. Diese Bedingung wird häufig angezeigt, wenn ein bestimmter Handler für ein bestimmtes Verb definiert wurde und dieser Handler den Handler überschreibt, den Sie für die Verarbeitung der Anforderung erwarten.