Webový server neudržuje trvalé spojení s klientem a každý požadavek je zpracován jako nový, bez spojení s předchozími.
To znamená, že nemůžete ani sledovat požadavky od stejného návštěvníka, ani pro něj ukládat proměnné mezi zobrazeními samostatných stránek. K vyřešení těchto dvou problémů byly vynalezeny relace.
Ve skutečnosti jsou relace v kostce mechanismus, který vám umožňuje jednoznačně identifikovat prohlížeč a vytvořit soubor pro tento prohlížeč na serveru, který ukládá proměnné relace.

Nebudu podrobně popisovat potřebu takového mechanismu. Jsou to takové učebnicové případy jako nákupní košík v e-shopu, autorizace, ale i ne úplně triviální problémy, jako je například ochrana interaktivních částí webu před spamem.

V zásadě je docela snadné vytvořit si vlastní analog relací, ne tak funkční jako vestavěné PHP, ale v podstatě podobné. O cookies a databázi.
Při požadavku na skript se podíváme, zda dorazila cookie s konkrétním názvem. Pokud žádný soubor cookie neexistuje, nastavte jej a zapište do databáze nový řádek s uživatelskými údaji. Pokud existuje cookie, čteme z databáze. Ještě jedním požadavkem vymažeme staré záznamy z databáze a nyní máme připravený mechanismus relace. Není to vůbec těžké. Existují však některé nuance, kvůli kterým je vhodnější použít vestavěný mechanismus relace.

Pokud je povoleno pouze první, pak se na začátku relace (s každým voláním session_start ()) klientovi nastaví cookie. Prohlížeč správně vrací tento cookie s každým dalším požadavkem a PHP má identifikátor relace. Problémy začínají, pokud prohlížeč nevrací soubory cookie. V tomto případě PHP vždy zahájí novou relaci bez přijetí cookies s identifikátorem a mechanismus nebude fungovat.

Pokud je povolena pouze druhá, pak se soubor cookie nenastaví. A co se stane, je to, kvůli čemu v podstatě ve skutečnosti stojí za to použít vestavěný mechanismus relace. Poté, co skript udělá svou práci a stránka je plně zformována, PHP se na to vše podívá a ke každému odkazu a ke každému formuláři připojí ID relace. Vypadá to nějak takto:
Index promění v
Index
a do formulářů se přidá skryté pole

A prohlížeč, když kliknete na jakýkoli odkaz nebo když kliknete na tlačítko ve formuláři, odešle v požadavku proměnnou, kterou potřebujeme - identifikátor relace!
Z pochopitelných důvodů se ID přidává pouze k relativním odkazům.

Teoreticky můžete v našich domácích relacích o souborech cookie a databázi ručně přiřadit přenos id všem odkazům - a naše vlastní relace pak budou fungovat nezávisle na souborech cookie. Ale vidíte – je příjemnější, když tuhle práci dělá někdo jiný? ;-)

Obě možnosti jsou v posledních verzích PHP standardně povoleny. Jak to PHP řeší? Cook je vždy vystaven. A odkazy se automaticky doplňují pouze v případě, že PHP nenajde cookie s ID relace. Když uživatel navštíví web poprvé během této relace, obdrží soubor cookie a přidají se odkazy. Při dalším požadavku, pokud jsou soubory cookie podporovány, PHP soubor cookie uvidí a přestane doplňovat odkazy. Pokud soubory cookie nefungují, PHP pokračuje ve správném přidávání id do odkazů a relace se neztratí.
Uživatelé, kteří mají soubory cookie funkční, uvidí dlouhý odkaz s ID pouze jednou.

Fuj. Po dokončení přenosu identifikátoru.
Nyní zbývá svázat soubor s daty na straně serveru.
PHP to udělá za nás. Stačí jen napsat
session_start ();
$ _SESSION ["test"] = "Ahoj světe!";
A PHP zapíše testovací proměnnou do souboru spojeného s touto relací.
Je zde velmi důležitý bod.
Pole $ _SESSION je speciální.
V něm jsou ve skutečnosti proměnné, které chceme zpřístupnit v různých skriptech.
Chcete-li umístit proměnnou do relace, stačí ji přiřadit k prvku pole $ _SESSION.
K získání jeho hodnoty stačí odkazovat na stejný prvek. Příklad bude níže.

Garbage collection – PHP se také podílí na odstraňování zastaralých souborů. Stejně tak kódování dat a hromada dalších potřebných věcí. Díky této péči je práce se sezeními velmi snadná.
Tady jsme ve skutečnosti a dostáváme se k příkladu práce relací.
Příklad je velmi malý:
session_start ();

echo "Aktualizovali jste tuto stránku". $ _ SESSION ["počítadlo"] ++. "krát.";
echo"
Aktualizace ";
?>
Zkontrolujeme, zda máme v relaci proměnnou čítače, pokud ne, pak ji vytvoříme s hodnotou 0 a poté vypíšeme její hodnotu a zvýšíme ji o jednu. Zvýšená hodnota bude zapsána do relace a při příštím volání skriptu bude mít proměnná hodnotu 1 a tak dále.
Vše je velmi jednoduché.

Abyste měli přístup k proměnným relace na jakékoli stránce webu, musíte napsat POUZE JEDEN (!) řádek na úplný začátek KAŽDÉHO souboru, ve kterém potřebujeme relace:
session_start ();
A pak se podívejte na prvky pole $ _SESSION. Například kontrola autorizace by vypadala nějak takto:
session_start ();
if ($ _SESSION ["autorizováno"]<>1) {
záhlaví ("Umístění: /auth.php");
výstup;
}

Odebrání proměnných z relace.
Pokud máte register_globals = off, tak stačí napsat
unset ($ _ SESSION ["var"]);
Pokud ne, tak u Musím si s ní napsat
session_unregister ("var");

Nejčastější chyby, které PHP dává při pokusu o práci s relacemi, jsou:
Dva z nich,
Upozornění: Nelze odeslat cookie relace – záhlaví již byla odeslána
Upozornění: Nelze odeslat omezovač mezipaměti relace – záhlaví již byla odeslána
způsobené stejným důvodem, řešení je popsáno v této skutečnosti
Třetí,
Varování: otevřít (/ tmp \ sess_SID, O_RDWR) se nezdařilo: Žádný takový soubor nebo adresář (2) v full_script_path na řádku číslo(předtím vypadala Upozornění: Zápis dat relace (souborů) se nezdařil. Ověřte prosím, že aktuální nastavení session.save_path je správné (/ tmp)),
pokud je přeložen z angličtiny, vysvětluje problém podrobně: cesta uvedená v php.ini k adresáři, kde jsou zapsány soubory relace, není k dispozici. Tuto chybu lze nejsnáze opravit. Stačí napsat adresář, který existuje a do kterého lze zapisovat, např.
session.save_path = c: \ windows \ temp
A poté nezapomeňte restartovat Apache.

Jak se ukazuje, lidská inteligence nemá meze, a proto musím vysvětlit:
třetí chybová zpráva (adresář nelze nalézt) NEDOSTUPNÁ povede k prvním dvěma, protože chybová zpráva se odešle do prohlížeče a po ní nelze použít záhlaví. Nespěchejte proto hledat předčasný závěr, ale nejprve napište správnou cestu!

Dalším nejčastějším problémem při práci s relacemi je těžké dědictví register_globals. NEDÁVEJTE proměnným skriptu stejná jména jako indexy pole $ _SESSION!
S register_globals = on se hodnoty navzájem přepíší a budete zmateni.
A pokud register_globals = off, objeví se další chyba: "Váš skript možná spoléhá na vedlejší efekt relace, který existoval až do PHP 4.2.3." ... Abyste se toho zbavili, měli byste vždy před použitím inicializovat proměnné (nebo alespoň zkontrolovat jejich existenci) a nedávat globálním proměnným názvy, které odpovídají indexům pole $ _SESSION.

Pokud to nefunguje, ale nezobrazují se ani žádné zprávy, přidejte na úplný začátek skriptu dva řádky, které jsou zodpovědné za zobrazení VŠECH chyb na obrazovce - je docela možné, že tam jsou chyby, ale prostě nevidíte jim.
ini_set ("display_errors", 1);
chybové hlášení (E_ALL);
nebo si prohlédněte chyby v error_log. Obecně platí, že téma zobrazování chybových zpráv přesahuje rámec tohoto článku, takže se ujistěte, že je alespoň vidíte. V této části si můžete přečíst trochu podrobněji o odstraňování problémů.

Pokud jste si jisti, že tam nejsou žádné chyby, ale uvedený příklad stejně nefunguje, je možné, že PHP neumožňuje přenos id přes url, a soubory cookie z nějakého důvodu nefungují.
Podívejte se, co máte s cookies.
Obecně platí, že pokud vaše relace „nefungují“, zkuste nejprve ručně přenést identifikátor relace, to znamená vytvořit odkaz a přiřadit mu identifikátor:
session_start ();
if (! isset ($ _ SESSION ["počítadlo"])) $ _SESSION ["počítadlo"] = 0;
echo "Aktualizovali jste tuto stránku". $ _ SESSION ["počítadlo"] ++. "krát.

Aktualizace ";
?>
Když to děláte, ujistěte se, že není povolena direktiva session.use_only_cookies, která brání PHP přijmout ID relace, pokud bylo předáno přes URL.

Pokud tento příklad nefunguje, pak je problém buď v banálním překlepy(polovina „problémů“ s relacemi pochází z nesprávně napsaného názvu proměnné) nebo v příliš staré verzi PHP: podpora relace se objevila ve verzi 4.0 a pole $ _SESSION - ve 4.1 (předtím se používal $ HTTP_SESSION_VARS) .
Pokud to funguje, pak je problém v cookies. Sledujte, jaký druh cookie server vkládá do prohlížeče, zda jej prohlížeč vrací. Vyhledávání je velmi užitečné při pohledu na výměny hlaviček HTTP mezi prohlížečem a serverem.
Vysvětlení toho, jak soubory cookie fungují, je nad rámec tohoto již tak velkého textu, ale alespoň se ujistěte, že server odešle cookie s identifikátorem a prohlížeč se vrátí. A zatímco se identifikátory navzájem shodují =)
Nastavení cookie by mělo vypadat takto
Set-Cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6;
nebo jak
Set-Cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; cesta = /
(pokud požadujete skript nikoli z kořenového adresáře)
Odpověď serveru by měla vypadat takto
Soubor cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6
nebo
Soubor cookie: PHPSESSID = prlgdfbvlg5fbsbshch6hj0cq6; b = b
pokud prohlížeč vrátí jiné soubory cookie kromě ID relace.

Pokud prohlížeč nevrací soubory cookie, zkontrolujte, zda soubory cookie vůbec fungují.
Ujistěte se, že doména, ke které přistupujete, má normální název (který má alespoň jednu tečku a neobsahuje zakázané znaky, jako jsou podtržítka) a vymažte mezipaměť prohlížeče – to jsou dva hlavní důvody, proč soubory cookie nemusí fungovat.

Pokud příklad zde funguje, ale váš vlastní kód ne, pak problém zjevně není v relacích, ale v algoritmu. Hledejte, kde jste proměnnou ztratili, přeneste příklad odsud krok za krokem, odlaďte svůj skript.

Další problém může nastat, pokud používáte přesměrování hlavičky nebo navigaci v JavaScriptu.
Faktem je, že PHP automaticky připojuje identifikátor relace pouze k odkazům formuláře , ale nedělá to pro záhlaví, javascript, meta tagy.
Proto musíte identifikátor přidat ručně, například takto:
záhlaví ("Umístění: /script.php?". název_relace (). "=". id_relace ());

Problém je také velmi vzácný a není zcela jasné, odkud problém pochází, že nastavení session.save_handler má jinou hodnotu než soubory. Pokud tomu tak není, opravte to.

Bezpečnost
Zabezpečení relace je rozsáhlé téma. Proto se zaměřím na několik hlavních bodů.
Nejučebnicovější věcí je nepředávat identifikátor přes adresní řádek. To je napsáno i v php.ini, ale to omezuje funkčnost relací. Pokud se rozhodnete řídit se touto radou, pak kromě session.use_trans_sid = 0 nezapomeňte session.use_only_cookies = 1
Je vhodné svázat relaci s IP adresou: tímto způsobem, pokud je identifikátor odcizen, darebák jej stále nebude moci ve většině případů použít.
Doporučuje se použít direktivu session.save_path, pomocí které si můžete nastavit vlastní adresář pro ukládání souborů session. To je bezpečnější, než když jsou uloženy ve výchozím sdíleném dočasném adresáři serveru.

Dodatečné informace:

Kromě cookies posílá mechanismus relace také hlavičky, které zakazují ukládání stránek do mezipaměti (stejný omezovač mezipaměti). Pro html je to správné a nutné. Ale když se pokusíte odeslat soubor se skriptem, který kontroluje autorizaci, Internet Explorer jej odmítne stáhnout. Je to kvůli tomuto titulu. Volání
session_cache_limiter ("soukromé");
musí vyřešit problém před zahájením relace.

I když se to může zdát divné, ale nemůžete použít číselné indexy v poli $ _SESSION - $ _SESSION, $ _SESSION ["10"] - relace nebudou fungovat.

Někde mezi 4.2 a 5.0 nebylo možné nastavit session.use_trans_sid pomocí ini_set (). Od verze 5.0 je to již možné.

Před verzí 4.3.3 odesílal soubor cookie PHP soubor cookie pouze v případě, že požadavek na začátku relace neobsahoval identifikátor. Nyní je cookie odesláno pokaždé, když je zavoláno session_start ().

Příklad autorizace pomocí relací
Pojďme si vše výše uvedené ilustrovat na malém příkladu:
vytvoříme soubor auth.php:
if (isset ($ _ POST ["auth_name"]))
{
$ sql = "SELECT * FROM users WHERE name =? S";
$ row = $ db -> getRow ($ sql, $ _POST ["auth_name"]);
if ($ řádek && password_verify ($ _POST ["auth_pass"], $ řádek ["pass"])) (
$ _SESSION ["user_id"] = $ řádek ["id"];
}
záhlaví ("Umístění: http: //". $ _SERVER ["HTTP_HOST"]. $ _SERVER ["REQUEST_URI"]);
výstup;
}

if (isset ($ _ GET ["akce"]) AND $ _GET ["akce"] == "odhlášení") (
session_start ();
session_destroy ();
záhlaví ("Umístění: http: //". $ _SERVER ["HTTP_HOST"]. "/");
výstup;
}

if (! isset ($ _ SESSION ["user_id"])) (
?>

výstup;
}

Nyní stačí ve všech chráněných skriptech napsat řádek
vyžadovat "auth.php";
V tomto příkladu se předpokládá, že relace již začala a připojení k databázi bylo vytvořeno pomocí Class pro bezpečnou a pohodlnou práci s MySQL. Rovněž předpokládá, že heslo bylo zahašováno pomocí doporučené funkce password_hash.
Příklad chráněného souboru:

session_start ();
zahrnout "safemysql.class.php";
$ db = nový safemysql (["db" => "test"]);
zahrnout "auth.php";
?>
tajný

odhlásit se

OPS! Velmi užitečné odkazy:
http://www.php.net/manual/ru/ref.session.php – nejnovější a aktuální informace o podpoře relací v PHP v oficiální dokumentaci plus četné komentáře uživatelů. Čtení vysoce doporučeno.
http://phpclub.ru/manrus/f/ref.session.html - VELMI zastaralý překlad této kapitoly do ruštiny z dokumentace přeložené Alexandrem Pyramidinem.
http://phpclub.ru/detail/article/sessions
Článek s honosným názvem „The Truth About Sessions“. Zanechává ambivalentní dojem. Na začátku autor mluví o mechanismu relace VELMI snadno, ale metody, které navrhuje ke konci článku, jsou zcela blátivé.

Učebnicový článek Dmitrije Borodina z webu
http://php.spb.ru/ se důrazně NEDOPORUČUJE.
Kluci, je strašně zastaralá. Nejen, že jsou v něm faktické nepřesnosti, ale sessions v PHP se prostě už dávno nepoužívají.
Dima za ni moc děkuji, tohle byl první článek o sezeních v ruštině, sám jsem to studoval, ale teď ji potřebuji poslat na zasloužený odpočinek.
Také mnoho dalších článků, které jsou na internetu a léta neaktualizované, je bohužel také zastaralých.

Relace (z latiny - sessio - meeting, anglicky - session) je časový úsek, který pokrývá práci uživatele na internetu od okamžiku otevření prvního odkazu po poslední odkaz. Vypočítá se jako časový rozdíl mezi počátečními a konečnými požadavky. Poslední stránku si však uživatel může prohlížet různě dlouhou dobu, od čehož je měření doby mezi dvěma požadavky obtížnější.

Jak souvisí relace s HTTP a COOKIES

Co je relace, lze vysvětlit pomocí protokolu HTTP. Tento protokol sám o sobě neposkytuje způsob, jak přetrvávat stav mezi dvěma operacemi. Jinými slovy, otevřením jedné stránky a následným přechodem z ní na druhou nebude HTTP schopen zjistit, že oba požadavky patří stejnému uživateli. A právě zde přichází na pomoc speciální sledovací metoda – správa relací (naše relace).
Odpovědí na otázku, co je relace, tedy můžeme říci, že jde o pomocný logický objekt, který usnadňuje přenos dat mezi po sobě jdoucími požadavky HTTP od jednoho uživatele.
Soubory cookie, stejně jako relace, ukládají informace o uživateli, když prochází různými stránkami, a zlepšují fungování protokolu. Ale na rozdíl od druhého, kde jsou data uložena v dočasných souborech na serveru, ukládají je v počítači uživatele ve formě malých fragmentů.

K čemu jsou relace?

Používání relací se stává nepostradatelným při práci s weby, jako jsou fóra, nástěnky a online obchody, protože v tomto případě je nutné uložit uživatelská data na více stránkách.

Fáze relace

Celé sezení lze rozdělit do tří fází:

• otevření relace (když uživatel začne pracovat s konkrétním webem),
• účtování proměnných relace (při přechodu na různé stránky),
• konec relace.

Vzhledem k tomu, že data relace jsou uložena na serveru třetí strany, je nejlepší na ně neukládat velké množství informací, ale používat soubory cookie.

Sessions v PHP aneb jak se ukládají data o uživateli nebo zákazníkovi, který vstoupil na stránky, při navigaci mezi stránkami webu bez větších potíží. Lekce je velmi důležitá. Relevantní pro vytvoření 95 % webů.

Co je session v php

Relace se používají k ukládání informací o dočasných datech (například o tom, že uživatel vstoupil na web) při procházení mezi stránkami stejného webu. Při používání relací se data ukládají do dočasných souborů na serveru.
Nejčastěji se relace (a mimochodem také soubory cookie) používají při vytváření internetových obchodů, fór, nástěnek, sociálních sítí, blogů a dalších zdrojů. Pohodlí relace systému spočívá v ukládání dočasných informací přihlášeného uživatele/zákazníka, o kterých jsou údaje po určitou dobu v rychlém přístupu. Relace má přirozené datum vypršení platnosti – do zavření prohlížeče. Pokud zavřete pouze stránku, pak při otevření stránky budou údaje o uživateli / kupujícím stále dostupné.

Logika relace

Session (neboli session) je druh dočasného úložiště dat. Hned vás varuji, že se vyplatí ušetřit malé množství dat. Například přihlašovací jméno a heslo přihlašujícího se uživatele nebo jeho sériové číslo v databázi.

Ukázka práce
1. Uživatel zadá uživatelské jméno a heslo a vstoupí na web
2. Údaje s přihlašovacím jménem a heslem jsou uloženy v relaci jedné ze stránek webu:

Soubor index.php

Session_start (); // každý soubor, ve kterém chcete použít data relace, musí na začátku kódu obsahovat příkaz "start session".

$ login = "admin";
$ heslo = "pass";
$ _SESSION ["login"] = $ přihlášení; // uložení proměnné obsahující login
$ _SESSION ["heslo"] = $ heslo; // uložení proměnné obsahující heslo

3. Když přejdete na jinou stránku webu, budou k dispozici také tato data:

Soubor example.php(nebo jakákoli jiná stránka)

Echo "Vaše přihlášení". $ _ SESSION ["přihlášení"]; // zobrazí "Vaše přihlašovací jméno je admin", ačkoli jsme na této stránce nezaznamenali data!
Vidíte, je to jednoduché!

4. Pokud chcete vymazat data relace, stačí:

Soubor example.php

Session_start (); // "zahájit relaci" znovu

Zrušeno ($ _ SESSION ["přihlášení"]); // takto byla proměnná odregistrována nebo "zničena"
echo "Vaše přihlášení". $ _ SESSION ["přihlášení"]; // zobrazí "Vaše přihlášení". Protože jsme to zničili v posledním řádku, nejsou tam ani žádná data.

Session_destroy (); // zničit relaci. Všechna data včetně $ _SESSION ["heslo"] jsou pryč. Na požádání se zobrazí chyba
Obecně je takový přenos podobný metodě POST, ale již nemusíte psát mnoho zbytečného kódu a všechna data přenášená ze stránky na stránku jsou uložena v dočasných souborech na serveru. Opět platí, že relace by měly obsahovat malé množství dat, takže jsou vhodné pro ukládání uživatelského jména / hesla, nákupního košíku a dalších malých objemů.

Předání hodnoty nebo pole pomocí relace PHP

V relaci můžete psát nejen řetězec, ale také pole dat. Jen to nepřehánějte s velikostí pole, protože to vše ovlivní výkon a obsazené místo na serveru.

Opět použijeme určitou úvodní stránku index.php

Session_start ();

$ r = pole ("jeden", "dva", "tři");

$ _SESSION ["arr"] = $ r;

Na stránku, kde je vše zobrazeno
Data jsme uložili v relaci a přejděte na odkaz na další stránku, kde zobrazíme všechna data.

Příjemce souboru, stránka test.php kde otevřeme pole

Session_start ();
print_r ($ _ SESSION ["arr"]);
// vypíše
/*
Pole
=> jeden
=> dva
=> tři
*/
?>
Možná budete chtít oprášit nějaký tutoriál. Obecně by mělo být vše jasné.

Další funkce pro práci s relacemi

session_unregister (řetězec)- relace zapomene hodnotu zadané globální proměnné;
session_destroy ()- relace je zničena (například pokud uživatel opustil systém stisknutím tlačítka pro odhlášení);
session_set_cookie_params (int lifetime [, cesta řetězce [, doména řetězce]])- pomocí této funkce můžete nastavit, jak dlouho bude relace žít, nastavením unix_timestamp, který určuje čas smrti relace.

Seznam funkcí pro práci s session (session) v php
session_cache_expire - Vrátí vypršení platnosti aktuální mezipaměti
session_cache_limiter - Získejte a / nebo nastavte aktuální limit mezipaměti
session_commit – alias pro session_write_close ()
session_decode – dekóduje data relace z řetězce
session_destroy - Zničí všechna data registrovaná pro relaci
session_encode - zašifruje data aktuální relace jako řetězec
session_get_cookie_params – Získání parametrů souborů cookie relace
session_id - získá a / nebo nastaví aktuální ID relace
session_is_registered - určuje, zda je v relaci registrována proměnná
session_module_name - Získejte a / nebo nainstalujte modul pro aktuální relaci
session_name - získá a / nebo nastaví název aktuální relace
session_regenerate_id – Změní aktuální ID relace na nově vygenerované
session_register - registruje jednu nebo více proměnných pro aktuální relaci
session_save_path - získá a / nebo nastaví cestu k uložení aktuální relace
session_set_cookie_params – nastavuje parametry cookie relace
session_set_save_handler – nastavuje funkce úložiště relace na úrovni uživatele
session_start - inicializuje data relace
session_unregister – Zruší registraci proměnné z aktuální relace
session_unset - Uvolní všechny proměnné relace
session_write_close - Zapíše data relace a konec relace

Příklady relace

Počítadlo zobrazení stránek během relace. Názorná ukázka práce. Po zavření prohlížeče však odpočítávání začne znovu.

Počítadlo návštěv jedné stránky v rámci jedné relace

// Jednoduchý příklad použití relací bez souborů cookie.
název_relace ("test");
session_start ();
$ _SESSION ["počet"] = @ $ _ SESSION ["počet"] + 1;
?>

Čelit

V aktuální relaci práce s prohlížečem jste otevřeli tuto stránku
čas (s).
Chcete-li toto počítadlo vynulovat, zavřete prohlížeč.
Kliknutím sem stránku obnovíte!
S každým přechodem se počítadlo zvýší o 1)

Děkuji za pozornost! Hodně štěstí ve vašem snažení!

Protože HTTP je protokol klient-server, relace HTTP se skládá ze tří fází:

1. Klient naváže spojení TCP (nebo jiné spojení, pokud není použit transport TCP).
2. Klient odešle požadavek a čeká na odpověď.
3. Server zpracuje požadavek a odešle odpověď obsahující stavový kód a související data.

Počínaje HTTP / 1.1 se po třetí fázi spojení neuzavře, protože klient může iniciovat další požadavek. To znamená, že druhá a třetí fáze se mohou opakovat.

Navazování spojení

Protože HTTP je protokol klient-server, spojení vždy naváže klient. Otevření spojení v HTTP znamená navázání spojení prostřednictvím vhodného transportu, obvykle TCP.

V případě TCP se jako výchozí port HTTP serveru v počítači používá port 80, i když se často používají i jiné, například 8000 nebo 8080. Adresa URL načtené stránky obsahuje název domény a port, které lze vynechat pokud odpovídá výchozímu portu.

Myslíme: Model klient-server brání serveru v odesílání dat klientovi, aniž by tato data výslovně požadoval. K vyřešení tohoto problému používají weboví vývojáři různé techniky: pravidelně ping na server pomocí objektu XMLHTTPRequest Javascript, HTML WebSockets API nebo podobných protokolů.

Odeslání požadavku zákazníka

Po navázání spojení může user-agent odeslat požadavek. (user-agent je obvykle webový prohlížeč, ale nemusí) Požadavek klienta jsou textové direktivy oddělené CRLF (zalomení řádku). Samotná žádost obsahuje tři bloky:

1. První řádky obsahují metodu požadavku a její parametry:
   • cesta k dokumentu - absolutní URL bez uvedení protokolu a názvu domény
   • Verze protokolu HTTP
2. Každý následující řádek je hlavička HTTP a posílá serveru nějaké informace o typech preferovaných dat (například jaký jazyk, jaké typy MIME) nebo pokyny, které mění chování serveru (například neposílat odpověď, pokud je již v mezipaměti). Tyto HTTP hlavičky tvoří blok, který končí prázdným řádkem.
3. Poslední blok je volitelný a obsahuje další údaje. Většinou se používá metodou POST.

Příklady žádostí

Získáme hlavní stránku webu a sdělíme serveru, že uživatelský agent preferuje stránku ve francouzštině, pokud je to možné:

GET / HTTP / 1.1 Host: site Accept-Language: fr

Pozor na prázdný řádek na konci, který odděluje blok dat od bloku záhlaví. Protože požadavek neobsahuje hlavičku Content-Length: HTTP, je datový blok prázdný a server může začít zpracovávat požadavek, jakmile obdrží prázdný řetězec označující konec hlaviček.

Výsledek odeslání formuláře zasíláme:

POST /contact_form.php HTTP / 1.1 Host: site Content-Leng: 64 Content-Type: application / x-www-form-urlencoded name = Joe% 20User & request = Send% 20me% 20one% 20of% 20your% 20catalogue

Metody požadavku

HTTP definuje sadu metod požadavku indikujících požadovanou akci na zdroji. Ačkoli to mohou být také podstatná jména, tyto metody požadavku se někdy označují jako příkazy HTTP. Nejběžnější požadavky GET a POST jsou:

• GET se používá k vyžádání obsahu zadaného zdroje. Požadavek pomocí GET by měl přijímat pouze data.
• Metoda POST odesílá data na server, aby mohl změnit svůj stav. Tato metoda se často používá pro formuláře HTML.

Struktura odezvy serveru

Poté, co připojený agent odešle svůj požadavek, webový server jej zpracuje a odešle odpověď. Analogicky k požadavku klienta jsou odpovědí serveru textové direktivy oddělené CRLF, seskupené do tří různých bloků:

1. První řádek - stavový řádek, se skládá z potvrzení použité verze HTTP a stavu požadavku (a jeho hodnoty v lidsky čitelné podobě).
2. Následující řádky jsou HTTP hlavičky, které klientovi poskytují nějaké informace o odesílaných datech (např. typ, velikost, kompresní algoritmus, tipy pro ukládání do mezipaměti). Stejně jako u požadavku klienta tvoří tyto HTTP hlavičky blok zakončený prázdným řádkem.
3. Poslední blok obsahuje data (pokud existují).

Vzorové odpovědi

Úspěšné načtení webové stránky:

HTTP / 1.1 200 OK Datum: So, 09. října 2010 14:28:02 GMT Server: Apache Poslední změna: Út, 01. prosince 2009 20:18:22 GMT ETag: "51142bc1-7449-479bRakcept55anges" byb29bR7 Content-Length: 29769 Content-Type: text / html(zde je 29769 bajtů požadované webové stránky)

Zpráva, že požadovaný zdroj byl přesunut:

HTTP / 1.1 301 trvale přesunuto Server: Apache / 2.2.3 (Red Hat) Typ obsahu: text / html; znaková sada = iso-8859-1 Datum: So, 09. října 2010 14:30:24 GMT Místo: (toto je nová adresa požadovaného zdroje, očekává se, že si ji klient vyžádá) Keep-Alive: časový limit = 15, max = 98 Accept-Ranges: bytes Přes: Moz-Cache-zlb05 Connection: Keep-Alive X-Cache-Info: caching X-Cache-Info: caching Content-Length: 325 (Obsah obsahuje standardní stránku, která se zobrazí, pokud klient nebude moci přejít na odkaz)

Přesunuto natrvalo

Dokument byl přesunut sem.

---

Server Apache / 2.2.3 (Red Hat) na Port 80

Zpráva, že požadovaný zdroj neexistuje: