Cztery najważniejsze żądania HTTP

Protokół transferu dokumentów hipertekstowych (HTTP) jest podstawowym protokołem komunikacyjnym wykorzystywanym przez przeglądarki w interakcjach z serwerami WWW. Odnosząc się do modelu klient-serwer, należy stwierdzić, że przeglądarka jest w tym przypadku klientem, który kontaktuje się z serwerem dzięki nazwie tegoż serwera, zapisanej w adresie URL. Większość adresów URL zawiera bezpośrednie odniesienie do protokołu HTTP (w sekcji http://). Niemniej pominięcie specyfikatora protokołu powoduje automatyczne przyjęcie, że odwołanie dotyczy http.
Oto kilka cech protokołu HTTP:
  • Bazuje na tekstowych komunikatach sterujących.
  • Umożliwia przekazywanie binarnych plików z danymi.
  • Umożliwia pobieranie danych z serwera i przesyłanie danych do serwera.
  • Uwzględnia mechanizmy buforowania danych.
Po ustanowieniu połączenia przeglądarka wysyła do serwera żądanie HTTP. Cztery podstawowe rodzaje żądań HTTP zostały przedstawione w tabelce 1. u dołu

Tabelka 1. Cztery najważniejsze żądania HTTP.

Żądanie Opis
GET Żądanie dostarczenia dokumentu. Serwer odpowiada, odsyłając kod statusu oraz kopię samego dokumentu.
HEAD Żądanie dostarczenia informacji statusowych. Serwer odsyła kod statusu, ale bez dołączania kopii dokumentu.
POST Przesłanie danych do serwera. Serwer dodaje przesłane dane do wskazanego elementu (na przykład wpis do listy komunikatów).
PUT Przesłanie danych do serwera. Serwer wykorzystuje dostarczone informacje do zastąpienia określonego elementu (tj. nadpisuje wcześniejsze dane).

Najczęściej wykorzystywaną formą interakcji jest żądanie dostarczenia strony do przeglądarki. W ramach ustanowionego wcześniej połączenia przeglądarka wysyła żądanie GET, na które serwer odpowiada, odsyłając nagłówek, pusty wiersz oraz treść wskazanego dokumentu. Zgodnie ze standardem HTTP żądanie oraz nagłówek mają format informacji tekstowej . Składnia żądania GET jest następująca:


GET / dokument wersja CRLF

Ciąg dokument wskazuje plik do pobrania z serwera (którego nazwa jest zawarta w adresie URL). Element wersja odpowiada wersji protokołu (zazwyczaj HTT P/1 . o lub HTTP/1.1). Natomiast człon CRLF symbolizuje dwa znaki ASCII - powrotu na początek wiersza (ang. carriage return) oraz zmiany wiersza (ang. linefeed) - wyznaczające koniec wiersza tekstowego.
Informacja o wersji jest bardzo ważna, ponieważ pozwala na zachowanie zgodności z wcześniejszymi implementacjami protokołu HTTP. Na przykład gdy przeglądarka obsługująca starszą wersję protokołu komunikuje się z nowszym serwerem, serwer przełącza się na starszą wersję protokołu i dostosowuje odpowiednio generowane odpowiedzi. Podsumowując:

Korzystając z protokołu HTTP, przeglądarki dostarczają informację na temat obsługiwanej wersji protokołu, dzięki czemu serwer może wybrać najwyższą wersję zaimplementowaną po obydwu stronach.

Pierwszy wiersz odpowiedzi zawiera kod statusu, który informuje przeglądarkę o tym, czy serwer przetworzył żądanie. Jeśli żądanie zostało błędnie sformatowane lub żądany element nie jest dostępny, kod statusu wskaże zaistniały problem. Na przykład jeśli wymieniony w żądaniu plik nie jest dostępny, serwer odeśle kod o wartości 404 (wartość ta jest zdefiniowana w standardzie HTTP). W przypadku odebrania poprawnego żądania serwer odsyła kod statusowy 200. Pozostałe wiersze nagłówka zawierają dodatkowe informacje na temat pobieranego elementu (rozmiar, czas ostatniej modyfikacji oraz typ zawartości). Ogólny format nagłówka odpowiedzi został przedstawiony w tabelce 1.

HTTP/1.0 kod_statusu tekst_statusu CRLF
Server: identyfikator_serwera CRLF
Last-Modified: data_modyfikacji_dokumentu CRLF
Content-Length: rozmiar_danych CRLF
Content-Type: typ_danych CRLF
CRLF

Tabelka 1. Ogólny format nagłówka odpowiedzi.

Pole kod_ statusu jest przeznaczone na wartość liczbową zapisaną w formie tekstowej. Z kolei tekst_statusu to odpowiadające tej wartości tekstowe wyjaśnienie znaczenia kodu. W tabeli 2. zamieszczony został wykaz najczęściej przesyłanych kodów i ich wersji tekstowych wraz z wyjaśnieniem. Element identyfikator_serwera zawiera tekstowy opis serwera (łatwy do zapamiętania przez człowieka), zazwyczaj odpowiadający jego nazwie domenowej . Wartość rozmiar_danych w nagłówku Content - Length określa rozmiar zasadniczej treści przekazywanego dokumentu liczony w bajtach. Pole typ_ danych przechowuje wartość tekstową stanowiącą dla przeglądarki informację o tym, jakiego rodzaju treść jest przekazywana. Wartość pola składa się z dwóch elementów rozdzielonych znakiem ukośnika - typu dokumentu oraz jego reprezentacji. Na przykład podczas przekazywania strony HTML pole to zawiera ciąg text /html. Natomiast w przypadku przesyłania pliku jpeg typ dokumentu jest określany jako image / jpeg.

Tabela 2. Przykłady kodów statusowych protokołu HTTP.

Kod statusu Tekst statusu Opis
200 OK Poprawne żądanie
400 Bad Request Błędne żądanie
404 Not Found Brak dokumentu

Na rysunku 2. przedstawiono przykładową odpowiedź serwera WWW Apache. Żądanym dokumentem był plik tekstowy składający się z 24 znaków (zliczane są znaki To jest strona testowa. oraz znak nowego wiersza). Mimo że żądanie zostało dostarczone w wersji HTTP 1.0, odpowiedź serwera została wygenerowana zgodnie z protokołem HTTP 1.1 , ponieważ taka wersj a jest obsługiwana przez serwer. Wynikiem jest dziewięć wierszy nagłówkowych, jeden pusty wiersz oraz zasadnicza treść pliku.

HTTP/1.1 200 OK
Date: Sat, 15 Mar 2008 07:35:25 GMT
Server: Apache / 1.3.3 7 ( U n i x )
Last -Modified : Tue, 1 Jan 2008 12:03:37 GMT
ETag : "78595-81-3883bbe9"
Accept-Ranges: bytes
Content-Length: 24
Connection : close
Content-Type: text /plain
To jest strona testowa.

Rysunek 2. Przykład odpowiedzi HTTP wygenerowanej przez serwer WWW Apache.


Źródła i Literatura:
Douglas E. Comer - "Sieci komputerowe i intersieci - kompendium każdego administratora !", Wydanie V, Wydawnictwo Helion 2012, ISBN: 978-83-246-3607-5.
Polish language edition published by HELION S.A. Copyright© 2012.
Copyright© 2012 Wydawnictwo HELION S.A
WWW: http:pl/helion.pl (księgarnia internetowa, katalog książek)

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *