| Kod stanu HTTP | Znaczenie kodu stanu |
|---|
| 100 | Strona klienta powinna nadal wysyłać żądania. Tym tymczasowym odpowiedzią informuje się stronę klienta, że niektóre z jej żądań zostały odebrane przez serwer i nie zostały odrzucone. Strona klienta powinna nadal wysyłać resztę żądania, lub zignorować odpowiedź, jeśli żądanie zostało zakończone. Serwer musi wysłać końcową odpowiedź do strony klienta po zakończeniu żądania. |
| 101 | Serwer zrozumiał żądanie klienta i poinformuje stronę klienta poprzez nagłówek Upgrade o użyciu innego protokołu do ukończenia żądania. Po wysłaniu ostatniego pustego wiersza w odpowiedzi, serwer przejdzie do protokołów zdefiniowanych w nagłówku Upgrade. Podobne kroki powinny być podejmowane tylko wtedy, gdy przejście do nowego protokołu jest bardziej korzystne. Na przykład, przejście do nowej wersji HTTP ma zalety w porównaniu do starej wersji, lub przejście do prawdziwego-czas i synchroniczny protokół do dostarczania zasobów korzystających z takich funkcji. |
| 102 | Kod stanu rozszerzony przez WebDAV (RFC 2518) wskazuje, że przetwarzanie będzie kontynuowane. |
| 200. | Żądanie zakończyło się sukcesem, i z odpowiedzią zwrócono pożądane nagłówki odpowiedzi lub ciała danych. |
| 201 | Żądanie zostało spełnione, i nowy zasób został utworzony na podstawie wymagań żądania, a jego URI został zwrócony z nagłówkiem Location. Jeśli wymagany zasób nie może zostać utworzony w odpowiednim czasie, '202 Akceptowane' powinno być zwrócone. |
| 202 | Serwer przyjął żądanie, ale jeszcze go nie przetworzył. Jak może być odrzucone, żądanie może lub nie może być w końcu wykonane. W przypadku operacji asynchronicznych, nie ma bardziej wygodnego sposobu na to niż wysłanie tego kodu stanu. Celem zwrócenia 202 odpowiedzi kodu stanu, aby umożliwić serwerowi przyjmowanie żądań z innych procesów (np. operacji-operacja bazowa, która jest wykonywana tylko raz dziennie) bez potrzeby utrzymywania połączenia klienta z serwerem do momentu ukończenia operacji zbiorczej. W odpowiedzi na przyjęcie żądania do przetworzenia i zwrócenie 202 kod stanu, zwrócona entuta powinna zawierać pewne informacje wskazujące na bieżący stan procesu, jak również wskaźnik do monitora stanu procesu lub prognozy stanu, aby użytkownik mógł oszacować, czy operacja została zakończona. |
| 203 | serwer pomyślnie przetworzył żądanie, ale zwrócony nagłówek metadanych entuty nie jest poprawnym zestawem deterministycznym na oryginalnym serwerze, ale lokalnym lub trzecim-kopia strony. Bieżąca informacja może być podzbiorem lub supersetem oryginalnej wersji. Na przykład, metadane zawierające zasoby mogą sprawić, że oryginalny serwer będzie wiedział o meta super. Użycie tego kodu stanu nie jest wymagane i jest odpowiednie tylko wtedy, gdy odpowiedź zwraca 200 OK bez tego kodu stanu. |
| 204 | serwer pomyślnie przetworzył żądanie, ale nie musi zwracać żadnej fizycznej treści i chce zwrócić zaktualizowaną metainformację. Odpowiedź może być w formie nagłówka entuty, zwracając nowe lub zaktualizowane metainformację. Jeśli istnieje ten nagłówek, powinien on odpowiadać żądanym zmiennym. Jeśli strona klienta to przeglądarka, przeglądarka użytkownika powinna zachować stronę, która wysłała żądanie, bez jakichkolwiek zmian w widoku dokumentu, nawet jeśli nowe lub zaktualizowane metainformacje powinny być zastosowane do dokumentu w aktywnym widoku przeglądarki użytkownika zgodnie z specyfikacją. Ponieważ 204 odpowiedź nie może zawierać żadnego ciała wiadomości, zawsze kończy się pierwszą pustą linią po nagłówku. |
| 205 | serwer pomyślnie przetworzył żądanie i nic nie zwrócił. Ale w przeciwieństwie do 204 odpowiedź, która zwraca ten kod stanu wymaga, aby żądający zresetował widok dokumentu. Ta odpowiedź jest głównie używana do natychmiastowego zresetowania formularza po akceptowaniu wprowadzenia użytkownika, aby użytkownik mógł łatwo zacząć kolejne wprowadzenie. Jak 204 odpowiedzi, ta odpowiedź jest również zabroniona od zawierania jakiegokolwiek ciała wiadomości i kończy się pierwszym pustym wierszem po nagłówku. |
| 206 | Serwer pomyślnie przetworzył część żądania GET. Narzędzia do pobierania HTTP, takie jak FlashGet lub Xunlei, używają tego typu odpowiedzi do implementacji kontynuacji punktu przerwania lub do dzielenia dużego dokumentu na wiele segmentów pobierania do jednoczesnego pobierania. Żądanie musi zawierać nagłówek Range do wskazania zakresu zawartości, którą klient chce, i może zawierać If-Range jako warunek żądania. Odpowiedź musi zawierać następujące pola nagłówków: Content-Range do wskazania zakresu zawartości zwróconej w tej odpowiedzi; jeśli jest to wielo-pobieranie segmentu z Content-Typ wieloczęściowy/byteranges, każdy segment wieloczęściowy powinien zawierać Content-Pole Range do wskazania zakresu zawartości tego segmentu. Jeśli odpowiedź zawiera Content-Length, jego wartość musi pasować do rzeczywistej liczby bajtów w zwracanym zakresie zawartości. Data ETag i/lub Content-Location, jeśli to samo żądanie powinno zwrócić 200 odpowiedzi. Expires, Cache-Control, i/lub Vary, jeśli jego wartość może być inna niż wartość odpowiadająca innym odpowiedziom na ten sam zmiennik przed. Jeśli żądanie tej odpowiedzi używa If-Range silny weryfikacja bufora, wtedy ta odpowiedź nie powinna zawierać innych nagłówków encji; jeśli żądanie tej odpowiedzi używa If-Range słaby weryfikacja bufora, wtedy ta odpowiedź nie powinna zawierać innych nagłówków encji; to unika niespójności między zbuforowaną zawartością encji a zaktualizowanymi informacjami nagłówków encji. W przeciwnym razie, ta odpowiedź powinna zawierać wszystkie pola nagłówków encji, które powinny być zwrócone w 2odpowiedzi 00. Jeśli ETag lub Last-Modified, nie pasują dokładnie, bufor klienta powinien zabronić łączenia zawartości zwróconej w 206 odpowiedzi z jakąkolwiek wcześniej zbuforowaną zawartością. Każdy bufor, który nie obsługuje Range i nagłówków-Nagłówek Range jest zabroniony od buforowania zawartości zwróconej przez 206 odpowiedzi. |
| 207 | Kod stanu rozszerzony przez WebDAV (RFC 2518) oznacza, że ciało następnego komunikatu będzie komunikatem XML, i może zawierać serię niezależnych kodów odpowiedzi w zależności od liczby poprzednich pod-żądań. |
| 300 | Żądzony zasób ma zakres opcji opinii, każda z własnym specyficznym adresem i przeglądarką-informacjami. Użytkownik lub przeglądarka może wybrać preferowany adres dla przekierowania. O ile to nie jest żądanie HEAD, odpowiedź powinna zawierać encję z listą atrybutów zasobu i adresów, z których użytkownik lub przeglądarka może wybrać najbardziej odpowiedni adres przekierowania. Format tej encji jest określony przez format zdefiniowany przez Content-Typ. Przeglądarka może automatycznie dokonać najbardziej odpowiedniego wyboru na podstawie formatu odpowiedzi i własnych możliwości przeglądarki. Oczywiście, negocjacja napędzana RFC 2616 specyfikację nie określa, jak powinno być wykonywane takie automatyczne wybieranie. Jeśli serwer sam ma preferowaną opcję wyboru opinii, adres opinii powinien być określony w Location; przeglądarki mogą używać tej wartości Location jako adresu dla automatycznego przekierowania. W dodatkowym przypadku, o ile nie wskazano inaczej, odpowiedź jest również przechowywana w pamięci podręcznej. |
| 301 | Żądiony zasób został trwale przeniesiony do nowej lokalizacji, a przyszłe odniesienia do tego zasobu powinny używać jednego z kilku URI zwróconych przez tę odpowiedź. Jeśli to możliwe, strona klienta z możliwością edycji linków powinna automatycznie zmienić żądany adres na adres zwrócony z serwera. O ile nie wskazano inaczej, ta odpowiedź jest również przechowywana w pamięci podręcznej. Nowy trwały URI powinien być zwrócony w polu Location odpowiedzi. O ile to nie jest żądanie HEAD, odpowiedź powinna zawierać encję z listą atrybutów zasobu i adresów, z których użytkownik lub przeglądarka może wybrać najbardziej odpowiedni adres przekierowania. Format tej encji jest określony przez format zdefiniowany przez Content/1.0 protokółu, gdy wysyłają żądanie POST i otrzymują 301 odpowiedzi, kolejne żądanie przekierowania będzie GET. |
| 302 | żądany zasób teraz tymczasowo odpowiada na żądanie z innej URI. Ponieważ takie przekierowania są tymczasowe, strona klienta powinna nadal wysyłać przyszłe żądania do oryginalnego adresu. Ta odpowiedź jest przechowywana w pamięci podręcznej tylko jeśli określono to w Cache-kontrola lub Expires. Nowa tymczasowa URI powinna być zwrócona w polu Location odpowiedzi. O ile nie jest to żądanie HEAD, odpowiedź powinna zawierać hiperłącze do nowej URI oraz krótki opis. Jeśli nie jest to żądanie GET lub HEAD, przeglądarka zabrania automatycznego przekierowywania, chyba że potwierdzono to przez użytkownika, ponieważ warunki żądania mogą się zmienić w wyniku tego. 1945 i RFC 2068 specyfikacje nie pozwalają stronie klienta na zmianę metody żądania podczas przekierowywania, wiele istniejących przeglądarek traktuje 302 odpowiedzi jako 303 odpowiedź oraz użycie GET do uzyskania dostępu do URI określonej w polu Location, ignorując oryginalną metodę żądania. Kody stanu 303 i 307 dodano, aby wyjaśnić, czego serwer oczekuje od strony klienta. |
| 303 | odpowiedź na bieżące żądanie można znaleźć na innej URI, a strona klienta powinna uzyskać dostęp do tego zasobu za pomocą metody GET. Ta metoda istnieje głównie, aby umożliwić skryptom-Aktywowano wynik żądania POST, aby został przekierowany do nowego zasobu. Ta nowa URI nie jest zamiennikiem odniesienia do oryginalnego zasobu. Również, 303 odpowiedzi są zabronione od zapisywania w pamięci podręcznej. Oczywiście, drugie żądanie (przekierowanie) może być zapisane w pamięci podręcznej. Nowy URI powinien być zwrócony w polu Location odpowiedzi. O ile nie jest to żądanie HEAD, odpowiedź encja powinna zawierać hiperłącze do nowego URI i krótki opis. Uwaga: Wiele przeglądarek przed HTTP}}/1.1 nie rozumie 303 poprawnie. Jeśli musisz rozważyć interakcję z tymi przeglądarkami, the 302 kod stanu powinien być wystarczający, ponieważ większość przeglądarek obsługuje 302 odpowiedzi dokładnie w sposób, w jaki powyższa specyfikacja wymaga, aby strona klienta przetwarzała 303 odpowiedzi. |
| 304 | Jeśli strona klienta wysyła żądanie GET warunkowe i żądanie jest dozwolone, a zawartość dokumentu nie zmieniła się (od ostatniej wizyty lub zgodnie z warunkami żądania), serwer powinien zwrócić ten kod stanu. 304 odpowiedzi są zabronione od zawierania ciał wiadomości, więc zawsze kończą się pierwszym pustym wierszem po nagłówku. Odpowiedź musi zawierać następujące informacje nagłówkowe: Date, chyba że ten serwer nie ma zegara.
Jeśli serwer bez zegara również przestrzega tych zasad, serwer proxy i strona klienta mogą samodzielnie dodać pole Date do otrzymanego nagłówka odpowiedzi (jak określono w RFC 2068), i mechanizm cache będzie działał poprawnie. ETag i/lub Content-Location, jeśli to samo żądanie powinno zwrócić 200 odpowiedzi. Expires, Cache-Control, i/lub Vary, jeśli jego wartość może być inna niż wartość odpowiadająca innym odpowiedziom na to samo zmienną przed.
Jeśli żądanie odpowiedzi używa silnej walidacji pamięci podręcznej, odpowiedź nie powinna zawierać innych nagłówków encji; w przeciwnym razie (np. żądanie GET warunkowe używa słabej walidacji pamięci podręcznej), odpowiedź nie może zawierać innych nagłówków encji; to zapobiega niezgodnościom między zawartością encji w pamięci podręcznej a zaktualizowanymi informacjami o nagłówkach encji. Jeśli 304 odpowiedzi wskazuje, że jednostka nie jest w tej chwili przechowywana w pamięci podręcznej, system pamięci podręcznej musi zignorować odpowiedź i wysyłać powtarzające się żądania bez ograniczeń.
Jeśli 304 odpowiedzi jest odbierana do aktualizacji wpisu pamięci podręcznej, system pamięci podręcznej musi zaktualizować cały wpis, aby odzwierciedlić wartości wszystkich pól, które zostały zaktualizowane w odpowiedzi. |
| 305 | żądany zasób musi być uzyskany przez określony proxy. Informacje o URI określonego proxy są podane w polu Location. Odbiorca musi wysyłać powtarzające się osobne żądania, aby uzyskać dostęp do odpowiedniego zasobu przez ten proxy. Tylko serwer źródłowy może ustanowić 305 odpowiedzi. Uwaga: Nie ma wyraźnego 305 odpowiedzi w RFC 2068 aby przekierować pojedyncze żądanie, i może być ustanowione tylko przez serwer źródłowy. Ignorowanie tych ograniczeń może prowadzić do poważnych konsekwencji bezpieczeństwa. |
| 306 | w najnowszej wersji specyfikacji, 306 kod stanu już nie jest używany. |
| 307 | żądany zasób teraz tymczasowo odpowiada na żądanie z innego URI. Ponieważ takie przekierowania są tymczasowe, strona klienta powinna kontynuować wysyłanie przyszłych żądań do oryginalnego adresu. Ta odpowiedź jest przechowywana w pamięci podręcznej tylko jeśli określono w Cache-kontrola lub Expires. Nowy tymczasowy URI powinien być zwrócony w polu Location odpowiedzi. O ile to nie jest żądanie HEAD, odpowiednia jednostka powinna zawierać hiperłącze wskazujące na nowy URI oraz krótki opis. Ponieważ niektóre przeglądarki nie rozpoznają 307 odpowiedzi, powyższe informacje muszą być dodane, aby użytkownik mógł zrozumieć i uzyskać dostęp do nowego URI.
Jeśli to nie jest żądanie GET lub HEAD, przeglądarka zabrania automatycznego przekierowania, chyba że potwierdzono to przez użytkownika, ponieważ warunki żądania mogą się zmienić w wyniku tego. |
| 400 | 1. Semantyka jest błędna, a bieżące żądanie nie może być zrozumiane przez serwer. O ile nie zostanie zmienione, strona klienta nie powinna ponownie wysyłać żądania. 2. Parametry żądania są błędne. |
| 401 | Bieżące żądanie wymaga uwierzytelnienia użytkownika. Odpowiedź musi zawierać WWW-nagłówek uwierzytelniania dla żądanego zasobu, aby poprosić użytkownika o informacje. Strona klienta może ponownie wysłać żądanie z odpowiednimi informacjami nagłówka Autoryzacji. Jeśli bieżące żądanie już zawiera certyfikaty Autoryzacji, then the 401 odpowiedź oznacza, że serwer odrzucił te certyfikaty. Jeśli 401 odpowiedź zawiera tę samą prośbę uwierzytelniania, co poprzednia odpowiedź, a przeglądarka przetestowała uwierzytelnianie przynajmniej raz, wtedy przeglądarka powinna pokazać użytkownikowi informacje o encji zawarte w odpowiedzi, ponieważ te informacje o encji mogą zawierać istotne informacje diagnostyczne. Zobacz RFC 2617. |
| 402 | Ten kod stanu jest zarezerwowany na możliwe przyszłe wymagania. |
| 403 | Serwer zrozumiał żądanie, ale odmówił jego wykonania. W przeciwieństwie do 401 odpowiedź, uwierzytelnienie nie pomoże i żądanie nie powinno być powtarzane. Jeśli to nie jest żądanie HEAD, a serwer chce móc wyjaśnić, dlaczego żądanie nie może być wykonane, powód odrzucenia powinien być opisany wewnątrz encji. Oczywiście, serwer może również zwrócić 404 odpowiedź, jeśli nie chce, aby strona klienta uzyskała żadne informacje. |
| 404 | Żądanie nie powiodło się, a żądany zasób nie został znaleziony na serwerze. Nie ma informacji, aby poinformować użytkownika, czy stan jest tymczasowy czy trwały. Jeśli serwer jest świadomy sytuacji, the 410 Kod stanu powinien być używany do poinformowania starego zasobu, że jest trwale niedostępny z powodu pewnego mechanizmu konfiguracji wewnętrznej i nie ma adresu do przejścia. The 404 Kod stanu jest szeroko używany, gdy serwer nie chce ujawniać, dlaczego żądanie zostało odrzucone lub nie ma innych odpowiednich odpowiedzi. |
| 405 | 405 Metoda żądania określona w wierszu żądania nie może być użyta do żądania odpowiedniego zasobu. Odpowiedź musi zwrócić nagłówek Allow, który wskazuje listę metod żądania, które mogą być zaakceptowane przez bieżący zasób. Ponieważ metody PUT i DELETE zapisują zasoby na serwerze, większość serwerów WWW nie obsługuje lub domyślnie nie pozwala na powyższe metody żądania i zwraca |
| 406 | błąd dla takich żądań.-Charakterystyka treści żądanego zasobu nie spełnia warunków w nagłówku żądania, więc nie można wygenerować odpowiedniego obiektu odpowiedzi. O ile nie jest to żądanie HEAD, odpowiedź powinna zwrócić obiekt, który pozwala użytkownikowi lub przeglądarce wybrać najbardziej odpowiednie cechy obiektu i listę adresów. Format obiektu jest określony przez typ medium zdefiniowany w Content |
| 407 | Nagłówek typu. Przeglądarka może dokonać najlepszej decyzji na podstawie formatu i swoich możliwości. Jednak specyfikacja nie definiuje żadnych kryteriów dla podejmowania takich automatycznych wyborów. 401 Podobnie jak w-Uwierzytelnij dla uwierzytelniania. Strona klienta może zwrócić odpowiedź pośrednika, ale strona klienta musi uwierzytelniać się na serwerze pośrednika. Serwer pośrednika musi zwrócić odpowiedź pośrednika-Nagłówek autoryzacji dla uwierzytelniania. Zobacz RFC 2617. |
| 408 | Żądanie przekroczyło limit czasu. Strona klienta nie ukończyła wysyłania żądania w czasie, w którym serwer był gotowy czekać. Strona klienta może w każdej chwili ponownie wysłać żądanie bez jakichkolwiek zmian. |
| 409 | Żądanie nie może zostać ukończone z powodu konfliktu z bieżącym stanem żądanego zasobu. Ten kod może być użyty tylko wtedy, gdy założono, że użytkownik jest w stanie rozwiązać konflikt i ponownie wysłać nowe żądanie. Odpowiedź powinna zawierać wystarczające informacje, aby użytkownik mógł zidentyfikować źródło konfliktu. Konflikty zwykle występują w przetwarzaniu żądań PUT. Na przykład, w wersji-sprawdzonym środowisku, jeśli informacje o wersji dołączonych do PUT-złożony wniosek o modyfikację dla konkretnego zasobu koliduje z poprzednim (trzecim-strona) żądanie, serwer powinien zwrócić 409 błąd informujący użytkownika, że żądanie nie mogło zostać ukończone.
W tym momencie, odpowiedź entuty prawdopodobnie zawiera porównanie różnic między dwoma sprzecznymi wersjami, aby użytkownik mógł ponownie wysłać zintegrowaną wersję. |
| 410 | żądany zasób już nie jest dostępny na serwerze i nie ma żadnego znanego adresu przekierowania. Ta sytuacja powinna być uznana za trwałą. Jeśli to możliwe, strona klienta z możliwością edycji linków powinna usunąć wszystkie odniesienia do tego adresu z upoważnienia użytkownika. Jeśli serwer nie wie lub nie może określić, czy ta sytuacja jest trwała, to 404 kod stanu powinien być używany. O ile w przeciwnym razie nie jest określone, ta odpowiedź jest przechowywana w pamięci podręcznej. Celem 410 odpowiedź jest głównie używana do pomocy webmasterowi w utrzymaniu strony, informowania użytkownika, że zasób już nie jest dostępny, oraz że właściciel serwera chce, aby wszystkie połączenia zdalne do tego zasobu zostały usunięte.
Tego typu wydarzenie jest powszechne w czasie-ograniczona, wartość-dodane usługi. Podobnie, 410 odpowiedź jest używana do informowania strony klienta, że zasoby pierwotnie należące do indywidualnego już nie są dostępne na bieżącej stronie serwera. Oczywiście, cała decyzja należy do właściciela serwera, czy oznaczyć wszystkie trwale niedostępne zasoby jako ' 410 Stan 'Gone', oraz jak długo utrzymać ten znak. |
| 411 | Serwer odmawia przyjęcia żądania bez zdefiniowania Zawartości-Nagłówek długości. Po dodaniu poprawnego Zawartości-Nagłówek długości wskazujący długość ciała żądania, strona klienta może ponownie wysłać żądanie. |
| 412 | Serwer nie spełnił jednego lub więcej wymagań podczas weryfikacji, że zostały one podane w polu nagłówka żądania. Ten kod stanu pozwala stronie klienta na ustawienie wymagań w żądanym metadanych (danych pola nagłówka żądania) podczas pobierania zasobów, zapobiegając zastosowaniu metody żądania do zasobów innych niż te, które chce. |
| 413 | Serwer odmawia przetwarzania bieżącego żądania, ponieważ żądanie przesyła więcej danych jednostki niż serwer jest gotów lub w stanie obsłużyć. W tym przypadku serwer może zamknąć połączenie, aby zapobiec dalszemu wysyłaniu żądania przez stronę klienta. Jeśli ta sytuacja jest tymczasowa, serwer powinien zwrócić Retry-Po nagłówku odpowiedzi, aby poinformować stronę klienta, jak długo może spróbować ponownie. |
| 414 | Żądany URI jest dłuższy niż serwer może interpretować, więc serwer odmawia obsługi żądania. To jest rzadkie, i typowe przypadki obejmują: Przesłanie formularza, które powinno używać metody POST, staje się metodą GET, powodując, że ciąg zapytania (Query String) jest zbyt długi. Przekierowanie URI "czarnych dziur", takie jak każde przekierowanie używające starego URI jako części nowego URI, prowadzące do tego, że URI jest zbyt długi po kilku przekierowaniach. Klient próbuje zaatakować serwer za pomocą błędów zabezpieczeń istniejących w niektórych serwerach.
Tego typu serwer używa stałego-bufor długości do odczytu lub manipulacji żądanym URI. Gdy parametry po GET przekraczają pewną wartość, może wystąpić przepełnienie bufora, prowadzące do wykonania dowolnego kodu [1]. Serwery bez takich luk powinny zwrócić 414 kod stanu. |
| 415 | Dla metody bieżącego żądania i żądanej zasoby, przedstawiona w żądaniu jednostka nie jest w formacie obsługiwanym przez serwer, więc żądanie jest odrzucone. |
| 416 | Jeśli żądanie zawiera nagłówek zakresu i żaden z określonych zakresów danych w zakresie nie zgadza się z dostępnym zakresem bieżącego zasobu, oraz Jeśli-Nie zdefiniowano nagłówka zakresu w żądaniu, serwer powinien zwrócić 416 kodem stanu. Jeśli zakres używa zakresu bajtów, to ta sytuacja oznacza, że pierwsza pozycja bajtowa wszystkich określonych przez żądanie zakresów danych przekracza długość bieżącego zasobu. Serwer powinien również zawierać Content-Nagłówek jednostki zakresu razem z 416 kod stanu do wskazania długości bieżącego zasobu. Odpowiedź ta jest również zabroniona od używania multipart/byteranges jako jego zawartość-Typ. |
| 417 | Oczekiwane zawartość określona w nagłówku żądania Expect nie może zostać spełniona przez serwer, lub serwer jest serwerem proxy, który ma jasne dowody, że oczekiwana zawartość nie może zostać spełniona na następnym węźle bieżącej trasy. |
| 421 | Liczba połączeń do serwera z adresu protokołu Internet, z którego znajduje się obecna strona klienta, przekracza maksymalną dozwoloną przez serwer. Zwykle adres protokołu Internet tutaj odnosi się do adresu strony klienta widocznego z serwera (np. adres bramy użytkownika lub serwera proxy). W tym przypadku liczba połączeń może obejmować więcej niż jednego użytkownika końcowego. |
| 422 | Liczba połączeń do serwera z adresu protokołu Internet, z którego znajduje się obecna strona klienta, przekracza maksymalną dozwoloną przez serwer. Zwykle adres protokołu Internet tutaj odnosi się do adresu strony klienta widocznego z serwera (np. adres bramy użytkownika lub serwera proxy). W tym przypadku liczba połączeń może obejmować więcej niż jednego użytkownika końcowego. |
| 422 | Żądanie zostało poprawnie sformatowane, ale nie można było na nie odpowiedzieć z powodu błędu semantycznego. (RFC 4918 WebDAV) 423 Zablokowane Bieżący zasób jest zablokowany. (RFC 4918 WebDAV) |
| 424 | Bieżące żądanie zawiodło z powodu błędu w poprzednim żądaniu, takim jak PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Zdefiniowane w projekcie zaawansowanych kolekcji WebDav, ale nie w protokole sekwencyjnych zestawów WebDAV (RFC 3658). |
| 426 | Strona klienta powinna przejść na TLS/1.0. (RFC 2817) |
| 449 | Rozszerzone przez Microsoft, żądania powinny być ponawiane po wykonaniu odpowiednich działań. |
| 500 | Serwer napotkał niespodziewaną sytuację, która zapobiegła mu ukończeniu żądania. Ogólnie rzecz biorąc, ten problem występuje, gdy kod serwera zawodzi. |
| 501 | Serwer nie obsługuje funkcji wymaganej przez bieżące żądanie. Kiedy serwer nie może rozpoznać żądanej metody i nie może obsługiwać żądania żadnego zasobu. |
| 502 | Kiedy serwer działający jako brama lub pośrednik próbuje wykonać żądanie, otrzymuje niewłaściwą odpowiedź od serwera górnego. |
| 503 | Serwer obecnie nie jest w stanie przetwarzać żądań z powodu tymczasowego utrzymania serwera lub przeciążenia. Ten stan jest tymczasowy i zostanie przywrócony po pewnym czasie. Jeśli czas opóźnienia można przewidzieć, odpowiedź może zawierać Retry-Po nagłówku do wskazania czasu opóźnienia. Jeśli ten Retry-Po braku podania informacji, strona klienta powinna ją traktować jak 5odpowiedź 00. Uwaga: Istnienie 503 kod stanu nie oznacza, że serwer musi go używać w przypadku przeciążenia. Niektóre serwery po prostu chcą odmówić połączenia klienta. |
| 504 | Kiedy serwer działający jako brama lub proxy próbuje wykonać żądanie, nie otrzymuje odpowiedzi od serwera nadrzędnego (zidentyfikowanego przez URI, takie jak HTTP, FTP, LDAP) lub serwera wtórnego (takiego jak DNS) w odpowiednim czasie. Uwaga: Niektóre serwery proxy zwracają 400 lub 5Błąd 00, gdy zapytanie DNS wygasa |
| 505 | Serwer nie obsługuje, lub odmawia obsługi, wersji HTTP używanej w żądaniu. To oznacza, że serwer nie może lub nie będzie używał tej samej wersji co strona klienta. Odpowiedź powinna zawierać encję opisującą, dlaczego wersja nie jest obsługiwana oraz które protokoły obsługuje serwer. |
| 506 | Rozszerzony przez Protokół Przejrzystej Negocjacji Treści (RFC 2295), to reprezentuje wewnętrzny błąd konfiguracyjny na serwerze: żądany zmienny zasób negocjacji jest skonfigurowany do użycia samego siebie w przejrzystej negocjacji treści, i z tego powodu nie jest odpowiednim punktem odniesienia w procesie negocjacji. |
| 507 | Serwer nie może przechować treści niezbędnej do zakończenia żądania. Ten stan jest uważany za tymczasowy. WebDAV (RFC 4918) |
| 509 | Serwer osiągnął limit przepustowości. Nie jest to oficjalny kod stanu, ale jest nadal szeroko używany. |
| 510 | Nie spełnione są polityki wymagane do uzyskania zasobów. (RFC 2774) |
