Błąd podczas rejestrowania w interfejsach API HTTP

  • Artykuł

W tym artykule opisano możliwości rejestrowania błędów interfejsów programowania aplikacji (API) protokołu HyperText Transfer Protocol (HTTP).

Oryginalna wersja produktu: Windows Server 2008 R2, Windows Server 2008, Windows Server 2012 R2, Windows Server 2012, Windows 10, Windows 8.1
Oryginalny numer KB: 820729

Podsumowanie

Niektóre błędy występujące w aplikacji opartej na protokole HTTP są automatycznie obsługiwane przez interfejs API HTTP, a nie przekazywane z powrotem do aplikacji w celu obsługi. To zachowanie występuje, ponieważ częstotliwość występowania takich błędów może w przeciwnym razie zalać dziennik zdarzeń lub program obsługi aplikacji.

W poniższych tematach opisano różne aspekty rejestrowania błędów interfejsu API HTTP.

Poniższe metody opisują rozwiązywanie rejestrowania błędów interfejsu API HTTP.

Konfigurowanie rejestrowania błędów interfejsu API HTTP

Trzy wartości rejestru w ramach klucza HTTP \Parameters kontrolują rejestrowanie błędów interfejsu API HTTP. Te klucze znajdują się w kluczu rejestru: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters.

Uwaga

Lokalizacja i forma wartości konfiguracji mogą ulec zmianie w późniejszych wersjach systemu operacyjnego Windows.

Musisz mieć poświadczenia administratora/systemu lokalnego, aby zmienić wartości rejestru oraz wyświetlić lub zmienić pliki dziennika i folder, który je zawiera.

Informacje o konfiguracji w wartościach rejestru są odczytywane po uruchomieniu sterownika interfejsu API HTTP. Jeśli więc zmienisz ustawienia, musisz zatrzymać się, a następnie ponownie uruchomić sterownik, aby odczytać nowe wartości. Aby to zrobić, wpisz następujące polecenia konsoli:

net stop http
net start http

Poniższa konwencja nazewnictwa jest używana do nadawania nazw plikom dziennika:
httperr + numer sekwencji + .log
Przykład: httperr4.log

Pliki dziennika są cyklicznie uruchamiane po osiągnięciu maksymalnego rozmiaru określonego przez wartość rejestru ErrorLogFileTruncateSize. Ta wartość nie może być mniejsza niż 1 megabajt (MB).

Jeśli konfiguracja rejestrowania błędów jest nieprawidłowa lub jeśli wystąpi jakikolwiek błąd podczas zapisywania interfejsu API HTTP w plikach dziennika, interfejs API HTTP używa rejestrowania zdarzeń, aby powiadomić administratorów, że rejestrowanie błędów nie występuje.

W poniższej tabeli opisano wartości konfiguracji rejestru.

Wartość rejestru Opis
EnableErrorLogging Dword, który można ustawić na wartość TRUE, aby włączyć rejestrowanie błędów lub wartość FALSE, aby go wyłączyć. Wartość domyślna to TRUE.
ErrorLogFileTruncateSize Identyfikator DWORD określający maksymalny rozmiar pliku dziennika błędów w bajtach. Wartość domyślna to 1 MB (0x100000).

Określona wartość nie może być mniejsza niż wartość domyślna.
ErrorLoggingDir Ciąg określający folder, w którym interfejs API HTTP umieszcza pliki rejestrowania.

Interfejs API HTTP tworzy podfolder HTTPERR w określonym folderze, a następnie przechowuje pliki dziennika w podfoldecie. Ten podfolder i pliki dziennika otrzymują te same ustawienia uprawnień. Konta administratora i systemu lokalnego mają pełny dostęp. Inni użytkownicy nie mają dostępu.

Poniższy przykład jest folderem domyślnym, gdy folder nie jest określony w rejestrze:
%SystemRoot%\System32\LogFiles

Wartość ciągu ErrorLoggingDir musi być w pełni kwalifikowaną ścieżką lokalną. Może jednak zawierać wartość %SystemRoot%. Nie można użyć dysku sieciowego ani udziału sieciowego.

Format dzienników błędów interfejsu API HTTP

Ogólnie rzecz biorąc, pliki dziennika błędów interfejsu API HTTP mają taki sam format jak dzienniki błędów W3C, z tą różnicą, że pliki dziennika błędów interfejsu API HTTP nie zawierają nagłówków kolumn. Każdy wiersz dziennika błędów interfejsu API HTTP rejestruje jeden błąd. Pola są wyświetlane w określonej kolejności. Pojedynczy znak spacji (0x0020) oddziela każde pole od poprzedniego pola. W każdym polu znaki plus (0x002B) zastępują znaki spacji, karty i znaki kontrolki, których nie można drukować.

W poniższej tabeli zidentyfikowano pola i kolejność pól w rekordzie dziennika błędów.

Pole Opis
Data Pole Data jest zgodne z formatem W3C. To pole jest oparte na uniwersalnym czasie koordynowanym (UTC). Pole Date (Data) ma zawsze 10 znaków w postaci RRRR-MM-DD. Na przykład 1 maja 2003 r. jest wyrażona jako 2003-05-01.
Czas Pole Czas jest zgodne z formatem W3C. To pole jest oparte na formacie UTC. Pole czasowe ma zawsze osiem znaków w postaci MM:HH:SS. Na przykład godzina 17:30 (UTC) jest wyrażona jako 17:30:00.
Adres IP (Client Internet Protocol) Adres IP klienta, którego dotyczy problem. Wartość w tym polu może być adresem IPv4 lub adresem IPv6. Jeśli adres IP klienta jest adresem IPv6, pole ScopeId jest również zawarte w adresie.
Port klienta Numer portu dla klienta, którego dotyczy problem.
Adres IP serwera Adres IP serwera, którego dotyczy problem. Wartość w tym polu może być adresem IPv4 lub adresem IPv6. Jeśli adres IP serwera jest adresem IPv6, pole ScopeId jest również zawarte w adresie.
Port serwera Numer portu serwera, którego dotyczy problem.
Wersja protokołu Używana wersja protokołu.

Jeśli połączenie nie zostało wystarczająco przeanalizowane, aby określić wersję protokołu, łącznik (0x002D) jest używany jako symbol zastępczy pustego pola.

Jeśli numer wersji głównej lub numer wersji pomocniczej, który jest analizowany, jest większy lub równy 10, wersja jest rejestrowana jako HTTP/?.?.
Czasownik Czasownik określa ostatnie żądanie, które jest analizowane, przechodzi. Dołączane są nieznane czasowniki, ale wszystkie czasowniki przekraczające 255 bajtów są obcinane do tej długości. Jeśli czasownik nie jest dostępny, łącznik (0x002D) jest używany jako symbol zastępczy pustego pola.
CookedURL + Zapytanie Adres URL i wszystkie skojarzone z nim zapytania są rejestrowane jako jedno pole oddzielone znakiem zapytania (0x3F). To pole jest obcinane z limitem długości wynoszącym 4096 bajtów.

Jeśli ten adres URL został przeanalizowany ("ugotowany"), jest rejestrowany przy użyciu lokalnej konwersji strony kodowej i jest traktowany jako pole Unicode.

Jeśli ten adres URL nie został przeanalizowany ("ugotowany") w czasie rejestrowania, zostanie on skopiowany dokładnie bez żadnej konwersji Unicode.

Jeśli interfejs API HTTP nie może przeanalizować tego adresu URL, łącznik (0x002D) jest używany jako symbol zastępczy pustego pola.
Stan protokołu Stan protokołu nie może być większy niż 999.

Jeśli stan protokołu odpowiedzi na żądanie jest dostępny, jest on zalogowany w tym polu.

Jeśli stan protokołu nie jest dostępny, łącznik (0x002D) jest używany jako symbol zastępczy pustego pola.
Identyfikator witryny Nie jest używany w tej wersji interfejsu API HTTP. W tym polu zawsze pojawia się łącznik zastępczy (0x002D).
Fraza przyczyny To pole zawiera ciąg identyfikujący rodzaj rejestrowanego błędu. To pole nigdy nie pozostaje puste.
Nazwa kolejki Jest to nazwa kolejki żądań.

Następujące przykładowe wiersze pochodzą z dziennika błędów interfejsu API HTTP:

2002-07-05 18:45:09 172.31.77.6 2094 172.31.77.6 80 HTTP/1.1 GET /qos/1kbfile.txt 503 - ConnLimit  
2002-07-05 19:51:59 127.0.0.1 2780 127.0.0.1 80 HTTP/1.1 GET /ThisIsMyUrl.htm 400 - Hostname  
2002-07-05 19:53:00 127.0.0.1 2894 127.0.0.1 80 HTTP/2.0 GET / 505 - Version_N/S  
2002-07-05 20:06:01 172.31.77.6 64388 127.0.0.1 80 - - - - - Timer_MinBytesPerSecond

Rodzaje błędów dzienników interfejsu API HTTP

Interfejs API HTTP rejestruje odpowiedzi na błędy dla klientów, limity czasu połączenia, żądania oddzielone i porzucone połączenia, które są niepoprawnie obsługiwane.

Na poniższej liście zidentyfikowano rodzaje błędów dzienników interfejsu API HTTP:

  • Odpowiedzi na klientów
    Interfejs API HTTP wysyła odpowiedź o błędzie do klienta, na przykład błąd 400, który jest spowodowany błędem analizy w ostatnim odebranym żądaniu. Gdy interfejs API HTTP wyśle odpowiedź o błędzie, zamknie połączenie.

  • Limity czasu połączenia
    Interfejs API HTTP przekracza limit czasu połączenia. Jeśli żądanie jest oczekujące po przekroczeniu limitu czasu połączenia, żądanie jest używane do dostarczania dodatkowych informacji o połączeniu w dzienniku błędów.

  • Oddzielone żądania
    Proces w trybie użytkownika zatrzymuje się nieoczekiwanie, gdy nadal istnieją żądania w kolejce, które są kierowane do tego procesu. Interfejs API HTTP rejestruje oddzielone żądania w dzienniku błędów. Określone typy błędów są nazywane ciągami fraz przyczyny, które zawsze są wyświetlane jako ostatnie pole każdego wiersza błędu. W poniższej tabeli zidentyfikowano frazy przyczyn interfejsu API HTTP.

Fraza przyczyny Opis
AppOffline Wystąpił błąd niedostępności usługi (błąd HTTP 503). Usługa nie jest dostępna, ponieważ błędy aplikacji spowodowały, że aplikacja została przesunięte w tryb offline.
AppPoolTimer Wystąpił błąd niedostępności usługi (błąd HTTP 503). Usługa nie jest dostępna, ponieważ proces puli aplikacji jest zbyt zajęty, aby obsłużyć żądanie.
AppShutdown Wystąpił błąd niedostępności usługi (błąd HTTP 503). Usługa nie jest dostępna, ponieważ aplikacja zostanie automatycznie zamknięta w odpowiedzi na zasady administratora.
BadRequest Wystąpił błąd analizy podczas przetwarzania żądania.
Client_Reset Połączenie między klientem a serwerem zostało zamknięte przed przypisaniem żądania do procesu roboczego. Najczęstszą przyczyną tego zachowania jest to, że klient przedwcześnie zamyka połączenie z serwerem.
Connection_Abandoned_By_AppPool Proces roboczy z puli aplikacji nieoczekiwanie zakończył lub oddzielono oczekujące żądanie, zamykając jego dojście.
Connection_Abandoned_By_ReqQueue Proces roboczy z puli aplikacji nieoczekiwanie zakończył lub oddzielono oczekujące żądanie, zamykając jego dojście. Specyficzne dla systemu Windows Vista i nowszych wersji oraz systemu Windows Server 2008 i nowszych wersji.
Connection_Dropped Połączenie między klientem a serwerem zostało zamknięte, zanim serwer mógł wysłać ostateczny pakiet odpowiedzi. Najczęstszą przyczyną tego zachowania jest to, że klient przedwcześnie zamyka połączenie z serwerem.
Connection_Dropped_List_Full Lista porzuconych połączeń między klientami a serwerem jest pełna. Specyficzne dla systemu Windows Vista i nowszych wersji oraz systemu Windows Server 2008 i nowszych wersji.
ConnLimit Wystąpił błąd niedostępności usługi (błąd HTTP 503). Usługa nie jest dostępna, ponieważ osiągnięto lub przekroczono limit połączenia na poziomie lokacji.
Connections_Refused Pamięć nonPagedPool jądra spadła poniżej 20 MB, a http.sys przestała odbierać nowe połączenia
Wyłączona Wystąpił błąd niedostępności usługi (błąd HTTP 503). Usługa nie jest dostępna, ponieważ administrator przeszedł aplikację w tryb offline.
EntityTooLarge Jednostka przekroczyła dozwolony maksymalny rozmiar.
FieldLength Przekroczono limit długości pola.
Dostęp zabroniony Podczas analizowania został spełniony zabroniony element lub sekwencja.
Nagłówek Wystąpił błąd analizy w nagłówku.
Nazwa hosta Wystąpił błąd analizy podczas przetwarzania nazwy hosta.
Wewnętrzne Wystąpił wewnętrzny błąd serwera (błąd HTTP 500).
Invalid_CR/LF Doszło do nielegalnego powrotu karetki lub kanału informacyjnego.
LengthRequired Brakowało wymaganej wartości długości.
Nie dotyczy Wystąpił błąd niedostępności usługi (błąd HTTP 503). Usługa nie jest dostępna, ponieważ wystąpił błąd wewnętrzny (na przykład błąd alokacji pamięci lub konflikt listy rezerwacji adresu URL).
N/I Wystąpił niezaimplementowany błąd (błąd HTTP 501) lub wystąpił błąd niedostępny usługi (błąd HTTP 503) z powodu nieznanego kodowania transferu.
Numer Wystąpił błąd analizy podczas przetwarzania liczby.
Warunek wstępny Brak wymaganego warunku wstępnego.
QueueFull Wystąpił błąd niedostępności usługi (błąd HTTP 503). Usługa nie jest dostępna, ponieważ kolejka żądań aplikacji jest pełna.
RequestLength Przekroczono limit długości żądania.
Timer_AppPool Połączenie wygasło, ponieważ żądanie czekało zbyt długo w kolejce puli aplikacji, aby aplikacja serwera anulowała kolejkę i przetworzyć je. Ten czas trwania limitu czasu to ConnectionTimeout. Domyślnie ta wartość jest ustawiona na dwie minuty.
Timer_ConnectionIdle Połączenie wygasło i pozostaje bezczynne. Domyślny czas trwania parametru ConnectionTimeout to dwie minuty.
Timer_EntityBody Połączenie wygasło przed nadejściem treści jednostki żądania. Gdy żądanie ma wyraźnie treść jednostki, interfejs API HTTP włącza czasomierz Timer_EntityBody. Na początku limit tego czasomierza jest ustawiony na wartość ConnectionTimeout (zazwyczaj dwie minuty). Za każdym razem, gdy w tym żądaniu jest odbierane inne wskazanie danych, interfejs API HTTP resetuje czasomierz, aby zapewnić połączenie jeszcze dwie minuty (lub cokolwiek określonego w parametrze ConnectionTimeout).
Timer_HeaderWait Połączenie wygasło, ponieważ analizowanie nagłówka żądania trwało więcej czasu niż domyślny limit wynoszący dwie minuty.
Timer_MinBytesPerSecond Połączenie wygasło, ponieważ klient nie otrzymał odpowiedzi z rozsądną szybkością. Szybkość wysyłania odpowiedzi była wolniejsza niż domyślna wartość 240 bajtów na sekundę. Które można kontrolować za pomocą właściwości metabazy MinFileBytesPerSec.
Timer_ReqQueue Połączenie wygasło, ponieważ żądanie czekało zbyt długo w kolejce puli aplikacji, aby aplikacja serwera została wycofana z kolejki. Ten czas trwania limitu czasu to ConnectionTimeout. Domyślnie ta wartość jest ustawiona na dwie minuty. Specyficzne dla systemu Windows Vista i nowszych wersji oraz systemu Windows Server 2008 i nowszych wersji.
Timer_Response Zastrzeżone. Obecnie nie jest używany.
Timer_SslRenegotiation
 Połączenie wygasło, ponieważ renegocjacja protokołu Secure Sockets Layer (SSL) między klientem a serwerem trwała dłużej niż domyślny limit czasu wynoszący dwie minuty.
URL Wystąpił błąd analizy podczas przetwarzania adresu URL.
URL_Length Adres URL przekroczył maksymalny dozwolony rozmiar.
Czasownik Wystąpił błąd analizy podczas przetwarzania zlecenia.
Version_N/S Wystąpił błąd nieobsługiwany przez wersję (błąd HTTP 505).