HTTP. Opiera się na interakcji” klient-serwer„, czyli zakłada się, że:

1. Konsument- klient po zainicjowaniu połączenia z dostawcą-serwerem wysyła do niego żądanie;
2. Dostawca- serwer po otrzymaniu żądania wykonuje niezbędne działania i zwraca odpowiedź z wynikiem z powrotem do klienta.

   W takim przypadku istnieją dwa możliwe sposoby organizacji pracy komputera klienckiego:

   • Cienki klient to komputer kliencki, który przekazuje wszystkie zadania przetwarzania informacji na serwer. Przykładem cienkiego klienta jest komputer z przeglądarką, który służy do pracy z aplikacjami internetowymi.
   • Gruby klient wręcz przeciwnie, przetwarza informacje niezależnie od serwera, wykorzystując ten ostatni głównie do przechowywania danych.

Zanim przejdziemy do konkretnych technologii sieciowych klient-serwer, rozważmy podstawowe zasady i strukturę podstawową Protokół HTTP.

Protokół HTTP

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) to protokół warstwy aplikacji służący do przesyłania hipertekstu.

Centralną jednostką protokołu HTTP jest ratunek Adres URL wskazany w żądaniu klienta. Zazwyczaj zasobami tymi są pliki przechowywane na serwerze. Cechą protokołu HTTP jest możliwość określenia w żądaniu i odpowiedzi sposobu reprezentowania tego samego zasobu według różnych parametrów: formatu, kodowania, języka itp. Dzieje się tak dzięki możliwości określenia sposobu kodowania wiadomości że klient i serwer mogą wymieniać dane binarne, chociaż początkowo ten protokół przeznaczony do przekazywania informacji symbolicznych. Na pierwszy rzut oka może się to wydawać stratą zasobów. Rzeczywiście, dane w formie symbolicznej zajmują więcej pamięci, komunikaty powodują dodatkowe obciążenie kanałów komunikacyjnych, ale ten format ma wiele zalet. Komunikaty przesyłane siecią są czytelne, a po analizie otrzymanych danych, Administrator systemu łatwo znaleźć błąd i go naprawić. W razie potrzeby osoba może wcielić się w rolę jednej z współpracujących aplikacji, ręcznie wprowadzając wiadomości w wymaganym formacie.

W przeciwieństwie do wielu innych protokołów, HTTP jest protokołem bez pamięci. Oznacza to, że protokół nie przechowuje informacji o poprzednich żądaniach klientów i odpowiedziach serwera. Komponenty korzystające z protokołu HTTP mogą niezależnie utrzymywać informacje o stanie powiązane z ostatnimi żądaniami i odpowiedziami. Na przykład klient Aplikacja internetowa, wysyłanie żądań, może monitorować opóźnienia w odpowiedziach oraz serwer internetowy może przechowywać adresy IP i nagłówki żądań ostatnich klientów.

Wszystko oprogramowanie do pracy z protokołem HTTP dzieli się na trzy główne kategorie:

• Serwery- dostawcom usług przechowywania i przetwarzania informacji (przetwarzania żądań).
• Klienci- odbiorcy końcowi usług serwerowych (wysyłanie żądań).
• Serwery proxy do wspomagania pracy służb transportowych.

Głównymi klientami są przeglądarki np.: Internet Explorer, Opera, Mozilla Firefoksa, Netscape’a Nawigator i inni. Najpopularniejsze wdrożenia serwerów WWW to: Internet Informacja Usługi (IIS), Apache, lighttpd, nginx. Najbardziej znane wdrożenia serwerów proxy: Squid, UserGate, Multiproxy, Naviscope.

„Klasyczny” schemat sesji HTTP wygląda następująco.

1. Nawiązanie połączenia TCP.
2. Żądanie klienta.
3. Odpowiedź serwera.
4. Zakończenie połączenia TCP.

W ten sposób klient wysyła żądanie do serwera, otrzymuje od niego odpowiedź, po czym interakcja zostaje zatrzymana. Zazwyczaj żądanie klienta jest żądaniem przesłania dokumentu HTML lub innego zasobu, a odpowiedź serwera zawiera kod tego zasobu.

Żądanie HTTP wysłane przez klienta do serwera zawiera następujące elementy.

• Linia stanu (czasami w odniesieniu do niej używa się również terminów „linia stanu” lub „linia zapytania”).
• Pola nagłówka.
• Pusta linia.
• Treść żądania.

Pasek stanu razem z pola nagłówka czasami też tzw nagłówek żądania.

Ryż. 2.1.

Pasek stanu ma następujący format:

metoda_żądania URL_pecypca wersja_protokołu HTTP

Przyjrzyjmy się komponentom paska stanu, ze szczególnym uwzględnieniem metod żądania.

metoda określony w wierszu stanu określa, w jaki sposób wpływa to na zasób, którego adres URL jest określony w tym samym wierszu. Metoda może przyjmować wartości GET, POST, HEAD, PUT, DELETE itp. Pomimo mnóstwa metod, tylko dwie z nich są naprawdę ważne dla programisty WWW: GET i POST.

• DOSTAWAĆ. Zgodnie z formalną definicją metoda GET ma na celu pozyskanie zasobu o podanym adresie URL. Po otrzymaniu żądania GET serwer musi odczytać określony zasób i dołączyć kod zasobu jako część odpowiedzi kierowanej do klienta. Zasób, którego adres URL jest przekazywany w ramach żądania, nie musi być stroną HTML, plikiem obrazu ani innymi danymi. Adres URL zasobu może wskazywać na kod programu wykonywalnego, który po spełnieniu określonych warunków musi zostać wykonany na serwerze. W takim przypadku klientowi zwracany jest nie kod programu, ale dane wygenerowane podczas jego wykonywania. Choć z definicji metoda GET ma na celu odzyskanie informacji, można ją wykorzystać do innych celów. Metoda GET jest całkiem odpowiednia do przesyłania małych fragmentów danych na serwer.
• POST. Według tej samej formalnej definicji, główny cel Metoda POST- transfer danych na serwer. Jednakże, podobnie jak metoda GET, metoda POST może być używana na wiele różnych sposobów i często jest używana do pobierania informacji z serwera. Podobnie jak w przypadku metody GET, adres URL podany na pasku stanu wskazuje na konkretny zasób. Metodę POST można również wykorzystać do uruchomienia procesu.
• Metody HEAD i PUT są modyfikacjami metod GET i POST.

Wersja protokołu HTTP jest zwykle określany w następującym formacie:

Modyfikacja protokołu HTTP/wersji

Pola nagłówka, podążając za linią statusu, pozwalają na doprecyzowanie żądania, tj. przesyłać dodatkowe informacje do serwera. Pole nagłówka ma następujący format:

Nazwa pola: Wartość

Przeznaczenie pola określa jego nazwa, która jest oddzielona od wartości dwukropkiem.

Nazwy niektórych najpopularniejszych pól nagłówka w żądaniach klienta oraz ich przeznaczenie przedstawiono w tabeli 2.1.

Tabela 2.1. Pola nagłówka żądania HTTP.

Pola nagłówka HTTP -wniosek	Oznaczający
Gospodarz	Nazwa domeny lub adres IP hosta, do którego uzyskuje dostęp klient
Osoba odsyłająca	Adres URL dokumentu odwołującego się do zasobu wymienionego na pasku stanu
Z	Adres E-mail użytkownik pracujący z klientem
Zaakceptować	Typy MIME danych przetwarzanych przez klienta. To pole może mieć wiele wartości oddzielonych przecinkami. Często pole nagłówka Accept jest używane do poinformowania serwera, jakie typy plików graficznych obsługuje klient
Zaakceptuj język	Zestaw dwuznakowych identyfikatorów oddzielonych przecinkami, które wskazują języki obsługiwane przez klienta
Zaakceptuj-Charset	Lista obsługiwanych zestawów znaków
Typ zawartości	Typ MIME danych zawartych w treści żądania (jeżeli żądanie nie składa się z pojedynczego nagłówka)
Długość treści	Liczba znaków zawarta w treści żądania (jeśli żądanie nie składa się z pojedynczego nagłówka)
Zakres	Występuje, jeśli klient nie żąda całego dokumentu, a jedynie jego część
Połączenie	Służy do zarządzania połączeniem TCP. Jeżeli w polu znajduje się informacja Zamknij oznacza to, że po przetworzeniu żądania serwer powinien zamknąć połączenie. Wartość Keep-Alive sugeruje pozostawienie otwartego połączenia TCP, aby można było go wykorzystać do kolejnych żądań
Agent użytkownika	Informacja klientów

W wielu przypadkach podczas pracy w Internecie nie ma treści żądania. Po uruchomieniu skryptów CGI dane przekazane im w żądaniu można umieścić w treści żądania.

HTTP(HyperText Transfer Protocol - „protokół przesyłania hipertekstu”) to protokół na poziomie aplikacji służący do przesyłania danych (początkowo w formie dokumentów hipertekstowych). Podstawą protokołu HTTP jest technologia klient-serwer, czyli zakłada istnienie konsumentów (klientów), którzy inicjują połączenie i wysyłają żądanie, oraz dostawców (serwerów), którzy czekają na połączenie, aby otrzymać żądanie i dokonać niezbędne działania i zwróć wiadomość z wynikiem.

HTTP jest również używany jako „transport” dla innych protokołów warstwy aplikacji, takich jak SOAP, XML-RPC, WebDAV.

Głównym obiektem manipulacji w HTTP jest zasób wskazywany przez URI (Uniform Resource Identifier) ​​w żądaniu klienta. Zazwyczaj zasoby te są plikami przechowywanymi na serwerze, ale mogą to być obiekty logiczne lub coś abstrakcyjnego. Cechą protokołu HTTP jest możliwość określenia w żądaniu i odpowiedzi sposobu reprezentowania tego samego zasobu według różnych parametrów: formatu, kodowania, języka itp. Dzieje się tak dzięki możliwości określenia sposobu kodowania wiadomości że klient i serwer mogą wymieniać dane binarne, chociaż tym protokołem jest tekst.

HTTP jest protokołem warstwy aplikacji, podobnie jak FTP i SMTP – Simple Mail Transfer Protocol. Wiadomości wymieniane są według zwykłego schematu żądanie-odpowiedź. HTTP używa globalnych identyfikatorów URI do identyfikacji zasobów. W przeciwieństwie do wielu innych protokołów, HTTP jest bezstanowy. Oznacza to, że pomiędzy parami żądanie-odpowiedź nie ma utrzymywania się stanu pośredniego. Komponenty korzystające z protokołu HTTP mogą niezależnie utrzymywać informacje o stanie powiązane z ostatnimi żądaniami i odpowiedziami. Przeglądarka wysyłająca żądania może śledzić opóźnienia w odpowiedziach. Serwer może przechowywać adresy IP i nagłówki żądań najnowszych klientów. Jednak sam protokół nie jest świadomy wcześniejszych żądań i odpowiedzi, nie zapewnia wewnętrznego wsparcia stanu i nie są na niego narzucane żadne tego typu wymagania.

Rozciągliwość

Możliwości protokołu można łatwo rozszerzać poprzez wprowadzenie własnych nagłówków, przy jednoczesnym zachowaniu kompatybilności z innymi klientami i serwerami. Zignorują nieznane im nagłówki, ale jednocześnie mogą uzyskać niezbędną funkcjonalność do rozwiązania konkretnych problemów.

HTTP/1.1 - Obecna wersja protokół. Nowością w tej wersji było „ stałe połączenie": Połączenie TCP może pozostać otwarte po wysłaniu odpowiedzi na żądanie, umożliwiając wysłanie wielu żądań w jednym połączeniu. Klient ma teraz obowiązek przesłać informację o nazwie hosta, do którego się łączy, co umożliwiło łatwiejszą organizację wirtualnego hostingu.

HTTP nie przechowuje informacji o transakcjach, więc przy następnej transakcji musisz zacząć wszystko od nowa. Zaletą jest to Serwer HTTP może obsłużyć znacznie większą liczbę klientów w danym okresie czasu, ponieważ wyeliminowany zostaje dodatkowy narzut związany ze śledzeniem sesji z jednego połączenia na drugie. Jest też wada: zapisywanie informacji o transakcjach jest bardziej złożone programy CGI musi korzystać z ukrytych pól wejściowych lub środków zewnętrznych, takich jak pliki cookie.

Metody żądania HTTP

Metoda HTTP- ciąg dowolnych znaków, z wyjątkiem kontrolek i separatorów, wskazujący główną operację na zasobie. Zazwyczaj metodą jest zapisanie krótkiego angielskiego słowa wielkimi literami. Należy pamiętać, że w nazwie metody rozróżniana jest wielkość liter.

Każdy serwer musi obsługiwać przynajmniej metody GET i HEAD. Jeżeli serwer nie rozpoznaje metody określonej przez klienta powinien zwrócić status 501 (Niezaimplementowany). Jeżeli serwer zna metodę, ale nie ma ona zastosowania do konkretnego zasobu, to zwracany jest komunikat z kodem 405 (Metoda niedozwolona). W obu przypadkach serwer POWINIEN załączyć w odpowiedzi nagłówek Zezwalaj z listą obsługiwanych metod.

Oprócz metod GET i HEAD często stosowana jest metoda POST.

• Żądanie HTTP, odpowiedź, nagłówki jednostek (parametry)

  Wszystkie nagłówki w protokole HTTP podzielone są na cztery główne grupy (zaleca się wysyłanie nagłówków do odbiorcy w poniższej kolejności):

  Nagłówki ogólne(Główne nagłówki) - muszą być zawarte w każdej wiadomości klienta i serwera.

  Nagłówki żądań(Nagłówki żądań) - używane tylko w żądaniach klientów.

  Nagłówki odpowiedzi(Nagłówki odpowiedzi) - tylko dla odpowiedzi z serwera.

  Nagłówki jednostek(Nagłówki jednostek) — towarzyszą każdej encji wiadomości. W osobna klasa Nagłówki jednostek są wyróżnione, aby uniknąć pomyłek z nagłówkami żądań lub nagłówkami odpowiedzi w przypadku przesyłania wielu treści (MIME).

  Wszystkie nagłówki niezbędne do działania protokołu HTTP opisano w głównych dokumentach RFC. W razie potrzeby możesz stworzyć własne nagłówki. Tradycyjnie nazwy takich dodatkowych nagłówków są poprzedzane znakiem „X-”, aby uniknąć konfliktów nazw z potencjalnie istniejącymi.

  Linie po głównej linii żądania (GET /index.html HTTP/1.1) mają następujący format: Parametr: wartość. W ten sposób ustawiane są parametry żądania. Jest to opcjonalne; może brakować wszystkich linii po głównej linii zapytania; w tym przypadku serwer domyślnie akceptuje ich wartość lub na podstawie wyników poprzedniego żądania (przy pracy w trybie Połączenie: Keep-Alive).

  Parametr Połączenie(połączenie) - może przyjąć wartości Keep-Alive i zamknąć. W HTTP 1.0 po przesłaniu żądanych danych przez serwer następuje rozłączenie z klientem, a transakcję uważa się za zakończoną, chyba że zostanie wysłany nagłówek Connection: Keep Alive. W HTTP 1.1 serwer domyślnie nie zamyka połączenia i klient może wysyłać inne żądania. Ponieważ wiele dokumentów zawiera osadzone inne dokumenty — obrazy, ramki, aplety itp. — oszczędza to czas i koszty klienta, który w przeciwnym razie musiałby wielokrotnie łączyć się z tym samym serwerem, aby uzyskać tylko jedną stronę. Zatem w HTTP 1.1 transakcja może być powtarzana w pętli, dopóki klient lub serwer jawnie nie zamknie połączenia.

  Parametr Agent użytkownika- wartością jest „kod” przeglądarki.

  Parametr Zaakceptować- lista typów treści obsługiwanych przez przeglądarkę w kolejności preferencji dla tej przeglądarki.

  Parametr Gospodarz- nazwa domeny, z której żądany jest zasób. Przydatne, jeśli serwer ma kilka serwerów wirtualnych pod jednym adres IP. W tym przypadku imię domena wirtualna określona przez to pole.

  Parametr Ostatnio zmodyfikowany(zmodyfikowany w ostatni raz) (W3C Last-Modified) - data i godzina Ostatnia zmiana dokument. Za jego pomocą klient, podobnie jak w przypadku ETag, może skontaktować się z serwerem z żądaniem „If-Modified-Since” – w tym przypadku serwer musi porównać datę ostatniej modyfikacji kopii przechowywanej na kliencie z rzeczywistą data ostatniej modyfikacji. Jeśli są zgodne, oznacza to, że kopia w pamięci podręcznej klienta nie jest nieaktualna i pobierz ponownie niepotrzebne (kod odpowiedzi „304 Nie zmodyfikowano”). Last-Modified jest także niezbędny do prawidłowego przetwarzania witryny przez roboty, które na podstawie informacji o dacie modyfikacji stron sortują wyniki wyszukiwania według daty, a także określają częstotliwość aktualizacji Twojej witryny.

  W przypadku dokumentów SSI Apache wyda komunikat „Last-Modified”, jeśli określono dyrektywę „XBitHack full” (na przykład w pliku .htaccess)

  Parametr ETag(znacznik obiektu) - wprowadzony w HTTP 1.1 (W3C ETag). ETag służy do przypisywania każdej strony unikalny identyfikator, którego wartość zmienia się wraz ze zmianą strony (dokumentu). ETag to skrót („odcisk palca”) bajtów dokumentu; jeśli choć jeden bajt w dokumencie ulegnie zmianie, wówczas ETag ulegnie zmianie. ETag jest używany podczas buforowania dokumentu. Nagłówek ten jest przechowywany na kliencie i w przypadku wielokrotnego dostępu do dokumentu umożliwia przeglądarce skontaktowanie się z serwerem z żądaniem „If-None-Match”, a serwer musi określić na podstawie wartości znacznika ETag, czy dokument (strona) uległ zmianie, a jeśli nie, wpisz kod „304 Not Modified”.

  Parametr Wygasa(expiration)(W3C Expires) - informuje przeglądarkę, po jakim czasie może przyjąć, że kopia strony w pamięci podręcznej jest świeża i w ogóle nie kontaktować się z serwerem z żądaniami. Jest to wygodne w przypadku plików, o których wiesz, że nie ulegną zmianie przez następną godzinę/dzień/miesiąc: obraz tła strony np.

  Inne nagłówki HTTP:

  HTTP_X_FORWARDED_FOR

  HTTP_X_FORWARDED

  HTTP_FORWARDED_FOR

  • HTTP_X_COMING_FROM

    HTTP_COMING_FROM

  • HTTP_X_CLUSTER_CLIENT_IP

  • HTTP_XROXY_CONNECTION

    POŁĄCZENIE HTTP_PROXY

    HTTP_USERAGENT_VIA – serwer proxy

  Przykład analizy żądań HTTP

  Żądanie HTTP składa się z trzech części: linii żądania (odpowiedzi), sekcji nagłówka, po której następuje opcjonalna treść. Nagłówki są zwykłym tekstem, przy czym każdy nagłówek jest oddzielony od następnego znakiem nowej linii (\r\n), natomiast treść może być tekstem lub danymi binarnymi. Treść jest oddzielona od nagłówków dwoma znakami nowej linii.

  Nagłówek żądania składa się z głównej (pierwszej) linii żądania i kolejnych linii wyjaśniających żądanie magistrala. Może brakować także kolejnych linii.

  Klient inicjuje transakcję w następujący sposób:

  Klient nawiązuje połączenie z serwerem wykorzystując przydzielony numer portu, oficjalny numer Domyślny port to 80. Następnie klient wysyła żądanie dokumentu, określając metodę, adres dokumentu i numer wersji HTTP. Na przykład w głównej linii żądania GET /index.html HTTP/1.1

  Metoda GET służy do żądania dokumentu Index.html przy użyciu protokołu HTTP w wersji 1.1.

  Klient wysyła informacje z nagłówka (opcjonalne; nagłówek hosta jest wymagany), aby przekazać serwerowi informacje o konfiguracji oraz informacje o akceptowanych formatach dokumentów. Wszystkie informacje nagłówka są wyświetlane wiersz po wierszu, a każdy wiersz zawiera nazwę i wartość. Na przykład następujący nagłówek wysłany przez klienta zawiera jego nazwę i numer wersji, a także informacje o niektórych preferowanych przez klienta typach dokumentów: Host: list.mail.ru User-Agent: Mozilla/5.0 (Ubuntu; X11; Linux x86_64; rv :8.0) Gecko/20100101 Firefox/8.0 Akceptuj: tekst/html,aplikacja/xhtml+xml,aplikacja/xml;q=0.9,*/*;q=0.8

  Nagłówek kończy się pustą linią.

  Po wysłaniu żądania i nagłówków klient może przesłać dodatkowe dane np. dla skryptów CGI.

  Serwer odpowiada na żądanie klienta w następujący sposób:

  Pierwszą częścią odpowiedzi serwera jest linia stanu, która zawiera trzy pola: wersję HTTP, kod stanu i opis. Pole wersji zawiera numer wersji HTTP, której ten serwer używa do wysyłania odpowiedzi. Kod statusu to trzycyfrowa liczba wskazująca wynik przetworzenia żądania klienta przez serwer. Opis następujący po kodzie stanu to po prostu czytelny dla człowieka tekst wyjaśniający kod stanu. Na przykład pasek stanu HTTP/1.1 304 Nie zmodyfikowano

  wskazuje, że serwer do odpowiedzi używa protokołu HTTP w wersji 1.1. Kod statusu 304 oznacza, że ​​klient zażądał dokumentu metodą GET, użył nagłówka If-Modified-Since lub If-None-Match, a dokument nie uległ zmianie od określonego momentu.

  Po linii statusu serwer wysyła do klienta informację nagłówkową zawierającą informacje o samym serwerze i żądanym dokumencie. Poniżej znajduje się przykładowy nagłówek: Data: czw, 15 grudnia 2011 r. 09:34:15 GMT Serwer: Apache/2.2.21 (Debian) X-Powered-By: PHP/5.3.8-1+b1 Wygasa: czw, 19 listopada 1981 08:52:00 GMT Kontrola pamięci podręcznej: brak przechowywania, brak pamięci podręcznej, konieczna ponowna weryfikacja, sprawdzanie końcowe = 0, sprawdzanie wstępne = 0 Pragma: brak pamięci podręcznej Vary: akceptowanie kodowania kodowanie zawartości: gzip Keep - Alive: timeout=5, max=100 Połączenie: Keep-Alive Typ zawartości: tekst/html; zestaw znaków=utf-8

  Nagłówek kończy się pustą linią.

  Jeśli żądanie klienta zostanie przyjęte, żądane dane zostaną wysłane. Może to być kopia pliku lub wynik działania programu CGI. Jeżeli żądanie klienta nie może zostać spełnione, przekazywane są dodatkowe dane w formie przyjaznego dla użytkownika wyjaśnienia powodów, dla których serwer nie był w stanie zrealizować żądania.

  Kod stanu HTTP

  Kod stanu HTTP jest częścią pierwszej linii odpowiedzi serwera. Jest to trzycyfrowa liczba całkowita. Pierwsza cyfra wskazuje klasę warunku. Po kodzie odpowiedzi zwykle następuje zdanie objaśniające oddzielone spacją. język angielski, co wyjaśnia danej osobie powód udzielenia tej konkretnej odpowiedzi.

  Klient może nie znać wszystkich kodów statusu, ale musi odpowiedzieć zgodnie z klasą kodu. Obecnie istnieje pięć klas kodów stanu:

  1xx: Informacyjne. Informacyjne kody stanu informujące klienta, że ​​serwer jest w trakcie przetwarzania żądania. Reakcja Klienta na te kody nie jest wymagana;

  2xx: Powodzenie.

  1. 200 OK(Cienki). Wprowadzono w HTTP/1.0. Pomyślne żądanie zasobu. Jeśli klient zażądał jakichkolwiek danych, znajdują się one w nagłówku i/lub treści wiadomości.

  3xx: Przekierowanie. Kody klasy 3xx informują klienta, że ​​aby operacja się powiodła, należy wykonać inne żądanie (zwykle do innego identyfikatora URI). Z tej klasy pięć kodów 301, 302, 303, 305 i 307 odnosi się bezpośrednio do przekierowań (przekierowań). Serwer określa adres, na który klient powinien skierować żądanie w nagłówku Location. Wielu klientów przekierowując z kodami 301 i 302 błędnie stosuje metodę GET do drugiego zasobu, mimo że żądanie do pierwszego było realizowane inną metodą. Aby uniknąć nieporozumień, w wersji HTTP/1.1 zamiast 302 wprowadzono kody 303 i 307. Metodę żądania należy zmienić tylko wtedy, gdy serwer odpowiedział kodem 303. W pozostałych przypadkach kolejne żądanie złóż oryginalną metodą.

  1. Znaleziono 302(Znaleziony). Wprowadzono w HTTP/1.0. Żądany dokument jest tymczasowo dostępny pod innym URI określonym w nagłówku w polu Lokalizacja.

  4xx: Błąd klienta. Klasa kodu 4xx ma za zadanie wskazywać błędy po stronie klienta. W przypadku korzystania ze wszystkich metod z wyjątkiem HEAD, serwer musi zwrócić użytkownikowi wyjaśnienie hipertekstowe w treści wiadomości.

  1. 404 Nie znaleziono(Nie znaleziono). Wprowadzono w HTTP/1.0. Serwer zrozumiał żądanie, ale nie znalazł odpowiedniego zasobu o podanym URI.

  5xx: błąd serwera(Błąd serwera)

  Linki powiązane dotyczące protokołu HTTP 1.1

  HTTP/2

  HTTP/2 (pierwotnie HTTP/2.0) to druga główna wersja protokołu sieciowego HTTP. Protokół oparty jest na SPDY (protokół zgodny z HTTP opracowany przez Google).

  Protokół HTTP/2 jest binarny. W porównaniu do poprzedniego standardu zmieniono sposoby dzielenia danych na fragmenty i transportu ich pomiędzy serwerem a klientem.

  W HTTP/2 serwer ma prawo wysyłać treści, których jeszcze nie zażądał klient. Umożliwi to serwerowi natychmiastowe wysłanie dodatkowe pliki, których przeglądarka będzie potrzebować do wyświetlania stron, bez konieczności analizowania strony głównej przez przeglądarkę i żądania niezbędnych uzupełnień.

Żądanie HTTP, czyli wiadomość, składa się z trzech części: wiersza zapytania i treści wiadomości HTTP.

Ciąg zapytania lub linia początkowa: w żądaniu kierowanym do serwera, linia zawierająca typ żądania (metodę), identyfikator URI żądanej strony i wersję (na przykład HTTP/1.1). W odpowiedzi serwera ta linia zawiera wersję protokołu HTTP i kod odpowiedzi. Kod odpowiedzi jest trzycyfrową liczbą całkowitą. Zwykle następuje po nim oddzielona spacjami fraza wyjaśniająca wyjaśniająca kod, na przykład: 200 OK lub 404 Not Found.

Metody żądania HTTP (typy): POBIERZ, WYŚLIJ, WSTAW, POPRAW, GŁÓW, USUŃ, ŚLEDŹ. Najczęściej w żądaniu HTTP używane są metody GET lub POST: GET służy do żądania treści strony internetowej o określonym URI. URI to adres strony bez określenia, na przykład: /internet/chto-takoe-http-zapros-soobshhenie/ zamiast site/internet/chto-takoe-http-zapros-soobshhenie/. Przeglądarka może przekazywać parametry w metodzie GET w identyfikatorze URI po znaku „? ": GET /index.php?param1=wartość1¶m2=wartość2. Z wyjątkiem metoda konwencjonalna GET, istnieją również warunkowe GET i częściowe GET. Warunkowy POBIERZ żądania zawierają If-Modified-Since , If-Match , If-Range i podobne nagłówki.

POST - używany do wysyłania informacji do . W przypadku wysyłania danych metodą POST jest to wskazane w treści wiadomości HTTP, a nie w wierszu wprowadzania adresu w przeglądarce, jak ma to miejsce w przypadku przesyłania danych metodą GET. Przykładowo podczas wysyłania komentarza poprzez formularz znajdujący się pod artykułem, informacja przekazywana jest do serwera metodą POST. Pliki przesyłane są również na serwer metodą POST.

- jest to część żądania, która zawiera różne parametry wykorzystywane do prawidłowego zbudowania strony internetowej.

Treść wiadomości HTTP— zawiera dane otrzymane z serwera, np. wygenerowaną stronę internetową w postaci kodu HTML lub zasób, np. zdjęcie.

Przykładowe wiadomości HTTP:

Żądanie HTTP do serwera:

GET /internet/chto-takoe-http-zapros-soobshhenie/ HTTP/1..9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 ( KHTML, jak Gecko) Chrome/40.0.2150.0 Kodowanie akceptacji: gzip, deflate, sdch Język akceptacji: ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4 Cookie: wp- ustawienia-1=ukryjb%3D; wp-settings-time-1=1424958215; wordpress_test_cookie=WP+Cookie;

Odpowiedź z serwera:

HTTP/1.1 200 OK - linia początkowa odpowiedzi: Serwer: nginx/1.6.2 Data: niedziela, 19 kwietnia 2015 00:22:50 GMT Typ zawartości: tekst/html; charset=UTF-8 Długość zawartości: 9431 Połączenie: keep-alive Keep-Alive: timeout=30 X-Powered-By: PHP/5.5.22 Wygasa: środa, 11 stycznia 1984 05:00:00 GMT Kontrola pamięci podręcznej: no-cache, must-revalidate, max-age=0 Pragma: no-cache Vary: Akceptuj-kodowanie Kodowanie treści: gzip Poniżej znajduje się treść odpowiedzi (strona HTML).

Jeśli chcesz wiedzieć, w jaki sposób przesyłane są dane w Internecie, ten artykuł jest dla Ciebie. Opowiem Ci wszystko co wiem o protokołach HTTP i HTTPS, pokażę różnicę i różnice pomiędzy nimi. Miłego czytania!

HTTP 1.1 – co to za protokół?

HTTP (angielski: protokół przesyłania hipertekstu) - protokół sieciowy Najwyższy poziom do przesyłania hipertekstu i dowolnych danych w Internecie.

Na Pomoc HTTP przeglądarka otrzymuje dane z serwerów internetowych i może je wyświetlić w formie akceptowalnej i zrozumiałej dla użytkowników Internetu. Proces odwrotny przebiega dokładnie w ten sam sposób - przesłanie danych użytkownika z powrotem na serwer (na przykład podczas rejestracji).

Treść wysyłana z i na serwer może być prezentowana w dowolnej formie: obrazków, plików, dokumentów, linków i kodu - w każdym razie to dzięki HTTP ludzie mogą korzystać z Internetu i ładować setki stron internetowych w przeglądarce.

Obecna wersja protokół - 1.1. Jego opis znajduje się w specyfikacji RFC.

W infrastrukturze przesyłania danych klient-serwer używany jest protokół HTTP. Jak to działa? Aplikacja po stronie „klienta” generuje żądanie do przetworzenia po stronie „serwera”, po czym odpowiedź jest odsyłana do „klienta”. „Klient” może następnie inicjować dodatkowe żądania i otrzymywać nowe odpowiedzi. I tak dalej.

Najpopularniejszą aplikacją „kliencką” jest przeglądarka internetowa, za pośrednictwem której uzyskuje się dostęp do zasobów sieciowych. Z rozwojem technologie mobilne dodano więcej przeglądarek aplikacje mobilne na różnych smartfonach i tabletach. Co więcej, strona serwerowa nowoczesnych multidyscyplinarnych aplikacji może jednocześnie przetwarzać dane zarówno z przeglądarki, jak i smartfona. Wszystko to odbywa się poprzez protokół HTTP.

Co więcej, HTTP często działa jako protokół transportowy do przesyłania innych danych protokoły aplikacji i ich API: WebDAV, XML-RPC, REST, SOAP. Otóż ​​danych przesyłanych poprzez API może być najwięcej inny format: XML, JSON i inne.

W jaki sposób te dane są przesyłane? Najczęściej poprzez połączenie TCP/IP: aplikacja kliencka domyślnie korzysta z portu TCP 80, a serwer może używać dowolnego innego, ale zazwyczaj jest to również port 80.

Obiekt manipulacji HTTP to zasób określony w identyfikatorze URI żądania aplikacji klienckiej w celu prawidłowego zidentyfikowania „tego, co jest faktycznie potrzebne”. Zazwyczaj są to pliki, dane lub obiekty logiczne przechowywane na serwerze. W takim przypadku żądanie może dokładnie wskazać sposób prezentacji tych samych danych: jaki format, kodowanie, język wybrać. Ta „funkcja” umożliwia wymianę nie tylko hipertekstu, ale także danych binarnych.

Drugą cechą protokołu HTTP jest to, że nie zapisuje stanu pomiędzy kolejnymi parami żądanie-odpowiedź. Nie stanowi to jednak problemu, ponieważ komponenty aplikacji po stronie klienta lub serwera mogą same przechowywać informacje o stanie najnowszych żądań i odpowiedzi. Po stronie klienta takie informacje nazywane są plikami cookie, po stronie serwera – sesjami.

Jednocześnie dla przeglądarki klienta nie jest problemem monitorowanie opóźnienia odpowiedzi serwera, a dla serwera nie jest problemem przechowywanie nagłówków najnowszych żądań i adresów IP klientów. Ale, podkreślam jeszcze raz, sam protokół nic o tym nie wie - tylko przesyła dane.

W przekazywaniu danych mogą brać udział także pośrednicy (serwery proxy) w celu odróżnienia serwerów proxy od serwerów końcowych (tzw. „serwer źródłowy”).

Magia zaczyna się, gdy ten sam program (klient lub serwer) może pełnić funkcje pośrednika, klienta lub serwera – w zależności od zadań.

HTTP/2 - co to za protokół?

Oryginalna wersja protokołu HTTP pojawiła się w CERN w 1991 roku. Już w 1992 roku opublikowano publiczną wersję protokołu HTTP 0.9 i jego specyfikację, dzięki której zasady interakcji pomiędzy klientem a aplikacje serwerowe, a także jasne określenie funkcjonalności.

HTTP/1.0 pojawił się w 1996 r. i nowoczesna wersja protokół - HTTP/1.1 - w 1999 r. Na przełomie tysiącleci protokół HTTP nauczył się obsługiwać tryb połączenia trwałego, czyli tzw. pozostaw połączenie otwarte po otrzymaniu odpowiedzi na żądanie. Umożliwiło to wysłanie kilku żądań jednocześnie w jednym połączeniu, zamiast za każdym razem otwierać i zamykać sesję.

Czas mijał, a wraz z rozwojem Internetu zwiększał się rozmiar stron, rosła liczba żądań – potrzeba było coraz więcej zasobów. W ten sposób powstała potrzeba nowego protokołu.

Natomiast szesnaście lat później, w 2015 roku, opublikowano ostateczną wersję projektu specyfikacji kolejnej wersji protokołu HTTP/2. Protokół binarny HTTP/2 jest lepiej przygotowany na współczesne realia niż jego poprzednik HTTP 1.1, ponieważ nowy protokół rozwiązuje najważniejszy problem przesyłania danych w Internecie - wiele otwartych połączeń.

A wszystko dlatego, że obecne strony ładują mnóstwo elementów, zarówno ze swojego serwera, jak i z CDN: skryptów JS, stylów CSS, czcionek i obrazów. Podczas przenoszenia kompletny zestaw plików przy użyciu protokołu HTTP 1.1, tworzonych jest wiele połączeń. Jeśli w przyszłości przejdziemy na protokół HTTP/2, transfer będzie odbywał się w ramach jednego połączenia pomiędzy klientem a serwerem, co znacząco przyspieszy i zoptymalizuje ładowanie zawartości serwisu.

Najważniejsze cechy protokołu HTTP/2, które będą przydatne w przypadku witryn internetowych:

• Uporządkowanie i zarządzanie priorytetami żądań/przepływów - klient samodzielnie ustala priorytety zasobów i danych dla serwera
• Kompresja nagłówka HTTP;
• Multipleksowanie żądań lub równoległe ładowanie kilku elementów serwisu poprzez połączenie TCP - jednym połączeniem przesyłanych jest kilka żądań, a klient może otrzymywać odpowiedzi w dowolnej kolejności, tj. teraz nie potrzebujesz kilku otwierać połączenia TCP;
• Dostępność i wsparcie z serwera proaktywnych powiadomień push - serwer może samodzielnie wysyłać do klienta dane, których klient jeszcze nie żądał (np. na podstawie informacji o tym, jaką stronę użytkownik otworzy po tej).

Oczywiście najważniejsze jest tutaj multipleksowanie strumienia. Zasada działania jest łatwa do wyjaśnienia: pakiety połączeń TCP/IP są mieszane w ramach jednego połączenia. Zatem w trybie mieszanym kilka „samochodów danych” jest połączonych w jeden „pociąg”, które są rozdzielane „po przyjeździe”. Wcześniej „samochody” zmuszone były podróżować dłużej i osobno, ale teraz będą podróżować razem i szybciej.

Powyższe zalety protokołu HTTP/2 pozwolą twórcom stron WWW odetchnąć głęboko i porzucić takie „kule” jak:

• Stosowanie więcej powiązane domeny, aby zapewnić instalację duże ilości Połączenia TCP/IP (do pobierania plików);
• Sprite'y obrazkowe - kiedy obrazy są łączone w jeden plik, aby zmniejszyć liczbę żądań do serwera WWW (a sam plik „rozdęwa się”, ponieważ zapisuje się do niego więcej obrazów);
• Łączenie plików CSS i JS, które również mają na celu zmniejszenie liczby żądań.

Ostatnia rzecz oczywista zaleta Problem w tym, że z samą witryną nie trzeba nic dodatkowo robić (aby włączyć HTTP/2) - cała praca na serwerze odbywa się niemal za „1 kliknięciem”, a dla klientów hostingu współdzielonego i VPS będzie to możliwe generalnie pozostają niezauważone.

Jednym słowem będziemy żyć!

HTTP/2 został stworzony i opracowany w oparciu o projekt protokołu SPDY/3 (Google) i przekroczył go - Google uznał zalety protokołu HTTP/2 za bardziej obiecujące i w przyszłości zrezygnuje ze wsparcia dla SPDY/2.

Przewidywane przyspieszenie odpowiedzi serwera poprzez protokół HTTP/2 wyniesie około 30%, - prawdziwe testy pokazały już prędkości o 19-23% wyższe i to nie jest limit.

Według wyników testów Airi.rf, wzrost prędkości od samego włączenia protokołu HTTP/2 wynosi 13-18% (bez optymalizacji). Dlaczego to jest ważne?

Pomimo tego, że strona nie obsługuje protokołu HTTP/2 ten moment nie wpływa bezpośrednio na ranking witryn w Google i Yandex, na pozycje w wynikach wyszukiwania wpływa prędkość ładowania. A skoro protokół pokazuje więcej wysoka prędkość pobrań (co jest dość istotnym czynnikiem), pośrednio wpływa to na rankingi.

Przede wszystkim ze względu na czynniki behawioralne. Przyspieszenie ładowania pozwala użytkownikom być mniej zmęczonym i bardziej skupionym na przeglądaniu witryny: przeglądać więcej stron i nie opuszczać witryny z powodu długi czas ładowania(redukcja niepowodzeń).

Większość nowoczesnych przeglądarek obsługuje już protokół HTTP/2 — przechodzi przez nie około 70% ruchu internetowego:

• Chrome 41-52 i Chrome 46+ na Androidzie;
• Firefox 36-48 i Firefox 41+ na Androidzie;
• Opera 28-34 i Opera 30+ na Androida;
• Safari 9 i Safari w iOS 9.1;
• IE 11 na Windows 10 i przeglądarka Edge 12, 13.

Nie jest jeszcze jasne, kiedy nastąpi pełne przejście na HTTP/2 – najprawdopodobniej w najbliższej przyszłości. Najważniejsze, że nikt nie będzie pochopnie rezygnował z protokołu HTTP/1.x. Jak to mówią: „Jeśli coś działa, nie dotykaj tego”.

Co oznacza protokół HTTPS i gdzie jest używany?

Cóż, wiesz już wszystko o wymianie danych za pomocą protokołu HTTP: każdy transfer danych odbywa się poprzez żądania wykorzystujące ten protokół transportowy. Dlaczego zatem potrzebujemy HTTPS i co to jest? Przecież żyliśmy normalnie bez niego?

Problem polega na tym, że dane za pośrednictwem protokołu HTTP nie są chronione i są przesyłane do otwarta forma. Internet - globalny sieć rozproszona węzły A jeśli przesyłasz otwarte dane przy użyciu niezabezpieczonego protokołu (tutaj obowiązuje także Wi-Fi w centrum handlowym), to jeden z tych węzłów może je przechwycić.

Oczywiście nie jest to celowe działanie, może to być po prostu włamanie dokonane przez przestępców. HTTPS został stworzony, aby zapewnić bezpieczeństwo połączenia i przesyłanie danych w formie zaszyfrowanej z wykorzystaniem protokołu kryptograficznego SSL/TLS. Jest to specjalne „opakowanie” na HTTP; szyfruje dane, czyniąc je niedostępnymi dla atakujących nieznajomi.

HTTPS — angielski " bezpieczny protokół transmisja hipertekstowa.”

Zatem w przeciwieństwie do domyślnego portu 80 w protokole HTTP, HTTPS wykorzystuje port TCP 443 i ma klucz szyfrowania. Klucz może mieć długość 40, 56, 128 lub 256 bitów; wystarczający poziom bezpieczeństwa zaczyna się obecnie od kluczy 128-bitowych.

Teraz wszystkie przeglądarki obsługują protokół HTTPS - jest on włączany automatycznie, gdy jest to możliwe i serwer tego wymaga.

Korzystanie z protokołu HTTPS jest niezbędne w następujących usługach:

• Elektroniczne systemy płatności (banki, pieniądz elektroniczny itp.);
• Usługi odbierające i wysyłające prywatne informacje i dane osobowe, na przykład Yandex ma: paszport, taksówkę, bezpośredni, metrykę, pocztę, pieniądze, webmaster i inne;
• Media społecznościowe I konta osobiste w usługach internetowych;
• Wyszukiwarki.

HTTPS działa po prostu. Wyjaśnię na przykładzie.

Wkładasz ważna informacja(login, hasło, dane karty, dane osobowe) do komórki, „zamknij ją na klucz”: komórka szyfruje Twoje dane za pomocą tego klucza.

Teraz wyślij go pocztą do adresata. Adresat otrzymuje paczkę, ale nie może jej otworzyć – nie ma klucza. Następnie zamyka (szyfruje) komórkę drugim zamkiem i zwraca paczkę z powrotem do Ciebie. Otrzymujesz paczkę z dwoma zamkami, ale masz klucz do jednego. Teraz możesz odblokować zamek (odszyfrować dane) i ponownie wysłać paczkę do pierwotnego odbiorcy.

Jednocześnie dane pozostają chronione – w końcu nie były przez nikogo przeglądane ani zmieniane i do czasu otrzymania przez odbiorcę są chronione zaszyfrowanym kluczem. Adresat odbiera przesyłkę już z jednym zamkiem, odszyfrowuje ją i przetwarza Twoje dane. Na przykład realizuje Twoją transakcję.

To wszystko – tak działa HTTPS.

Sztuczka polega na tym, że podczas pierwszej takiej wymiany klucz szyfrujący jest wymieniany w taki sposób, aby był znany obu ostatecznym odbiorcom, ale nie był znany żadnemu z węzłów na trasie transmisji danych. Po wymianie szyfru można swobodnie wymieniać wiadomości (zaszyfrowane) bez obawy o przechwycenie tych danych, gdyż bez klucza szyfrującego nie będzie możliwe ich otwarcie i odczytanie.

Jedynym zastrzeżeniem jest to, że musisz wiedzieć, że wysyłasz dane dokładnie tam, gdzie są potrzebne. I że ostatecznym punktem jest cel. Musisz jednak potwierdzić i mieć pewność, że miejsce docelowe istnieje i jest kontrolowane przez sam serwer, do którego przesyłane są dane.

W tym celu serwery otrzymują od centrów certyfikacji specjalne certyfikaty bezpieczeństwa HTTPS, które potwierdzają „ostateczność” miejsca docelowego (że witryna nie jest dalej węzłem przesyłającym dane) oraz funkcjonalność technologii szyfrowania SSL/TLS, tj. bezpieczeństwo połączenia.

A oto jak wygląda sam certyfikat:

Obecnie protokół HTTPS jest wbudowany we wszystko nowoczesne przeglądarki a jedyne, czego wymaga się od użytkownika, aby zachować bezpieczeństwo przesyłania danych za pośrednictwem protokołu HTTPS, to regularna aktualizacja oprogramowania umożliwiającego surfowanie, odbieranie i wysyłanie ważnych danych w Internecie.

Przeprowadzanie interakcji klient-serwer za pośrednictwem Protokół HTTPS nie musisz martwić się o bezpieczeństwo swoich danych – jesteś niezawodnie chroniony przed podsłuchem połączenie internetowe: ataki węchowe i man-in-the-middle.

Co oznacza przekreślona ikona HTTPS i zielona ikona HTTPS, jaka jest różnica? W bezpieczeństwie. Zielony jest bezpieczny, czerwony i przekreślony są niebezpieczne.

A bardzo wygodne jest to, że przekreślona ikona HTTPS oznacza, że ​​mimo użycia tego protokołu połączenie nie jest bezpieczne. Dzieje się tak, gdy elementy witryny nie są ładowane przez HTTPS lub certyfikat wygasł. Użytkownik od razu widzi – tak, to niebezpieczne. Może też opuścić witrynę lub zaryzykować swoje dane.

Co jest lepsze: HTTP 1.1, HTTP/2 czy HTTPS?

Podsumowując, poruszę temat preferowanego wykorzystania protokołów.

Oczywiste jest, że w tej chwili HTTP 1.1 jest najpopularniejszym protokołem i jest używany domyślnie. Czas HTTP/2 jeszcze nie nadszedł, ale już niedługo większość ruchu internetowego będzie przechodzić przez drugą wersję protokołu HTTP. Ułatwi to życie użytkownikom, ponieważ strony będą ładowały się szybciej. Administratorzy serwerów i witryn również będą zadowoleni, ponieważ nowy protokół pozwala w nowy sposób optymalizować strony internetowe, przyspieszając ładowanie i przesyłanie danych.

Biorąc to pod uwagę, jest mało prawdopodobne, aby wszystkie witryny przełączyły się na HTTPS ze względu na cele konsumpcyjne treści rozrywkowe szyfrowanie jest bezużyteczne. Tak, obecnie 10% witryn korzysta z protokołu HTTPS w rankingu Alexa najczęściej odwiedzanych zasobów sieciowych. Ale to tylko dziesięć procent, w tym tacy giganci jak Google, PayPal, Amazon, Aliexpress i inni. Oznacza to, że istnieje wiele witryn, w których niestosowanie protokołu HTTPS oznacza naruszenie prawa internauty do bezpieczeństwa i integralności danych.

Ale zwykłe strony, takie jak blog siedmiu blogerów, nie potrzebują protokołu HTTPS - nie ma odbioru danych osobowych ani płatności, nie ma rejestracji i wysyłania ważne wiadomości.

Dlatego w najbliższej przyszłości będziemy stopniowo odchodzić od HTTP 1.1 na rzecz HTTP/2 i HTTPS.

Format odpowiedzi jest bardzo podobny do formatu żądania: zawiera również nagłówek i treść oddzielone pustą linią.

Nagłówek również składa się z linii głównej i linii parametrów, ale format linii głównej różni się od formatu nagłówka żądania.

Główny ciąg zapytania składa się z 3 pól oddzielonych spacjami:

Wersja protokołu- podobny do odpowiedniego parametru żądania.

Kod błędu- oznaczenie kodowe „sukcesu” żądania. Kod 200 oznacza „wszystko w porządku” (OK).

Ustny opis błędu- „odszyfrowanie” poprzedniego kodu. Na przykład za 200 jest OK, za 500 - Serwer wewnętrzny Błąd.

Najczęstsze parametry odpowiedzi http:

Połączenie- podobny do odpowiedniego parametru żądania.
Jeśli serwer nie obsługuje funkcji Keep-Alive (jest ich kilka), wówczas wartość połączenia w odpowiedzi jest zawsze bliska.

Dlatego moim zdaniem prawidłowa taktyka przeglądarki jest następująca:
1. w żądaniu wystaw połączenie: Keep-Alive;
2. Stan połączenia można ocenić na podstawie pola Połączenie znajdującego się w odpowiedzi.

Typ zawartości(„typ treści”) – zawiera oznaczenie typu treści odpowiedzi.

W zależności od wartości Content-Type przeglądarka interpretuje odpowiedź jako stronę HTML, obraz GIF lub jpeg jako plik do zapisania na dysku lub czymkolwiek innym i podejmuje odpowiednie działania. Wartość Content-Type dla przeglądarki jest taka sama, jak wartość rozszerzenia pliku dla systemu Windows.

Niektóre typy treści:

tekst/html - tekst w formacie HTML(Strona internetowa);
tekst/zwykły - zwykły tekst (podobnie jak Notatnik);
image/jpeg - obraz w formacie JPEG;
image/gif - to samo, w formacie GIF;
application/octet-stream - strumień „oktetów” (tj. samych bajtów) do zapisu na dysku.

W rzeczywistości istnieje znacznie więcej rodzajów treści.

Długość treści(„długość treści”) – długość treści odpowiedzi w bajtach.

Ostatnio zmodyfikowany(„Ostatnia modyfikacja”) – data ostatniej modyfikacji dokumentu.