HTTP
Odpowiedzi HTTP

Android Angular 2 AngularJS C# Language HTML Java Language JavaScript Node.js PHP Python Language
Szukaj…


Parametry

Kod statusu Powód-wyrażenie - opis
100 Kontynuuj - klient powinien wysłać następującą część żądania wieloczęściowego.
101 Przełączanie protokołów - serwer zmienia wersję lub typ protokołu używanego w tej komunikacji.
200 OK - serwer otrzymał i zrealizował żądanie klienta.
201 Utworzono - serwer zaakceptował żądanie i utworzył nowy zasób, który jest dostępny pod identyfikatorem URI w nagłówku Location .
202 Zaakceptowano - serwer otrzymał i zaakceptował żądanie klienta, ale jeszcze się nie rozpoczął lub nie zakończył przetwarzania.
203 Informacje nieautorytatywne - serwer zwraca dane, które mogą być pod- lub nadzbiorem informacji dostępnych na oryginalnym serwerze. Używany głównie przez proxy.
204 Brak treści - używany zamiast 200 (OK), gdy nie ma treści dla odpowiedzi.
205 Resetuj zawartość - identycznie jak 204 (bez zawartości), ale klient powinien ponownie załadować widok aktywnego dokumentu.
206 Częściowa treść - używana zamiast 200 (OK), gdy klient zażądał nagłówka Range .
300 Wiele wyborów - żądany zasób jest dostępny pod wieloma identyfikatorami URI, a klient powinien przekierować żądanie do identyfikatora URI określonego na liście w treści wiadomości.
301 Przeniesiony na stałe - żądany zasób nie jest już dostępny przy tym URI, a klient powinien przekierować to i wszystkie przyszłe żądania do URI określonego w nagłówku Location .
302 Znaleziono - zasób tymczasowo znajduje się pod innym identyfikatorem URI. To żądanie powinno zostać przekierowane po potwierdzeniu przez użytkownika do identyfikatora URI w nagłówku Location , ale przyszłych żądań nie należy zmieniać.
303 Zobacz Inne - bardzo podobny do 302 (Znaleziono), ale nie wymaga danych wejściowych użytkownika, aby przekierować do podanego identyfikatora URI. Podany identyfikator URI powinien zostać pobrany za pomocą żądania GET.
304 Nie zmodyfikowano - klient wysłał nagłówek If-Modified-Since lub podobny, a zasób nie został zmodyfikowany od tego momentu; klient powinien wyświetlić buforowaną kopię zasobu.
305 Użyj serwera proxy - żądanego zasobu należy ponownie zażądać za pośrednictwem serwera proxy określonego w polu nagłówka Location .
307 Tymczasowe przekierowanie - identyczne jak 302 (znaleziono), ale klienci HTTP 1.0 nie obsługują 307 odpowiedzi.
400 Złe żądanie - klient wysłał źle sformułowane żądanie zawierające błędy składniowe i powinien je zmodyfikować, aby to poprawić przed powtórzeniem.
401 Nieautoryzowany - żądany zasób nie jest dostępny bez uwierzytelnienia. Klient może powtórzyć żądanie za pomocą nagłówka Authorization aby podać szczegóły uwierzytelnienia.
402 Wymagana płatność - zastrzeżony, nieokreślony kod stanu do użytku przez aplikacje wymagające subskrypcji użytkownika do przeglądania treści.
403 Zabronione - serwer rozumie żądanie, ale odmawia jego spełnienia z powodu istniejących kontroli dostępu. Żądanie nie powinno być powtarzane.
404 Nie znaleziono - brak dostępnych zasobów na tym serwerze, które pasowałyby do żądanego identyfikatora URI. Można użyć zamiast 403, aby uniknąć ujawnienia szczegółów kontroli dostępu.
405 Metoda niedozwolona - zasób nie obsługuje metody żądania (czasownik HTTP); nagłówek Allow zawiera listę dopuszczalnych metod żądania.
406 Niedopuszczalne - zasób ma cechy, które naruszają akceptowalne nagłówki wysłane w żądaniu.
407 Wymagane uwierzytelnienie proxy - podobne do 401 (nieautoryzowane), ale wskazuje, że klient musi najpierw uwierzytelnić się za pomocą pośredniego proxy.
408 Limit czasu żądania - serwer oczekiwał kolejnego żądania od klienta, ale żadne nie zostało dostarczone w dopuszczalnym terminie.
409 Konflikt - nie można ukończyć żądania, ponieważ było w konflikcie z bieżącym stanem zasobu.
410 Minął - podobnie jak 404 (Nie znaleziono), ale wskazuje na trwałe usunięcie. Brak adresu do przekazania.
411 Wymagana długość - klient nie określił prawidłowego nagłówka Content-Length i musi to zrobić, zanim serwer zaakceptuje to żądanie.
412 Warunek wstępny nie powiódł się - zasób nie jest dostępny we wszystkich warunkach określonych przez nagłówki warunkowe wysłane przez klienta.
413 Żądanie jednostki jest zbyt duże - serwer nie jest obecnie w stanie przetworzyć treści wiadomości o długości wysłanej przez klienta.
414 Żądanie URI zbyt długo - serwer odrzuca żądanie, ponieważ URI żądania jest dłuższy niż serwer jest skłonny zinterpretować.
415 Nieobsługiwany typ nośnika - serwer nie obsługuje MIME lub typu nośnika określonego przez klienta i nie może obsłużyć tego żądania.
416 Żądany zakres jest niezadowalający - klient zażądał zakresu bajtów, ale serwer nie może dostarczyć treści zgodnej z tą specyfikacją.
417 Oczekiwanie nie powiodło się - klient określił ograniczenia w nagłówku Expect , których serwer nie może spełnić.
500 Internal Server Error - serwer spełnił nieoczekiwany warunek lub błąd, który uniemożliwia mu wykonanie tego żądania.
501 Nie zaimplementowano - serwer nie obsługuje funkcji wymaganych do wykonania żądania. Zwykle używany do wskazania metody żądania, która nie jest obsługiwana w żadnym zasobie.
502 Bad Gateway - serwer jest serwerem proxy i otrzymał niepoprawną odpowiedź od serwera nadrzędnego podczas przetwarzania tego żądania.
503 Usługa niedostępna - serwer jest obciążony lub przechodzi konserwację i obecnie nie jest w stanie obsłużyć tego żądania.
504 Limit czasu bramy - serwer jest serwerem proxy i nie otrzymał odpowiedzi od serwera nadrzędnego w odpowiednim czasie.
505 Wersja HTTP nieobsługiwana - serwer nie obsługuje wersji protokołu HTTP, za pomocą której klient wysłał żądanie.

Podstawowy format odpowiedzi

Gdy serwer HTTP odbiera poprawnie sformułowane żądanie HTTP , musi przetworzyć informacje, które zawiera żądanie, i zwrócić odpowiedź klientowi. Prosta odpowiedź HTTP 1.1, może wyglądać jak poniżej, zwykle z pewną liczbą pól nagłówka i ewentualnie treścią odpowiedzi: 

HTTP/1.1 200 OK \r\n

HTTP/1.1 404 Not Found \r\n

HTTP/1.1 503 Service Unavailable \r\n

Prosta odpowiedź HTTP 1.1 ma następujący format: 

HTTP-Version Status-Code Reason-Phrase CRLF

Podobnie jak w żądaniu, HTTP-Version wskazuje wersję używanego protokołu HTTP; dla HTTP 1.1 musi to być zawsze ciąg HTTP/1.1 .

Status-Code to trzycyfrowy kod wskazujący status żądania klienta. Pierwszą cyfrą tego kodu jest klasa statusu , która umieszcza kod statusu w jednej z 5 kategorii odpowiedzi [1] :

  • 1xx Informacyjny - serwer otrzymał żądanie i przetwarzanie jest kontynuowane
  • 2xx Sukces - serwer zaakceptował i przetworzył żądanie
  • 3xx Przekierowanie - konieczne jest dalsze działanie ze strony klienta, aby zrealizować żądanie
  • 4xx Błędy klienta - klient wysłał żądanie, które było źle sformułowane lub nie może zostać spełnione
  • 5xx Błędy serwera - żądanie było prawidłowe, ale serwer nie może go obecnie spełnić

Reason-Phrase to krótki opis kodu stanu. Na przykład kod 200 ma frazę przyczyny OK ; kod 404 zawiera frazę Not Found . Pełna lista fraz przyczyny jest dostępna w parametrach poniżej lub w specyfikacji HTTP .

Linia kończy się znakiem powrotu karetki - linia przesuwu linii, zwykle reprezentowana przez \r\n .

Dodatkowe nagłówki

Podobnie jak żądanie HTTP, odpowiedź HTTP może zawierać dodatkowe nagłówki w celu zmodyfikowania lub rozszerzenia dostarczonej odpowiedzi.

Pełna lista dostępnych nagłówków jest zdefiniowana w § 6.2 specyfikacji . Najczęściej używane nagłówki to:

  • Server , który działa jak nagłówek żądania User-Agent dla serwera;
  • Location , która jest używana w odpowiedziach o statusie 201 i 3xx w celu wskazania identyfikatora URI, na który należy przekierować; i
  • ETag , który jest unikalnym identyfikatorem tej wersji zwracanego zasobu, umożliwiającym klientom buforowanie odpowiedzi.

Nagłówki odpowiedzi pojawiają się za linią statusu i podobnie jak nagłówki żądania są tworzone w ten sposób: 

Name: Value CRLF

Name zapewnia nazwę nagłówka, taką jak ETag lub Location , a Value określa wartość, którą serwer ustawia dla tego nagłówka. Linia kończy się na CRLF.

Odpowiedź z nagłówkami może wyglądać następująco: 

HTTP/1.1 201 Created \r\n
Server: WEBrick/1.3.1 \r\n
Location: http://example.com/files/129742 \r\n

Organy wiadomości

Podobnie jak w przypadku treści żądania , odpowiedzi HTTP mogą zawierać treść wiadomości. Zapewnia to dodatkowe dane, które klient będzie przetwarzał. W szczególności 200 odpowiedzi OK na poprawnie sformułowane żądanie GET powinno zawsze zawierać treść wiadomości zawierającą żądane dane. (Jeśli nie, 204 No Content jest bardziej odpowiednią odpowiedzią).

Treść wiadomości jest zawarta po wszystkich nagłówkach i podwójnym CRLF. W przypadku żądań należy podać jego długość w bajtach z nagłówkiem Content-Length . Dlatego pomyślna odpowiedź na żądanie GET może wyglądać następująco: 

HTTP/1.1 200 OK\r\n
Server: WEBrick/1.3.1\r\n
Content-Length: 39\r\n
ETag: 4f7e2ed02b836f60716a7a3227e2b5bda7ee12c53be282a5459d7851c2b4fdfd\r\n
\r\n
Nobody expects the Spanish Inquisition.


Modified text is an extract of the original Stack Overflow Documentation
Licencjonowany na podstawie CC BY-SA 3.0
Nie związany z Stack Overflow