HTTP
Żądania HTTP
Szukaj…
Parametry
Metoda HTTP | Cel, powód |
---|---|
OPTIONS | Pobierz informacje o opcjach komunikacji (dostępne metody i nagłówki) dostępnych dla określonego identyfikatora URI żądania. |
GET | Pobierz dane zidentyfikowane przez identyfikator URI żądania lub dane wygenerowane przez skrypt dostępny w identyfikatorze URI żądania. |
HEAD | Identyczne z GET z wyjątkiem tego, że serwer nie zwróci treści wiadomości: tylko nagłówki. |
POST | Prześlij blok danych (określony w treści wiadomości) na serwer w celu dodania do zasobu określonego w identyfikatorze URI żądania. Najczęściej używany do przetwarzania formularzy. |
PUT | Przechowuj załączone informacje (w treści wiadomości) jako nowy lub zaktualizowany zasób pod danym identyfikatorem URI żądania. |
DELETE | Usuń zasób wskazany przez identyfikator URI żądania lub ustaw kolejkę do usunięcia. |
TRACE | Zasadniczo polecenie echa: działający, zgodny serwer HTTP musi odesłać całe żądanie z powrotem jako treść odpowiedzi 200 (OK). |
Uwagi
Metoda CONNECT
jest zarezerwowana w specyfikacji definicji metody do użytku z serwerami proxy, które są w stanie przełączać się między trybami proxy i tunelowania (np. Dla tunelowania SSL).
Ręczne wysyłanie minimalnego żądania HTTP za pomocą usługi Telnet
Ten przykład pokazuje, że HTTP jest tekstowym protokołem komunikacji internetowej i pokazuje podstawowe żądanie HTTP oraz odpowiednią odpowiedź HTTP.
Za pomocą usługi Telnet można ręcznie wysłać minimalne żądanie HTTP z wiersza polecenia w następujący sposób.
Rozpocznij sesję Telnet na serwerze internetowym
www.example.org
na porcie 80:telnet www.example.org 80
Raporty Telnet, że masz połączenie z serwerem:
Connected to www.example.org. Escape character is '^]'.
Wprowadź wiersz żądania, aby wysłać ścieżkę adresu URL żądania GET
/
, używając HTTP 1.1GET / HTTP/1.1
Wprowadź wiersz pola nagłówka HTTP, aby zidentyfikować część nazwy hosta wymaganego adresu URL, który jest wymagany w HTTP 1.1
Host: www.example.org
Wpisz pusty wiersz, aby zakończyć żądanie.
Serwer WWW wysyła odpowiedź HTTP, która pojawia się w sesji Telnet.
Pełna sesja wygląda następująco. Pierwszy wiersz odpowiedzi to wiersz stanu HTTP , który zawiera kod stanu 200 i tekst statusu OK , co wskazuje, że żądanie zostało pomyślnie przetworzone. Po tym następuje szereg pól nagłówka HTTP, pusta linia i odpowiedź HTML.
$ telnet www.example.org 80
Trying 2606:2800:220:1:248:1893:25c8:1946...
Connected to www.example.org.
Escape character is '^]'.
GET / HTTP/1.1
Host: www.example.org
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=604800
Content-Type: text/html
Date: Thu, 21 Jul 2016 15:56:05 GMT
Etag: "359670651"
Expires: Thu, 28 Jul 2016 15:56:05 GMT
Last-Modified: Fri, 09 Aug 2013 23:54:35 GMT
Server: ECS (lga/1318)
Vary: Accept-Encoding
X-Cache: HIT
x-ec-custom-error: 1
Content-Length: 1270
<!doctype html>
<html>
<head>
<title>Example Domain</title>
<meta charset="utf-8" />
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
</head>
<body>
<div>
<h1>Example Domain</h1>
<p>This domain is established to be used for illustrative examples in documents. You may use this
domain in examples without prior coordination or asking for permission.</p>
<p><a href="http://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>
(dla zwięzłości usunięto element style
i puste linie z odpowiedzi HTML).
Podstawowy format zapytania
W HTTP 1.1 minimalne żądanie HTTP składa się z wiersza żądania i nagłówka Host
:
GET /search HTTP/1.1 \r\n
Host: google.com \r\n
\r\n
Pierwszy wiersz ma ten format:
Method Request-URI HTTP-Version CRLF
Method
powinna być prawidłową metodą HTTP; jeden z [1] [2] :
-
OPTIONS
-
GET
-
HEAD
-
POST
-
PUT
-
DELETE
-
PATCH
-
TRACE
-
CONNECT
Request-URI
wskazuje identyfikator URI lub ścieżkę do zasobu, którego żąda klient. Może to być:
- w pełni kwalifikowany identyfikator URI, w tym schemat, host, (opcjonalnie) port i ścieżka; lub
- ścieżka, w którym to przypadku host musi zostać określony w nagłówku
Host
HTTP-Version
wskazuje wersję protokołu HTTP, z którego korzysta klient. W przypadku żądań HTTP 1.1 musi to być zawsze HTTP/1.1
.
Wiersz żądania kończy się znakiem powrotu karetki - przesunięcie wiersza, zwykle reprezentowane przez \r\n
.
Poproś o pola nagłówka
Pola nagłówka (zwykle zwane po prostu „nagłówkami”) można dodać do żądania HTTP, aby dostarczyć dodatkowe informacje wraz z żądaniem. Nagłówek ma semantykę podobną do parametrów przekazywanych do metody w dowolnym języku programowania, który obsługuje takie rzeczy.
Żądanie z nagłówkami Host
, User-Agent
i Referer
może wyglądać następująco:
GET /search HTTP/1.1 \r\n
Host: google.com \r\n
User-Agent: Chrome/54.0.2803.1 \r\n
Referer: http://google.com/ \r\n
\r\n
Pełna lista obsługiwanych nagłówków żądań HTTP 1.1 znajduje się w specyfikacji . Najczęstsze to:
-
Host
- część nazwy hosta adresu URL żądania (wymagana w HTTP / 1.1) -
User-Agent
- ciąg znaków reprezentujący żądającego klienta użytkownika; -
Referer
- identyfikator URI, z którego odsyłano klienta; i -
If-Modified-Since
- podaje datę, której serwer może użyć, aby ustalić, czy zasób się zmienił, i wskazać, że klient może użyć kopii w pamięci podręcznej, jeśli tak się nie stało.
Nagłówek powinien zostać utworzony jako Name: Value CRLF
. Name
to nazwa nagłówka, na przykład User-Agent
. Value
to przypisane do niej dane, a wiersz powinien kończyć się CRLF. Nazwy nagłówków nie rozróżniają wielkości liter i mogą używać tylko liter, cyfr i znaków !#$%&'*+-.^_`|~
(Sekcja RFC7230 3.2.6 Składniki wartości pola ).
Referer
nazwa pola nagłówka jest literówka dla „polecający”, wprowadzone przypadkowo w RFC1945 .
Treść wiadomości
Niektóre żądania HTTP mogą zawierać treść wiadomości. Są to dodatkowe dane, które serwer wykorzysta do przetworzenia żądania. Treści wiadomości są najczęściej używane w żądaniach POST lub PATCH i PUT, aby dostarczyć nowe dane, które serwer powinien zastosować do zasobu.
Żądania zawierające treść komunikatu powinny zawsze zawierać jego długość w bajtach z nagłówkiem Content-Length
.
Treść wiadomości jest zawarta po wszystkich nagłówkach i podwójnym CRLF. Przykładowe żądanie PUT z treścią może wyglądać następująco:
PUT /files/129742 HTTP/1.1\r\n
Host: example.com\r\n
User-Agent: Chrome/54.0.2803.1\r\n
Content-Length: 202\r\n
\r\n
This is a message body. All content in this message body should be stored under the
/files/129742 path, as specified by the PUT specification. The message body does
not have to be terminated with CRLF.
Żądania HEAD
i TRACE
nie mogą zawierać treści wiadomości.