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

  • Artikel

In dieser Dokumentation wird erläutert, wie Sie Web-API2-Apps behandeln, die auf einem IIS-Produktionsserver bereitgestellt werden. Es behandelt häufige HTTP 405- und 501-Fehler.

In diesem Tutorial verwendete Software

Web-API-Apps verwenden in der Regel mehrere HTTP-Verben: GET, POST, PUT, DELETE und manchmal PATCH. Allerdings treten Entwickler möglicherweise in Situationen auf, in denen diese Verben von einem anderen IIS-Modul auf ihrem IIS-Produktionsserver implementiert werden, was zu einer Situation führt, in der ein Web-API-Controller, der ordnungsgemäß in Visual Studio oder auf einem Entwicklungsserver funktioniert, einen HTTP 405-Fehler zurückgibt, wenn er auf einem IIS-Produktionsserver bereitgestellt wird.

Was verursacht 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 gültige Dokument für HTTP ist RFC 2616, das den HTTP 405-status-Code als Method Not Allowed definiert und dies status Code als Situation beschreibt, in der "die im Request-Line angegebene Methode für die vom Anforderungs-URI identifizierte Ressource nicht zulässig ist". Anders ausgedrückt: Das HTTP-Verb ist für die spezifische URL, die ein HTTP-Client angefordert hat, nicht zulässig.

Hier sind einige der am häufigsten verwendeten HTTP-Methoden wie in RFC 2616, RFC 4918 und RFC 5789 definiert:

HTTP-Methode BESCHREIBUNG
GET Diese Methode wird verwendet, um Daten aus einem URI abzurufen, und sie ist wahrscheinlich die am häufigsten verwendete HTTP-Methode.
HEAD Diese Methode ähnelt der GET-Methode, mit dem Unterschied, 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 Übermitteln 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 Webanwendungen zu übermitteln.
DELETE Diese Methode wird verwendet, um Daten aus einem URI zu entfernen.
OPTIONS Diese Methode wird in der Regel verwendet, um die Liste der HTTP-Methoden abzurufen, die für einen URI unterstützt werden.
VERSCHIEBEN KOPIEREN Diese beiden Methoden werden mit WebDAV verwendet, und ihr Zweck ist selbsterklärend.
MKCOL Diese Methode wird mit WebDAV verwendet und wird verwendet, um eine Sammlung (z. B. ein Verzeichnis) am angegebenen URI zu erstellen.
PROPFIND PROPPATCH Diese beiden Methoden werden mit WebDAV verwendet und zum Abfragen oder Festlegen von Eigenschaften für einen URI verwendet.
ENTSPERREN Diese beiden Methoden werden mit WebDAV verwendet, und sie werden verwendet, um die Ressource zu sperren/entsperren, die beim Erstellen durch den Anforderungs-URI identifiziert wurde.
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. (Beispielsweise kann eine GET-Methode eine HTTP 200 OK-Antwort empfangen, und eine PUT-Methode kann eine HTTP 201 Created-Antwort empfangen.)

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 dem Fehler HTTP 405 Method Not Allowed .

HTTP 405-Beispielfehler

Das folgende Beispiel für HTTP-Anforderung und -Antwort veranschaulicht eine Situation, in der ein HTTP-Client versucht, einen PUT-Wert für eine Web-API-App auf einem Webserver zu verwenden, und der Server einen HTTP-Fehler zurückgibt, 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 hingegen 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 Hauptursache für diesen Fehler in IIS ist: Mehrere Handler werden für dasselbe Verb/dieselbe Methode definiert, und einer der Handler blockiert die Verarbeitung der Anforderung durch den erwarteten Handler. Als Erklärung verarbeitet IIS Handler von der ersten bis zur letzten, basierend auf den Bestellhandlereinträgen in den applicationHost.config - und web.config-Dateien , wobei die erste übereinstimmende Kombination aus Pfad, Verb, Ressource usw. für die Verarbeitung der Anforderung verwendet wird.

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 Übermitteln von Daten an eine Web-API-Anwendung 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 der Standardhandler ist, der verwendet wird, nachdem die anderen Handler gelegenheit hatten, die Anforderung zu untersuchen:

<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) für separate Listen von HTTP-Methoden klar definiert. Beachten Sie, dass der ISAPI-DLL-Handler für alle HTTP-Methoden konfiguriert ist, obwohl diese Konfiguration nicht unbedingt einen Fehler verursacht. Konfigurationseinstellungen wie diese müssen jedoch bei der Problembehandlung von HTTP 405-Fehlern berücksichtigt werden.

Im vorherigen Beispiel war der ISAPI-DLL-Handler nicht das Problem. Tatsächlich wurde das Problem nicht in der applicationHost.config-Datei für den IIS-Server definiert. Das Problem wurde durch einen Eintrag in der web.config-Datei verursacht, als die Web-API-Anwendung 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 Web-API-Anwendung 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 Web-API-Anwendung 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 stellt fest, dass es deaktiviert ist. Daher gibt es für jede Anforderung, die einer WebDAV-Anforderung ähnelt, den Fehler HTTP 405 Method Not Allowed zurück. 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 dies 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 aus einer Entwicklungsumgebung in einer IIS-Produktionsumgebung veröffentlicht wurde. Dies tritt auf, weil sich die Liste der Handler/Module zwischen Ihren Entwicklungs- und Produktionsumgebungen unterscheidet. Wenn Sie beispielsweise Visual Studio 2012 oder höher verwenden, um eine Web-API-Anwendung zu entwickeln, ist IIS Express der Standardwebserver für Tests. Dieser Entwicklungswebserver ist eine herunterskalierte 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 nie auf IIS Express geladen wird, es sei denn, Sie ändern Ihre IIS Express Konfigurationseinstellungen speziell, um Ihrer IIS Express Installation WebDAV-Funktionalität hinzuzufügen. Daher funktioniert Ihre Webanwendung möglicherweise ordnungsgemäß auf Ihrem Entwicklungscomputer, aber es können HTTP 405-Fehler auftreten, wenn Sie Ihre Web-API-Anwendung auf Ihrem IIS-Produktionswebserver veröffentlichen.

HTTP 501-Fehler

  • Gibt an, dass die spezifische Funktionalität nicht auf dem Server implementiert wurde.
  • In der Regel bedeutet, dass in Ihren IIS-Einstellungen kein Handler definiert ist, der der HTTP-Anforderung entspricht:
    • Gibt wahrscheinlich an, dass etwas nicht ordnungsgemäß in IIS oder installiert wurde.
    • Ihre 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 zugelassen wird. Diese Bedingung tritt häufig auf, 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.