Metody udržování stavových informací v protokolu HTTP

Transkript

1 VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE Fakulta informatiky a statistiky Katedra informačního a znalostního inženýrství Metody udržování stavových informací v protokolu HTTP Bakalářská práce Michal Hauzírek Vedoucí práce: PhDr. Otakar Pinkas Září 2004

2 Poděkování Rád bych tímto poděkoval vedoucímu své práce PhDr. Otakaru Pinkasovi za podporu při její tvorbě a mnohé cenné podněty.

3 Prohlášení Prohlašuji, že jsem bakalářskou práci vypracoval samostatně a že jsem uvedl všechny použité prameny a literaturu, ze které jsem čerpal. V Praze dne 2. září 2004 Michal Hauzírek

4 Abstrakt Tato bakalářská práce se zabývá metodami udržování stavových informací v prostředí služby WWW za užití protokolu HTTP. Jejím cílem je v teoretické části zejména zmapovat nejpoužívanější metody udržování stavových informací a jejich výhody a nevýhody. V úvodní části je jednak v souladu s technickými specifikacemi dokumentů RFC popsán samotný protokol HTTP a také důvody, proč v něm není přítomna podpora práce se stavy. Po historickém shrnutí vývoje služby World Wide Web a protokolu HTTP je diskutována potřeba přenosu stavových informací v prostředí WWW. Je konstatováno, že při udržování stavových informací na serveru je rovněž nutno udržovat na straně klienta a přenášet informaci identifikační. Základní metody přenosu informací tak mají opodstatnění v obou případech. Následuje přehled těchto metod. Ty jsou rozděleny do tří skupin. V první jsou ty, které využívají pouze vlastností protokolu HTTP. Sem patří zejména různé způsoby zakódování informací do URI či jejich odesílání metodou POST. Druhá reprezentuje rozšíření protokolu HTTP a v jejím rámci jsou popisovány tzv. cookies. Práce se zabývá jak jejich technologickými záležitostmi, jako jsou jejich jednotlivé varianty a obecná funkčnost, tak také některými dalšími okolnostmi zejména ochrany soukromí. Ve třetí skupině jsou pouze krátce naznačeny některé ostatní metody. V závěru teoretické části je v souvislosti s udržováním stavových informací na serveru a nutností ochrany identifikátoru naznačeno několik typů možných bezpečnostních problémů a některých protiopatření. Praktickou část tvoří jednak testy podpory cookies v různých prohlížečích, ale zejména tvorba aplikace, s jejíž pomocí je možné lépe analyzovat metody užité k přenosu stavových informací na konkrétních serverech.

5 Abstract This bachelor thesis concerns with methods of maintaining state information in the WWW environment using the HTTP protocol. Its aim in its theoretical part is to show the most frequently used methods of maintaining state information and their advantages and disadvantages. In the first part, I describe the HTTP protocol itself (according to the technical specifications in RFC documents) and I also note there some reasons for its statelessness. After historic summary of evolution of the World Wide Web service and the HTTP protocol, there is a discussion about need of maintaining states on the web. I note there the fact, that even when state is maintained on the server side, there must be some piece of information for identification purpose maintained on the client side. So there is always need for methods of transporting state information in both cases. The next text provides overview of those methods. I divided them into three groups. In the first group there are methods, that use only properties of the HTTP protocol. Those are in particular various ways of encoding information in URI or sending it via POST method. The second group represents extension of the HTTP protocol, and there I describe so-called cookies. That part concerns not only with their technological details (such as types of them and their general function), but also some other consequences especially concerning privacy. In the third group I briefly note some other methods. I suggest a few of potential security problems and some countermeasures the end of the theoretical part in connection with server-side state management and need of protection of the IDs. Practical part consists of my tests of cookies support in various browsers, and especially of implementing an application that makes it easier to analyze various methods of state information transport on particular web servers.

6 Obsah Obsah Úvod Protokol HTTP Základy HTTP HTTP HTTP Stavový řádek Hlavičky Metody HTTP Perzistentní spojení Podpora pro virtuální servery Určení délky Vyjednávání o obsahu Spolupráce s proxy a cache Další změny RFC Shrnutí Stavové informace Bezstavovost protokolu HTTP Potřeba udržování stavových informací v protokolu HTTP Stavové informace v prostředí Metody přenosu stavových informací Stavové informace dle významu Práce se stavovými informacemi v prostředí WWW mimo rámec HTTP Přenos stavových informací prostředky HTTP Data zakódovaná do URI Obecná východiska Data za názvem dokumentu Data před názvem dokumentu Formulářová pole HTTP autentizace IP adresa Hlavička From Cookies Základní funkce cookies Specifikace Netscape K původu termínu cookie Hlavička Set-Cookie Chování klienta a hlavička Cookie RFC Okolnosti vzniku Nedostatky specifikace Netscape Neověřitelné transakce a cookies třetích stran Hlavní změny v RFC RCF 2965 a Strana 6

7 Obsah Nekompatibilita Internet Exploreru Další diskutovaná témata Změny v RFC Velké zpoždění a neúspěch RFC Cookies a ochrana soukromí Cookies třetích stran a reklama P3P Mýty okolo cookies Test podpory v prohlížečích Testované prohlížeče Základní možnosti uživatelského nastavení práce s cookies Podpora cookies dle specifikace Netscape Podpora cookies dle RFC Podpora cookies dle RFC Shrnutí výsledků Udržování stavových informací na serveru Ukládání stavových informací Ohrožení identifikátorů relací Odhadnutí Odposlechnutí z komunikace Hlavička Referer Některé možnosti ochrany před zneužitím identifikátoru Shrnutí A.S.I.A.T Uživatelské rozhraní HTTP klient Práce se stavovými informacemi Cookies Formuláře Odkazy a URI Návrh aplikace Závěr...57 Rejstříky vložených tabulek a obrázků...58 Seznam použité literatury Seznam použitých zkratek a termínů...62 Strana 7

8 Úvod Úvod Služba WWW (World Wide Web) postavená mimo jiné na protokolu HTTP 1 se stala bezesporu nejpopulárnější službou internetu vůbec. Zdaleka již neslouží pouze několika málo vědcům a zdaleka již také neslouží pouze pro publikování statických dokumentů. Jejím prostřednictvím je rovněž přistupováno k rozsáhlý aplikacím a bývá také užívána jako brána k některým ostatním službám internetu. S tím je však v rozporu od prvopočátků bezstavový charakter protokolu HTTP. S tím mám také vlastní zkušenosti i proto, že jsem také já osobně v minulosti s tvorbou webových aplikací již také několikrát přišel do styku a byl tak nucen se problematikou stavových informací do jisté míry prakticky zabývat. To byl také jeden z hlavních důvodů, proč jsem si právě tuto problematiku zvolil jako téma své bakalářské práce. Stavové informace je v takových případech nezbytné pro správné fungování těchto dynamických aplikací za pomoci protokolu HTTP nebo některých jeho rozšíření udržovat a přenášet. Právě metody udržování stavových informací v protokolu HTTP jsou tématem této práce. Jejím cílem je na vymezeném prostoru na pozadí vzniku a postupného vývoje protokolu HTTP popsat základní metody pro udržování a přenos stavových informací v prostředí služby WWW. V základním pohledu budou rozděleny na metody udržování na straně klienta a na straně serveru. Jak bude ukázáno, v praxi je ovšem při obou způsobech nutné zajistit přenos určitých informací mezi klientem a serverem. Zmíním se proto zejména o metodách přenosu. A to jak o těch velmi často užívaných, tak i o těch, jejichž použití připadá do úvahy spíše pouze teoreticky. U každé z metod se pokusím upozornit na její nevýhody a nedostatky a naproti tomu také na přednosti, kterými vyniká nad ostatními. Přitom budu do značné míry abstrahovat od otázek spojených s problematikou cacheování a omezím se zejména na otázky přímé komunikace výchozího klienta s cílovým serverem. Poměrně rozsáhle se v teoretické části hodlám zejména ve 4. kapitole věnovat rozšíření protokolu HTTP právě pro udržování a přenos stavových informací (tzv. cookies). Chtěl bych se tomuto tématu věnovat nejen z čistě technologického hlediska, ale také se dotknout souvislostí, které jednak vedly k praktickému ustrnutí jeho dalšího vývoje a také k relativně velké publicitě této problematiky mezi širší veřejností. Tomuto tématu bude věnována i menší část praktického příspěvku této práce totiž otestování několika významných prohlížečů právě na podporu cookies. Zásadní podíl na praktické části si však vyžádá tvorba aplikace, která by měla usnadnit právě analýzu stavových informací na konkrétních serverech zejména co do metody jejich přenosu. 1 Jsem si vědom toho, že 'P' v této zkratce znamená protocol (tedy česky protokol) a užití tohoto slova spolu s ní je tak logicky nadbytečné. Toto spojení však nejen lépe zní, ale hlavně se takto objevuje i samotné originální specifikaci [43]. Budu jej tedy užívat v této práci i nadále. Strana 8

9 1 Protokol HTTP Kapitola 1: Protokol HTTP Protokol HTTP je spolu s jazykem HTML a schématem URI 2 jedním ze tří základních pilířů dnes zřejmě celosvětově nejpoužívanější internetové služby WWW (World Wide Web). Služba WWW se postupně vyvinula z prostředku pro sdílení zejména textových informací mezi vědci ve zcela nové médium, které slouží jako brána pro přístup k jiným službám a to již zdaleka ne pouze internetovým. Je to nyní mimo jiné také specifický marketingový kanál, kterým je možno oslovit široké spektrum zákazníků. Tato poměrně velice výrazná změna jak kvantitativní (počet serverů a koncových uživatelů), tak zároveň i kvalitativní (z toho se odvozující požadavky na funkce a vlastnosti) musely v průběhu času vést k určitým změnám a vylepšením v samotných základech WWW tedy i v protokolu HTTP. 1.1 Základy HTTP Základní filosofie a funkčnost protokolu HTTP zůstala ve všech verzích stejná. Proto ji ukážeme na prvním místě a v dalších subkapitolách potom uvedeme pouze změny a dodatky, které byly k těmto základním principům dodatečně přidány. HTTP je bezstavovým (viz kapitolu 2) aplikačním protokolem. V prostředí internetu tedy tvoří nejvyšší vrstvu nad vrstvou transportní (tvořenou zejména protokolem TCP) a vrstvou síťovou (protokol IP). Komunikace je založena na principu klient/server. HTTP klient (často prohlížeč ale například i proxy server) naváže spojení s HTTP serverem a otevře přenosový kanál. Standardně je pro protokol HTTP na serveru vyhrazen port 80. HTTP neslouží pouze ke komunikaci s WWW servery, ale i ke komunikaci s některými dalšími typy serverů například proxy. Samotná komunikace protokolem HTTP je založena na principu požadavek/odpověď (request/response). Klient po otevření přenosového kanálu odešle serveru požadavek, kterým mu sdělí, jaký dokument po něm vyžaduje. Server odešle klientu odpověď obsahující požadovaný dokument (resp. zprávu o chybě, pokud takový dokument z libovolného důvodu nemůže poslat 3 ). Server po odeslání odpovědi přenosový kanál uzavře a spojení ukončí. Pokud si chce klient vyžádat od serveru další dokument, celý postup (včetně otevření nového přenosového kanálu 4 ) se opakuje. Komunikace, jak byla popsána nemusí probíhat přímo mezi koncovým klientem (webovým prohlížečem uživatele) a cílovým serverem, na kterém se nachází požadovaný dokument. Mezi nimi může existovat několik prostředníků či zprostředkovatelů. Ti mohou, například v podobě proxy serveru, fungovat jako server ve vztahu k prohlížeči a jako klient ve vztahu k cílovému serveru (případně dalšímu prostředníkovi). Je také možné, že některý z prostředníků má požadovaný dokument uložený z některého z předchozích požadavků, které jím procházely. V takovém případě ho za daných podmínek 5 může vrátit klientu (koncovému uživateli nebo předcházejícímu prostředníkovi) jako odpověď (tzv. caching). Popsané situace znázorňují následující obrázky. Obrázek 1 ukazuje situaci několika dotazů přímo na cílový server. Obrázek 2 požadavky několika koncových klientů, které procházejí přes proxy server. 2 Dříve se v souvislosti s WWW častěji užívalo v témž smyslu spíše termínu URL K této problematice viz [54] a [42]. 3 Může jít o prostý případ, kdy se požadovaný dokument na serveru nenachází, ale také například když k jeho získání nemá server (nebo klient) potřebná oprávnění. Nastat může i situace, kdy dojde na straně serveru k chybě apod. 4 S výjimkou tzv. perzistentního spojení definovaného v HTTP 1.1 (viz subkapitolu 1.4.1) případně v některých rozšířených implementacích HTTP Například stáří takového dokumentu, to, zda si jeho autor přeje, aby byl po cestě ukládán, zda koncový uživatel chce přijmout uloženou verzi dokumentu apod. Strana 9

10 Kapitola 1: Protokol HTTP Na obrázku 3 je zachycena situace, kdy je prostředníkem na cestě mezi koncovým klientem a cílovým serverem (CS) jiný proxy server, který pracuje také jako cache. V zobrazeném případě má tento server k dispozici dostatečně čerstvou uloženou kopii požadovaného dokumentu a proto ji může klientovi odeslat místo cílového serveru a ušetřit tak přenosové kapacity. Obrázek 1: Opakovaný požadavek v HTTP s vyznačením otevíraných spojení Obrázek 2: Použití proxy serveru Obrázek 3: Použití cache v HTTP 1.2 HTTP 0.9 První verze protokolu HTTP (v současnosti se o ní mluví jako o verzi HTTP 0.9 ač se tak původně nenazývala) byla velmi jednoduchá[5]. Pro původní účely tj. přenos hypertextu (textových dokumentů provázaných odkazy) protokol docela dobře postačoval. Základní struktura již byla naznačena výše. Formát požadavku sestával z jediné řádky textu. Na začátku bylo klíčové slovo GET, následovala mezera, potom adresa dokumentu bez jména serveru a portu tedy pouze její část s cestou tj. od znaku /. Celý požadavek byl zakončen znaky pro konec řádku (CR LF). Odpověď serveru tvořil samotný dokument v jazyce HTML. Jiný formát se nepředpokládal a ani nebyl dovolen. Prostý text měl být odesílán rovněž jako HTML dokument v tagu <PLAINTEXT>. Případnou chybu měl server oznámit stejným způsobem odeslat HTML dokument s popisem chyby. V této verzi protokolu tedy nebylo možné nijak automatizovaně rozeznat úspěšný přenos od chyby, neboť jediný kdo mohl rozeznat výsledek, byl člověk, který si získaný dokument přečetl. Následuje jednoduchý příklad požadavku a odpovědi v HTTP 0.9 (požadavek je kurzívou): GET /index.htm <html>... </html> Strana 10

11 1.3 HTTP 1.0 Kapitola 1: Protokol HTTP Výše popsaný velice jednoduchý protokol si s sebou nesl několik problémů. Jedním z nich bylo to, že jediný způsob, kterým se klient mohl dozvědět délku získávaného dokumentu, bylo ukončení spojení se serverem 6. S rozšiřováním požadavků na WWW (a vylepšováním jazyka HTML) vyvstal také problém s přenosem jiných typů dokumentů (zejména obrázků). Obrázky vložené v HTML dokumentech jsou samostatné soubory s vlastním URI získávají se tedy samostatným HTTP požadavkem. Bylo proto žádoucí, aby klient mohl dopředu rozpoznat typ získávaného dokumentu a mohl ho odpovídajícím způsobem interpretovat 7. Dalším problémem raných verzí tohoto protokolu je již zmiňovaná nemožnost automaticky detekovat chybu v komunikaci. Objevila se také potřeba určité interaktivity tj. schopnosti zasílat serveru data pro další zpracování. Původní jednoduchý koncept HTTP 0.9 tak byl rozvinut do komplexnějšího protokolu označovaného jako HTTP 1.0. Tato verze je popsána v dokumentu RFC 1945[38] vydaném v únoru Tento dokument však není standardem ve smyslu, že by předepisoval správné postupy a metody práce HTTP 1.0. Jde o ex-post sepsaný dokument, který reflektoval soudobý stav implementace HTTP. Hlavní změny oproti HTTP 0.9 spočívají zejména v rozšíření odpovědi serveru z pouhého těla dokumentu o stavový řádek a hlavičky s meta informacemi. Také požadavek lze rozšířit o hlavičky, které jsou však nepovinné Stavový řádek Jeden z dříve nastolených problémů původní verze HTTP totiž nerozlišitelnost chybového hlášení od dokumentu je od této verze řešena zavedením stavového řádku. Odpověď serveru již není pouze samotný dokument, předchází mu stavový řádek a většinou ještě hlavičky. Stavový řádek je první řádek odpovědi, který má přesně danou strukturu. Začíná označením použité verze HTTP tj. znaky HTTP/ s číslem verze v desetinném formátu (zde tedy 1.0). Následuje mezera a trojciferný kód, který udává výsledek operace. Stavový řádek pokračuje mezerou odděleným slovním popisem kódu a končí znaky konce řádku (CR LF). Klient tedy může automaticky podle kódu zjistit, jaký byl výsledek požadavku. Programu je srozumitelný číselný kód a uživateli může být zobrazen slovní popis 8. Stavové kódy jsou rozčleněny do pěti tříd. Kódy začínající číslicí 2 (tedy čísla v rozmezí 200 až 299) značí úspěch. Počáteční číslice 3 potom uvádí přesměrování na jinou adresu. Čtvrtá třída znamená neúspěch způsobený chybou na straně klienta a poslední pátá chybu na straně serveru. Stavové kódy začínající jedničkou jsou vyhrazeny jako informativní a v HTTP 1.0 není žádný definován. Jinak RFC 1945 uvádí význam celkem patnácti kódů z ostatních tříd. Kódy dělitelné stem jsou obecné a reprezentují celou třídu. Pokud klient nerozumí některému konkrétnímu kódu, může jej interpretovat tak, jako by to byl právě tento obecný. Problém identifikace chyb byl tedy vyřešen stavovým řádkem. Další problémy, týkající se typu dokumentu a jeho délky řeší hlavičky. 6 Teoreticky by přicházela v úvahu kontrola obsahu a hledání tagu </HTML>, který značí konec HTML dokumentu. Tento způsob je však nevhodný hned z několika důvodů: zasahuje o úroveň níže pod samotný protokol. Navíc je použitelný pouze pro HTML dokumenty (a to ještě pouze ty se správnou strukturou). 7 Podobně jako GOPHER klient rozlišuje menu, textový soubor, binární soubor apod. 8 Případně může program podle kódu zobrazit jiný vysvětlující text například v jazyce uživatele. Strana 11

12 1.3.2 Hlavičky Kapitola 1: Protokol HTTP Mechanismus hlaviček byl přebrán z podobného konceptu hlaviček internetové pošty. Hlavičky se odesílají před samotným dokumentem a každá je tvořena jedním řádkem textu. Hlavička sestává z názvu a hodnoty. Název a hodnota jsou odděleny dvojtečkou a celá hlavička je zakončena znaky pro konec řádku (CR LF). Od těla odpovědi respektive požadavku 9 se hlavičky oddělují jedním prázdným řádkem (tedy kombinací znaků CR LF). Hlavičky poskytují dodatečné informace k přenášenému dokumentu a k požadavku respektive odpovědi. RFC 1945 uvádí základních šestnáct hlaviček 10. V příloze D, kde jsou uvedeny některé další vlastnosti podporované pouze v několika implementacích, je jich potom dalších deset 11. Podle toho, ke které části komunikace se váží, lze hlavičky rozdělit do čtyř skupin. Obecné hlavičky (General-Header) se váží pouze k danému spojení. V hlavičce Date je uvedeno datum jeho uskutečnění a hlavička Pragma byla určena pro případné prostředníky při spojení (konkrétně cache). Další skupinu tvoří hlavičky požadavku (Request-Header). Ty odesílá klient a týkají se tohoto konkrétního požadavku 12. Kromě autentizačních údajů, identifikace klientského programu a hlavičky pro podmíněný požadavek jsou pro další kapitoly zajímavé zejména následující dvě hlavičky z této skupiny. První z nich je Referer 13, která jako svou hodnotu obsahuje URI dokumentu, ze kterého byl uživatel na požadovaný dokument odkázán. Totéž platí i pro požadavky na vložené objekty (například obrázky), v tomto případě se jako referer odešle URI dokumentu obsahujícího tento objekt. Autor či správce webu tak může analýzou těchto údajů zjistit, odkud na jeho stránky návštěvníci přicházejí a v případě změny struktury webu může autory příslušných odkazujících stran informovat. Zároveň však může tato hlavička znamenat v jistých případech a při nesprávně navrženém zabezpečení webové aplikace určité riziko viz kapitolu 5. Některé prohlížeče (také s přihlédnutím k určitému stupni narušení soukromí ) umožňují tuto hlavičku neodesílat, případně odesílat ji v pozměněné podobě. Hlavička From by měla obsahovat elektronickou adresu uživatele zodpovědného za odeslaný požadavek. Původně měla zřejmě sloužit pro případné upozornění uživatelů, kteří zasílali určitým způsobem nesprávné požadavky. Dnes je ale používána jen v minimu případů (například automatické programy pro indexování apod.). V běžných případech není prohlížeči odesílána, neboť by tím docházelo k obdobné situaci jako u cookies třetích stran viz dále (navíc zhoršené tím, že by byla odesílána s úplně všemi požadavky). A nejen to internetová poštovní adresa může do jisté míry identifikovat konkrétního uživatele, navíc by na ni v důsledku takovéhoto rozšiřování začalo velmi rychle přicházet velké množství nevyžádané reklamní pošty. Třetí skupinou jsou hlavičky odpovědi (Response-Header). Ty umožňují serveru představit svůj software, přesměrovat klienta na jinou adresu, případně ho vyzvat k zadání autentizačních údajů. A konečně poslední skupinou jsou hlavičky, které se váží k tělu odpovědi respektive požadavku (Entity-Header). Ty popisují přenášený dokument tedy jeho typ (Content-Type), dále datum poslední úpravy (Last-Modified), případné transformace (například komprimace) (Content- 9 Jak bude uvedeno dále, HTTP 1.0 umožňuje pomocí metody POST odesílat data také v požadavku general, 5 request, 3 response a 6 entity viz dále rozdělení hlaviček 11 1 general, 4 request, 1 response a 4 entity viz dále rozdělení hlaviček 12 V případě hlavičky Referer jde však jistým způsobem spíše o požadavek předcházející viz dále. 13 Správný název by dle anglického pravopisu měl zřejmě být Referrer (tedy s dvěma 'r'), tato chyba je však již vžitá a hlavně implementovaná v mnoha HTTP klientech i serverech Strana 12

13 Kapitola 1: Protokol HTTP Encoding) a samozřejmě délku v bytech (Content-Length). V případě, že délka není uvedena, platí nadále, že dokument končí ukončením spojení Metody HTTP ve verzi 1.0 rozšiřuje možnosti také tím, že zavádí dvě nové metody, kterými lze komunikovat se serverem. Kromě metody GET již známé z předchozí verze, to jsou metody POST a HEAD. V již jednou zmiňované příloze D dokumentu RFC 1945 jsou popsány mj. ještě metody pro vytváření a mazání souborů na serveru (PUT a DELETE). Odlišná metoda v požadavku způsobí odlišné zpracování tohoto požadavku serverem. Jméno metody tvoří první část prvního řádku požadavku. Pomocí metody HEAD klient serveru sděluje, že nechce získat tělo dokumentu ale pouze příslušné hlavičky. Odpověď na tuto metodu je tedy stejná (co se týče hlaviček a stavového řádku), jako kdyby požadavek přišel metodou GET, ovšem bez samotného těla dokumentu. To je výhodné například při testování platnosti odkazů, kdy je potřeba pouze zjistit, zda cílový dokument existuje a není třeba si vyžadovat jeho obsah. Oproti tomu metoda POST umožňuje klientu odeslat spolu s požadavkem (v jeho těle) data, která server zpracuje. Může jít například o data odeslaná z HTML formuláře. Jejich délka však musí být výslovně uvedena v hlavičce Content-Length a to z toho zřejmého důvodu, že zde nelze použít pro určení jejich délky konec spojení. Pokud by totiž klient během odesílání svého dotazu uzavřel přenosový kanál, nemohl by jím server vrátit svou odpověď. Pro odlišení požadavku verzí 0.9 a 1.0 se ve verzi 1.0 za adresu dokumentu vkládá mezerou oddělené označení verze ve stejném formátu, jaký je použit ve stavovém řádku odpovědi (tedy HTTP/1.0). V HTTP 1.0 totiž musí server počkat ještě na případné hlavičky. Opět následují dva jednoduché příklady požadavků a odpovědí ve verzi HTTP 1.0: GET /index.html HTTP/1.0 (prázdný řádek ukončující hlavičky) HTTP/ OK Date: Wed, 1 Aug :56:00 GMT Server: Apache/1.3.7 (FreeBSD) Content-Length: Content-Type: text/html; charset=iso (...) POST /index.php HTTP/1.0 Content-Length: HTTP/ Not Found Date: Wed, 1 Aug :00:29 GMT Server: Apache/1.3.7 (Win32) Content-Length: 301 Content-Type: text/html; charset=iso (...) Strana 13

14 1.4 HTTP 1.1 Kapitola 1: Protokol HTTP Rychlý růst popularity služby WWW jak mezi koncovými uživateli, tak mezi poskytovateli obsahu, kteří se stále více rekrutovali z řad obchodníků (které samozřejmě lákal rostoucí počet uživatelů jako potenciálních zákazníků) s sebou přinášel, co se týče protokolu HTTP, zejména dva další problémy. Nebyly to problémy nové, oba lze snadno vystopovat již od počátků, ovšem dokud bylo uživatelů poměrně málo a přenášené HTML dokumenty relativně jednoduché, nijak výrazně se neprojevovaly. Prvním problémem je to, že jak již bylo řečeno a jak to dobře ukazuje Obrázek 1 na straně 10, během jednoho spojení je možné přenést pouze jeden dokument. Poměrně náročná operace navázání spojení tak musí být mnohokrát opakována v případech, kdy je k jednomu HTML dokumentu připojeno několik dalších dokumentů (zejména obrázků, ale i skriptů, souborů stylů, animací a podobně). Pokaždé je přenesen pouze jeden takový objekt a spojení je opět uzavřeno. Tímto způsobem se prohlížení takových graficky bohatých dokumentů stává pomalým a náročným na výkon. Další problém souvisí s tím, že v požadavku se nikde neobjevuje jméno serveru, které je součástí adresy dokumentu. HTTP klient si z úplné adresy dokumentu (například dotazem na DNS server) zjistí IP adresu koncového serveru a naváže s ním spojení. V požadavku se pak objevuje pouze část adresy za jménem serveru (a případným portem). Tato situace tedy předpokládá, že pro každé jméno serveru použité v URI, existuje jiná IP adresa 14. Takto byl původní protokol skutečně koncipován. Problém však nastal v době, kdy se vlastnictví vlastního lukrativního doménového jména (samozřejmě spolu s na něm běžícím HTTP serverem) stalo prestižní či ještě o něco později módní záležitostí. Navíc se stále rostoucí oblibou WWW si chtěly společnosti vytvářet WWW servery nejen s názvy svých firem, ale rovněž s názvy značek svých výrobků. Někteří lidé zase toužili po doménovém jménu odpovídajícím jejich jménu skutečnému. Tato fakta ještě více zhoršila situaci, kdy začalo hrozit brzké vyčerpání dostupných 32-bitových IP adres 15. Bylo tedy žádoucí umožnit na jedné IP adrese (na jednom portu) provozovat více oddělených virtuálních serverů s odlišnými doménovými jmény. Jinými slovy bylo potřeba do samotného protokolu HTTP nějakým způsobem dodat podporu pro doménová jména. Tyto dva důvody patřily mezi hlavní impulsy pro další verzi protokolu HTTP 1.1. První z problémů byl vyřešen zavedením perzistentních spojení, druhý potom povinnou hlavičkou požadavku Host. Kromě toho byly do protokolu zakomponovány některé další vlastnosti jako například podpora vyjednávání o obsahu a částečných přenosů. V neposlední řadě do specifikace přibylo velké množství textu týkajícího se spolupráce s proxy a cache servery a rovněž jejich správným chováním. První schválenou a uveřejněnou verzí protokolu HTTP 1.1 je dokument RFC 2068 z ledna roku 1997 [39]. Ten byl nahrazen dalším dokumentem RFC 2616 uveřejněným v červnu 1999 [43]. Změny mezi těmito dvěma dokumenty nejsou zdaleka tak výrazné (číslo verze také zůstalo stejné tedy 1.1) a ještě o nich bude řeč. Oba dokumenty byly (na rozdíl od RFC 1945) vydány jako standardy IETF. 14 Pokud abstrahujeme od jiných portů, než výchozího tj Tento problém nebyl způsoben pouze protokolem HTTP, ale má hlubší kořeny v samotném systému fungování a přidělování adres. Blíže k tomuto problému a jeho řešením, která se netýkají protokolu HTTP viz např. [34] Strana 14

15 1.4.1 Perzistentní spojení Kapitola 1: Protokol HTTP V předchozích odstavcích naznačený koncepční nedostatek způsoboval při mnohonásobných opakovaných požadavcích potíže jak na straně klientů, tak na straně serverů a snižoval výkonnost na obou stranách (k dané problematice viz například [52]). Dobrým řešením se ukázalo být perzistentní spojení. Tím se myslí ta skutečnost, že server po odeslání odpovědi neuzavře ihned přenosový kanál, ale ponechá jej po nějaký (krátký) časový interval otevřený. Klient jím posléze může poslat další svůj případný požadavek 16. Odpadá tím nákladné ukončování a znovunavazování spojení. Dle slov autorů standardu nebylo zejména kvůli možným problémům se staršími proxy servery možné identifikovat užití perzistentního spojení nějakou speciální hlavičkou. Ty by je totiž (jakožto jim neznámé) mohly přeposílat dál, přestože tento způsob práce sami nepodporují. Pokud by se potom spojily se serverem, který takto pracovat umí, mohly by s odesláním odpovědi čekat teprve do uzavření spojení s koncovým serverem, což by práci s nimi výrazně zpomalilo. Perzistentní spojení tak bylo zvoleno za výchozí stav pro verzi protokolu HTTP 1.1. Pokud kterákoli ze stran komunikace nechce použít perzistentního spojení, odešle ve své zprávě hlavičku Connection: close. V případě popsaném výše (starší proxy server) koncový server perzistentní spojení neužije, neboť požadavek na něho bude ve verzi HTTP 1.0, kde toto není implicitní. Perzistentní spojení je možné využít také k odeslání více požadavků bez nutnosti čekat na jednotlivé odpovědi (tzv. pipelining). Tím je možné také do jisté míry zlepšit efektivnost přenosu, nicméně ne všechny HTTP servery tuto možnost (korektně) podporují a to v některých případech může vést namísto ke zrychlení a zefektivnění komunikace k pravému opaku. Obrázky 4 a 5 znázorňují perzistentní spojení a pipelining (srov. s obrázkem 1 na straně 10). Obrázek 4: Opakovaný požadavek v HTTP při perzistentním spojení Podpora pro virtuální servery Obrázek 5: Opakovaný požadavek v HTTP při perzistentním spojení a pipeliningu Druhý ze zásadních problémů, které se k předchozí verzi protokolu HTTP vázaly, byl vyřešen pomocí nové hlavičky požadavku 17. Ta nese název Host a jejím obsahem je doménové jméno serveru (včetně případného portu), ze kterého klient požaduje zaslat odpověď. Tato nová hlavička je, na rozdíl od všech ostatních hlaviček požadavku, ve verzi 1.1 povinná. Pokud server obdrží HTTP 1.1 požadavek, který ji neobsahuje, musí odpovědět chybovým hlášením s kódem 400 tj. chybný požadavek. Tak je možné úspěšně provozovat na jedné IP adrese velké množství virtuálních serverů. Pokud na konkrétní IP adrese není provozováno více virtuálních serverů, pracuje vše tak, jak bylo naznačeno dříve. Jestliže jich tam více existuje, software serveru podle hlavičky Host, kterou si 16 Tím se ovšem nic nemění na tom faktu, že každý z požadavků je nezávislý a s každým se zachází tak, jako by byl první. Protokol i tak zůstává bezstavový, jedinou změnou je, že se v jednom přenosovém kanálu vyřídí více požadavků. 17 Jinou možností řešení, která se nabízela bylo přidání doménového jména přímo adresy požadavku resp. přechod na absolutní adresy v požadavku. Strana 15

16 Kapitola 1: Protokol HTTP přečte v požadavku, zvolí dokument například z odpovídajícího adresáře a ten vrátí. Standard RFC 2068 rovněž požaduje, aby s požadavky, které obsahují úplnou URI adresu (tedy včetně doménového jména), uměly pracovat nejen proxy 18, ale také ostatní servery. V některé z potenciálních budoucích verzí HTTP by tak mohlo dojít k případnému úplnému přechodu na absolutní URI ve všech požadavcích Určení délky Již dříve bylo řečeno, že délka odpovědi se určovala nejprve uzavřením spojení ze strany serveru (což nebylo zcela vyhovující), později potom pomocí hlavičky Content-Length. Ta musí být samozřejmě odeslána již před samotným dokumentem. U statického obsahu není pro server problém zjistit velikost souboru, který bude odeslán. S příchodem dynamicky generovaných dokumentů však může nastat potíž. Ta spočívá v očividném faktu, že server nemusí předem vědět, jak dlouhý obsah bude (například externí aplikací či CGI skriptem) vygenerován. Pokud se jedná o poměrně malý objem dat, jehož generování navíc trvá velmi krátkou dobu, může server, na jeho skončení počkat a odeslat jej celý najednou s příslušnou hlavičkou označující délku. Naproti tomu probíhá-li vytváření obsahu pomalu, nebo je-li dat velké množství, vznikají nepříjemné prodlevy. V takovém případě by určitým řešením byl jakýsi krok zpět, totiž neodesílat hlavičku s údajem o velikosti a data posílat postupně tak, jak jsou vytvářena. Klient by potom jejich délku určil koncem spojení. Tento přístup však není možný, bude-li využito výhod perzistentního spojení (viz výše). Po odeslání dokumentu se totiž spojení po nějakou dobu neuzavírá. HTTP 1.1 proto přichází s jiným řešením nastíněného problému. Tím je chunked encoding 19 tj. jistý způsob zakódování přenášených dat tak, že jsou posílána po částech a každá z těchto částí je uvozena svou vlastní délkou. Délka kažné takové části se uvádí na samostatném řádku odpovědi jako hexadecimální číslo vyjadřující počet bytů této části. Následuje řádek s příslušnými daty. Úplný konec dokumentu je signalizován řádkem oznamujícím nulovou délku. Za ním mohou ještě následovat některé HTTP hlavičky týkající se přenášeného dokumentu (tzv. footer 20 ). Použití tohoto způsobu přenosu se označuje hlavičkou Transfer-Encoding: chunked. Na rozdíl od předchozí verze, kdy byla délka určována hlavičkou Content-Length a v případě její nepřítomnosti ukončením spojení, v HTTP 1.1 je spektrum možností, jak určit délku mnohem pestřejší. Standard stanovuje následující pořadí. Odpovědi, u kterých nikdy není přenášeno žádné tělo dokumentu (např. odpovědi na HEAD či některé stavové kódy), končí ihned za hlavičkami. Pokud je použito výše popsané kódování, určí se délka podle něho. Jinak platí hlavička Content- Length a až poté ukončení spojení Vyjednávání o obsahu V této verzi protokolu se objevuje několik hlaviček, které umožňují implementovat tzv. vyjednávání o obsahu (content negotiation). S rozvojem a rozšířením internetu a jeho globálním působením může být žádoucí, aby jeden zdroj byl dostupný v různých svých verzích (například jazykových). Kromě toho, pro přístup k WWW je možné používat různé prohlížeče na různých zařízeních, jejichž zobrazovací schopnosti nejsou stejné. Pomocí vyjednávání o obsahu mohou klient a server 18 Požadavek posílaný přes proxy server musí samozřejmě obsahovat doménové jméno cílového serveru. Toho je dosaženo právě uváděním absolutních URI v požadavcích. 19 z anglického chunk kus, odřezek 20 V novější verzi HTTP 1.1 tj. RFC2616 je nazýván trailer. 21 Ve skutečnosti v této posloupnosti ukončení spojení předchází ještě přenos pouze určené části dokumentu (rozmezí bytů), kde je délka dána explicitně. Strana 16

17 Kapitola 1: Protokol HTTP poskytnout uživateli nejvhodnější podobu požadovaného zdroje (jazykovou mutaci, složitost grafiky apod.). RFC 2068 popisuje tři způsoby vyjednávání. Prvním je vyjednávání řízené serverem (serverdriven). V tomto případě server analyzuje hlavičky, které získal od klienta 22 a na jejich základě (případně i z dalších informací 23 ) se rozhodne, kterou z dostupných reprezentací vrátí. V případě klientem řízeného vyjednávání (agent-driven) server vrátí seznam dostupných reprezentací a klient automaticky jednu vybere, či umožní výběr přímo uživateli. Posledním způsobem je transparentní vyjednávání (transparent), které je kombinací obou předchozích. Blíže k této problematice viz [41]. Obrázek 6 ukazuje příklad vyjednávání o obsahu řízeného serverem 24 způsobem, jakým je například použito ve vyhledávači Google < Obrázek 6: Příklad vyjednávání o obsahu v HTTP Spolupráce s proxy a cache Nově je ve specifikaci HTTP 1.1 věnováno mnoho prostoru spolupráci klientů a serverů s proxy a zejména cache. Je zde definován model pro práci s uloženými dokumenty 25 a mnoho hlaviček pro popis jejich vlastností užívaných právě k těmto účelům. Dále jsou uvedena standardní pravidla pro chování proxy a cache serverů a další hlavičky, které umožňují tato výchozí pravidla pro konkrétní dokumenty či požadavky měnit. Toto téma je zpracováno skutečně podrobně a svým rozsahem přesahuje okruh zájmu této práce Další změny Výše popsané nebyly ani zdaleka veškeré změny a novinky, které se v nové verzi objevily. HTTP 1.1 je poměrně velmi rozsáhlým a komplexním protokolem. Pro představu snad uveďme, že zatímco RFC 1945 má bez příloh 54 stran (s přílohami 60), tak RFC 2068 jich bez příloh má celých 150 (a s přílohami ještě o dvanáct více). I z těchto počtů je tedy zřejmé, že jsme zcela jistě nemohli vyčerpat kompletní přehled změn. Výše zmíněné jsou však těmi nejpodstatnějšími. Z těch zbývajících zde okrajově zmíníme ještě několik. Jak jsme již naznačili, byla zavedena podpora pro vyžádání a přenos neúplných dokumentů (pouze určité rozmezí bytů) například pro navázání stahování již částečně stažených dokumentů. Dále přibyly čtyři nové metody již zmiňované PUT a DELETE a k nim nově ještě OPTIONS umožňující zjistit vlastnosti určitého dokumentu a TRACE, kde je jako odpověď vrácen požadavek tak, jak došel na cílový server. Celkový počet stavových kódů byl rozšířen na 37 a přibylo na třicet nových hlaviček. 22 HTTP 1.1 pro tento účel definuje zejména hlavičky Accept, Accept-Charset, Accept-Encoding a Accept-Language 23 Příkladně IP adresa klienta může být použita pro odlišení domácích a cizích návštěvníků. 24 Pro přehlednost jsou uvedeny pouze Accept- hlavičky a chybí povinná hlavička Host. 25 založený na expiraci (vypršení) platnosti či čerstvosti dokumentu a jeho validaci (ověření) Strana 17

18 1.4.7 RFC 2616 Kapitola 1: Protokol HTTP V červnu roku 1999 byl vydán nový RFC dokument s číslem 2616 (164 stran bez příloh 176 s nimi), který nahradil předchozí specifikaci. V samotném protokolu nebyly provedeny zásadnější změny, šlo spíše o precizaci některých formulací (zejména ve vztahu k požadavkům na implementaci) a upřesnění několika detailů. Mezi metody přibyla jedna nová pro použití s proxy servery, která však nebyla blíže specifikována (jde tedy spíše o rezervování jejího názvu). Přibylo několik málo nových stavových kódů zejména mezi těmi ze třetí třídy 26. Výchozí název kódu 302 byl pro lepší odlišení významu od kódu 301 přejmenován 27. Několik málo nepříliš používaných hlaviček bylo zrušeno, a přibylo několik nových. Následuje souhrnný příklad užití protokolu HTTP 1.1. GET /index.html HTTP/1.1 Host: Accept: text/html, image/png, image/jpeg, image/gif, */*;q=0.1 Accept-Language: cs;q=1.0, en;q=0.9, sk;q=0.5, de;q=0.1 Accept-Charset: iso , utf-8, iso ;q=0.6, *;q=0.1 HTTP/ OK Date: Wed, 1 Aug :30:29 GMT Server: Apache/ (Win32) Content-Type: text/html Transfer-Encoding: chunked Last-Modified: Wed, 1 Aug :01:18 GMT 1c <html> <head><title>doc</tit 1a le></head> <body>text</bod a y> </html> Shrnutí V současnosti je tedy platným standardem ve zmiňované oblasti HTTP verze 1.1 dle specifikace v dokumentu RFC Ve svém celku se jedná o protokol poměrně komplexní 29, přesto v něm zůstává velmi silně zakořeněný jeho původní účel totiž jednorázový přenos dokumentů. Stále je protokolem bezstavovým, ovšem zejména díky popularitě služby WWW je dnes používán pro přístup ke službám a aplikacím, které jsou ze své podstaty stavové. Tento rozpor musí být samozřejmě určitým způsobem řešen a stavové informace je nutno mezi jednotlivými požadavky nějak udržovat. 26 Včetně kódu 306, u kterého stojí, že byl používán v dřívějších specifikacích a nyní je nevyužit a rezervován. V žádné z jmenovaných předchozích specifikací se však neobjevuje. Pochází pravděpodobně z některého z pracovních dokumentů, jak lze vysledovat např. z [8]. Odtud také vyplývá, že původní význam tohoto kódu zněl switch proxy Moved Permanently (trvale přesunuto) 302 původně Moved Temporarily (dočasně přesunuto) nyní Found (nalezeno) navíc přibyl nový kód 307 Temporary Redirect (dočasné přesměrování) 28 Některá rozšíření protokolu jsou obsažena v dalších dokumentech například HTTP autentizace v RFC 2617[44]. 29 Některým zainteresovaným se kolem roku 1997 (i když první impulsy pochází již z roku 1995) začal zdát možná až příliš komplexní a složitý, navíc s malou možností rozšíření. Začali pracovat na návrhu HTTP-ng (next generation) [53]. Nemělo jít pouze o revizi stávajícího HTTP, ale o kompletní vícevrstvou architekturu, která by mimo jiné podporovala RPC (Remote Procedure Call vzdálené volání procedur). Tato snaha však nebyla dotažena do konce (snad přišla příliš brzy) a byla ukončena na sklonku roku Strana 18

19 Kapitola 2: Stavové informace 2 Stavové informace 2.1 Bezstavovost protokolu HTTP Jak bylo již řečeno, protokol HTTP je protokolem bezstavovým. Klient ani server tedy po vznesení požadavku a transportu odpovědi nepřechází do jiného vnitřního stavu. Nepamatují si žádné informace, týkající se uskutečněného spojení 30. To je výhodné zejména kvůli možné jednodušší implementaci jak klientů, tak i serverů. Není nutno řešit případné problémy s obnovením těchto informací při neočekávaném ukončení spojení nebo softwarové chybě. Konečným důsledkem tohoto přístupu je, že s každým požadavkem je ze strany serveru nakládáno tak, jako by byl prvním. Zde je na místě znovu připomenout, že (na logické úrovni) toto platí rovněž při perzistentním spojení, zmiňovaném v souvislosti s HTTP 1.1. Spojení sice zůstane otevřeno pro další požadavky, ovšem týká se to pouze nižších vrstev (transportní, síťové, ). Ostatní chování vnitřní logiky protokolu HTTP je nezměněné, jako kdyby spojení bylo uzavřeno a znovu navázáno. 2.2 Potřeba udržování stavových informací v protokolu HTTP Popsaná situace je zcela postačující pro původní poslání protokolu přenos statických dokumentů na základě požadavku. Postupem času se však služba WWW stala zcela jistě nejpopulárnější ze služeb internetu. Poměrně mnoho nezkušených uživatelů s ní dokonce celý internet ztotožňuje [59]. Navíc skutečnost, že se díky konkurenčnímu boji staly nejrozšířenější webové prohlížeče z původně placeného softwaru bezplatnými (či přímo předinstalovanými v operačním systému), tento trend ještě urychlila. Služba WWW se tak zejména v polovině devadesátých let začala stávat mimo jiné i novým marketingovým médiem a mnoho (později velmi neúspěšných) společností založilo své obchodní strategie z velké části právě pouze na ní 31. Kvůli vysoké míře dostupnosti, relativně dobré vybavenosti softwarem (prohlížeči) a poměrně nízkým potřebným výchozím znalostem 32 se pod křídla WWW začaly přesouvat i další služby internetu. Jmenujme například elektronickou poštu či vyhledávání v katalozích a informačních databázích. V poslední době se rovněž poměrně silně rozmohlo využití webového rozhraní pro přístup zaměstnanců k podnikovým informačním systémům. Zde je výhodou mj. zejména snadná změna verzí, neboť není nutné všem zaměstnancům instalovat nový software, změna se provede pouze na serveru. Všechny výše zmíněné operace nákupy, práce s poštou, vyhledávání v databázích i práce v informačním systému ovšem vyžadují pro svou plnohodnotnou funkčnost přes WWW přenos stavových informací. Takové nároky však protokol HTTP přímo může jen těžko uspokojit, neboť na ně není uzpůsobený. Jak bylo již řečeno, každý požadavek je ze strany serveru brán jako by byl první. Aby server (případně na něm běžící obslužný skript či aplikace), mohl takovéto informace získávat, je proto nutné, aby byly obsaženy přímo v požadavku. Toho lze dosáhnout několika možnými metodami. Každá z nich má své výhody a nedostatky, které se v následujícím textu budeme snažit zohlednit. 30 Myšleno vzhledem k následujícím spojením a k protokolu HTTP. Samozřejmě je pravděpodobné, že server zapíše informaci o uskutečněném požadavku do logu, či klient zaznamená čas přístupu tak, aby mohl potenciální budoucí požadavky na tentýž dokument učinit podmíněnými (např. hlavičkou If-Modified-Since). 31 tzv. dot-com se koncem devadesátých let ukázaly jako tragicky neúspěšné, společně se tzv. splasknutím technologické bubliny čili vystřízlivěním investorů, obchodníků a konec konců i zákazníků z původního téměř bezbřehého nadšení a opojení informačními a komunikačními technologiemi. 32 Výchozí nastavení prohlížeče většinou umožňuje jeho přímé použití, kdežto kupříkladu nastavení poštovního programu pro příjem a odesílání zpráv vyžaduje jisté úsilí a určité znalosti. Strana 19

20 2.3 Stavové informace v prostředí WWW Kapitola 2: Stavové informace Existuje několik možností, jak lze stavové informace během komunikace v prostředí WWW udržovat a pracovat s nimi. V základním pohledu mohou být informace buď přenášeny přímo s každým požadavkem a nebo mohou být udržovány na serveru. I v druhém případě, jak si ukážeme v úvodu kapitoly 5, která mu bude věnována a kde se zmíníme i o některých otázkách bezpečnosti přenosu stavových informací, je ovšem nutný přenos odpovídajících identifikátorů mezi serverem a klientem. V obou případech je tedy legitimní hovořit o metodách přenosu stavových informací. Tyto metody jsme se rozhodli pro přehlednost rozčlenit do několika skupin. Kritériem byl samotný způsob přenosu informací mezi oběma komunikujícími stranami. Dále jsme se rozhodli rozčlenit samotné přenášené informace na dva druhy a to podle jejich významu (viz již zmiňované identifikátory). Zde abstrahujeme od způsobu přenosu a zabýváme se tím, jaké informace jsou přenášeny. Ne všechny způsoby přenosu jsou totiž vhodné pro oba tyto druhy informací Metody přenosu stavových informací V nejhrubším pohledu lze metody pro přenos stavových informací v prostředí WWW rozdělit na tři velké skupiny. První, početně největší, skupinu tvoří metody využívající přímo vlastností protokolu HTTP. Patří k nim zejména různé způsoby zakódování informací do URI požadavku případně využití některých dalších informací dostupných z protokolu HTTP. Těmito metodami se bude zabývat kapitola 3. Druhá skupina obsahuje fakticky jedinou, ovšem co do technologie a také historie svého vzniku a vývoje velmi zajímavou metodu tzv. cookies. Ta je jistým rozšířením protokolu HTTP určeným právě výslovně pro uchovávání stavových informací a také proto jí bude věnována samostatná kapitola 4. Třetí skupina obsahuje řešení, která se netýkají přímo protokolu HTTP či jeho rozšíření. Sem byla zařazena řešení, která jej jistými způsoby obcházejí. Z důvodu této specifičnosti se jim budeme věnovat pouze okrajově v závěru této kapitoly. Pro přehlednost zde uvádíme hierarchický soupis metod. Detailně k jednotlivým metodám viz následující kapitoly. Metody přenosu stavových informací v prostředí WWW Prostředky protokolu HTTP URI požadavku za otazníkem (query) virtuální adresář za dokumentem (path info) virtuální adresář před dokumentem skrytá formulářová pole HTTP autentizace IP adresa hlavička From Rozšíření protokolu HTTP (cookies) dle specifikace Netscape dle RFC 2109 dle RFC2965 Zcela mimo protokol HTTP klientské skripty vložené samostatné aplikace Strana 20

21 2.3.2 Stavové informace dle významu Kapitola 2: Stavové informace Zde nám půjde zejména o to, jaký typ informací je shora popsanými způsoby přenášen. Přecházíme tu jaksi o úroveň výše z úrovně přenosu dat v komunikačním kanálu v rámci HTTP, na úroveň logiky aplikace, která s takto přenášenými daty (zde již spíše informacemi) pracuje. Z hlediska významu nás budou zajímat dva druhy informací. První z nich jsou informace identifikační tedy takové, které napříč přes několik HTTP požadavků identifikují jednotlivé uživatele (často je pro takový typ informace užíván termín session-id či česky identifikátor relace). Tam, kde je požadováno důsledné odlišení uživatelů (například u rozhraní elektronické pošty, ovládání bankovního účtu apod.), je nutno brát v úvahu zejména bezpečnost použití takových identifikátorů. Tímto tématem a na jisté obecné úrovni ochranou před možnými útoky se zabývá kapitola 5. Druhou uvažovanou skupinu informací, které je také nutno přenášet prostředky protokolu HTTP tvoří informace jiné než identifikační. Nazvěme je transakčními, neboť se často váží k transakcím v dané konkrétní aplikaci. Může jít o identifikace transakcí, tak aby bylo víceúčelovému skriptu dáno najevo, kterou akci má provést, případně se může jednat o data poskytnutá aplikaci ke zpracování. Ve většině dynamických aplikací je také nutné tento typ informací udržovat. Často však pouze po relativně krátkou dobu po několik málo dalších požadavků. Udržované a přenášené informace jsme si tedy pro vlastní potřeby rozdělili na identifikační ty, podle kterých aplikace rozlišují uživatele a transakční ty ostatní, které je nutné udržovat a přenášet (nejčastěji se týkají uskutečňovaných transakcí). 2.4 Práce se stavovými informacemi v prostředí WWW mimo rámec HTTP Na tomto místě je velmi obecně pojednáno o možných způsobech práce se stavovými informacemi v prostředí služby WWW, které pro svou činnost neužívají protokolu HTTP či jeho rozšíření. Tato práce se těmito způsoby detailně nezabývá a uvádíme je zde pouze pro úplnost možností udržování stavových informací v prostředí WWW. S použitím klientských skriptů Je možné, že se autor webové aplikace rozhodne, že není potřeba (nebo to není možné 33 ) odesílat stavové informace serveru, ale postačí pokud tyto budou uchovávány a zpracovávány přímo na klientském softwaru tedy v prohlížeči. Toho lze dosáhnout použitím některého ze skriptovacích jazyků implementovaných v prohlížečích (nejčastěji různé verze JavaScriptu). Takové jazyky však z pochopitelných bezpečnostních důvodů samozřejmě nemají přístup k souborovému systému klientského počítače 34. Data je proto nutné uložit jiným způsobem. Jeden z nich ač je poměrně funkční, má celou řadu nevýhod. Je jím ukládání dat dynamicky do dokumentu nahraného v neviditelném HTML rámci (frame resp. iframe). Tento způsob je podrobně popsán např. v [24]. K zásadním nevýhodám patří již samotné použití skriptů, které je nutné velmi pečlivě odladit v různých verzích různých prohlížečů. Druhým zásadním nedostatkem je použití rámů. Je totiž nutno zabránit uživateli dosažení dokumentu jinak, než v tomto rámu. Toto je velmi problematické zejména pokud se uživatel na web dostává z externího odkazu (například z vyhledávače). Teoreticky je možné toto kontrolovat opět s použitím klientských skriptů, je to však způsob nanejvýš nevhodný. Navíc utvořit odkaz tak, aby 33 Například na serveru není nainstalována podpora pro skriptování. 34 nepočítaje v to různé chyby v implementaci Strana 21