Narzędzia online
Kody statusu HTTP Kod stanu Znaczenie
100 Klient powinien kontynuować wysyłanie żądań. Ta tymczasowa odpowiedź służy do poinformowania klienta, że część jego żądania została odebrana przez serwer i nie została odrzucona. Klient powinien kontynuować wysyłanie pozostałej części żądania lub zignorować tę odpowiedź, jeśli żądanie jest kompletne. Serwer musi wysłać ostateczną odpowiedź do klienta, gdy żądanie jest kompletne.
101 Serwer zrozumiał żądanie klienta i powiadomi klienta za pośrednictwem nagłówka Upgrade, że do ukończenia żądania użyto innego protokołu. Po wysłaniu ostatniej pustej linii odpowiedzi serwer przełączy się na protokoły zdefiniowane w nagłówku Upgrade. Należy to zrobić tylko wtedy, gdy przejście na nowy protokół jest bardziej korzystne. Na przykład, przejście na nową wersję protokołu HTTP może być bardziej korzystne niż starsza wersja lub przejście na synchroniczny protokół czasu rzeczywistego w celu dostarczenia zasobów, które wykorzystują takie funkcje.
102 Kody statusu, rozszerzone przez WebDAV (RFC 2518), wskazują, że przetwarzanie będzie kontynuowane.
200 Żądanie powiodło się, a nagłówki odpowiedzi lub dane wymagane przez żądanie zostaną zwrócone wraz z odpowiedzią.
201 Żądanie zostało spełnione i nowy zasób został utworzony w odpowiedzi na żądanie, a jego URI został zwrócony z nagłówkiem Location. Jeśli żądany zasób nie może zostać utworzony na czas, powinien zostać zwrócony następujący komunikat'202 Accepted'。
202 Serwer zaakceptował żądanie, ale jeszcze go nie przetworzył. Podobnie jak może zostać odrzucone, żądanie może zostać ostatecznie wykonane lub nie. W przypadku operacji asynchronicznych nie ma nic wygodniejszego niż wysłanie tego kodu statusu. Celem zwracania odpowiedzi 202 jest umożliwienie serwerowi akceptowania żądań z innych procesów (takich jak operacja wsadowa, która jest wykonywana tylko raz dziennie) bez konieczności utrzymywania przez klienta połączenia z serwerem do czasu zakończenia operacji wsadowej. Odpowiedź, która akceptuje żądanie przetwarzania i zwraca kod stanu 202, powinna zawierać w zwróconej encji pewne informacje wskazujące na bieżący stan procesu, a także wskaźnik do monitora stanu przetwarzania lub przewidywania stanu, aby użytkownik mógł oszacować, czy operacja została zakończona.
203 Serwer pomyślnie przetworzył żądanie, ale zwrócone metainformacje nagłówka encji nie są ostatecznym zestawem obowiązującym na oryginalnym serwerze, ale kopią od strony lokalnej lub trzeciej. Bieżące informacje mogą być podzbiorem lub nadzbiorem oryginału. Na przykład metadane zawierające zasoby mogą spowodować, że serwer pochodzenia będzie znał super meta-informacje. Użycie tego kodu stanu nie jest wymagane i jest właściwe tylko wtedy, gdy odpowiedź zwróciłaby 200 OK bez niego.
204 Serwer pomyślnie przetworzył żądanie, ale nie musi zwracać żadnej fizycznej zawartości i chce zwrócić zaktualizowane metainformacje. Odpowiedź może zwrócić nowe lub zaktualizowane metainformacje w postaci nagłówków encji. Jeśli nagłówki te istnieją, powinny odpowiadać żądanym zmiennym. Jeśli klient jest przeglądarką, przeglądarka użytkownika POWINNA zachować stronę, na której wysłano żądanie, bez żadnych zmian w widoku dokumentu, nawet jeśli nowe lub zaktualizowane metainformacje POWINNY, zgodnie ze specyfikacją, zostać zastosowane do dokumentu w aktywnym widoku przeglądarki użytkownika. Ponieważ odpowiedź 204 nie może zawierać żadnej treści wiadomości, zawsze kończy się pierwszą pustą linią po nagłówku wiadomości.
205 Serwer pomyślnie obsługuje żądanie i nic nie zwraca. Jednak w przeciwieństwie do odpowiedzi 204, odpowiedź, która zwraca ten kod stanu, prosi żądającego o zresetowanie widoku dokumentu. Ta odpowiedź jest używana głównie do resetowania formularza natychmiast po zaakceptowaniu danych wejściowych użytkownika, aby użytkownik mógł łatwo rozpocząć kolejne wprowadzanie danych. Podobnie jak odpowiedź 204, ta odpowiedź nie może zawierać żadnej treści wiadomości i kończy się pierwszą pustą linią po nagłówku wiadomości.
206 Serwer pomyślnie przetworzył część żądania GET. Narzędzia do pobierania HTTP, takie jak FlashGet lub Thunderbolt, używają tego typu odpowiedzi do przerywanego pobierania lub do dzielenia dużego pliku na wiele plików do pobrania w tym samym czasie. Żądanie musi zawierać nagłówek Range, aby wskazać zakres treści, które klient chce otrzymać, i może zawierać If-Range jako warunek żądania. Odpowiedź musi zawierać następujące pola nagłówka: Content-Range, aby wskazać zakres zawartości zwróconej w tej odpowiedzi lub, w przypadku pobierania wieloczęściowego z typem zawartości multipart/byteranges, pole Content-Range w każdym segmencie wieloczęściowym, aby wskazać zakres zawartości w tym segmencie. Jeśli odpowiedź zawiera Content-Length, jego wartość musi być zgodna z rzeczywistą liczbą bajtów w zakresie zwracanej zawartości. Expires, Cache-Control i/lub Vary, jeśli ich wartości mogą różnić się od wartości innych poprzednich odpowiedzi z tymi samymi zmiennymi. Ta odpowiedź nie powinna zawierać innych nagłówków encji, jeśli żądanie używa silnej walidacji pamięci podręcznej If-Range i nie powinna zawierać innych nagłówków encji, jeśli żądanie używa słabej walidacji pamięci podręcznej If-Range; pozwala to uniknąć niespójności między zawartością buforowanej encji a zaktualizowanymi informacjami nagłówka encji. W przeciwnym razie ta odpowiedź POWINNA zawierać wszystkie pola nagłówka encji, które powinny zostać zwrócone w odpowiedzi 200. Jeśli nagłówki ETag lub Last-Modified nie są dokładnie zgodne, pamięć podręczna po stronie klienta nie powinna zezwalać na łączenie zawartości zwróconej w odpowiedzi 206 z jakąkolwiek wcześniej buforowaną zawartością. Każda pamięć podręczna, która nie obsługuje nagłówków Range i Content-Range, nie może buforować zawartości zwróconej przez odpowiedź 206.
207 Kody stanu rozszerzone przez WebDAV(RFC 2518) Kod statusu, rozszerzony przez WebDAV, oznacza, że kolejna treść komunikatu będzie komunikatem XML i może zawierać serię oddzielnych kodów odpowiedzi, w zależności od liczby poprzednich żądań podrzędnych.
300 Żądany zasób ma szereg alternatywnych odpowiedzi, z których każda ma swój własny adres i informacje negocjacyjne zależne od przeglądarki. Wybór preferowanego adresu przekierowania należy do użytkownika lub przeglądarki. O ile nie jest to żądanie HEAD, odpowiedź powinna zawierać encję, która jest listą cech zasobów i adresów, z których użytkownik lub przeglądarka może wybrać najbardziej odpowiedni adres przekierowania. Format tej jednostki jest określony przez format definicji Content-Type. Przeglądarka może automatycznie dokonać najbardziej odpowiedniego wyboru na podstawie formatu odpowiedzi i własnych możliwości przeglądarki. Oczywiście specyfikacja RFC 2616 nie określa, w jaki sposób należy dokonać tego automatycznego wyboru. Jeśli sam serwer ma już preferowaną opcję zwrotu, URI zwrotu powinien być określony w Location; przeglądarki mogą używać tej wartości Location jako adresu do automatycznego przekierowania. Ponadto odpowiedź można buforować, chyba że określono inaczej.
301 Żądany zasób został trwale przeniesiony do nowej lokalizacji, a wszelkie przyszłe odniesienia do niego powinny używać jednego z kilku identyfikatorów URI zwróconych w tej odpowiedzi. Jeśli to możliwe, klienci z możliwością edycji linków powinni automatycznie zmienić żądany adres na ten zwrócony przez serwer. Ta odpowiedź jest również buforowana, chyba że określono inaczej. Nowy stały URI powinien zostać zwrócony w polu Location odpowiedzi. O ile nie jest to żądanie HEAD, encja odpowiedzi powinna zawierać hiperłącze do nowego URI i krótki opis. Jeśli nie jest to żądanie GET lub HEAD, przeglądarka nie może automatycznie przekierowywać, chyba że zostanie to potwierdzone przez użytkownika, ponieważ w rezultacie warunki żądania mogą ulec zmianie. Uwaga: W przypadku niektórych przeglądarek korzystających z protokołu HTTP/1.0, po wysłaniu żądania POST i otrzymaniu odpowiedzi 301, następnym żądaniem przekierowania będzie GET.
302 Żądany zasób tymczasowo odpowiada na żądanie z innego identyfikatora URI. Ponieważ to przekierowanie jest tymczasowe, klient powinien nadal wysyłać przyszłe żądania na oryginalny adres. Odpowiedź jest buforowana tylko wtedy, gdy określono ją w Cache-Control lub Expires. Nowy tymczasowy URI powinien zostać zwrócony w polu Location odpowiedzi. O ile nie jest to żądanie HEAD, encja odpowiedzi powinna zawierać hiperłącze do nowego URI i krótki opis. Jeśli nie jest to żądanie GET lub HEAD, przeglądarka nie może automatycznie przekierowywać, chyba że zostanie to potwierdzone przez użytkownika, ponieważ w rezultacie warunki żądania mogą ulec zmianie. Uwaga: Chociaż specyfikacje RFC 1945 i RFC 2068 nie pozwalają klientowi na zmianę metody żądania podczas przekierowania, wiele istniejących przeglądarek traktuje odpowiedź 302 jako odpowiedź 303 i używa GET, aby uzyskać dostęp do URI określonego w lokalizacji, ignorując metodę pierwotnego żądania. Kody statusu 303 i 307 zostały dodane w celu wyjaśnienia, jakiej odpowiedzi serwer oczekuje od klienta.
303 Odpowiedź na bieżące żądanie można znaleźć w innym URI, a klient powinien uzyskać dostęp do tego zasobu za pomocą GET. Ta metoda istnieje głównie po to, aby umożliwić przekierowanie danych wyjściowych żądania POST aktywowanego skryptem do nowego zasobu. Ten nowy URI nie jest zastępczym odniesieniem do oryginalnego zasobu. Ponadto odpowiedź 303 nie może być buforowana. Oczywiście drugie żądanie (przekierowanie) może być buforowane. Nowy URI powinien zostać zwrócony w polu Location odpowiedzi. O ile nie jest to żądanie HEAD, jednostka odpowiedzi powinna zawierać hiperłącze do nowego URI i krótki opis. Uwaga: Wiele przeglądarek przed HTTP/1.1 nie rozumie poprawnie stanu 303. Jeśli należy rozważyć interakcję z tymi przeglądarkami, kod stanu 302 powinien działać, ponieważ większość przeglądarek obsługuje odpowiedź 302 dokładnie w taki sposób, w jaki powyższa specyfikacja wymaga od klienta obsługi odpowiedzi 303.
304 Ten kod stanu powinien zostać zwrócony przez serwer, jeśli klient wysyła warunkowe żądanie GET i żądanie jest dozwolone, a zawartość dokumentu nie uległa zmianie (ani od ostatniej wizyty, ani zgodnie z warunkami żądania). 304 odpowiedzi nie mogą zawierać treści wiadomości, dlatego zawsze kończą się pierwszą pustą linią po nagłówku wiadomości. Odpowiedź musi zawierać następujące informacje nagłówka: Data, chyba że serwer nie ma zegara. Jeśli serwer nie ma zegara, zgodnie z tymi zasadami, serwer proxy i klient mogą samodzielnie dodać pole Date do nagłówka odpowiedzi przychodzącej (zgodnie z RFC 2068), a mechanizm buforowania będzie działał poprawnie.ETag i/lub Content-Location, jeśli to samo żądanie powinno zwrócić odpowiedź 200. Expires, Cache-Control i/lub Vary, jeśli ich wartości mogą różnić się od wartości innych poprzednich odpowiedzi z tymi samymi zmiennymi. Jeśli żądanie odpowiedzi wykorzystuje silną walidację pamięci podręcznej, odpowiedź nie powinna zawierać dodatkowych nagłówków encji; w przeciwnym razie (np. warunkowe żądanie GET wykorzystuje słabą walidację pamięci podręcznej), odpowiedź nie może zawierać dodatkowych nagłówków encji; pozwala to uniknąć niespójności między buforowaną zawartością encji a zaktualizowanymi informacjami nagłówka encji. Jeśli odpowiedź 304 wskazuje, że jednostka nie jest obecnie buforowana, system buforowania musi zignorować odpowiedź i powtórzyć żądanie bez ograniczenia. W przypadku otrzymania odpowiedzi 304 z żądaniem aktualizacji wpisu w pamięci podręcznej, system buforowania MUSI zaktualizować cały wpis, aby odzwierciedlić wartości wszystkich pól zaktualizowanych w odpowiedzi.
305 Żądany zasób musi być dostępny za pośrednictwem określonego serwera proxy. Pole Lokalizacja będzie zawierać informacje o identyfikatorze URI określonego serwera proxy, a odbiorca będzie musiał wielokrotnie wysyłać osobne żądanie, aby uzyskać dostęp do zasobu za pośrednictwem tego serwera proxy. Tylko oryginalny serwer może utworzyć odpowiedź 305. Uwaga: Z RFC 2068 nie wynika jasno, że odpowiedź 305 jest przeznaczona do przekierowania pojedynczego żądania i może być utworzona tylko przez serwer źródłowy. Ignorowanie tych ograniczeń może prowadzić do poważnych konsekwencji w zakresie bezpieczeństwa.
306 W najnowszej wersji specyfikacji kod statusu 306 nie jest już używany.
307 Żądane zasoby odpowiadają teraz tymczasowo na żądania z różnych URI. Ponieważ to przekierowanie jest tymczasowe, klienci powinni nadal wysyłać przyszłe żądania na oryginalny adres. Ta odpowiedź może być buforowana tylko wtedy, gdy jest określona w Cache-Control lub Expires. Nowy tymczasowy URI powinien zostać zwrócony w polu Location odpowiedzi. O ile nie jest to żądanie HEAD, jednostka odpowiedzi powinna zawierać hiperłącze do nowego URI i krótki opis. Ponieważ niektóre przeglądarki nie rozpoznają odpowiedzi 307, konieczne jest dodanie powyższych informacji, aby użytkownik mógł zrozumieć i zażądać dostępu do nowego URI. Jeśli nie jest to żądanie GET lub HEAD, przeglądarka zabrania automatycznego przekierowania, chyba że zostanie to potwierdzone przez użytkownika, ponieważ warunki żądania mogą ulec zmianie.
400 1, błąd semantyczny, bieżące żądanie nie może zostać zrozumiane przez serwer. O ile nie zostanie zmodyfikowane, klient nie powinien powtarzać żądania. 2, parametry żądania są nieprawidłowe.
401 Bieżące żądanie wymaga uwierzytelnienia użytkownika. Odpowiedź musi zawierać nagłówek WWW-Authenticate dla żądanego zasobu, aby poprosić o informacje o użytkowniku. Klient może ponownie przesłać żądanie z odpowiednimi informacjami nagłówka Authorization. Jeśli bieżące żądanie zawiera już poświadczenia autoryzacji, odpowiedź 401 oznacza, że serwer weryfikuje, czy te poświadczenia zostały odrzucone. Jeśli odpowiedź 401 zawiera to samo zapytanie uwierzytelniające, co poprzednia odpowiedź, a przeglądarka podjęła już co najmniej jedną próbę uwierzytelnienia, przeglądarka powinna pokazać użytkownikowi informacje o podmiocie zawarte w odpowiedzi, ponieważ te informacje o podmiocie mogą zawierać odpowiednie informacje diagnostyczne. Patrz RFC 2617.
402 Ten kod stanu jest zarezerwowany dla możliwych przyszłych wymagań.
403 Serwer zrozumiał żądanie, ale odmawia jego wykonania. W przeciwieństwie do odpowiedzi 401, uwierzytelnianie nie zapewnia żadnej pomocy, a żądanie nie powinno być ponownie przesyłane. Jeśli nie jest to żądanie HEAD, a serwer chce być w stanie powiedzieć, dlaczego żądanie nie może zostać wykonane, wówczas powód odmowy powinien zostać opisany w encji. Oczywiście serwer może również zwrócić odpowiedź 404, jeśli nie chce, aby klient otrzymał jakiekolwiek informacje.
404 Żądanie nie powiodło się, żądany zasób nie został znaleziony na serwerze. Nie ma informacji, aby powiedzieć użytkownikowi, czy sytuacja jest tymczasowa czy stała. Jeśli serwer jest świadomy sytuacji, powinien użyć kodu stanu 410, aby poinformować serwer, że stary zasób jest trwale niedostępny z powodu jakiegoś wewnętrznego mechanizmu konfiguracji i że nie ma dostępnego przekierowania. 404 jest powszechnie używany, gdy serwer nie chce ujawniać, dlaczego żądanie zostało odrzucone lub gdy nie ma innej odpowiedniej odpowiedzi.
405 Metoda żądania określona w wierszu żądania nie może być użyta do zażądania odpowiedniego zasobu. Odpowiedź musi zwrócić nagłówek Allow wskazujący listę metod żądania, które są akceptowalne dla bieżącego zasobu. Ponieważ metody PUT i DELETE zapisują do zasobów na serwerze, większość serwerów internetowych nie obsługuje lub nie zezwala na nie domyślnie i zwróci błąd 405 dla takich żądań.
406 Charakterystyka zawartości żądanego zasobu nie spełnia warunków w nagłówku żądania i nie można wygenerować encji odpowiedzi. O ile nie jest to żądanie HEAD, odpowiedź powinna zwrócić encję, która zawiera najbardziej odpowiednią charakterystykę encji i listę adresów, z których użytkownik lub przeglądarka może wybrać. Format encji jest określany przez typ nośnika zdefiniowany w nagłówku Content-Type. Przeglądarka może dokonać najlepszego wyboru w oparciu o format i własne możliwości. Specyfikacja nie definiuje jednak żadnych kryteriów dokonywania takich automatycznych wyborów.
407 Podobne do odpowiedzi 401, z wyjątkiem tego, że klient musi uwierzytelnić się na serwerze proxy. Serwer proxy MUSI zwrócić Proxy-Authenticate w celu sprawdzenia tożsamości. Klient może zwrócić nagłówek Proxy-Authorisation w celu uwierzytelnienia. Patrz RFC 2617.
408 Limit czasu żądania. Klient nie ukończył żądania w czasie, na który serwer był przygotowany. Klient może ponownie przesłać żądanie w dowolnym momencie bez wprowadzania żadnych zmian.
409 Żądanie nie mogło zostać ukończone z powodu konfliktu z bieżącym stanem żądanego zasobu. Ten kod może być użyty tylko wtedy, gdy użytkownik jest w stanie rozwiązać konflikt i ponownie przesłać nowe żądanie. Odpowiedź powinna zawierać wystarczającą ilość informacji, aby użytkownik mógł odkryć źródło konfliktu. Konflikty często występują podczas przetwarzania żądań PUT. Na przykład w środowisku sprawdzania wersji, PUT przesłany w celu zmodyfikowania określonego zasobu z informacjami o wersji, które są sprzeczne z poprzednim żądaniem (strony trzeciej), powinien zwrócić błąd 409 informujący użytkownika, że żądanie nie mogło zostać zakończone. W takim przypadku jednostka odpowiedzi prawdopodobnie będzie zawierać porównanie różnic między dwiema sprzecznymi wersjami, aby użytkownik mógł ponownie przesłać nową, scaloną wersję.
410 Żądany zasób nie jest już dostępny na serwerze i nie jest znany adres przekierowania. Taką sytuację należy uznać za trwałą. Jeśli to możliwe, klienci z możliwością edycji linków powinni usunąć wszystkie odniesienia do tego adresu za zgodą użytkownika. Jeśli serwer nie wie lub nie może określić, czy stan jest trwały, należy użyć kodu stanu 404. O ile nie określono inaczej, odpowiedź ta może być przechowywana w pamięci podręcznej. Celem odpowiedzi 410 jest przede wszystkim pomoc webmasterowi w utrzymaniu witryny poprzez poinformowanie użytkownika, że zasób nie jest już dostępny i że właściciel serwera chce, aby wszystkie zdalne połączenia z zasobem również zostały usunięte. Ten typ zdarzenia jest powszechny w ograniczonych czasowo usługach o wartości dodanej. Podobnie, odpowiedź 410 jest używana do powiadamiania klienta, że zasób należący do osoby fizycznej nie jest już dostępny w bieżącej witrynie serwera. Oczywiście ważne jest również pytanie, czy wszystkie trwale niedostępne zasoby muszą być oznaczone jako takie i jak długo należy je w ten sposób utrzymywać.'410 Gone'， To, jak długo należy je utrzymywać, zależy wyłącznie od właściciela serwera.
411 Serwer odmawia akceptowania żądań bez zdefiniowanego nagłówka Content-Length. Klient może ponownie przesłać żądanie po dodaniu prawidłowego nagłówka Content-Length wskazującego długość treści żądania.
412 Serwer nie spełnił jednego lub więcej warunków wstępnych podanych w polu nagłówka żądania podczas sprawdzania poprawności żądania. Ten kod stanu umożliwia klientowi ustawienie warunków wstępnych w metainformacjach żądania (dane pola nagłówka żądania) podczas uzyskiwania zasobu, zapobiegając w ten sposób zastosowaniu metody żądania do zasobów innych niż żądana zawartość.
413 Serwer odmawia przetworzenia bieżącego żądania, ponieważ przesyła więcej danych fizycznych niż serwer chce lub jest w stanie obsłużyć. W takim przypadku serwer może zamknąć połączenie, aby uniemożliwić klientowi dalsze wysyłanie żądania. Jeśli sytuacja jest tymczasowa, serwer powinien zwrócić nagłówek Retry-After, aby poinformować klienta, ile czasu ma na ponowienie próby.
414 Identyfikator URI żądania jest dłuższy niż serwer może zinterpretować, więc serwer odmawia obsługi żądania. Zdarza się to rzadko i zwykle ma miejsce, gdy przesłanie formularza, które powinno używać metody POST, staje się metodą GET, co skutkuje długim ciągiem zapytania. "Czarne dziury" w przekierowaniach URI, takie jak używanie starego URI jako części nowego URI dla każdego przekierowania, co skutkuje długim URI po kilku przekierowaniach. Klienci próbują atakować serwery, wykorzystując luki w zabezpieczeniach niektórych serwerów. Takie serwery używają bufora o stałej długości do odczytu lub manipulowania żądanym identyfikatorem URI, co może skutkować przepełnieniem bufora, gdy parametr GET przekroczy określoną wartość, prowadząc do wykonania dowolnego kodu.[1]。 Serwery bez takich luk powinny zwracać kod stanu 414.
415 Dla aktualnie żądanej metody i żądanego zasobu, jednostka przesłana w żądaniu nie jest w formacie obsługiwanym przez serwer i żądanie jest odrzucane.
416 Jeśli żądanie zawiera nagłówek żądania Range, a wszelkie zakresy danych określone w Range nie pokrywają się z zakresami dostępnymi dla bieżącego zasobu, a żądanie nie definiuje nagłówka żądania If-Range, serwer powinien zwrócić kod stanu 416. Jeśli Range używa zakresów bajtowych, oznacza to, że pierwszy bajt wszystkich zakresów danych określonych w żądaniu przekracza długość bieżącego zasobu. Serwer powinien również dołączyć nagłówek encji Content-Range, który określa długość bieżącego zasobu wraz z kodem stanu 416. Ta odpowiedź nie może również używać multipart/byteranges jako swojego Content-Type.
417 Oczekiwana zawartość określona w nagłówku żądania Expect nie może zostać spełniona przez serwer lub serwer jest serwerem proxy, który ma wyraźne dowody na to, że zawartość Expect nie może zostać spełniona w następnym węźle na bieżącej trasie.
421 Liczba połączeń z serwerem z adresu IP bieżącego klienta przekracza maksymalną dozwoloną przez serwer. Zazwyczaj adres IP odnosi się tutaj do adresu klienta widzianego z serwera (np. bramy użytkownika lub adresu serwera proxy). W takim przypadku w zliczaniu połączeń może brać udział więcej niż jeden użytkownik końcowy.
422 Liczba połączeń z adresu IP bieżącego klienta do serwera przekracza maksymalną dozwoloną przez serwer. Zazwyczaj adres IP odnosi się tutaj do adresu klienta widzianego z serwera (np. bramy użytkownika lub adresu serwera proxy). W tym przypadku w zliczaniu połączeń może brać udział więcej niż jeden użytkownik końcowy.
422 Żądanie zostało poprawnie sformatowane, ale nie można było na nie odpowiedzieć, ponieważ zawierało błędy semantyczne. (RFC 4918 WebDAV) 423 Zablokowany Bieżący zasób jest zablokowany. (RFC 4918 WebDAV) 423 Zablokowane
424 Bieżące żądanie nie powiodło się z powodu błędu w poprzednim żądaniu, takim jak PROPPATCH. (RFC 4918 WebDAV)
425 Zdefiniowany w projekcie WebDav Advanced Collections, ale nie występuje w protokole WebDAV Sequential Collections Protocol (RFC 3658).
426 Klienci powinni przełączyć się na TLS/1.0. (RFC 2817)
449 Rozszerzone przez Microsoft, aby reprezentować, że żądania powinny być ponawiane po wykonaniu odpowiedniej akcji.
500 Serwer napotkał nieprzewidziany warunek, który uniemożliwił mu ukończenie przetwarzania żądania. Zazwyczaj problem ten występuje w przypadku błędu w kodzie programu serwera.
501 Serwer nie obsługuje funkcji wymaganej przez bieżące żądanie. Gdy serwer nie rozpoznaje żądanej metody i nie może obsłużyć żądania dla żadnego zasobu.
502 Serwer działający jako brama lub serwer proxy otrzymuje nieprawidłową odpowiedź od serwera nadrzędnego, gdy próbuje wykonać żądanie.
503 Serwer nie jest obecnie w stanie przetworzyć żądania z powodu tymczasowej konserwacji serwera lub przeciążenia. Ten stan jest tymczasowy i zostanie przywrócony po pewnym czasie. Jeśli można spodziewać się opóźnienia, odpowiedź może zawierać nagłówek Retry-After, aby wskazać opóźnienie. Jeśli ta informacja Retry-After nie zostanie podana, klient powinien obsłużyć ją w taki sam sposób, jak odpowiedź 500. Uwaga: Istnienie kodu stanu 503 nie oznacza, że serwer musi go użyć, jeśli jest przeciążony. Niektóre serwery po prostu chcą odmówić klientowi połączenia.
504 Serwer działający jako brama lub serwer proxy, który próbuje wykonać żądanie, nie otrzymuje terminowej odpowiedzi od serwera nadrzędnego (serwera identyfikowanego przez URI, takiego jak HTTP, FTP, LDAP) lub serwera pomocniczego (takiego jak DNS). Uwaga: Niektóre serwery proxy zwracają błąd 400 lub 500, gdy wyszukiwanie DNS przekroczy limit czasu.
505 Serwer nie obsługuje lub odmawia obsługi wersji protokołu HTTP użytej w żądaniu. Oznacza to, że serwer nie może lub nie chce używać tej samej wersji, co klient. Odpowiedź powinna zawierać jednostkę opisującą, dlaczego wersja nie jest obsługiwana i jakie protokoły obsługuje serwer.
506 Rozszerzony przez Transparent Content Negotiation Protocol (RFC 2295), aby reprezentować wewnętrzną błędną konfigurację po stronie serwera: żądany zasób Negotiation Variant jest skonfigurowany do użycia samego siebie w Transparent Content Negotiation, a zatem nie jest odpowiednim celem w procesie negocjacji.
507 Serwer nie jest w stanie przechowywać zawartości niezbędnej do spełnienia żądania. Ten warunek jest uważany za tymczasowy.WebDAV(RFC 4918)
509 Serwer osiągnął limit przepustowości. Nie jest to oficjalny kod statusu, ale nadal jest szeroko stosowany.
510 Zasady wymagane do uzyskania zasobu nie zostały spełnione. (RFC 2774)
Dostęp do rekordów: