webmastertoolbag.com

Online tools Web school 在线工具 基础教程 菜鸟教程 编程学习 Web 学校
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: