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.

  1. 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 '^]'.
    
  1. Wprowadź wiersz żądania, aby wysłać ścieżkę adresu URL żądania GET / , używając HTTP 1.1

    GET / HTTP/1.1
    
  2. 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
    
  3. 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.



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