URL
V knize najdete lecjaká témata, ale protokol jsme tu ještě neměli. K čemu je dobrý? Protokol obecně stanoví pravidla komunikace mezi dvěma partnery - jak jsou přenášené informace uspořádány, co všechno lze protějšku sdělit a jaké mohou být jeho reakce. Konkrétně v případě HTTP se definují zákonitosti dialogu mezi WWW klientem a serverem.
Již v úvodním seznámení s WWW jsem prozradil, že HTTP je protokol bezstavový. Vychází striktně z modelu dotaz-odpověď. Tato dvojice tvoří ucelenou jednotku komunikace. Jakmile server obdrží dotaz, odpoví na něj a tím pro něj dialog končí. Případné uchovávání stavových informací (typu nacházíme se právě na dokumentu X a z něj jsme vybrali odkaz na Y, kdykoli se však můžeme vrátit k předchozímu dokumentu Q) je plně ponecháno na klientovi.
HTTP patří mezi protokoly aplikační vrstvy. To znamená, že se zaobírá výlučně otázkami, spojenými s WWW, a neřeší například transport dat mezi partnery. Předpokládá, že pro tento účel má k dispozici spolehlivý (viz poznámka) - data, která do ní na jednom konci vkládáte, na druhém vytékají ven v nezměněné podobě. Ručí se za to, že se nic neztratí, nic nezpřehází, nic neduplikuje a podobně.} transportní protokol. Standardně je používáno TCP, avšak teoreticky může posloužit libovolný protokol s odpovídajícími vlastnostmi. Server typicky bydlí na TCP portu číslo 80.
Situaci lehce komplikuje existence dvou verzí HTTP. V dobách jeho začátků se používal protokol verze 0.9. Jeho charakteristickými znaky jsou velmi omezené vyjadřovací možnosti - například server nemá možnost idenitifkovat typ odesílaných dat; musí jej hádat klient podle přípony nebo obsahu. Současné HTTP nese verzi 1.0 a může se pochlubit podstatně košatějšími vyjadřovacími schopnostmi. V definici je pamatováno i na zpětnou kompatibilitu. Zjednodušeně řečeno zní příslušná pravidla takto:
Dotaz i odpověď mají shodnou strukturu, která do značné míry připomíná dopisy elektronické pošty. Začíná speciálním dotazovým nebo stavovým řádkem, za ním následují hlavičky s podrobnějšími informacemi a nakonec, odděleno od hlaviček prázdným řádkem, tělo zprávy. Délka zprávy nemá předepsány žádné pevné meze a zmizelo i těch pár omezení, které RFC 822 pro E-dopisy zavádí - především omezení na znaky standardního ASCII kódu a omezená délka řádků. Tělo HTTP zprávy se obecně chová jako binární data. Řadu prvků převzal protokol od nového poštovního standardu MIME, například jeho typologii.
Dotazem všechno začíná. Typická HTTP transakce vypadá následovně:
Jednoduchý dotaz je podporován výlučně pro zachování zpětné kompatibility s HTTP 0.9. Moderní klienti by jej neměli používat. Má tvar
GETa vyjadřuje touhu klienta získat dokument s uvedeným URL.
Kompletní dotaz dává podstatně větší možnosti. Vypadá následovně:
Přítomnost prvku
verze HTTP odlišuje kompletní dotaz od jednoduchého. V současné době na
jejím místě stojí HTTP/1.0. metoda určuje druh služby, kterou klient od serveru požaduje.
Standardní nabídku metod shrnuje tabulka:
| GET | Klient chce získat informaci, určenou
URL.
|
| HEAD | Má význam podobný, jako GET. Server však má poslat jen stavový řádek a hlavičky, nikoli tělo dokumentu. |
| POST | Server má předat
tělo dotazu jako data pro prvek,
identifikovaný URL dotazu.
Metodu POST lze používat například pro vytváření nových souborů
v adresáři nebo (nejčastěji) pro předání dat ke zpracování CGI skriptem.
|
Sortiment metod obecně není uzavřen a může se postupem času dynamicky měnit.
Jestliže klient projeví zájem o metodu, kterou server neumí, odpoví chybovým
kódem 501 not implemented. Na použitou metodu se těsně váže tělo dotazu. Je obsaženo jen pokud
metoda požaduje jeho přítomnost (ze standardní trojice klade tento požadavek
pouze POST). Drtivá většina současných dotazů používá metodu
GET. Dotaz s tělem proto uvidíte jen velmi vzácně.
URL dotazu musí být buď
absolutní. Nanejvýš je přípustné vynechat v něm identifikaci serveru - pak se
předpokládá, že serverem je ten, komu byl dotaz dopraven. Cesta v URL však musí být v každém případě
absolutní. Pokud je dotaz předáván zprostředkujícímu (proxy) serveru, musí
obsahovat kompletní absolutní URL.
Nejsložitější části dotazu jsou nepochybně hlavičky. Budu se jim věnovat o něco
později v části odkaz. Všimněte si prádného
řádku, kterým jsou hlavičky
odděleny od těla.
Takmé odpověď existuje ve dvou odrůdách. Jednoduchá odpověď má své
kořeny v HTTP verze 0.9 a obsahuje pouhé tělo. Server ji používá jen ve dvou případech: Jako odpověď na
jednoduchý dotaz nebo pokud nepodporuje HTTP verze 1.0.
Ve všech ostatních případech je povinen poskytnout kompletní odpověď ve tvaru
První řádek je nazýván stavový a oznamuje klientovi výsledek zpracování jeho dotazu. Opět začíná identifikací
verze HTTP, tedy HTTP/1.0. Za ním následuje kód a vysvětlení. Tyto dva údaje jsou
stranami téže mince. Oba říkají totéž, ale každý je určen pro jiného čtenáře.
kód slouží WWW klientovi (tedy
programu). Jedná se o číselný kód, informující klienta o úspěšnosti či
neúspěšnosti zpracování jeho dotazu. Nejčastějším kódem je 200, vyjadřující
šťastný konec. vysvětlení
obsahuje stejnou informaci jako kód, ale v přirozeném jazyce. Je určen pro
lidského čtenáře. Například ke zmíněnému kódu 200 se váže vysvětlení OK.
Kódy jsou rozděleny do pěti tématických skupin podle své první číslice.
Formát, ve kterém jsou hlavičky zapisovány, si HTTP vypůjčil od elektronické pošty, přesněji z RFC 822. Každá položka hlavičky je zapisována na samostatný řádek. Začíná vždy jménem, identifikujícím hlavičku. Za ním následuje dvojtečka, mezera a vlastní hodnota hlavičky - například
Pragma: no-cache
Hlavičky jsou rozděleny do tří tematických skupin. Obecné poskytují univerzální informace o zprávě. Hlavičky dotazu/odpovědi poskytují informace, specifické pro dotaz nebo odpověď. V jejich sortimentu se odlišuje dotaz od odpovědi, zbývající dvě skupiny se shodují pro oba druhy zpráv. Hlavičky těla popisují tělo zprávy. Na pořadí samozřejmě nezáleží, nicméně ve standardu se doporučuje, aby hlavičky zprávy byly uspořádány podle svých tematických kategorií v uvedeném pořadí.
Sun, 06 Nov 1994 08:49:37 GMT
Pragma: no-cachezakazuje umístit zprávu ve vyrovnávací paměti.
GET http://www.kdesi.cz/top.html HTTP/1.0Tato informace může být užitečná například při chybných odkazech. Jestliže se změnilo URL některého dokumentu, můžete díky hlavičce Referer identifikovat stránky, které se odkazují na původní (nyní již neplatné) URL. Kromě toho využívají údaj z Referer některá počítadla přístupů, aby se chránila proti čítačovému pirátství (viz strana odkaz).
Referer: http://www.kdesi.cz/home.html
User-Agent: Mozilla/2.0b3 (X11; I; Linux 1.2.11 i586)Dotaz byl vznesen klientem Netscape (v HTTP se představuje jako Mozilla, v dobách jeho počátků autoři doporučovali, aby se tak vyslovovalo i jméno "Netscape") verze 2.0 beta 3. Jak vidíte, Netscape podal také informace o operačním systému, ve kterém pracuje.
HTTP/1.0 301 Moved Permanently
Location: http://www.jinde.cz/text.html
Allow: GET, HEAD
Content-Encoding: x-gzip
Content-Length: 5216
typ/podtyp. Odesílá-li server WWW
stránku, ponese hlavičku Content-Type: text/html
V závěrečné části se podíváme, jak HTTP řeší otázky prokazování totožnosti a autorizace přístupu k dokumentů. Používá celkem jednoduchý model, založený na principu výzva-odpověď. Pokud se klient pokusí získat dokument, přístupný jen autorizovaným uživatelům, reaguje server známým zvoláním, které jsem použil pro nadpis kapitoly. Přesněji řečeno pošle odpověď, která vypadá asi takto:
HTTP/1.0 401 UnauthorizedZákladem odpovědi je návratový kód 401, ozanující, že klient není oprávněn získat dokument. Jeho povinným doplňkem je hlavička WWW-Authenticate, poskytující klientovi údaje, potřebné k prokázání totožnosti. Obecný tvar této hlavičky je
WWW-Authenticate: Basic realm="zamestnanci"
schéma definuje
způsob prokazování totožnosti - především informace, které si mezi sebou
vyměňují server s klientem. Jediným schématem, podporovaným v současné verzi
HTTP, je Basic.
Definice oblasti umožňuje
klientovi odpovídat na příští autentifikační dotazy automaticky. Dokumenty
uvnitř serveru jsou totiž rozloženy do tak zvaných chráněných
prostorů. Každý z nich má společnou databázi uživatelů a pro všechny
dokumenty z jednoho prostoru používá klient stejné autentifikační informace.
Uživatel by jistě příliš nejásal, kdyby se na ně klient ptal pokaždé znovu.
Proto si klient zapamatuje, že pro daný chráněný prostor uživatel zadal
určité jméno a heslo a pro příští dokumenty z téhož chráněného prostoru
použije automaticky stejné údaje. K jednoznačné identifikaci chráněného
prostoru slouží dvojice: kanonické kořenové URL serveru (obsahuje jen
jméno/adresu serveru a číslo portu, chybí cesta a vše za ní) a oblast, definovaná v hlavičce WWW
-Authenticate.
Tím jsme se propracovali k reakci klienta. Ten zopakuje svůj předchozí
dotaz, ovšem přidá k němu hlavičku Authorization. Její obsah zcela
závisí na použitém schématu.
Jediné v současnosti dostupné schéma Basic používá pro autorizaci klasické údaje - jméno uživatele a jemu příslušející heslo. Klient je ohlašuje v hlavičce Authorization takto:
BasicZávěrečná dvojice
uživatel:heslo je přepravována v kódování
BASE64, což je jedno ze standardních MIME kódování, používaných pro přenos
binárních dat. Ve skutečnosti vypadá příslušná hlavička třeba následovně:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
BASE64 je kódování přepravní, nikoli
kryptografické! Ačkoli text vypadá na první pohled zcela nesrozumitelně,
algoritmy a programy pro jeho dekódování do původní podoby jsou veřejně
přístupné. Rozhodně nepropadejte naději, že přenášené jméno a heslo je
bezpečné. Pro zajištění zabezpečeného přenosu informací je třeba použít jiný
mechanismus (např. Secure HTTP nebo Secure Socket Interface).
Když server získá autorizační informace (v našem případě jméno a heslo), nahlédne do databází, příslušejících danému chráněnému prostoru. Pokud v nich najde uživatele a zjistí, že heslo je správně zadáno, a pokud zjistí, že dotyčný uživatel je oprávněn získat požadovaný dokument, pošle standardní odpověď. V opačném případě odpoví 403 Forbidden a dává tak na vědomí, že poskytnutá autentifikace k získání dokumentu nestačí.
Tato stránka je součástí on-line podpory knihy WWW pro čtenáře, autory a misionářePavel Satrapa
28. února 1996