Rozwiązywanie problemów z aplikacjami Web API2, które działają w programie Visual Studio i nie działają na produkcyjnym serwerze IIS.

W tym dokumencie wyjaśniono, jak rozwiązywać problemy z aplikacjami Web API2 wdrożonymi na produkcyjny serwer IIS. Dotyczy to typowych błędów HTTP 405 i 501.

Oprogramowanie wykorzystywane w tym samouczku

• Internet Information Services (IIS) ( wersja 7 lub nowsza)
• Internetowy interfejs API

Aplikacje internetowego interfejsu API zwykle używają kilku zleceń HTTP: GET, POST, PUT, DELETE, a czasami PATCH. Oznacza to, że deweloperzy mogą napotkać sytuacje, w których te czasowniki są implementowane przez inny moduł IIS na serwerze produkcyjnym, co prowadzi do sytuacji, gdy kontroler Web API, który pracuje poprawnie w programie Visual Studio lub na serwerze deweloperskim, zwróci błąd HTTP 405 po wdrożeniu na serwer produkcyjny IIS.

Co powoduje błędy HTTP 405

Pierwszym krokiem dowiedzieć się, jak rozwiązywać problemy z błędami HTTP 405, jest zrozumienie, co faktycznie oznacza błąd HTTP 405. Podstawowym dokumentem zarządzającym dla protokołu HTTP jest RFC 2616, który definiuje kod stanu HTTP 405 jako Niedozwolony, a następnie opisuje ten kod stanu jako sytuację, w której "metoda określona w Request-Line nie jest dozwolona dla zasobu zidentyfikowanego przez identyfikator URI żądania". Innymi słowy czasownik HTTP nie jest dozwolony dla określonego adresu URL, którego zażądał klient HTTP.

Poniżej przedstawiono kilka najczęściej używanych metod HTTP zdefiniowanych w dokumencie RFC 2616, RFC 4918 i RFC 5789:

Gdy jedna z tych metod HTTP jest skonfigurowana do użycia na serwerze, serwer odpowie stanem HTTP i innymi danymi odpowiednimi dla żądania. (Na przykład metoda GET może otrzymać odpowiedź HTTP 200 OK , a metoda PUT może otrzymać odpowiedź HTTP 201 Utworzona ).

Jeśli metoda HTTP nie jest skonfigurowana do użycia na serwerze, serwer odpowie błędem HTTP 501 Nie zaimplementowano .

Jednak jeśli metoda HTTP jest skonfigurowana do użycia na serwerze, ale została wyłączona dla danego identyfikatora URI, serwer odpowie z błędem HTTP 405 Metoda Niedozwolona.

Przykładowy błąd HTTP 405

Następujące przykładowe żądanie HTTP i odpowiedź ilustrują sytuację, w której klient HTTP próbuje umieścić wartość w aplikacji internetowego interfejsu API na serwerze internetowym, a serwer zwraca błąd HTTP, który wskazuje, że metoda PUT jest niedozwolona:

Żądanie HTTP:

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

"Some Value"

Odpowiedź HTTP:

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'."}

W tym przykładzie klient HTTP wysłał prawidłowe żądanie JSON do adresu URL aplikacji internetowego interfejsu API na serwerze internetowym, ale serwer zwrócił komunikat o błędzie HTTP 405, który wskazuje, że metoda PUT nie była dozwolona dla adresu URL. Z kolei, jeśli identyfikator URI żądania nie odpowiada ścieżce dla aplikacji internetowego interfejsu API, serwer zwróci błąd HTTP 404 Nie znaleziono.

Usuwanie błędów HTTP 405

Istnieje kilka powodów, dla których określone zlecenie HTTP może nie być dozwolone, ale istnieje jeden podstawowy scenariusz, który jest główną przyczyną tego błędu w usługach IIS: wiele procedur obsługi jest zdefiniowanych dla tego samego zlecenia/metody, a jeden z procedur obsługi blokuje oczekiwaną procedurę obsługi podczas przetwarzania żądania. Zgodnie z wyjaśnieniem, usługi IIS przetwarzają programy obsługi od pierwszego do ostatniego na podstawie kolejności wpisów w plikach applicationHost.config i web.config, gdzie pierwsze pasujące połączenie ścieżki, czasownika, zasobu itp. zostanie użyte do obsługi żądania.

Poniższy przykład to fragment pliku applicationHost.config dla serwera usług IIS, który zwracał błąd HTTP 405 podczas używania metody PUT do przesyłania danych do aplikacji internetowego interfejsu API. W tym fragmancie zdefiniowano kilka procedur obsługi HTTP, a każdy program obsługi ma inny zestaw metod HTTP, dla których jest skonfigurowany — ostatni wpis na liście to statyczna procedura obsługi zawartości, która jest domyślną procedurą obsługi, która jest używana po tym, jak inne programy obsługi miały szansę zbadać żądanie:

<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>

W poprzednim przykładzie program obsługi WebDAV i program obsługi adresów URL bez rozszerzenia dla ASP.NET (który jest używany dla internetowego interfejsu API) są jasno zdefiniowane dla oddzielnych list metod HTTP. Należy pamiętać, że program obsługi bibliotek DLL ISAPI jest skonfigurowany dla wszystkich metod HTTP, chociaż ta konfiguracja nie musi powodować błędu. Jednak ustawienia konfiguracji takie jak te należy wziąć pod uwagę podczas rozwiązywania problemów z błędami HTTP 405.

W poprzednim przykładzie biblioteka DLL ISAPI nie była problemem; w rzeczywistości problem nie został zdefiniowany w pliku applicationHost.config serwera IIS — problem został spowodowany wpisem, który został utworzony w pliku web.config podczas tworzenia aplikacji Web API w programie Visual Studio. Poniższy fragment pliku web.config aplikacji pokazuje lokalizację problemu:

<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>

W tym fragcie program obsługi adresów URL bez rozszerzenia dla ASP.NET jest ponownie definiowany w celu uwzględnienia dodatkowych metod HTTP, które będą używane z aplikacją internetowego interfejsu API. Jednak ze względu na to, że podobny zestaw metod HTTP jest definiowany dla programu obsługi WebDAV, występuje konflikt. W tym konkretnym przypadku program obsługi WebDAV jest definiowany i ładowany przez usługi IIS, mimo że funkcja WebDAV jest wyłączona dla witryny internetowej zawierającej aplikację internetowego interfejsu API. Podczas przetwarzania żądania HTTP PUT, usługa IIS wywołuje moduł WebDAV, ponieważ jest on przypisany do operacji PUT. Po wywołaniu modułu WebDAV sprawdza konfigurację i widzi, że jest on wyłączony, dlatego zwróci błąd HTTP 405 Method Not Allowed (Niedozwolona metoda HTTP 405) dla każdego żądania przypominającego żądanie WebDAV. Aby rozwiązać ten problem, należy usunąć WebDAV z listy modułów HTTP dla witryny, w której zdefiniowano aplikację Web API. W poniższym przykładzie pokazano, jak może to wyglądać:

<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>

Ten scenariusz jest często spotykany po opublikowaniu aplikacji ze środowiska deweloperskiego do środowiska produkcyjnego usług IIS. Dzieje się tak, ponieważ lista programów obsługi/modułów różni się między środowiskami deweloperskimi i produkcyjnymi. Jeśli na przykład używasz programu Visual Studio 2012 lub nowszego do tworzenia aplikacji internetowego interfejsu API, usługa IIS Express jest domyślnym serwerem internetowym do testowania. Ten programowy serwer sieci Web to skalowana w dół wersja pełnej funkcjonalności usług IIS, która jest dostarczana w produkcie serwera, a ten programowy serwer sieci Web zawiera kilka zmian, które zostały dodane do scenariuszy programowania. Na przykład moduł WebDAV jest często instalowany na produkcyjnym serwerze internetowym z pełną wersją usług IIS, chociaż może nie być używany. Wersja programowa usług IIS (IIS Express) instaluje moduł WebDAV, ale wpisy modułu WebDAV są celowo komentowane, więc moduł WebDAV nigdy nie jest ładowany w usługach IIS Express, chyba że specjalnie zmienisz ustawienia konfiguracji usług IIS Express w celu dodania funkcji WebDAV do instalacji usług IIS Express. W związku z tym aplikacja internetowa może działać poprawnie na komputerze deweloperskim, ale mogą wystąpić błędy HTTP 405, gdy opublikujesz aplikację Web API na produkcyjnym serwerze IIS.

błędy HTTP 501

• Wskazuje, że określona funkcjonalność nie została zaimplementowana na serwerze.
• Zazwyczaj oznacza, że w ustawieniach usług IIS nie zdefiniowano procedury obsługi zgodnej z żądaniem HTTP:
  • Prawdopodobnie wskazuje, że coś nie zostało poprawnie zainstalowane w usługach IIS lub
  • Coś zmodyfikowało ustawienia usług IIS, aby nie zdefiniowano procedur obsługi obsługujących określoną metodę HTTP.

Aby rozwiązać ten problem, należy ponownie zainstalować dowolną aplikację, która próbuje użyć metody HTTP, dla której nie ma odpowiednich definicji modułu ani programu obsługi.

Podsumowanie

Błędy HTTP 405 są powodowane, gdy metoda HTTP nie jest dozwolona przez serwer internetowy dla żądanego adresu URL. Ten warunek jest często spotykany, gdy określony program obsługi został zdefiniowany dla określonego zlecenia, a program obsługi zastępuje procedurę obsługi, której oczekujesz przetworzenia żądania.