| Kod statusu HTTP |
Znaczenie kodu statusu |
| 100 |
Klient powinien kontynuować wysyłanie żądania. Ta tymczasowa odpowiedź ma na celu powiadomienie klienta, że jego część żądania została już odebrana przez serwer i nie została jeszcze odrzucona. Klient powinien kontynuować wysyłanie pozostałej części żądania lub zignorować tę odpowiedź, jeśli żądanie zostało już zakończone. Serwer musi wysłać końcową odpowiedź do klienta po zakończeniu żądania. |
| 101 |
Serwer zrozumiał żądanie klienta i powiadomi klienta za pomocą nagłówka Upgrade, że przyjmie inny protokół do ukończenia tego żądania. Po wysłaniu ostatniego pustego wiersza tej odpowiedzi, serwer przełączy się na protokoły określone w nagłówku Upgrade. Należy przyjąć podobne działania tylko wtedy, gdy przełączenie na nowy protokół będzie korzystne. Na przykład przełączenie na nową wersję HTTP może być bardziej korzystne niż stara wersja lub przełączenie do protokołu rzeczywistego i synchronicznego do przesyłania zasobów, które mają z tego korzystać. |
| 102 |
Kod statusu rozszerzony przez WebDAV (RFC 2518), który oznacza, że przetwarzanie będzie kontynuowane. |
| 200 |
Żądanie zostało pomyślnie zrealizowane, pożądane nagłówki odpowiedzi lub treść danych zostaną zwrócone z tą odpowiedzią. |
| 201 |
Żądanie zostało zrealizowane, a nowy zasób został utworzony na podstawie żądania i jego URI zostało zwrócone w informacji nagłówka Location. Jeśli żądany zasób nie może być utworzony na czas, należy zwrócić '202 Accepted'. |
| 202 |
Serwer przyjął żądanie, ale jeszcze go nie przetworzył. Może być tak, że żądanie zostało odrzucone, a ostateczne żądanie może zostać wykonane lub nie. W przypadku operacji asynchronicznych nie ma dogodniejszego działania niż zwrócenie tego kodu statusu. Celem odpowiedzi z kodem statusu 202 jest umożliwienie serwerowi zaakceptowania żądań innych procesów bez konieczności utrzymywania połączenia z klientem, aż wszystkie operacje wsadowe zostaną zakończone. Odpowiedź powinna zawierać wskaźnik wskazujący na aktualny status przetwarzania oraz wskazanie do monitora statusu lub przewidywania statusu, aby użytkownik mógł oszacować, czy operacja została zakończona. |
| 203 |
Serwer pomyślnie przetworzył żądanie, ale nagłówki metadanych zwróconego podmiotu nie są określoną kolekcją na oryginalnym serwerze, ale Pochodzą z lokalnej lub zewnętrznej kopii. Aktualne informacje mogą być zbiorem podzbioru lub nadzbiorem oryginalnej wersji. Na przykład metadane dotyczące zawartości mogą spowodować, że oryginalny serwer będzie znał nadmiar metadanych. Używanie tego kodu statusu nie jest obowiązkowe, a odpowiedzi, które zamiast tego powinny zwracać 200 OK, są jedynymi sytuacjami, w których ma zastosowanie. |
| 204 |
Serwer pomyślnie przetworzył żądanie, ale nie wymaga zwracania żadnej treści podmiotu, a zamiast tego chce zwrócić zaktualizowane metadane. Odpowiedź może zawierać nowe lub zaktualizowane informacje w formie nagłówków podmiotu. Jeśli takie nagłówki są obecne, to powinny się one odnosić do żądanych zmiennych. Jeśli klient jest przeglądarką, przeglądarka użytkownika powinna zachować stronę, która wysłała to żądanie bez wprowadzania żadnej zmiany w widoku dokumentu, nawet jeśli dostosowane do standardu nowe lub zaktualizowane metadane powinny być stosowane do dokumentu widoku akcji użytkownika przeglądarki. Ponieważ odpowiedzi 204 nie mogą zawierać ciała wiadomości, zawsze kończy się ona pierwszym pustym wierszem po nagłówkach wiadomości. |
| 205 |
Serwer pomyślnie przetworzył żądanie, ale nie zwrócono żadnej treści. Jednak w przeciwieństwie do odpowiedzi 204, odpowiedź z tym kodem statusu wymaga od żądającego zresetowania widoku dokumentu. Ta odpowiedź jest głównie używana po zaakceptowaniu wejścia użytkownika, aby natychmiast zresetować formularz, aby użytkownik mógł łatwo rozpocząć nową inny wpis. Podobnie jak odpowiedź 204, ta odpowiedź również nie może zawierać ciała wiadomości i kończy się pierwszym pustym wierszem po nagłówkach wiadomości. |
| 206 |
Serwer pomyślnie przetworzył część żądania GET. Narzędzia pobierania HTTP, takie jak FlashGet lub Thunder, używają tej odpowiedzi do realizacji wznowienia pobierania lub podziału dużych dokumentów na wiele segmentów do pobrania w tym samym czasie. To żądanie musi zawierać nagłówek Range, aby wskazać zakres treści, który klient chce otrzymać, i może zawierać If-Range jako warunek żądania. Odpowiedź musi zawierać następujące pola nagłówków: Content-Range, aby wskazać zakres treści zwracanej w tej odpowiedzi; jeśli jest to parcia multipart/byteranges od razu, należy również zawrzeć pole Content-Range, aby wskazać zakres treści tego segmentu. Jeżeli odpowiedź zawiera pole Content-Length, to jego wartość musi odpowiadać rzeczywistej liczbie bajtów zwróconych w zakresie treści. Data, ETag i/lub Content-Location, jeżeli podobne żądanie powinno zwrócić odpowiedź 200. Expires, Cache-Control, i/lub vary, jeżeli ich wartość może różnić się od odpowiednich wartości wcześniejszych odpowiedzi tego samego żądania. Jeżeli to zgłoszenie korzystało z mocy silniczków kablowych weryfikacji, wtedy nie może zawierać innych pól. Jeżeli stosunek tego zgłoszenia używał odmiennej weryfikacji rejestracyjnej, nie powinno się cofać innych głównych aktów. To zapobiega sprzeczności między treściami w pamięci podręcznej i nadzwycwionymi treściami nagłówków. W przeciwnym razie, respondencja powinna zawierać wszystkie pola nagłówków, które powinny być zawarte w odpowiedzi 200. Jeżeli nagłówki ETag a Last-Modified nie zgadzają się w precyzyjny sposób, to pamięci podręczne klientów powinny zwracać materiał odpowiadający treści zapętlonej na jakimkolwiek komputerze. Każda pamięć podręczna, która nie obsługuje nagłówków Range i Content-Range, nie powinna pamiętać 206. |
| 207 |
Kod statusu rozszerzony przez WebDAV (RFC 2518), który sygnalizuje, że następne ciało wiadomości będzie komunikatem XML i może zawierać szereg niezależnych kodów odpowiedzi w zależności od liczby wcześniej zgłoszonych żądań. |
| 300 |
Żądany zasób ma szereg możliwych opcji, z których każda ma swój określony adres i informacje handlowe, które są regulowane przez przeglądarkę. Użytkownik lub przeglądarka może samodzielnie wybrać preferowany adres do przekierowania. O ile nie jest to żądanie HEAD, ta odpowiedź powinna zawierać jednostkowe złożenie, które określa właściwości zasobów i adresów, z których użytkownik lub nagrodziona przeglądarka może wybrać najlepszy adres do przekierowania. Taki podmiot zależy od formatu zdefiniowanego jako Content-Type. Przeglądarka może zautomatyzować najlepszy wybór na podstawie formatu odpowiedzi i własnych możliwości przeglądarki. Oczywiście, specyfikacja RFC 2616 nie nakłada wymogów wyboru. Jeżeli serwer ma preferowane opcje do szeregu zasobów, URI powinna być wskazywana w Liście, a przeglądarka może przyjąć to lokatą jako domyślne obejście. Ponadto, chyba że to dodatkowo zaznaczone, ta odpowiedź jest również może być przechowywana w pamięci podręcznej. |
| 301 |
Żądany zasób został trwale przeniesiony do nowej lokalizacji, a wszystkie przyszłe odniesienia do tego zasobu powinny używać URI zwróconego w tej odpowiedzi. Jeśli to możliwe, klienci powinni automatycznie zmieniać żądane adresy na zwrócone przez serwer. O ile nie jest to dodatkowo określone, ta odpowiedź jest również pamiętana w pamięci podręcznej. Nowy, trwały URI powinny być zwracane w polu Location odpowiedzi. Jeżeli to nie jest żądanie HEAD, odpowiedź powinna zawierać hiperlink do nowego URI oraz krótkie uzasadnienie. Jeżeli to nie jest prośba o GET lub HEAD, to przeglądarka nie powinna automatycznie następować przekierowania, chyba że użytkownik potwierdzi, ponieważ warunki swojego żądania mogą ulec zmianie. Uwaga: w przypadku niektórych przeglądarek używających protokołu HTTP/1.0, gdy wysyłane przez nich zapytanie POST uzyska odpowiedź 301, kolejne przekierowanie automatycznie przekształci zapytanie w GET. |
| 302 |
Żądany zasób jest aktualnie tymczasowo dostępny z drugiego URI. Ze względu na tymczasowe przekierowanie, klienci powinni nadal wysyłać przyszłe zapytania do pierwotnego adresu. Ta odpowiedź może być zapamiętana w pamięci podręcznej tylko wtedy, gdy jest wskazania w nagłówkach Cache-Control lub Expires. Nowy URI powinien być zwracany w polu Location odpowiedzi. O ile nie jest to żądanie HEAD, odpowiedź powinna również zawierać hiperlink do nowego URI i krótkie uzasadnienie. Jeżeli to nie jest zapytanie GET ani HEAD, przeglądarka nie powinna automatycznie następować przekierowania, chyba że użytkownik to potwierdzi, ponieważ jego żądania mogą ulec zmianie. Należy zauważyć, że mimo iż specyfikacje RFC 1945 i RFC 2068 nie pozwalają na zmianę metody żądania przez klienta, wiele obecnie używanych przeglądarek traktuje odpowiedzi 302 jako 303 i wykorzystuje metodę GET do dostępu do URI określonego w pole Location, ignorując metodę pierwotnego żądania. Kody statusu 303 i 307 zostały dodane, aby wyjaśnić, czego klient oczekuje od serwera. |
| 303 |
Odpowiedź dotycząca bieżącego żądania może być znaleziona pod innym URI, a klient powinien uzyskać tę treść za pomocą metody GET. To podejście jest głównie stosowane w celu umożliwienia skryptom wyzwolenia procesu POST, aby wymusić przekierowanie do nowego URI. Nowe URI nie są alternatywnym odniesieniem do pierwotnego zasobu. Odpowiedzi 303 powinny być przez cały czas unikać pamięci podręcznej. Oczywiście, w przypadku drugiego żądania (przekierowania), może być pamiętane. Nowe URI powinny występować pod polami Location odpowiedzi. O ile nie jest to żądanie HEAD, odpowiedź powinna też zawierać hiperlink do nowego URI z krótkim opisem. Uwaga: wiele przeglądarek przed wersją HTTP/1.1 wcale nie zrozumiało poprawnie kodu 303 stanu. W kontekście interakcji z tymi przeglądarkami kod 302 powinien działać, ponieważ postępowanie większości przeglądarek w przypadku odpowiedzi 302 jest właśnie to, jakie opisuje protokół 303. |
| 304 |
Jeśli klient wysłał zapytanie GET z warunkami i takie żądanie zostało dozwolone, a treść dokumentu (od momentu ostatniego dostępu lub zgodnie z warunkami żądania) nie zmieniła się, to serwer powinien zwrócić ten kod statusu. Odpowiedź 304 nie może zawierać ciała wiadomości, dlatego zawsze kończy się pierwszym pustym wierszem po nagłówkach. Odpowiedź musi zawierać następujące pola nagłówków: Data, o ile serwer nie ma zegara. Jeżeli brak zegara serwera jest przestrzegany, to serwery pośredniczące i klienci mogą dodać pole daty z otrzymanymi danymi nagłówków zamówień (jak przewiduje RFC 2068); W większej odległości mogą zapewnić, że odpowiednia polityka witryny będzie wspierać. ETag i/lub Content-Location, jeśli podobne zapytanie powinno zwrócić odpowiedź 200. Expires, Cache-Control i/lub Vary, inne wyglądały na inną wartość na podstawie poprzednich wartości tych samych pól. Jeżeli to żądanie korzystało z paska siły plików, odpowiadając w zakładce z 200, nie powinny być zgłaszane przeciwnikami. W przeciwnym razie (na przykład w przypadku użycia słabszej weryfikacji z warunkowym zapytaniem GET), ta odpowiedź nie powinna być udzielana z innymi aktami, aby zapobiec sprzeczności z poprzednimi zakładkami i nagłówkami odpowiedzi. Jeżeli kod 304 wskazuje aktualny brak pełnych danych, system pamięci podręcznej musi zignorować tę wersję, a ponownie przewirować jej wersje. Jeśli 304 oznaczone jako niepełny, cały system pamięci podręcznej powinien zaktualizować polecenie z aktualnymi danymi. |
| 305 |
Żądany zasób można uzyskać tylko poprzez wskazany serwer proxy. W polu Location zostanie podany adres URI wskazujący serwer proxy; odbiorca powinien ponownie zwrócić żądanie tego zasobu za pośrednictwem proxy. Tylko oryginalny serwer może utworzyć odpowiedź 305. Uwaga: RFC 2068 wyraźnie nie wskazuje, że odpowiedzi 305 dotyczą przekierowywania pojedynczej proroczej części; można je tworzyć tylko na oryginalnym serwerze. Ignorowanie tych ograniczeń może prowadzić do poważnych konsekwencji bezpieczeństwa. |
| 306 |
W najnowszej wersji specyfikacji kod statusu 306 nie jest już używany. |
| 307 |
Żądany zasób jest obecnie tymczasowo dostępny z innego URI. Z powodu tymczasowego przekierowania klienci powinni nadal wysyłać przyszłe żądania do pierwotnego adresu. Tylko wtedy, gdy w Cache-Control lub Expires są wskazane, ta odpowiedź może być pamiętana w pamięci podręcznej. Nowy URI, powinny być zwracane w polu Location odpowiedzi. O ile nie jest to zapytanie HEAD, odpowiedź powinna zawierać hiperlink do nowego URI z krótkim opisem. Użytkownicy użytkowników powinni informować, że aplikacje usuwały czasami 307. Jeżeli to nie jest żądanie GET ani HEAD, to przeglądarka nie powinna automatycznie następować przekierowania, chyba że użytkownik to zatwierdzi, ponieważ dotyczące ich żądania mogą ulec zmianie. |
| 400 |
1. Semantyczny błąd; bieżące żądanie jest niezrozumiałe dla serwera. Klient nie powinien powtarzać tego żądania, o ile nie wprowadzą modyfikacji. 2. Złe parametry żądania. |
| 401 |
Bieżące żądanie wymaga autoryzacji użytkownika. Odpowiedź musi zawierać nagłówek WWW-Authenticate, który dotyczy żądanego zasobu, aby zapytać o informacje użytkownika. Klient może ponownie przesłać inne żądanie zawierające prawidłowy nagłówek Authorization. Jeżeli bieżące żądanie już zawierało dowód autoryzacji, to znaczy, że różnice w odpowiedzi 401 oznaczają tylko to, że serwer nie przyznaje jeszcze spożytkowania przez te dowody. Jeżeli odpowiedź 401 zawierało ten sam żądany nagłówek identyfikatora autoryzacji, a przeglądarka przynajmniej jeden raz próbowała potwierdzić, przeglądarka musi wyświetlić treść swojego podmiotu, bo jej element może zawierać istotne informacje dotyczące tego potwierdzenia. |
| 402 |
Ten kod statusu został zarezerwowany na przyszłe wrzenie. |
| 403 |
Serwer zrozumiał żądanie, ale odmawia jego realizacji. W przeciwieństwie do odpowiedzi 401, tutaj żadne zaufanie nie będzie pomocne, a to żądanie nie powinno być powtarzane. Jeżeli to nie jest żądanie HEAD, a serwer chce wyjaśnić, dlaczego żądanie nie może być zrealizowane, powinno zwrócić powód w treści. Oczywiście serwer może również zwrócić odpowiedź 404, jeżeli nie chce informować klienta o tej informacji. |
| 404 |
Żądanie nie zostało zrealizowane, ponieważ żądany zasób nie został znaleziony na tym serwerze. Nie ma informacji, aby poinformować użytkownika, czy ten status jest tymczasowy czy trwały. Jeżeli serwer zna sytuację, powinno użyć kodu 410, aby poinformować, że stary zasób nie jest już dostępny z powodu określonych problemów z konfiguracją wewnętrzną i nie ma żadnego dalszego linku do miejsca przeniesienia. Ten kod statusu 404 jest często stosowany, gdy serwer nie chce ujawniać, dlaczego żądanie zostało odrzucone lub w przypadku braku innych odpowiednich odpowiedzi. |
| 405 |
Metoda żądania określona w linii żądania nie może być użyta do odpowiedzenia na żądany zasób. Odpowiedź powinna zawierać nagłówek Allow, aby oddać listę metod żądań akceptowanych przez bieżący zasób. W związku z tym metody PUT i DELETE mogą być ustawiane w związku z zapisaniami do zasobów w serwerze, więc większość serwerów strony internetowej nie obsługuje tych metod lub co się najczęściej nie używa ze względu na domyślne ograniczenie. W przypadku żądań tych rodzajów powinny być 405. |
| 406 |
Proszona treść zasobu nie może spełniać wymagań warunków w nagłówku żądania i dlatego nie można wygenerować ciała odpowiedzi. Jeżeli to nie jest żądanie HEAD, odpowiedź powinna zwracać te subiekty spełniające odpowiednie formaty w niezawodnej formie podanej przez nagłówek Content-Type. Przeglądarka może podjąć najlepszą decyzję na podstawie formatu i dostępnych umiejętności. Specyfikacje jednak nie określają żadnych standardów do takich automatycznych wyborów. |
| 407 |
Podobnie jak w odpowiedzi 401, jedynie klient musi przejść weryfikację u serwera proxy. Serwer proxy musi zwrócić nagłówek Proxy-Authenticate, aby zadać pytanie o autoryzację. Klient może wysłać nagłówek Proxy-Authorization do weryfikacji. Zobacz RFC 2617. |
| 408 |
Przekroczenie czasu żądania. Klient nie uzupełnił wysyłania żądania w czasie, który serwer miał na myśli. Klient może ponownie przesłać to żądanie bez wprowadzania jakichkolwiek zmian. |
| 409 |
Nie można zakończyć żądania z powodu konfliktów z bieżącym stanem żądanego zasobu. Ten kod statusu można użyć tylko w sytuacjach, w których domniemywa się, że użytkownik może rozwiązać konflikt i ponownie złożyć nowe żądanie. Odpowiedź powinna zawierać wystarczające dane, aby użytkownik mógł zauważyć źródło konfliktu. Konflikty często wynikają z przetwarzania żądań PUT. Na przykład podczas weryfikacji wersji, jeśli pewna zmiana, na przykład PUT żądanie, zmienia wersję specyficznego zasobu na ścieżce, we wcześniejszych NAT-proszę przekazać poprzednio wstawione takie konflikty; wtedy można zwrócić błąd 409, aby poinformować użytkownika, że to żądanie nie może być ukończone. W odpowiedzi mogą nachodzić różnice między dwoma sprzecznymi wersjami, aby zezwolić użytkownikowi na nadanie nożówka. |
| 410 |
Żądany zasób nie jest dostępny na serwerze oraz nie ma żadnego znanego adresu do przekierowania. Taka sytuacja powinna być uznawana za trwałą. Jeśli to możliwe, klienci z montowanej wtyczki powinny usunąć wszystkie odniesienia do tego adresu, gdy uzyskują zgodę użytkownika. Jeśli serwer nie zna lub nie może wywnioskować tego stanu, powinien użyć kodu 404. Nie ma innych określonych wzorów, ale ogólnie zastosowano odpowiedzi 410. Odpowiedzi 410 są również w celu pomocy w utrzymaniu witryną, informując użytkowników, że dany zasób już nie jest dostępny, oraz że posiadacz serwera chce, aby wszystkie substytuty, które na ten zasób wiodą, zostały również usunięte. Tego rodzaju sytuacje są dość powszechne w ograniczonych zasobach lub sytuacji w której podawane mają być tylko zapisy. Ponadto 410 również zwraca wskazań, które były oryginalnie własnością zupełnie obcej.[/tr>
|
| 411 |
Serwer odmawia przyjęcia żądania, jeśli brak jest określonego nagłówka Content-Length. Klient może ponownie przesłać to żądanie po dodaniu walidującego nagłówka Content-Length. |
| 412 |
Serwer niespełnił jednego lub wielu świadczonych wymagań przy przetwarzaniu warunków podanych w nagłówkach żądania. Ten kod statusu pozwala klientom ustawić warunki określające dostawę identyfikatorów w odniesieniu do i mistrza uzyskania zasobów. |
| 413 |
Serwer odmawia przetwarzania bieżącego żądania ponieważ rozmiar danych podmiotu, jakie zostały przekazane, przekracza to, co serwer będzie w stanie zmieścić w swoich zakresach. W takim przypadku serwer może zamknąć połączenie, aby zapobiec dalszemu przesyłaniu tych żądań. Jeśli ten stan jest trwały, serwer powinien wskazać w odpowiedzi nagłówek Retry-After, aby powiadomić klienta o tym, w którym czasie mają ponownie spróbować. |
| 414 |
Długość żądania URI przekracza długość, którą serwer jest w stanie zrozumieć, dlatego serwer odmawia odpowiedzi na to żądanie. Taki stan jest rzadki, zwykle polega na: a) formularza, który powinien został zaprojektowany jako POST, zmieniając się w metodę GET, co prowadzi do zbyt długiego ciągu zapytania (Query String). b) wystąpienia puli gruntów np. przepisy do byłego ze zwracanym URI. c) klientów uderzających w pewne luki bezpieczeństwa na serwerach. Tego rodzaju serwery używają zmiennych długości wezwania w pamięci do obliczenia parametrów ich zapytań, które, po przekroczeniu określonej wartości, mogą wywołać zapisy panelem powyżej, co prowadzi do wywołania różnych komunikatów o błędzie POST. Serwery, które nie mają takich problemów, powinny zwracać kod statusu 414. |
| 415 |
Podczas obecnego procesu, używając żądanej metody i wymaganej treści, w żądaniu podano format, który nie będzie obsługiwany przez serwer, dlatego żądanie zostaje odrzucione. |
| 416 |
Jeśli żądanie zawierało nagłówek Range i wszelkie określone zakresy danych nie pokrywają się z innymi zakresami zasobów, na przykład jeżeli nie został wyznaczony nagłówek If-Range, serwer powinny zwrócić kod 416. Jeżeli użycie za jednym zamachem ranga wskakuje do bitych, które nie można powiązać z określoną wartością, lub jej postronny element musi być tam przed, serwer powinien wokół wygenerować tęgo wartość. |
| 417 |
Wymagania opisujące przyczyny żądania w oczekiwaniach niemożliwych do spełnienia lub serwer, który jest serwerem proxy, wykazuje żywe dowody, że pomiędzy oczekiwaną linią a sąsiednim węzłem tego zapytania. |
| 421 |
W odniesieniu do klienta, który znajduje się na etapie, serwer osiągnął liczbę maksymalną dozwolonych połączeń od swojej lokalizacji. Zazwyczaj występujący tutaj adres IP to adres Klient, który jest zgodny z adresem widocznym ze strony serwera (na przykład przez bramę lub proxy równolegle). Wtedy obliczania połączeń może obejmować więcej niż jeden użytkownik końcowy. |
| 422 |
Żądanie zostało skonstruowane poprawnie, ale z przyczyny błędnych synonimów i nie pociąga za sobą skutku dla serwera (RFC 4918 WebDAV). 423 Locked Zasób w zakluczeniu. |
| 424 |
Obecne zapytanie nie ciągnie możliwości funkcji z powodu błędów spowodowanych jakimiś przypadkowymi wezwaniami, takimi jak PROPPATCH (RFC 4918 WebDAV). |
| 425 |
Wyznaczone w podejściu do zasobów kolekcji schematu WebDav, ale nie zostały dodane do protokołu WebDAV (RFC 3658). |
| 426 |
Klient powinien przejść do TLS/1.0 (RFC 2817). |
| 449 |
Rozszerzone przez Microsoft, reprezentuje to, co klient powinien ponownie procedować po wykonaniu odpowiednich działań. |
| 500 |
Serwer napotkał nieoczekiwaną okoliczność, co spowodowało, że nie był w stanie zakończyć przekazywanego zapytania. Ogólnie rzecz biorąc, problem ten występuje, gdy program może pojawić się w wyniku błędu serwera. |
| 501 |
Serwer nie obsługuje jakiejś wymaganej funkcji do uzyskania bieżącego zapytania. Gdy serwer nie identyfikuje żądanej metody i nie może obsłużyć jej z natury. |
| 502 |
Jako brama lub serwer proxy próbujący zrealizować zapytanie ze skutkami otrzymanymi za pomocą niepoprawnych odpowiedzi z serwera źródłowego. |
| 503 |
Serwer jest obecnie niezdolny do przetworzenia zapytania z powodu tymczasowej konserwacji lub przeciążenia. Ten status jest tymczasowy, a serwer powinien reaktywować siebie w określonym czasie. Jeśli to możliwe, odpowiedź powinna zawierać nagłówek Retry-After, aby wskazać szacowany czas, w którym będą dostępne. Jeśli nie oznaczono tej informacji Retry-After, to klient powinien traktować go tak samo, jakby polegał na odpowiedzi 500. Należy jednak pamiętać, że unikanie kodu stanu 503 nie oznacza, że serwer powinien wykorzystywać tę metodę, gdy będzie obciążony. Niektóre serwery po prostu wymyśliły ścisłe ofiary dla klientów. |
| 504 |
Serwer, który pełni funkcję bramy lub pośrednika, próbuje wykonać żądania, ale nie otrzymuje odpowiedzi w czasowe powiązania z zapytaniem лидирующему serwer whoeverillery (URI, takie jak HTTP, FTP, LDAP) lub synerigwaną usługę (np. DNS). Należy zauważyć, że niektórzy serwery pośredniczące mogą zwracać błędy w kategoriach 400 lub 500 związanych z czasami przekroczenia w DNS. |
| 505 |
Serwer nie obsługuje lub odmawia wsparcia dla HD PDS w żądaniu. Co sugeruje, że serwer nie może lub nie zdecyduje się działać w podobny sposób, aby wykonać dany stan. Odpowiedź powinna zawierać opisy, co może być wymagane do wsparcia tej wersji i wszelkich innych pożądań. |
| 506 |
Rozszerzone przez "Transparentny protokół bez naszych meteorów" (RFC 2295) RPR, które reprezentują, że serwer ma duszoną koncepcję wewnętrzną warunków; został zaproszony ze względu na to, że wydany zasób stosowania w zamówieniach w tych warunkach nie spełnia wymogów wewnętrznych. |
| 507 |
Serwer nie jest w stanie przechować treści niezbędnej do zakończenia żądania. Stan ten uznaje się za tymczasowy (RFC 2418). |
| 509 |
Serwer osiągnął limit przepustowości. Nie jest to oficjalny kod statusu, ale jest nadal używany przez wielu serwerów. |
| 510 |
Polityki wymagane do uzyskania zasobów nie zostały spełnione (RFC 2774). |