| Kod statusu HTTP | Kod statusu 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 komunikatu Upgrade, aby użył innego protokołu do ukończenia żądania. Po wysłaniu ostatniej pustej linii tej odpowiedzi serwer przełączy się na protokoły zdefiniowane w nagłówku komunikatu 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 jest bardziej korzystne niż na starszą wersję lub przejście na protokół czasu rzeczywistego i synchroniczny w celu dostarczenia zasobów, które wykorzystują takie funkcje. |
| 102 | Kody statusu, rozszerzone przez WebDAV (RFC 2518), oznaczają, że przetwarzanie będzie kontynuowane. |
| 200 | Żądanie powiodło się, a nagłówek odpowiedzi lub treść danych żądanych przez żądanie zostaną zwrócone wraz z tą odpowiedzią. |
| 201 | Żądanie zostało spełnione i nowy zasób został utworzony zgodnie z żądaniem, a jego identyfikator URI został zwrócony wraz z nagłówkiem Location. Jeśli wymagany zasób nie może zostać utworzony na czas, powinien zostać zwrócony komunikat "202 Accepted". |
| 202 | Serwer zaakceptował żądanie, ale jeszcze go nie przetworzył. Podobnie jak może zostać odrzucone, ostatecznie żądanie może zostać wykonane lub nie. W kontekście operacji asynchronicznych nie ma nic wygodniejszego niż wysłanie tego kodu statusu. Celem zwracania odpowiedzi z kodem stanu 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 połączenia klienta z serwerem do czasu pełnego 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 oryginalnej wersji. Na przykład metadane zawierające zasoby mogą spowodować, że oryginalny serwer będzie znał super meta-informacje. Użycie tego kodu stanu nie jest wymagane i jest odpowiednie 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 takie nagłówki istnieją, powinny one 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 widoku dokumentu, mimo że zgodnie ze specyfikacją nowe lub zaktualizowane metainformacje POWINNY 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 przetworzył żądanie i nic nie zwrócił. Jednak w przeciwieństwie do odpowiedzi 204, odpowiedź, która zwraca ten kod stanu, prosi żądającego o zresetowanie widoku dokumentu. Ta odpowiedź jest przede wszystkim używana 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 dokumentu na wiele segmentów pobierania 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 treści zwróconej w tej odpowiedzi; w przypadku pobierania wielu segmentów z typem zawartości multipart/byteranges, każdy segment wieloczęściowy powinien zawierać pole Content-Range wskazujące zakres treści w tym segmencie. Jeśli odpowiedź zawiera Content-Length, jego wartość musi być zgodna z rzeczywistą liczbą bajtów w zwracanym zakresie zawartości. date 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 innych odpowiedzi z tymi samymi zmiennymi. Expires, Cache-Control i/lub Vary, jeśli ich wartości mogą różnić się od wartości innych poprzednich odpowiedzi dla tych samych zmiennych. 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 buforowaną zawartością 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 we wszystkich 200 odpowiedziach, które powinny zostać zwrócone. Jeśli nagłówki ETag lub Last-Modified nie pasują dokładnie, pamięć podręczna po stronie klienta POWINNA zabraniać łączenia 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 | Kod statusu, rozszerzony przez WebDAV (RFC 2518), oznacza, że kolejna treść wiadomości będzie komunikatem XML i może zawierać serię oddzielnych kodów odpowiedzi, w zależności od liczby poprzednich podprośb. |
| 300 | Żądany zasób ma szereg alternatywnych komunikatów zwrotnych, z których każdy ma swój własny adres i informacje negocjacyjne zależne od przeglądarki. Użytkownik lub przeglądarka może samodzielnie wybrać preferowany adres przekierowania. 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 encji 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ć takiego automatycznego wyboru. Jeśli sam serwer ma już preferowany wybór zwrotu, to URI tego zwrotu powinien być określony w Location; przeglądarka może użyć tej wartości Location jako adresu do automatycznego przekierowania. Ponadto ta odpowiedź jest również buforowana, 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. 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. 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 przy przekierowaniu, 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, aby wyjaśnić, 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 alternatywnym odniesieniem do oryginalnego zasobu. Zabronione jest również buforowanie odpowiedzi 303. 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 wersjami HTTP/1.1 nie rozumie poprawnie stanu 303. Jeśli należy rozważyć interakcję z tymi przeglądarkami, kod stanu 302 powinien załatwić sprawę, ponieważ większość przeglądarek przetwarza odpowiedzi 302 dokładnie w taki sam sposób, w jaki powyższa specyfikacja wymaga od klienta przetwarzania odpowiedzi 303. |
| 304 | Serwer POWINIEN zwrócić ten kod stanu, jeśli klient wysyła warunkowe żądanie GET, które zostało dozwolone, a zawartość dokumentu (od ostatniej wizyty lub zgodnie z warunkami żądania) nie uległa zmianie.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 nagłówki: Data, chyba że serwer nie ma zegara. Jeśli serwer bez zegara przestrzega tych zasad, wówczas serwer proxy i klient mogą samodzielnie dodać pole Date do nagłówka odpowiedzi przychodzącej (jak określono w RFC 2068), a mechanizm buforowania będzie działał poprawnie.ETag i/lub Content-Location, jeśli to samo żądanie zwróciłoby odpowiedź 200.Expires Expires, Cache-Control i/lub Vary, jeśli wartość może różnić się od wartości odpowiadającej innym poprzednim odpowiedziom dla tej samej zmiennej. Jeśli to żądanie odpowiedzi wykorzystuje silną walidację pamięci podręcznej, wówczas ta odpowiedź nie powinna zawierać innych nagłówków encji; w przeciwnym razie (np. warunkowe żądanie GET wykorzystuje słabą walidację pamięci podręcznej), ta odpowiedź nie może zawierać innych 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 zawiera informacje o identyfikatorze URI, w którym znajduje się określony serwer proxy. 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 oryginalny serwer. 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 | Żądany zasób tymczasowo odpowiada na żądanie z innego URI. Ponieważ takie przekierowania są 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, należy dodać powyższe informacje, 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) Wystąpił błąd semantyczny i bieżące żądanie nie może zostać zrozumiane przez serwer. O ile nie zostanie to zmodyfikowane, klient nie powinien wielokrotnie przesyłać tego żą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 wielokrotnie przesłać żądanie zawierające odpowiednie informacje nagłówka Authorization. Jeśli bieżące żądanie zawiera już poświadczenia Autoryzacji, wówczas 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ż próbę uwierzytelnienia co najmniej raz, przeglądarka POWINNA przedstawić 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 to żądanie nie powinno być ponownie przesyłane. Jeśli nie jest to żądanie HEAD i serwer chce być w stanie jasno 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 przekazywać klientowi żadnych informacji. |
| 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ć użytkownika, ż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 jest dostępna żadna inna odpowiednia odpowiedź. |
| 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. Biorąc pod uwagę, że metody PUT i DELETE zapisują do zasobu na serwerze, większość serwerów internetowych nie obsługuje tych metod żądań 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ę zawierającą listę cech encji i adresów, z których użytkownik lub przeglądarka może wybrać najbardziej odpowiednią. Format encji jest określony przez typ nośnika zdefiniowany w nagłówku Content-Type. Przeglądarki mogą dokonywać własnych najlepszych wyborów 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 tym wyjątkiem, ż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-Authorization w celu uwierzytelnienia. Patrz RFC 2617. |
| 408 | Limit czasu żądania. Klient nie zakończył wysyłania żą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 zazwyczaj występują podczas przetwarzania żądań PUT. Na przykład w środowisku sprawdzania wersji, jeśli informacje o wersji dołączone do PUT przesłanego w celu modyfikacji określonego zasobu są sprzeczne z poprzednim żądaniem (strony trzeciej), serwer 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ą wersję po scaleniu. |
| 410 | Żądany zasób nie jest już dostępny na serwerze i nie ma żadnego znanego adresu przekierowania. Taki stan należy uznać za trwały. 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 ten stan jest trwały, należy użyć kodu stanu 404. O ile nie zaznaczono inaczej, odpowiedź ta może być przechowywana w pamięci podręcznej.410 Celem tej odpowiedzi 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 tym 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 klientów, że zasób, który pierwotnie należał do osoby na bieżącej stronie serwera, nie jest już dostępny. Oczywiście to od właściciela serwera zależy, czy wszystkie trwale niedostępne zasoby muszą być oznaczone jako "410 Gone" i jak długo takie oznaczenie musi być utrzymywane. |
| 411 | Serwer odmawia przyjmowania żądań bez zdefiniowanego nagłówka Content-Length. Po dodaniu prawidłowego nagłówka Content-Length wskazującego długość treści żądania, klient może przesłać żądanie ponownie. |
| 412 | Serwer nie spełnił jednego lub więcej warunków wstępnych podczas sprawdzania, czy zostały one podane w polu nagłówka żądania. Ten kod stanu umożliwia klientowi ustawienie warunków wstępnych w metakomunikacie żą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 dane encji o rozmiarze większym niż serwer chce lub może obsłużyć. W takim przypadku serwer może zamknąć połączenie, aby uniemożliwić klientowi dalsze wysyłanie tego żądania. Jeśli ten warunek jest tymczasowy, serwer powinien zwrócić nagłówek odpowiedzi Retry-After, aby poinformować klienta, po jakim czasie może ponowić próbę. |
| 414 | Długość URI żądania przekracza długość, którą serwer może zinterpretować, więc serwer odmawia obsługi żądania. Jest to rzadkie i często 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 przy każdym przekierowaniu, 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 identyfikatorem URI żądania, a gdy parametry po GET przekraczają określoną wartość, może wystąpić przepełnienie bufora, prowadzące do wykonania dowolnego kodu [1]. Serwery bez takich luk powinny zwracać kod stanu 414. |
| 415 | W przypadku aktualnie żądanej metody i żądanego zasobu jednostka przesłana w żądaniu nie jest w formacie obsługiwanym przez serwer, więc żą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 nagłówek żądania If-Range nie jest zdefiniowany w żądaniu, serwer powinien zwrócić kod stanu 416. Jeśli Range używa zakresów bajtowych, ma to miejsce w przypadku, gdy pierwsza pozycja bajtowa 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 ten 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, na którym znajduje się bieżący klient, 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 liczba połączeń może obejmować więcej niż jednego użytkownika końcowego. |
| 422 | 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 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ć, ponieważ zawierało błędy semantyczne. (RFC 4918 WebDAV) 423 Zablokowany Bieżący zasób jest zablokowany. (RFC 4918 WebDAV) |
| 424 | Bieżące żądanie nie powiodło się z powodu błędu, który wystąpił 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ł nieoczekiwany 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 określonej funkcji, która jest wymagana dla bieżącego żądania. Gdy serwer nie jest w stanie rozpoznać żądanej metody i nie jest w stanie obsłużyć żądania dotyczącego jakiegokolwiek zasobu. |
| 502 | Serwer działający jako brama lub serwer proxy otrzymuje nieprawidłową odpowiedź z 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żywania samego siebie w przezroczystych negocjacjach treści, 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 niespełnione. (RFC 2774) |