1. Co je webový agent

Pojmy webový klient a webový server jsou jistě dobře známy, webového klienta používají uživatelé pro čtení webových stránek (jedná se např. o Firefox nebo Internet Explorer) a webový server je program pracující na serveru, který stránky klientovi zasílá (obecně například Apache nebo Microsoft-IIS). Stránky má webový server zpravidla nějak uloženy na počítači, na kterém pracuje - buď jako klasické HTML soubory, nebo je nějak poskládá z jiných částí těsně před odesláním. Může ale nastat situace, že zasílané stránky server vytvoří tak, že všechny části získá z jiného webového serveru. Tento (poněkud netypický) program tedy nejprve pracuje jako webový klient a poté stránku jako webový server odešle uživateli. O něm pak hovoříme jako o webovém agentovi.

Samotný pojem agenta je ale často nejasný.  V  dokumentech RFC popisujících přenos webových stránek se používá anglický termín user-agent (viz  RFC2616 [1]), což je v češtině webový klient. Agent je často také používán v umělé inteligenci nebo nyní nově v kognitivní informatice. Agentem je v tomto smyslu míněn samostatně pracující modul, program či robot. Pojetí agenta se snažili shrnout na internetu mnozí, jako příklad lze uvést vysvětlení pojmu z pohledu tvůrců webových robotů [2]. Nejnověji je třeba také zmínit pojem multiagentů, za nímž se skrývá vzájemná spolupráce inteligentních agentů.

Opomíjené ale často bývá využití agentů při zprostředkování rešeršních nebo knihovních informací. Právě to je asi nejbližší zde uváděnému pojmu webového agenta. Mnohdy totiž někde pracuje nadstavba na webového serveru, která pro uživatele zprostředkuje informace z jiného serveru, které by jinak byly obtížněji dostupné nebo jen těžko čitelné. Ilustrativním příkladem může být gateway v Kongresové knihovně [3] umožňující přístup z webového prostředí do systémů s rozhraním Z39.50. CGI skript  zgate se vždy obrací na cílový knihovní server, z něhož získá odpověď, jíž následně předává jako webovou stránku uživateli. Situace je téměř stejná jako u webového agenta, rozdíl je však v tom, že agent (skript) zgate získává informace z cílového serveru protokolem Z39.50 a nikoli pomocí protokolu HTTP používaného na webu. (To je právě hlavní smysl oné brány (gateway), neboť uživatel nemusí shánět, instalovat a konfigurovat klienta Z39.50 - jako je třeba Icone2 [4]. K informacím se tak uživatel může dostat pomocí svého obyčejného webového klienta.)

Je určitě otázkou diskuse, zda je za webového agenta možno pokládat i zmíněny skript zgate nebo se striktně omezit požadavkem na získávání údajů z jiných serverů jen pomocí protokolu HTTP. Protože však dnes dominují informace zasílané webovými servery, není toto omezení až tak významné, jak by se čistě teoreticky mohlo zdát.

Příkladem webového agenta v tomto užším pojetí, se kterým se určitě už každý setkal, může být proxy server. Nejlepším českým překladem tohoto pojmu by bylo "zástupný server". Tento termín se v češtině prakticky nepoužívá, ale vyjadřuje asi nejlépe věcnou podstatu (na rozdíl od nevýstižného "vyrovnávacího serveru"). Webový klient se totiž místo na originální webový server obrací (pomocí protokolu HTTP) na "zástupný server", který webovou stránku získá z originálního webového serveru a zasílá ji poté webovému klientovi. Zároveň si ale onu stránku uloží ("cachuje"), aby při následujících požadavcích tuto stránku mohl okamžitě již zaslat sám. Hlavním algoritmickým problémem pak samozřejmě je, aby proxy server nezasílal webovou stránku již neaktuální, pokud ta se často mění nebo je při každém požadavku originálním webovým serverem třeba jinak vytvořena. Například klasické obrázky si takto proxy server může výhodně ukládat, aby je při dalším požadavku zaslal přímo ze svého cache a zbytečně se znovu nezatěžovala přenosová cesta k originálnímu serveru. Proto bývalo (resp. je) využití proxy serveru nejvýznamnější v době nedostatečné kapacity přenosových linek, protože tak lze "vyrovnávat" přenosové požadavky. Pro úplnost doplňme, že použití proxy serveru si uživatel obvykle vždy sám konfiguruje ve svém webovém klientovi.

Odtud je patrné, že jednoduchého webového agenta, který pouze získá webovou stránku a předá ji klientovi, nebude asi neřešitelné vytvořit i na některém webovém serveru. Ve většině skriptovacích jazyků používaných na webových serverech to někdy bývá dokonce uváděno v příkladech jejich využití. Zajímavější věcí ale je, že tento webový agent sám vlastně změní identitu odesílatele požadavku. (Na rozdíl od proxy serverů, které se snaží úmyslně nasimulovat co nejvěrněji původního uživatele.) Webový agent totiž nejčastěji uvádí jako svou identitu programové vybavení, ve kterém byl vytvořen, nebo může navíc programátor stanovit zcela odlišné pojmenování. Příkladem takovéhoto webového agenta může být skript používaný na webovém serveru, který se pouze bude jinak představovat, řekněme jako Internet Explorer 6.78. Tento příklad není zcela smyšlený, ale takto se představuje webový agent UTF-NKP, který se dal využívat pro přístup do Alephu starší verze 14. V této verzi totiž v řadě instalací server Alephu automaticky přepínal kód češtiny, jenž byl UTF-8 pouze při použití webového klienta MSIE(přesněji Microsoft Intenet Explorer nižší verze než 7.0). Pro všechny ostatní prohlížeče(včetně nového MSIE 7.0) se pak v Alephu použila transformace do kódu ISO. Problém se tak mohl objevit u českého textu, pokud by obsahoval i některé západoevropské znaky chybějící v české kódové tabulce. Webový agent onen problém vyřešil, neboť pro požadavek z jakéhokoliv klienta se vždy představoval jako Mozilla/4.0 (compatible; MSIE 6.78; Linux).  Začátek se totiž shoduje s tím, jak se představuje každý Internet Explorer. Server Alephu pak celou komunikaci zasílal v kódu UTF-8, který snad všichni používaní weboví klienti od konce 90. let u nás znají. Nejen zobrazení všech znaků, ale i odkazy na záznamy potom ve všech (našich) klientech fungovaly správně. V URL odkazech tak bylo možno uvádět i (někdy nezbytnou) českou diakritiku (v kódu UTF-8):
 ../UTF-NKP/knihovna.jewishmuseum.cz/F/?...&request=stvo%C5%99eni+and+vesmiru  [5]

Původně jsem měl jako příklad uvedenu Knihovnu Akademie věd ČR. Než jsem však článek dopsal, přešla tato knihovna na vyšší verzi Alephu. Určitě se tedy něco podobného stane i pro tento odkaz. Na druhou stranu ale právě tato skutečnost může ilustrovat situaci, kdy poměrně snadno provozovatelný webový agent může posunout reinstalaci systému na dobu provozně nejvýhodnější (aniž by třeba uživatelé nového MSIE 7.0 pocítili problémy s archivem svých odkazů, které mají i s českou diakritikou).

2. Vyžití HTTP hlaviček

Webový klient může být na serveru identifikován díky HTTP hlavičkám. Ty byly zavedeny hned brzy po vzniku World Wide Webu. Před každou webovou stránku a obecně před každý soubor je webovým serverem přidána HTTP hlavička, ve které je kromě kódu odpovědi a data uváděn především typ zasílaných údajů. Webový klient tím dostává přesnou informaci, zda například získal nějaký textový soubor či obrázek. (Podle dalších informací v hlavičce se také proxy server rozhoduje, zda si obdržený soubor může uložit, případně na jak dlouhou dobu.)

Stejně tak i webový klient zasílá webovému serveru informace v hlavičce požadavku. V tomto případě jsou ovšem údaje uvedeny až za zadáním cesty k požadovaném souboru. Dalo by se tedy říci, že bychom u klientů spíše než o hlavičkách měli mluvit o "HTTP nožičkách". Všichni weboví klienti zde přitom uvádějí jméno cílového počítače a také své typické programové označení. Ani hlavičky ze serveru, ani hlavičky od klienta nejsou standardně uživateli zobrazovány. Zpravidla si k tomu člověk musí opatřit nějaký další programový doplněk. Hlavičky, které zasílají weboví klienti, se dají dost jednoduše zobrazit programovým skriptem na (vhodném) webovém serveru. To, jaké informace webový klient vždy zasílá, lze vidět například pomocí skriptu  .LADENI [6]. (Údaj uváděný skriptem pod čarou není klientem zasílán, ale sloužil původně právě k ladění jiného programu.)

Pokud nyní zadáme zmiňovanému agentovi UTF-NKP, aby se místo do knihovního systému obrátil na tento skript, můžeme potom takto zjistit, jaké informace vždy od onoho agenta obdrží server Alephu (http://146.102.68.32/ISO/UTF-NKP/gama.vse.cz/ISO/.LADENI [7]). Výše uváděný příklad ilustruje, jak z položky  User-Agent  ona instalace Alephu vyvozuje použitý kód češtiny. Pokud klient nevypadá jako Internet Explorer (verze nejvýše 6), musí v jeho požadavku být vše uvedeno v kódu ISO-8859-2. To je nepříjemné zvláště u odkazu, kde není možno nějak nahradit české písmeno s diakritickým znaménkem, a to je konkrétně v našem případě písmeno ř.

Odpovědi webového serveru, jež se odvíjejí od obsahu "neviditelných" položek v HTTP hlavičkách webových klientů, mají v principu mnohem hlubší význam. Obecně totiž informace na webových stránkách není možné popsat pouze pomocí specifikace URL. Jako příklad lze uvést odkaz na obrázek  http://4izi.vse.cz/~jjkastl/kizi.gif. Webový server zašle buď české, nebo anglické (obrázkové) logo podle toho, jaký jazyk si uživatel na svém webovém prohlížeči nastavil jako (první) preferovaný jazyk. Přesněji řečeno, uváděná odpověď webového serveru se řídí prvním jazykem uvedeným v položce Accept-Language v hlavičce zaslané klientem. Naštěstí ale tvůrci webových stránek tyto schopnosti webových serverů využívají obvykle jen pro jazykové nebo kódové mutace webových stránek (bez významné rozdílnosti v obsahu). V opačném případě by se totiž mohly pod URL odkazem pro každého skrývat úplně jiné informace. (Pro úplnost je třeba poznamenat, že takto hluboko ještě ve znalostech internetu ochránci jeho nezávadného obsahu nepokročili - nejspíše proto, že kdysi při studiu vynechali právě odkazy na knihy v Alephu.) Ona principiální nepřesnost při používání specifikací URL, které se jako jediné používají pro určení odkazů, je dána skutečností, že prapůvodně (1990-1992) v protokolu HTTP žádné hlavičky nebyly.

3. Vícenásobné použití webových agentů

Asi nejnázornějším příkladem použití webového agenta je agent AU, který umí na webové stránce odstranit diakritiku, tedy přepsat všechna písmena z kódu UTF-8 na znaky ASCII-1. Jako příklad můžeme uvést jednoduchý text o multiagentech (http://4izi.vse.cz/~jjkastl/MI-klient), u něhož zmíněný agent odstraní háčky a čárky:
http://146.102.68.26/ISO/AU/4izi.vse.cz/~jjkastl/MI-klient

Stejný postup ale můžeme aplikovat i na výše zmiňovaný odkaz [5] do systému Aleph:
http://146.102.68.26/ISO/AU/146.102.68.32/ISO/UTF-NKP/knihovna.jewishmuseum.cz/F/?...  [8].
Co se za tímto URL odkazem skrývá? Náš webový klient se obrátí na počítač (s IP adresou) 146.102.68.26, kde se aktivuje webový agent AU. Ten se obrátí na webového agenta UTF-NKP pracujícího na (dalším) počítači 146.102.68.32. Teprve tento agent se (jako nepravý MSIE klient) obrátí na knihovní systém na adrese knihovna.jewishmuseum.cz. Až když webový agent UTF-NKP dostane z Alephu odpověď, pošle ji webovému agentovi AU, který na ni (stále) čeká na počítači 146.102.68.26. Teprve pak může z textu odstranit háčky a čárky a zaslat tuto stránku webovému klientovi jako odpověď na námi zadaný požadavek. Pro úplnost dodejme, že případné obrázky z oné webové stránky si agenti (z důvodu urychlení práce) mezi sebou navzájem nepřeposílají, ale krátkou odpovědí (301) odkáží webového klienta vždy na cílový webový server knihovna.jewishmuseum.cz.

Agenti jsou na obou počítačích napsáni stejně a způsob jejich skládání je proto analogický skládání funkcí v matematice. Jako kdybychom v matematice napsali  AU(UTF‑NKP(F(stvořeni+and+vesmiru))). Pouze je třeba mít na paměti, že pro každou "funkci" je nutno v URL odkazu uvést počítač a adresář, kde se funkce/agent nalezne. Aby tyto webové agenty nebylo možné na první pohled identifikovat, nahrazují či zkracují se někdy jména počítačů i adresářů, protože často ty nejjednodušší změny standardních označení jsou pro (záludné) programy pátrající náhodně po síti již matoucí. Nutno ale poznamenat, že popisovaná spolupráce více agentů, ač teoreticky zmiňována v učebnicích věnovaných internetu, je stále v reálném internetu spíše výjimečná.

Pro úplnost se lze ještě podívat, jaké informace pro tyto dva složené agenty dorazí do Alephu: http://146.102.68.26/ISO/AU/146.102.68.32/ISO/UTF-NKP/gama.vse.cz/ISO/.LADENI [9].
Oproti odkazu [7], kdy byl použit pouze agent UTF-NKP, již nedorazí k cílovému Alephu informace o internetové adrese našeho počítače. Webový agent AU informaci o IP adrese počítače, odkud byl aktivován, nijak nezpracovává. Spíše je naopak neobvyklé, že internetovou IP adresu počítače, z něhož byl aktivován, předává cílovému serveru agent UTF-NKP (Ale činí tak z důvodů programové jednoduchosti v položce User-Agent a nikoliv podle doporučení RFC2616 [1] v položce Via. Pokud jsme tedy ještě použili agenta AU, dorazí do Alephu místo naší adresy už pouze informace o adrese počítače, na kterém byl tento agent spuštěn. Z toho mohou vyplývat jistá úskalí při vyžívání webových agentů.

4. Využití a zneužití webových agentů

Pokud jsou při přístupu k údajům webového serveru nějakým způsobem zohledňovány internetové adresy počítačů, ze kterých přišly požadavky, mohou se při využití webového agenta podstatným způsobem lišit získané odpovědi, tedy velmi analogicky zmiňovaným různým kódům odpovědí Alephu. Podstatný rozdíl je ovšem v tom, že běžnými programovými prostředky nejsme schopni si účelově změnit IP adresu jakéhokoliv počítače v internetu.

Odtud vyplývá i obtížnost napsat webového agenta, který by zcela věrohodně zobrazoval HTTP hlavičky odpovědi, kterou nám webový server zasílá. Takovýto webový agent především musí ve všech položkách svých hlaviček uvádět stejné údaje jako webový klient, který onu informaci požaduje. Ovšem pokud jsou odpovědi webového serveru nějakým způsobem závislé na IP adrese webového klienta, nelze problém ani principiálně vyřešit. I když na obou výše uvedených serverech existuje agent vytvořený pro výuku .head (případně .head9, který se navíc ještě obrací na lokální proxy server), jsou jeho informace platné jen omezeně. Nutno ale říci, že odpovědi jsou ve velké většině případů věrohodné, přinejmenším tedy v případech používaných ve výuce.

Na druhou stranu ale lze využít agentů v případě, že pro vybrané adresy serverů má uživatel přístup blokován. V internetu totiž existuje po celém světě mnoho serverů, kam lze relativně snadno získat přístup, a na nichž je možno si vytvořit i některé programové nadstavby. I když některé z těchto "programovatelných webhostingů" nedovolují použití všech funkcí, musel by být k určitému webovému serveru zamezen přístup ze všech webhostingů, kde je možno si webového agenta vytvořit. Určitou neznalostí proto mnohdy působí zaručené agenturní informace, jak a kde se na některé běžně přístupné webové servery nelze vůbec nijak dostat.

Daleko záludnější jsou ovšem změny webovým agentem úmyslně vnášené do obsahu webových stránek. Princip je velmi jednoduchý, tak jako agent AU převede každé písmeno s diakritikou na znak bez diakritického znaménka, může i celý textový řetězec znaků převádět na něco zcela jiného. Osobně tyto změny využívám pro opravu chyb nebo nedokonalostí na jiných webových serverech - viz již starší příspěvek [10]. Jako jednoduchý ilustrativní příklad lze uvést agenta KIZI [11], který oproti originálnímu obsahu umí podle zvoleného jazyka měnit české a anglické logo katedry. Jako službu navíc nenechává na konci řádku jednopísmenné předložky. Těžko samozřejmě říci, zde se jedná o informační zdokonalení stránek nebo již o začínající dezinformaci oficiálního serveru.

Na tomto příkladu snad lze i ukázat, jaká by proti tomu mohla být obrana. Nejjednodušší je pozorně prozkoumat cestu, zjistit si případně hlavičky zasílaných odpovědí, ověřit internetové adresy. I když zde odkazovaná cesta [11] byla pro snadnou aktivaci agenta účelově zkrácena, posléze je webový klient přesměrován na URL odkazy podle výše popisovaného schématu: http://146.102.68.32/ISO/KIZI/kizi5.vse.cz/
Přitom 146.102.68.26 je IP adresa serveru 4izi.vse.cz, zatímco oba (virtuální) webové servery kizi5.vse.cz i kizi.vse.cz mají IP adresu 146.102.17.94. (To lze snadno zjistit například pomocí programu nslookup.)Aby se předešlo možným nejasnostem s věrohodností získaných webových stránek, přidává webový agent KIZI do HTTP hlaviček položku snažící se upozornit na princip agenta:
X-Via-Agent: 1.0 4izi (Lynx -source + [k|s|v|z]'00A0') 

Ve velkém procentu případů již tyto tři jednoduché kroky vedou k odhalení někdy i úmyslných záludností v URL odkazech. Určitě by si je měl každý ověřit dříve, než některé údaje z internetového serveru zveřejní třeba v hromadném sdělovacím prostředku.