Automatický výběr varianty dokumentu v systému WWW

1. Úvod

Základním problémem použití systému WWW v našich podmínkách byl od počátku problém kódových variant dokumentů. Tento problém je ve skutečnosti pouze částí obecnějšího problému, problému prezentace různých jazykových, kódových a mediálních variant dokumentů. Problém prezentace dokumentů v národních jazycích a kódech byl postupně řešen jak na straně serverů a klientů, tak na úrovni protokolu http, kterým se uskutečňuje veškerá komunikace v systému WWW.

Nejjednodušší řešení, které je u nás nejvíce rozšířeno, využívá pro prezentaci různých kódových verzí dokumentů CGI skriptů. Uživatel musí explicitně vybrat kódovou nebo jazykovou variantu dokumentu prostřednictvím hypertextových odkazů a tato volba je pak dále nesena ve všech prezentovaných dokumentech. Nová verze protokolu http 1.1 [2] však umožňuje při použití novějších verzí klientů a serverů podstatně kvalitnější řešení výběru variant dokumentů ve formě automatického výběru varianty dokumentu na straně serveru. Dále je v současné době vyvíjena metoda výběru variant dokumentů  transparentním výběrem na straně klienta. Vyžaduje součinnost serveru, který musí klientovi oznámit dostupné mutace dokumentu, ale rozhodování je přesunuto na stranu klienta, který může z dostupných mutací vybrat tu, která nejlépe vyhovuje jeho schopnostem a požadavkům uživatele. Obě metody automatického výběru umožňují zobrazit správnou variantu dokumentu bez explicitního zásahu uživatele, což je nezbytnou podmínkou pro širší využití systému WWW.

2. Výběr varianty na straně serveru

Dokumenty mohou být v systému WWW uloženy v různých typových, jazykových a kódových mutacích. Výběr mutace dokumentu na straně serveru umožňuje automaticky prezentovat dokument v tom formátu a v té jazykové variantě, kterou požaduje klient. Automatický výběr pracuje tak, že klient sdělí serveru typ dokumentu, který mu vyhovuje, a server vybere, která z dostupných variant nejlépe odpovídá požadavkům klienta. Primární důvody pro zavedení byly:

• Hladké zavedení nových formátů dokumentů a audiovizuálních záznamů.
• Možnost několik úrovní zobrazení dokumentů podle schopností klienta.
• Odstranění výběru závislého na identifikaci klienta (User-Agent).
• Internacionalizace, zpřístupnění různých jazykových variant dokumentů.

Použití automatického výběru si nejprve předvedeme na příkladu výběru varianty dokumentu podle jazyka. Většina serverů dovoluje definovat různé přípony jmen souborů, které identifikují jazyk dokumentu. Například u serverů NCSA, CERN a Apache označíme všechny soubory s příponou  czech  za české dokumenty a s příponou  eng  za anglické takto:

AddLanguage cs czech # cs je identifikátor jazyka
AddLanguage en eng # czech je přípona souboru

Klient může požádat o konkrétní jazykovou mutaci dokumentu explicitně, doplněním postfixu jména souboru do URL (např. index.html.czech), ale jak lze vidět z uvedené konfigurace, tento postfix nemusí odpovídat oficiální identifikaci jazyka. Většinou se sice volí přípona souborů stejná jako identifikátor jazyka, ale nemusí to být pravidlem (například identifikátor pl pro polštinu je jako přípona jména nevhodný, protože přípona .pl je tradičně používána pro skripty v jazyce Perl). Podstatně pohodlnější je pro uživatele implicitní volba jazyka, nastavením preferencí v prohlížeči. Například u prohlížeče Netscape Communicator 4.0 lze jazyk nastavit výběrem Edit  Preferences  Navigator  Languages  Add  Czech. Prohlížeč pak přidává do požadavků hlavičku Accept-Language, ve které sděluje serveru preferovaný jazyk. V tomto případě ovšem musí sever vyhledat vhodnou jazykovou mutaci dokumentu sám, protože zadané URL (např. index.html) neidentifikuje přímo soubor na serveru. Hledání vhodné varianty dokumentu podle preferencí prohlížeče musí být samozřejmě na straně serveru podporováno a zapnuto. Například u serveru Apache musí být pro patřičný adresářový podstrom povolen parametr MultiViews:

<Directory /WWW/root>
Options Includes ExecCGI MultiViews
</Directory /WWW/root>

Pokud server dostane požadavek na URL http://server/index.html a v odpovídajícím adresáři existují pouze soubory index.html.czech a index.html.eng, zvolí jeden z nich podle preferovaného jazyka. Server tak dovoluje zpřístupnit pod jedním URL více verzí dokumentu. Pokud požadavek neobsahuje hlavičku Accept-Language, pak server vybere jazykovou mutaci dokumentu sám dle pevně nastavené priority jazyků.

2.1 Výběr variant v protokolu http verze 1.1

Výběr mutace dokumentů nebyl v protokolu http verze 1.0 [1] formálně definován. Odpovídající hlavičky sice jako volitelné definovány byly, ale jejich zpracování ne. Protokol http verze 1.1 [2] již výběr variant dokumentů definuje a to na základě požadavků klienta na:

• typ reprezentace (Accept),
• jazyk (Accept-Language),
• kód (Accept-Charset),
• způsob přenosu (Accept-Encoding).

Prohlížeč zasílá preference různých variant dokumentů při každém požadavku v hlavičkách požadavku. Prohlížeč může jednotlivým variantám přiřadit váhy v intervalu 0 až 1.0. Čím větší je hodnota váhy, tím více je preferována odpovídající varianta. Při interpretaci zápisu preferencí je třeba dát pozor na to, že oddělovačem variant je čárka, zatímco středník je oddělovačem parametrů v rámci jedné varianty. Váha varianty je zadána parametrem q:

GET /index HTTP/1.1
Accept: text/html, text/plain;q=0.2, audio/*;q=0.2;mxb=100000
Accept-Charset: ISO-8859-2, unicode-1-1
Accept-Language: cs, sk, en;q=0.9, de;q=0.5

Pokud není váha uvedena, je použita implicitní hodnota 1. V tomto příkladu tedy klient požaduje dokument ve formátu  text/html  s vahou 1.0,  text/plain  s vahou 0,2 nebo  audio/*  s vahou 0,2 a maximální velikostí 100000 slabik. Při výběru dostupné varianty dokumentu server vyhledá všechny akceptovatelné varianty, vypočte jejich váhy jako součin jednotlivých vah dle preferencí klienta a zašle dokument s nejvyšší výslednou vahou. Pokud dokument ve zvolené variantě přesáhne limit velikosti, zvolí následující vyhovující variantu. Priorita preferencí se stejnými vahami postupuje zleva doprava.

2.2 Proxy cache

Základním problémem výběru variant v protokolu http verze 1.0 byla nedořešená otázka ukládání variantních dokumentů do proxy cache. Proxy cache server neví o tom, že pod daným URL se skrývá více variant dokumentů a uloží do své cache pouze jednu. Protokol http verze 1.1 to řeší tím, že pokud je k dispozici více variant požadovaného dokumentu, obsahuje dokument navíc hlavičku Vary:

Content-Type: text/html; charset=ISO-8859-2
Content-Language: cs
Content-Length: 1241
Vary: accept-language, accept-charset
...

Proxy cache server komunikující protokolem http 1.1 musí ukládat dokumenty s hlavičkami Vary společně se všemi hlavičkami Accept-*, které použil pro jejich získání a které jsou uvedeny v hlavičce Vary. V daném příkladu si musí zapamatovat použité hlavičky Accept-Language a Accept-Charset. Takto uložený dokument může poskytnout klientovi pouze tehdy, pokud klient zadal stejné nebo ekvivalentní preference v těchto hlavičkách. Na hodnotě ostatních hlaviček Accept-* neuvedených v hlavičce Vary nezáleží, protože nemají vliv na výběr varianty požadovaného dokumentu.

2.3 Implementace

Hledání dostupných variant dokumentů je řešeno na straně serveru buď vyhledáním všech souborů se stejným začátkem jména bez přípony (index.*) nebo pomocí popisného souboru variant. V prvním případě jsou atributy dokumentů určeny příponami jmen existujících souborů. Například přípona .html znamená, že soubor je typu  text/html , přípona  czech , že je v jazyce českém, apod. V druhém případě jsou jména souborů a jejich atributy dány definicemi v popisném souboru:

# popisný soubor index.var
URI: english.html			# jméno souboru
Content-Language: en			# jazyk
Content-Type: text/html; charset=ISO-8859-1 # typ MIME
URI: czech.html
Content-Language: cs
Content-Type: text/html; charset=ISO-8859-2

V popisném souboru jsou popsány všechny dostupné varianty jednoho dokumentu. Server pozná, že má použít pro dané URL popisný soubor variant podle toho, že existuje soubor se stejným jménem jako v URL a příponou danou konfigurací serveru (obvykle .var).

Při výběru mutace dokumentů se může stát, že žádná z dostupných variant není pro klienta přijatelná. V tomto případě server může odpovědět chybovým kódem 406 (Not Acceptable) a nabídnout dostupné varianty dokumentu:

HTTP/1.1 406 Not Acceptable
Server: Apache/1.2.3
Vary: accept-language
Content-type: text/html
<HTML><HEAD>
<TITLE>406 Not Acceptable</TITLE>
</HEAD><BODY>
<H1>Not Acceptable</H1>
An appropriate representation of the requested resource / could not be found on this server.<P>
Available variants:
<ul>
<li><a href="index.html.czech">index.html.czech</a>, type text/html, charset=iso-8859-2, language cs
<li><a href="index.html.eng">index.html.eng</a>, type text/html, charset=iso-8859-1, language en
</ul>
</BODY></HTML>

3. Transparentní výběr variant

Výběr varianty dokumentu na straně serveru byl sice formálně definován až v protokolu http verze 1.1, ale je již delší dobu implementován a používán. Přitom se začaly postupně objevovat nevýhody této koncepce. Především popis přijatelných mutací dokumentů je u inteligentních prohlížečů poměrně složitý a dlouhý, takže by v plném tvaru podstatně prodlužoval každý požadavek. Naopak dokumenty nejsou obvykle dostupné ve všech možných mutacích, ale pouze v několika málo, například ve formátu  text/html  a  application/pdf . Proto zasílá klient v hlavičkách Accept pouze omezenou podmnožinu popisu svých schopností a volba mutace na straně serveru nemůže být díky tomu optimální. Proxy cache servery navíc musí ukládat dokumenty v různých variantách podle různých použitých preferencí klientů, přičemž nemohou zjistit, zda různé preference nevedou na stejnou variantu dokumentu. Obvykle je počet dostupných mutací dokumentu podstatně menší, než výčet mutací, které akceptuje klient. V definici protokolu http verze 1.1 je proto uvedena možnost přenést výběr varianty dokumentů na stranu klienta. Konkrétní realizace je pak předmětem připravovaného standardu Transparent Content Negotiation [3].

3.1 Funkce

Zásadní rozdíl oproti výběru varianty na straně serveru je transparentnost. Server musí oznámit, jaké varianty dokumentu se pod požadovaným URL skrývají, a to i v případě, že provede výběr optimální varianty sám. Seznam dostupných variant oznamuje novou hlavičkou Alternates. Formát seznamu je volen tak, aby jej mohl klient nebo proxy server snadno zpracovat. Seznam je tvořen bloky popisu jednotlivých variant oddělených čárkami. Každá dostupná varianta je popsána jedním blokem ve složených závorkách. První dva parametry popisu varianty jsou URL varianty a kvalita reprezentace varianty. Kvalita reprezentace varianty vyjadřuje úplnost reprezentace originálních dat. Pokud obsahuje varianta stejné informace ve stejné kvalitě jako originál, pak je kvalita rovna 1. Varianty, které mají horší reprezentaci nebo neobsahují úplná data, mají kvalitu menší než 1. Například obrázek ve formátu GIF má kvalitu 1.0, zatímco varianta ve formátu JPEG může mít kvalitu podle stupně komprese 0,9 až 0,8. Další parametry popisu varianty jsou volitelné. Jsou uloženy ve formě dvojic {jméno hodnota}.

Vary: accept-language, accept-features
Alternates: {"index.html.czech" 1.0 {type test/html} {length 1234}
{charset iso-8859-2} {language cs} {feature tables}},
{"index.html.czech.plain" 0.9 {type test/html} {length 1234}
{charset iso-8859-2} {language cs} {feature !tables}},
{"index.html.eng" 1.0 {type text/html} {length 2341}
{charset iso-8859-1} {language en}}
 

Mimo běžné atributy jako je typ, jazyk, kód a velikost je definován také atribut vlastnosti (features). Tento atribut dovoluje popsat další vlastnosti varianty dokumentu a to rozšiřitelným mechanismem. Vlastnosti reprezentují preference nebo schopnosti prohlížečů. Typickými vlastnostmi mohou být frames, tables, textonly, apod. Vlastnosti mohou mít také hodnotu typu řetězec nebo číslo (například colordepth=8, paper=a4, apod). Pro zavádění nových vlastností je navržen postup registrace [5].

Klient může podobně jako u ostatních atributů zaslat hlavičku Accept-Features, ve které oznámí serveru své preference. Protože některé vlastnosti mohou mít číselné hodnoty, je formát této hlavičky poněkud složitější. Může obsahovat tyto pole:

V následujícím příkladu požadavku je doplněna hlavička Accept-Features s příkladem různých požadovaných vlastností:

GET /index HTTP/1.1
Accept: text/html, text/plain;q=0.2, audio/*;q=0.2;mxb=100000
Accept-Charset: ISO-8859-2, unicode-1-1
Accept-Language: cs, sk, en;q=0.9, de;q=0.5
Accept-Features: tables, frames, screenwidth=800, colordepth={8}, *

Ke každé variantě dokumentu by měl mít server k dispozici její vlastnosti. Způsob uložení vlastností není definován, ale pro tyto účely lze použít konfigurační soubory serveru nebo seznam variant (soubor .var). Při hodnocení variant server analyzuje hlavičky zaslané klientem a porovnává je s vlastnostmi varianty. Při generování popisu variant do hlavičky Alternates navíc server může připojit ke každé vlastnosti, jak se projeví její existence nebo neexistence na zlepšení nebo zhoršení kvality dokumentu:

Alternates: {"index.html.czech" 1.0 {type test/html} {length 1234}
   {charset iso-8859-2} {language cs} {feature tables:1.4/0.8}},

Pokud je vlastnost tables přítomna (případně má uvedenou hodnotu), je kvalita 1,4 krát vyšší, jinak je 0,8 krát menší. Pokud není zlepšení nebo zhoršení kvality explicitně uvedeno, pak je uvažováno 1 a 0 (dokument není akceptovatelný). Hlavička Alternates by měla obsahovat úplný popis všech dostupných variant. Minimálně ale musí obsahovat alespoň hodnoty těch atributů, kterými se varianty liší, tedy těch, které jsou uvedeny v hlavičce Vary.

3.2 Metody výběru

Transparentní výběr varianty je řízen klientem. Pokud klient podporuje transparentní výběr, musí to oznámit hlavičkou Negotiate:

GET /index HTTP/1.1
Negotiate: trans, 1.0
Accept: text/html, text/plain;q=0.2, audio/*;q=0.2;mxb=100000
Accept-Charset: ISO-8859-2, unicode-1-1
Accept-Language: cs, sk, en;q=0.9, de;q=0.5

V hlavičce Negotiate může klient omezit požadovaný typ výběru a specifikovat verzi algoritmu výběru:

Pokud klient povolil výběr varianty na straně serveru a server má dostatek informací z hlaviček Accept zaslaných klientem, provede výběr a zašle odpověď typu choice. Pokud není schopen provést výběr, zašle odpověď typu list.

HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT 
TCN: list
Vary: negotiate, accept-language
Content-Type: text/html
Content-Length: 227
Alternates: {"index.html.czech" 1.0 {type test/html} {length 1234}
{charset iso-8859-2} {language cs} },
{"index.html.eng" 1.0 {type text/html} {length 2341}
{charset iso-8859-1} {language en}}
<h2>Multiple Choices:</h2>
<ul>
<li><a href="index.html.czech">HTML, Czech version</a>
<li><a href="index.html.eng">HTML, English version</a>
</ul>

3.3 Algoritmus vzdáleného výběru varianty

Algoritmus vzdáleného výběru varianty je předmětem samostatného návrhu [4], ale je nedílnou součástí návrhu specifikace transparentního výběru varianty. Výběr varianty dle tohoto algoritmu je volitelný, server může vždy v případě nedostatku informací nebo při nadměrné složitosti vrátit odpověď typu list a přenechat problém klientovi. Vstupními daty pro algoritmus jsou pouze informace obsažené v hlavičce Alternates a hlavičkách Accept od klienta. Díky tomu na rozdíl od výběru varianty na straně serveru dle http 1.1 nemusí běžet algoritmus vzdáleného výběru pouze na serveru, ale také na každém mezilehlém proxy serveru. Algoritmus počítá kvalitu varianty jako součin jednotlivých faktorů kvality:

kde qs je kvalita reprezentace varianty,

qt je faktor kvality typu dokumentu dle váhy v hlavičce Accept,

qt je faktor kvality kódu dokumentu dle váhy v hlavičce Accept-Charset,

ql je faktor kvality jazyka dle váhy v hlavičce Accept-Language,

qf je faktor požadovaných vlastností dokumentu v hlavičce Accept-Features.

Pokud klient nezašle odpovídající hlavičku Accept, je odpovídající faktor pro všechny varianty roven 1. Pokud ale některá hlavička Accept, která odpovídá dimenzi, ve které se varianty liší, schází, nebo bylo použito implicitního prvku * v této hlavičce, pak je vypočtená kvalita varianty spekulativní. Není totiž jasné, zda klient odpovídající informaci nezaslal nebo neupřesnil, protože by musel zasílat příliš mnoho informací, nebo mu na těchto dimenzích variability nezáleží. Pro každou variantu musí tedy algoritmus určit, zda je vypočtená kvalita definitivní nebo spekulativní. Server pak může zaslat odpověď typu choice pouze v případě, že varianta s největší vypočtenou kvalitou má kvalitu definitivní a větší než 0. Ve všech ostatních případech musí server zaslat odpověď typu list a přenechat výběr varianty klientovi.

Poznámka: Algoritmus explicitně zakazuje automatický výběr varianty dokumentu, která má URL vedoucí do jiného adresáře než původní URL (z důvodů bezpečnosti). Běžné řešení češtiny s odkazy typu  /cp1250/addr/index.html  tedy nemůže nikdy generovat odpověď typu choice.

3.4 Implementace

Výběr varianty na straně server a transparentní výběr variant na straně klienta sice lze implementovat ve formě CGI skriptů, ale takováto implementace je nutně nouzová. Ideální implementace znamená zabudování těchto mechanismů do WWW serveru. Jedním z prvních serverů, které podporují výběr variant je server Apache [7]. Výhodou tohoto serveru je jeho modularita, lze snadno přidávat další moduly, které mohou zasahovat do jednotlivých fází zpracování požadavku. Standardní modul mod_negotiation umožňoval již od prvních verzí serveru výběr variant dle jazyka a typu dokumentu. V nyní vyvíjené verzi serveru 1.2 je doplněno zpracování dle definice protokolu HTTP verze 1.1 (RFC 2068, [2]) a pracuje se na implementaci transparentního výběru. Server ovšem standardně nepodporuje automatické překódování mezi různými kódy, které je dostupné jako doplňkové moduly do serveru nebo jako CGI skripty. Cílem vývoje podpory národních kódů pro server Apache proto bylo, aby překódování bylo integrovanou součástí mechanismu výběru variant a aby umožňovalo uživateli vybírat kód dokumentu stejnými mechanismy, které jsou použity pro výběr jazyka a typu dokumentu. Vyvíjený modul mod_html [6] je určen pouze pro zpracování dokumentů typu text/html, text/* a CGI skriptů. Při dané koncepci serveru Apache zatím neumožňuje transparentní překódování všech výstupů serveru, tedy i těch, které vznikají v jiných modulech serveru. To umožní až vyvíjená nová verze serveru Apache 2.0, která umožní zařadit výstupní filtr z libovolného modulu. V praxi se ale ukazuje, překódování výstupu základních modulů a textových dokumentů zcela postačuje. V případě potřeby samozřejmě není problém doplnit překódování i do jiných modulů.

3.5 Postup zpracování požadavku

Generování variant dokumentů postupuje dvěmi různými cestami. První cesta je použita v okamžiku, kdy URL v požadavku neodpovídá souboru ve stromu WWW dokumentů. V tomto případě server vyhledá v odpovídajícím adresáři všechny soubory, které mají stejné bázové jméno souboru (bez přípon) jako jméno v URL. Pokud je nalezen alespoň jeden takový soubor, pokračuje zpracování dále, jinak zpracování končí a server oznámí, že dokument neexistuje. Standardním postupem je pro každý nalezený soubor vygenerována pomocí mechanismu subpožadavku struktura popisující variantu. Tato struktura obsahuje všechny atributy daného dokumentu, tj. typ dokumentu, jazyk, kód, velikost, atd. Ke každé nalezené variantě pak doplní modul mod_html všechny další varianty ve všech kódech, které je schopen vygenerovat. Konečný seznam variant pak podléhá běžnému zpracování výběru varianty nebo transparentnímu výběru, tak jak bylo výše uvedeno.

3.6 Výběr kódových variant

Druhá cesta zpracování je použita v okamžiku, kdy URL v požadavku odpovídá souboru ve stromu WWW dokumentů. V tomto případě standardní server Apache neaktivuje výběr varianty, protože ta je přesně určena. Nicméně při spolupráci s modulem mod_html zde může nastat výběr varianty podle požadovaného kódu. Proto je zde doplněno vygenerování všech kódových variant nalezeného dokumentu a opět standardní výběr varianty.

3.7 Výhody uvedeného řešení

Vložením mechanismu výběru kódu do standardního mechanismu výběru varianty je docíleno několika předností oproti jiným řešením:

• Pokud klient zasílá standardní hlavičku Accept-Charset, je dohoda na požadovaném kódu automatická.
• Pokud klient tuto hlavičku nezasílá, může server vygenerovat implicitní hlavičku Accept-Charset podle typu klienta, domény, ze které komunikuje, apod.
• Pokud nelze uspokojit požadavek klienta na výběr varianty, dostane uživatel standardní odpověď 406 (Not Acceptable) a může si z nabídnutého seznamu dostupných variant vybrat variantu v tom kódu, který mu vyhovuje.
• Pokud zvládá klient transparentní výběr variant, má dostupné plné informace o všech dostupných kódech a může si vybrat optimální kód pro zobrazení dokumentu.

Pro explicitní výběr varianty dokumentu musí mít ovšem klient možnost požádat o konkrétní kódovou variantu zadáním URL varianty. Toto URL musí v sobě skrývat jako jazykovou mutaci dokumentu, tak kódovou mutaci. Logickým řešením je rozšíření přípony jména dokumentu o požadovaný kód ve tvaru URI.lang.code. Oproti u nás běžnějšímu řešení ve tvaru /jazyk_kód/URI nemultiplikuje strom WWW dokumentů v různých vyhledávacích serverech a protože URL různých kódových variant dokumentů má stále stejnou přístupovou cestu, nečiní problémy při transparentním výběru varianty.

3.8 CGI skripty

Modul mod_html filtruje výstup běžných CGI skriptů a může tak podle potřeby překódovat výstup skriptu. Tato vlastnost neplatí pro nph-skripty, tj. skripty, které generují všechny hlavičky a nejsou filtrovány serverem. Každý CGI skript, který generuje výstup, musí vygenerovat hlavičku Content-Type, případně další hlavičky a poté prázdný řádek. Prázdný řádek signalizuje konec hlaviček a začátek vlastních dat. CGI skripty, které generují výstup v jiném kódu, než ISO-8859-1, musí v hlavičce Content-Type signalizovat použitý kód:

Content-Type: text/html; charset=iso-8859-2

Toto je výstup v kódu ISO-8859-2
..

Pokud není parametr charset v hlavičce uveden, předpokládá se, že výstup je v kódu ISO-8859-1.

3.9 Jazykové mutace CGI skriptů

Při použití CGI skriptů je třeba rozlišit dva základní přístupy. Buď je pro daný CGI skript použit výběr varianty serverem nebo není. V prvním případě existují různé jazykové varianty skriptu a každá takováto varianta má jméno souboru doplněné příponou zkratky jazyka:

/WWW/cgi-bin/script.cz
/WWW/cgi-bin/script.en

Tento postup je stejný jako při vytváření jazykových mutací dokumentů. V tomto případě se na skript odkazujeme pomocí URL  /cgi-bin/script  a server vybere požadovanou mutaci podle preferencí klienta. Předpokladem samozřejmě je, že pro adresář CGI skriptů je povolen parametr MultiViews. Skript generuje výstup přímo v daném jazyce a měl by generovat hlavičku Content-Language se správným obsahem:

Content-Type: text/html; charset=iso-8859-2
Content-Language: cs

Toto je výstup v jazyce cs a kódu ISO-8859-2
...

Kód výstupu může být libovolný a proto je při výběru jazykové mutace skriptu pouze odhadnut. Teprve po spuštění patřičné jazykové verze skriptu a dekódování hlaviček, které vyprodukoval, zjistí server skutečný kód, ve kterém skript výstup vyprodukoval. Pokud nesouhlasí s odhadem, musí provést dodatečnou volbu kódové mutace dokumentu podle preferencí klienta. Výsledkem je obvykle úspěšná volba toho kódu, který požaduje klient, ale výsledkem může být také neúspěšný výběr (výstup skriptu neodpovídá požadavkům klienta). Při neúspěšném výběru je výstup skriptu ignorován a klient dostane pouze signalizaci chyby (NOT ACCEPTABLE nebo MULTIPLE_CHOICE). Pokud byl výběr úspěšný, dostane klient výstup v požadovaném kódu, což může být jiný, než který skript oznámil a generuje. Při překódování výstupu modul mod_html zároveň doplní do odkazů v dokumentu kontext (zvolený kód a případně jazyk) a zpracuje vložené příkazy.

V druhém případě, jazykově neutrální nebo univerzální skript, existuje pouze jeden skript a výběr podle jazyka, typu a kódu není uplatněn. Kód výstupu může být opět libovolný, server provede dodatečný výběr kódové varianty dokumentu po dekódování hlaviček výstupu skriptu a případně převede výstup skriptu do kódu, který požaduje klient. Skript musí sám určit v jakém jazyce je požadován. Problémem zde je, že odpovídající hlavička Accept-Language může mít poměrně složitý tvar, viz výše. Skript by měl generovat na výstupu hlavičku Content-Language, ale její obsah musí být kompatibilní s hlavičkou Accept-Language. Pokud by nebyl, mohlo by se stát, že při následném výběru kódové varianty bude shledána vygenerovaná varianta nepřijatelnou a výsledkem bude odpověď Not Acceptable.

4. Závěr

Automatický výběr variant a zejména transparentní výběr variant umožňují poskytovat dokumenty v různých jazycích a kódech. Na rozdíl od jiných řešení mohou být takto poskytované dokumenty bez problémů ukládány do proxy cache. Transparentní výběr varianty dokumentu může být dokonce přesunut na proxy cache server, který v případě dostatku informací nemusí vůbec kontaktovat zdrojový WWW server. Řešení problému poskytování různých kódových variant stejného dokumentu v našich podmínkách by mělo využívat těchto standardních mechanismů, což bylo hlavním kritériem při vývoji modulu mod_html pro server Apache. Stávající verze modulu plně začleňuje výběr kódové varianty do standardního algoritmu výběru varianty na straně serveru a po dokončení vývoje transparentního výběru varianty bude podporovat i tento algoritmus (stávající verze serveru Apache má částečně implementovánu první verzi návrhu [3], ta je však již zastaralá a liší se od zde uvedeného popisu).

Literatura:

[1] T. Berners-Lee, R. Fielding, H. Frystyk: Hypertext Transfer Protocol -- HTTP/1.0, RFC 1945, May 1996

[2] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1, RFC2068, January 1997

[3] Koen Holtman, TUE, Andrew Mutz, Hewlett-Packard: Transparent Content Negotiation in HTTP, http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-negotiation-03.html, July 1997

[4] Koen Holtman, TUE, Andrew Mutz, Hewlett-Packard: HTTP Remote Variant Selection Algorithm - RVSA/1.0, http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-rvsa-v10-02.html, July 1997

[5] Koen Holtman, TUE, Andrew Mutz, Hewlett-Packard: Feature Tag Registration Procedures, http://gewis.win.tue.nl/~koen/conneg/draft-ietf-http-feature-reg-02.txt, July 1997

[6] Lampa, P.: Dokumentace k modulu mod_html, http://www.fee.vutbr.cz/~lampa/mod_html

[7] Apache Group: Apache User's Guide, http://www.apache.org/docs/