Błąd podczas rejestrowania w interfejsach API HTTP
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.
Konfigurowanie rejestrowania błędów interfejsu API HTTP
Ustawienia rejestru kontrolują błędy dzienników interfejsu API HTTP, maksymalny dozwolony rozmiar plików dziennika i lokalizację plików dziennika.Format dzienników błędów interfejsu API HTTP
Interfejs API HTTP tworzy pliki dziennika zgodne z konwencjami plików dziennika world wide web consortium (W3C). Do analizowania tych plików dziennika można użyć standardowych narzędzi. Jednak w przeciwieństwie do plików dziennika W3C pliki dziennika interfejsu API HTTP nie zawierają nazw kolumn.Rodzaje błędów dzienników interfejsu API HTTP
Interfejs API HTTP rejestruje wiele typowych błędów.
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). |
Opinia
https://aka.ms/ContentUserFeedback.
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź:Prześlij i wyświetl opinię dla