Obdobně Gopheru je přenosový kanál i v tomto případě po předání souboru WWW-serverem uzavřen, na přenos každého obrázku se tak vždy vytváří znova. Takovýto tvar protokolu HTTP , tedy komunikace WWW-klienta s WWW-serverem, je vlastně ještě jednodušší než tomu bylo u Gopheru. Nutno ovšem říci, že dobře vyhovuje, pokud klient získává z WWW-serveru zdrojové texty HTML-stránek anebo pak soubory, o nichž předem ví, že to jsou obrázky.
Při přenosu jiných souborů již například nemusí být klientu jasné, jakým
způsobem má být soubor interpretován. Situaci zpravidla odhaduje podle koncovky
pojmenování souboru. ( V Gopheru byl
tento problém vyřešen zavedením pole Type .)
Další nejasnosti se mohou někdy objevit, je-li takovýmto způsobem přenášen
velký textový soubor. Jeho konec pozná klient též uzavřením přenosového kanálu,
což ovšem může způsobit problémy při zrušení kanálu třeba kvůli komunikačním
chybám. ( Zcela analogicky přenosu binárních souborů
v Gopheru. Ostatní soubory jsou v něm totiž zakončovány
samotnou tečkou na řádku.)
Také pro WWW-server je o něco složitější okamžitě poznat, zda cesta
končí jménem souboru či adresáře. Někdy je tak WWW-klient nucen svůj požadavek
opakovat. ( Gopher kvůli
tomu požadavek v poli Path
znovu obvykle začíná stejnou hodnotou jako Type .)
Specifikaci cesty končící v adresáři je pro WWW-server nejlepší vždy zakončit
lomítkem, cestu končící konkrétním souborem nikoliv.
Končí-li cesta adresářem ( analogicky Gopheru, který pak zasílá Menu ) , WWW-server zpravidla zasílá soubor určitého jména, stanoveného při konfiguraci, nejčastěji index.html nebo welcome.html případně index.htm a podobně. Otázkou samozřejmě je, jak se WWW-server zachová, když takovýto soubor v adresáři neexistuje. WWW-server může být v takovémto případě schopen, nemá-li to případně i zakázáno v konfiguraci, vygenerovat WWW-stránku uvádějící jména všech souborů v onom adresáři - přesněji řečeno, všech souborů v systému obvykle používaných jmen. Takto také původně vznikl tvar WWW-stránky rozebírané v předchozí kapitole.
Popsané principy spolupráce klienta s WWW-serverem jsou v podstatě stejné jako spolupráce klienta s Gopher-serverem. Přitom Gopher má v poli Path naplněn přesně takový požadavek, který klient zasílá serveru. V zásadě je tak možné, aby onen požadavek vypadal jako: GET /cesta . Bude-li přitom zároveň uvedeno Port=80 , je pak z prostředí Gopheru možno spolupracovat i s WWW-servery.
Problémem samozřejmě je, zda v tomto případě klient získané soubory umí uživateli správně interpretovat, třeba jako obrázky nebo čitelné HTML-stránky. Nutno říci, že Type=I jako "image" v Gopheru předpokládá zpracování obrázků, anebo také Type=g , to mají být přímo obrázky ve formátu GIF - viz RFC1436 [1]. Posléze se objevila i možnost specifikovat Type=h , kdy získaný soubor ( v prostředí Gopheru ) má být interpretován hypertextově. Obvykle se tím myslí interpretace podle jazyka HTML.
Tento ( Gopheru zcela podobný ) způsob spolupráce WWW-klienta s WWW-serverem
se podrobněji neobjevil v žádném RFC-dokumetu. Pouze
v RFC1945 [2]
je tato základní varianta protokolu http označována jako
verze 0.9 . Uváděné RFC1945 se podrobně věnuje
vyšší verzi protokolu, který již odstraňuje shora naznačené problémy spolupráce
mezi klientem a WWW-serverem.
Tato vyšší verze protokolu http byla označena jako
1.0 . Nejpodstatnější změnou asi bylo, že bezprostředně
před každým přenášeným souborem WWW-server posílá ještě jeho hlavičku
( header ), podle níž může WWW-klient zjistit, jak má být správně soubor
interpretován či jakou má velikost. ( Tedy to, co ve srovnání
s Gopherem nebylo zpočátku ve WWW úplně do detailů
domyšleno. )
Takto konkrétně vypadá odpověď serveru, jenž zašle WWW-stránku
z předcházející kapitoly podle vyšší verze protokolu http :
HTTP/1.1 200 OK
Date: Fri, 19 Feb 1999 16:00:50 GMT
Server: Apache/1.2.4
Last-Modified: Tue, 19 May 1998 16:57:43 GMT
ETag: "205fd-5be-3561ba07"
Content-Length: 1470
Accept-Ranges: bytes
Connection: close
Content-Type: text/html
<HEAD><TITLE>Index of /kizi/information </TITLE></HEAD><BODY>
<H1>Index of /kizi/information</H1>
<PRE><IMG SRC="downloader/0.gif" ALT=" "> Name Last ..
<HR>
<IMG SRC="downloader/1.gif" ALT="[DIR]"> <A HREF="/kizi/">Parent Directory<..
...
...
...
<IMG SRC="downloader/4.gif" ALT="[ ]"> <A HREF="DIR">DIR</A> ..
</PRE></BODY>
Prázdný řádek ukončuje hlavičku a odděluje tak zároveň začátek vlastního souboru.
Nutno snad ještě poznamenat, že všechny řádky hlavičky ( včetně prázdného )
mají být vždy ukončeny dvojicí znaků CR LF . ( Ve vlastním HTML-souboru
tomu tak ale již býti nemusí.) Nikoliv podstatně odlišnou nesrovnalostí vůči
dosud uvedenému je, že WWW-server pracuje ještě ve vyšší verzi protokolu
http , a to 1.1 . ( O čemž bude ještě zmínka v dalším.)
Verze protokolu byly navrženy trochu odlišné i pro způsob, jímž klient
formuluje svůj požadavek pro získání souboru. Na základě toho by také server
měl svou odpověď přizpůsobit úrovni klientem použitého protokolu. Umí-li
klient zadat na náš soubor jen požadavek GET /kizi/information/ ,
zašle mu jej přesně jen tak, jak lze soubor vidět v předchozí kapitole.
Pro zde uvedený tvar odpovědi serveru musí i požadavek odpovídat vyšší verzi
protokolu. Ta předpokládá možné uvedení analogických informací WWW-klientem,
jaké uvádí v hlavičce i WWW-server. Obecně lze tvar požadavku vyjádřit jako
GET uri HTTP/1.0
header požadavku ( nepovinný )
prázdný řádek
( = pouze CR LF )
uri znamená buď cestu ( pro WWW-server ) k souboru, anebo to může být celé URL , v němž pak bude obsažena i specifikace počítače. Oproti předchozímu tvaru požadavku je zde ještě uváděno HTTP . Podle toho WWW-server pozná, že má ještě očekávat další řádky (řádek) od klienta. Každý tento řádek končí dvojice znaků CR LF .
Za slovem HTTP následuje lomítko a verze protokolu http, takže lze rozpoznat i požadavky dalších verzí. Pro mnohé WWW-servery však stačí uvést jen HTTP , což implicitně chápou jako specifikaci pro protokol verze 1.0 . Požadavek pro výše zde uvedený tvar odpovědi byl konkrétně zadán takto:
GET /kizi/information/ HTTP
prázdný řádek
Po zaslání souboru (s hlavičkou) WWW-server i nyní opět uzavírá přenosový
kanál. Klient pak analogickým způsobem po serveru žádá zaslání obrázků
a dostává přitom takovéto odpovědi:
HTTP/1.1 200 OK
Date: Fri, 19 Feb 1999 16:01:29 GMT
Server: Apache/1.2.4
Last-Modified: Thu, 06 Nov 1997 18:20:05 GMT
ETag: "c744-94-34620a55"
Content-Length: 148
Accept-Ranges: bytes
Connection: close
Content-Type: image/gif
GIF89a. . Ą . ...
...
Hlavičky (headers) zavedené od verze protokolu http 1.0 jsou tvořeny
podle obvyklých pravidel jako záhlaví dopisů v Internetu, přesněji řečeno
pravidel pro jejich rozšířený tvar podle MIME ( blíže viz
RFC1521 [3] ).
Někdy se tak lze setkat s formulací, že přenos podle vyšších verzí protokolu
http využívá MIME . Obdobná formulace se též používá v souvislosti
s přenosem E-mailu, což se ale častěji chápe jako způsob zakódování a
rozkódování českého textu eventuálně vkládaných binárních souborů. WWW-klient
takovéto rozkódování ale nebývá schopen zvládnout a český text se zakódovaný
podle MIME mezi WWW-serverem a WWW-klientem nepřenáší.
Jaké údaje jsou v hlavičkách přenášeny ? Ze strany klienta to nemusí být sice žádné, ale zpravidla je vždy uváděna informace (= řádek) User-Agent: o jménu a prostředí klienta. Někdy může klient v řádku From: uvádět i uživatelovu E-mailovou adresu. Zmiňované RFC1945 hovoří o tom, že by se tak nemělo dít bez souhlasu uživatele. Snad se lze ještě zmínit o položkách Accept: , ty sice oficiálně patří až do verze protokolu 1.1 , ale řada klientů je začala používat již dříve pro informace o tom, jaké typy souborů umějí správně interpretovat. Někdy tak možná zdlouhavě zasílají serveru snad až příliš dalších informací - ve srovnání s verzí 0.9 .
Obdobně v hlavičce zasílané WWW-serverem klientu ( spolu se souborem ) se vždy objevuje jeho jméno - viz výše řádek Server: . Z dalších položek (řádků) je zajímavá například informace Last-Modified: uvádějící časový údaj, který je v systému přiřazen zasílanému souboru.
Především je doporučeno, aby server v hlavičce uváděl explicitně položku Content-Length: specifikující velikost přenášeného souboru. Díky tomu je pak klient schopen eliminovat případné problémy vyvolané nesprávným přerušením přenosového kanálu. Poslední obvykle bývá v hlavičce ( snad významově nejpodstatnější ) řádek Content-Type: uvádějící typ souboru, tedy informaci o způsobu, jak má být klientem tento soubor interpretován. Viz z předchozích příkladů: text/html , image/gif . ( Na doplnění lze snad uvést, že pro obyčejný textový soubor by to bylo text/plain .) Je sice pravda, že WWW-server tuto informaci obvykle také odvozuje z koncovky jména zasílaného souboru, ale při tvorbě WWW-stránek nebývá problémem respektovat (známá) pravidla v prostředí příslušného operačního systému.
V RFC1866 [4]
popisujícím jazyk HTML verze 2.0 je v části 5.2.5 zmínka o specifikaci
<META> použitelné v úvodu HTML-dokumentu, v části
<HEAD> .
Její tvar
<META HTTP-EQUIV="položka" CONTENT="text">
má umožnit, aby WWW-server v hlavičce tohoto souboru (dokumentu) uváděl i řádek
položka: text
( pokud tak nedojde k rozporům se systémovými informacemi serveru ). Ve
skutečnosti však většina WWW-serverů takovouto položku do hlaviček odpovědí
ale uvést neumí. Pokud se klient touto informací řídí, převezme ji až
z přeneseného zdrojového textu, z jeho "hlavičky", tj. z části <HEAD> .
Poznámka: Specifikace <META> je v podstatě jediná věc,
jak souvisí HTTP-hlavička z přenosu souboru s HTML-hlavičkou zdrojového textu.
Verze 1.0 protokolu http umožňuje používat kromě metody
GET známé z původní verze také ještě
HEAD a POST . Požadavek HEAD
se zadává zcela shodně jako GET , WWW-server přitom ošem jako odpověď zasílá
jenom úvodní hlavičku ( tedy HTTP-hlavičku ), jakou by ( v úvodu ) posílal při
požadavku na tento soubor ( zadaném pomocí GET ). Naproti tomu POST umožňuje,
aby i klient zasílal serveru ( za hlavičkou svého požadavku ) přímo nějaká data,
nejčastěji nějaký textový soubor. A záleží potom na programovém vybavení
WWW-serveru, jak s takto získanými daty nakládá a jak je dál zpracovává.
Takto vypadá konkrétní požadavek používající zmíněnou metodu. Klient zaslal
požadavek WWW-serveru na listserv.cesnet.cz [5],
jenž kromě zaslání informativní WWW-stránky o přijetí požadavku zabezpečí i
jeho následné zpracování Listserverem. Uživatel pak na adresu ( uváděnou
v datové části ) obdrží E-mailem přehled hlavních příkazů Listserveru.
POST /lwgate/ HTTP/1.0
Content-Length: 41
prázdný řádek
execute=info&email=jjkastl@vse.cz&ref=yes
Dodejme, že v hlavičce musí klient vždy uvést velikost souboru (dat), který takovýmto způsobem WWW-serveru zasílá.
Protokol 1.0 přispěl především k rozvoji dalších možností a variantních
způsobů spolupráce WWW-klienta s WWW-serverem. Přesto obsahuje i některá slabá
místa. Ve specifikaci uri se může objevovat
adresa cílového počítače (tak jak ji zadával uživatel), čehož záhy začaly některé
programy WWW-serverů využívat při odpovědích. Problémem přitom bylo, že nikoliv
vždy se v komunikaci klienta ona adresa cílového počítače musí objevit.
Druhým problémem ( a to obou ) verzí protokolu je koncepční nelogičnost
s vytvářením kanálu pro přenos obrázků. Vytvoření ( a následné zrušení )
přenosového kanálu pro každý obrázek principiálně vyhovuje, pokud je nějaký
( třeba odborný ) text doplněn pár obrázky. Při přenosu například úvodní
WWW-stránky, do které je zakomponováno 10, 20 obrázků, je zbytečně zdlouhavé
stále znovu vytvářet přenosový kanál.
Oba tyto problémy se snažila překonat u protokolu http verze 1.1 . Přenosový kanál nemusí být po zaslání souboru serverem rušen. Přesněji řečeno, pokud zrušen bude, má to WWW-server výslovně uvést v řádku Connection: v hlavičce zasílané stejným způsobem i ve verzi protokolu 1.1 před vlastním souborem. V předchozích ukázkách odpovědí serveru se vždy objevuje Connection: close , protože WWW-server se takto snažil přizpůsobit požadavkům klienta, který s ním komunikoval podle protokolu 1.0 . Jak vypadá požadavek na stejnou WWW-stránku podle protokolu http 1.1 ( při němž WWW-server neruší přenosový kanál ) ?
GET /kizi/information/ HTTP/1.1
Host: beta.vse.cz
prázdný řádek
Požadavek zasílaný klientem se od předcházející verze liší pouze v tom, že nyní je již potřeba vždy uvádět za slovem HTTP verzi protokolu 1.1 , ale především nyní musí být v hlavičce požadavku (minimálně) položka Host: nějakým způsobem vždy naplněna.
Odpovědi serveru vypadají zcela shodně jako za předchozí situace, pouze
řádek (položka) Connection: chybí. To zároveň znamená, že
přenosový kanál WWW-serverem nebyl uzavřen a klient může hned zadat požadavek
na poslání obrázku ( jako třeba ve výše uváděném příkladě na
/icons/blank.gif ).
Pokud WWW-klient nezadá v hlavičce svého posledního požadavku na obrázek
položku Connection: close , WWW-server zpravidla
udržuje kanál po jistou dobu ještě otevřený. Pokud však neobdrží v této době
další požadavek, sám kanál uzavře. Z tohoto pohledu tak můžeme stále hovořit
o spolupráci WWW-klienta s WWW-serverem jako spíše o účelové
( nespojované ) spolupráci.
S jistým zjednodušením lze říci, že protokol http 1.1 je obdobný předchozí verzi 1.0 s přesnějším a podrobnějším popisem položek (řádků) HTTP-hlaviček - viz RFC2068 [6]. Nejpodstatnější odlišností je udržování otevřeného přenosového kanálu mezi klientem a serverem, což však není zásadním způsobem využito k rozšíření forem jejich spolupráce.
Protokol 1.1 umožňuje sice využití ještě dalších metod spolupráce,
konkrétně: OPTIONS , GET ,
HEAD , POST , PUT ,
DELETE , TRACE . Pouze GET a HEAD
musejí být každým serverem akceptovány. V opačném případě má server uvádět
v hlavičce odpovědi, v její první řádce, buď z verze 1.0 již známé
HTTP/1.1 501 Not Implemented
nebo nově zavedené
HTTP/1.1 405 Method Not Allowed ,
pokud některá metoda není povolena v jistých souvislostech případně
pro jisté klienty.
Kódy těchto zpráv jsou číslovány značně analogicky jako zprávy v protokolu
SMTP ( viz následující kapitola ), které si SMTP-programy
navzájem vyměňují při přenosu E-mailu. Číslování je trojciferné, přičemž
1__ začínají informativní zprávy ( nebylo použito ve verzi 1.0 ) ,
2__ začínají "úspěšné" odpovědi, 3__ začínají odpovědi
instruující klienta učinit něco jiného, dalšího. 4__ jsou "měkké"
chyby, které se zpravidla týkají činnosti klienta, a 5__ "tvrdé"
chyby dané možnostmi serveru.
Následující příklad jest ukázkou skutečné komunikace s WWW-serverem podle http-protokolu verze 1.1 , při první odpovědi serveru se zde objevuje zpráva s kódem 301 . Přenosový kanál přitom zůstal celou dobu otevřený :
HEAD /kizi/information HTTP/1.1
Host: beta.vse.cz HTTP/1.1 301 Moved Permanently
Date: Tue, 30 Mar 1999 15:51:04 GMT
Server: Apache/1.2.4
Location: http://beta.vse.cz/kizi/information/
Content-Type: text/html
HEAD /kizi/information/ HTTP/1.1
Host: beta.vse.cz HTTP/1.1 200 OK
Date: Tue, 30 Mar 1999 15:51:24 GMT
Server: Apache/1.2.4
Last-Modified: Tue, 19 May 1998 16:57:43 GMT
ETag: "205fd-5be-3561ba07"
Content-Length: 1470
Accept-Ranges: bytes
Content-Type: text/html
...
Connection closed by foreign host.
Klient v příkladu využil metodu HEAD , v požadavku jím zadaném
končí cesta ( uri ) jménem adresáře, avšak na konci
nebylo uvedeno / . WWW-server proto klientu v odpovědi
specifikoval ( viz položka Location: ), jak by měl
(znovu) požadavek zadat.
Udržování ( jistou dobu ) otevřeného přenosového kanálu se asi nejpodstatnějším
způsobem projevilo v možnosti "rourování" požadavků klientem -
v angličtině možná lepší termín pipelining . Klient může serveru
zaslat - při otevřeném přenosovém kanálu - naráz více požadavků ( třeba na všechny
obrázky úvodní WWW-stránky ), aniž by po každém požadavku vždy čekal na odpověď
WWW-serveru. Protože však v hlavičkách odpovědí není uváděno něco jako
"požadované uri" ( například tedy jméno žádaného obrázku ), musí WWW-server -
pokud je schopen "rourování" akceptovat - zaslat
odpovědi přesně v takovém pořadí, jak klient požadaky zadal. Jinak by
klient samozřejmě nemohl vědět, třeba kam který z obrázků patří. RFC2068
potom rozebírá i takovou situaci, když dojde k uzavření přenosového kanálu
v okamžiku nepředpokládaném klientem.
Cíl takovéhoto seskupování požadavků ( ale i odpovědí serveru ) je zřejmý,
zajistit při transportu jednoho IP-datagramu co možná jeho nejlepší
(největší) využití.
Problémy spolupráce WWW-klienta a WWW-serveru však nevznikají obvykle kvůli
otevírání a uzavírání přenosového kanálu, ale spíše kvůli odlišnému tvaru
hlaviček v různých verzích protokolu http. Chování klienta a serveru, které
oba nejsou připraveny pro tutéž verzi, se obecně snaží upřesnit
RFC2145 [7].
I když je zatím využitelné jen pro verze 1.0 a 1.1 .
( O vyšší verzi se RFC-dokumenty dosud nezmiňují, naopak se
nedávno pro http 1.1 objevilo
RFC2616 [8]
"přepisující" v podstatě RFC2068.)
Přesto některé servery nerespektují doporučený tvar spolupráci s klienty
(dvou) nižších verzí.
Ze serverů používaných u nás se asi nejlépe chovají servery Apache.
Pokud obdrží požadavek ve verzi 1.1 , odpovídají klientu podle této verze.
Pokud je požadavek v 1.0 , upraví odpověď podle tohoto protokolu ( viz
řádky Connection: close v předchozích příkladech ).
Pokud se na ně klient obrátí podle protokolu 0.9, vůbec v odpovědi
neuvádějí hlavičku, ale pouze požadovaný soubor. - Odtud pramení doporučení,
aby při odpovědích, jako ve ( výše zmíněném ) typu 301 ,
se krátká informace objevovala i v datové (obsahové) části odpovědi zasílané
WWW-serverem.
Naopak asi nejhůře jsou požadavkům podle nižších verzí protokolu http schopni
se přizpůsobovat servery Microsoft - IIS
(Internet Information Server 4.0). Uživateli potom zbývá
zkusit se jedině propojovat ( jak bude v dalším ) přes vhodný proxy-server .
Jen připomeňme, že virtuální přenosový kanál je určován čtveřicí čísel:
IP-adresami počítačů a porty použitými na cílovém a počátečním počítači.
Přenosový kanál tak vypadá pro WWW-server vždy stejně a podle takovýchto údajů
bude i odpověď serveru stejná. Využije-li však WWW-server z hlavičky požadavku
onu informaci ( Host: ) o zadaném jménu počítače, může pak jeho
odpověď být zcela odlišná. Tedy může zasílat zcela různé HTML-stránky, včetně
samozřejmě i WWW-stránky úvodní. Cesty k dalším souborům pak mohou být zcela
odlišné a vůbec nemusí být ani umožněno přejít z jedné varianty WWW-stránek
nějak k jiné, ledaže by uživatel zadal pouze jí odpovídající (alias-)jméno
cílového počítače. Takovýto server se pak uživateli jeví jako dva nebo i
více - úplně či jen částečně - odlišných serverů. A o těch právě hovoříme
jako o virtuálních WWW-serverech.
Jeden z prvních virtuálních WWW-serverů u nás byl na
Karlově univerzitě [9] ,
kde snad stále ještě mají informaci názorně vysvětlující onu skutečnost.
I na VŠE se posléze začaly objevovat virtuální WWW-servery. Například helpdesk.vse.cz [10], jehož originální HTML-stránku bychom mohli získat třeba takovouto specifikací URL: gopher://helpdesk.vse.cz:80/0GET / [11] . Toto je jeden ze způsobů, jak WWW-serveru na adrese helpdesk.vse.cz zadat požadavek podle http-protokolu 0.9 . WWW-server tak z (neexistující) http-hlavičky nemůže převzít žádnou informaci o zadaném jménu cílového počítače a zašle jako odpověď implicitní HTML-stránku originálního WWW-serveru. -- To by se ovšem mohlo stát i při použití protokolu 1.0 , až teprve ve verzi 1.1 musí vždy být (nějak) předáváno WWW-serveru také ono jméno cílového počítače.
V souvislosti s virtuálními servery je třeba se zmínit o možném problému
při zkracování doménových adres, obvykle v rámci sítě určité organizace.
Příkladně na VŠE je v řadě aplikací možno zadávat jako adresu jen jednoslovné
jméno počítače. Pro určení IP-adresy je jméno implicitně rozšiřováno
o (doménu organizace): vse.cz A tím je možno definovat
přenosový kanál, který tato aplikace využívá. Problém při spolupráci
WWW-klienta s virtuálním serverem může někdy způsobit situace, když
v http-hlavičce je předáno serveru jen jednoslovné jméno počítače.
( Například, zadává-li uživatel na VŠE jen specifikaci
http://helpdesk/ [12].) Jeden ze způsobů,
jak toto bez problémů vždy uživatelům umožnit, je definovat dva
virtuální servery. Například
kizi2.vse.cz
[13] a pak
druhý ( začínající ve zcela stejném adresáři ) jen pro
kizi2
[14] ( a samozřejmě
využitelný těžko vně VŠE ).
Podle hlaviček klientem zasílaných požadavků může WWW-server sám (automaticky) zvolit kód češtiny, ve kterém pak zašle svou odpověď zpátky WWW-klientu. Jaký kód WWW-klient preferuje, by měl uvádět v položce Accept-Charset: , která je ovšem oficiálně uváděna až ve verzi 1.1 . ( I když ve verzi 1.0 je o ní zmínka v dodatcích, co se nad rámec tohoto protokolu již nezávazně využívá.) Naplnění této položky ale není povinné a navíc řada našich WWW-klientů je "počeštěna" tak, že v této položce správně neuvádí kód skutečně používaný k interpretaci výstupů.
A tak se (u nás) rozšířilo, že se nakonec spíše využívá položka User-Agent: , ve které se každý klient snaží uvádět svoje jméno a také informaci o operačním prostředí. Z toho pak lze odhadnout, v jakém kódu češtiny bude tento klient nejspíše pracovat. ( A což samozřejmě nemusí být správně pro konkrétní implementaci.) Skutečně poslaný obsah zmíněných http-hlaviček ( při této konfiguraci klienta ) lze vidět třeba zde [15].
Například pro poslední konfiguraci - na VŠE - prohlížeče Netscape lze vidět takovéto informace:
HTTP_HOST = 146.102.64.30
HTTP_ACCEPT_CHARSET = iso-8859-1,*,utf-8
HTTP_ACCEPT_LANGUAGE = en
HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
HTTP_CONNECTION = Keep-Alive
HTTP_USER_AGENT = Mozilla/4.05 [en] (Win16; I ;Nav)
HTTP_REFERER = http://146.102.64.30/kizi/IKSy/kap8.iso88592.html
toCP1250
Jednotlivé řádky nezačínají přesně tak, jak mají vypadat položky
v http-hlavičce, ale jejich význam je jistě zřejmý. Odhlédneme-li od
toho, že klient komunikoval podle protokolu 1.0 , ale přitom přenosový
kanál nemusel být serverem uzavírán - viz podle
RFC1945 [2]
a RFC2068
[6]
"přechodná" položka Connection: Keep-Alive , je především položka
Accept-Charset: uváděna špatně, neboť onen prohlížeč neinterpretuje kód
ISO-Latin1 ( tj. ISO-8859-1 ), ale Windows-1250 . Pro správné
( nebo správnější ) rozhodnutí o volbě kódu je potřeba někdy použít až
druhou z tučně uváděných položek User-Agent: . Jak se WWW-server
rozhodne - lépe řečeno, jak se rozhoduje tento program "ladění" - je napsáno
na posledním řádku. ( Což je pochopitelně přizpůsobeno konvencím následně
spustitelného programu pro konverzi do jiných kódů češtiny.)
Z uvedeného příkladu je již zřejmé, že prakticky nelze ve všech případech rozhodnout úspěšně o správném kódu české diakritiky. Nešťastnou strategií jisté pseudodokonalosti používané na některých našich WWW-serverech je aplikace automatické volby kódu češtiny zasílaných HTML-stránek, aniž má uživatel možnost volbu, která mu z nějakého důvodu nevyhovuje, snadno změnit. I když bývá v nejasných případech zasílán HTML-soubor s odstraněnými diakritickými znaménky ( v kódu ASCII-1 ), nebývá bohužel pro uživatele v nezbytných případech ani tato varianta explicitně volitelná.
Konec konců pro automatickou volbu češtiny mohou být WWW-serverem využity
i informace z jiných položek. ( Například i z http-položky
Cookie: ) Toto už vůbec nebývá na WWW-serveru zveřejňováno, takže
kdyby uživatel i mohl změnit konfiguraci používaného WWW-klienta a ovlivnit
tím obsah http-položek, jejich potřebný tvar se ani nedozví.
Možná ještě větší problém takto realizované "pseudodokonalosti" se
projevuje při spolupráci s proxy-servery ( a jejich schopností poskytovat
úspěšně WWW-stránky v příslušném kódu češtiny ).
Co vlastně je proxy-server ? Dá se říci, že program, který umí pracovat jako klient i jako WWW-server. Získané stránky si určitou dobu uschovává a může je přitom sám také poskytovat jako server. Smysl používání proxy-serverů ( proxy = zástupce ) je snad okamžitě patrný. Nepřenášet až ze vzdálených WWW-serverů pokaždé tutéž (nezměněnou) WWW-stránku.
Na VŠE je proxy-server provozován na počítači, který se nyní jmenuje votrok.vse.cz . ( Symbolicky někdy také nazývaný cache [16].) Do sítě je tento počítač připojen dvěma způsoby, se dvěma adresami, a podle (svého) místa v síti by se měl WWW-klient obracet buď na cache.vse.cz nebo na httpcache.vse.cz . Pro úplnost je třeba říci, že v areálu na Jižním Městě používají (logicky) jiný proxy-server: jmcache.vse.cz .
Požadavek na proxy-server WWW-klient zadává zcela stejně, pouze jako
uri je nutno zadat celou URL-specifikaci, tedy
funkce://počítač/cesta
Konkrétně požadavek na WWW-stránku zmiňovaný výše by se přes proxy-server
zadal takto:
GET http://beta.vse.cz/kizi/information/ HTTP/1.0
prázdný řádek
Pokud klient v požadavku uvádí i položku Host: , je při uvedení jména počítače v absolutní specifikaci uri tato položka hlavičky ignorována. Proto může klient s proxy-servery úplně stejně komunikovat také podle http-protokolu 1.1 . Je ovšem pravda, že na rozdíl od WWW-serverů pracují i v současnosti proxy-servery většinou podle protokolu 1.0 .
Pokud proxy-server už nemá požadovanou stránku někde uloženu, obrátí se
jako klient na WWW-server, od něj získá příslušnou odpověď, kterou teprve pak
zašle WWW-klientu. Získanou WWW-stránku si (zpravidla) sám někam ukládá, aby
případný další takovýto požadavek od některého klienta mohl okamžitě uspokojit
zasláním této WWW-stránky.
Situaci lze ilustrovat na výše zmiňované odpovědi WWW-serveru, při níž server
vypisuje položky z http-hlavičky požadavku. Pokud se klient ( Netscape )
neobrátí přímo na WWW-server, ale na proxy-server, je pak odpověď takováto:
HTTP_VIA = 1.0 cache.vse.cz:8080 (Squid/2.1.PATCH2)
HTTP_HOST = 146.102.64.30
HTTP_X_FORWARDED_FOR = 146.102.66.238
HTTP_ACCEPT_CHARSET = iso-8859-1,*,utf-8
HTTP_CACHE_CONTROL = max-age=259200
HTTP_ACCEPT_LANGUAGE = en
HTTP_ACCEPT = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
HTTP_CONNECTION = keep-alive
HTTP_USER_AGENT = Mozilla/4.05 [en] (Win16; I ;Nav)
HTTP_REFERER = http://146.102.64.30/kizi/IKSy/kap8.iso88592.html
toCP1250
Asi je třeba připomenout, že zde se jedná o položky http-hlavičky, a to
požadavku zadaného proxy-serverem. ( Obdobně i odpovědi proxy-serveru zasílané
WWW-klientům mají http-hlavičky doplněny položkami informujícími
o použití proxy-serveru.)
Při využívání proxy-serverů je pochopitelně zásadní otázkou aktuálnost stránek, které proxy-server klientům poskytl a které měl někde (u sebe) uloženy. Problém ani tak není s obvyklými WWW-stránkami, jež po nějakém čase někdo zaktualizoval, a které pak proxy-server začne správně poskytovat s jistým časovým zpožděním. To podle toho, jak má implicitně stanovenu dobu, po kterou si stránky pamatuje ( aniž by ověřil jejich aktuálnost na originálním serveru ).
Problém je ale s WWW-stránkami, které jsou (anebo mohou) být na WWW-serveru aktuálně pozměněny při požadavku klienta. Jedna ze situací již byla o něco výše zmiňována, automatická volba kódu české diakritiky na WWW-serveru. Zpravidla bývá nezbytné, aby WWW-stránky, které se mohou při požadavku klienta aktuálně měnit, byly vždy přeneseny z určeného WWW-serveru. Tedy aby proxy-server věděl, že tyto stránky nemá sám poskytovat ( a ukládat ) . Pro přenos takovýchto informací, třeba se specifikací no-cache , byly v http-hlavičce zavedeny položky Pragma: ve verzi 1.0 , anebo nověji položka Cache-Control: pro verzi protokolu 1.1 .
Ovlivnit obsah http-hlavičky vytvořené WWW-stránky je zpravidla standardními prostředky jazyka HTML neproveditelné. S problémy se ale obvykle nesetkávají ani tvůrci dynamicky se měnících WWW-stránek, u kterých rovněž nebývají uváděny v http-hlavičkách explicitně položky omezující způsob cache-ování (ukládání) těchto stránek na proxy-serveru. V konfiguracích různých WWW-serverů je nejběžnější situace, že takovéto stránky jsou vždy vytvářeny v podadresáři cgi-bin . Mnohé proxy-servery proto odkazy s takovýmto jménem adresáře neukládají.
Pokud naopak chceme, aby některé takovéto stránky mohl proxy-server poskytovat
- jako například dynamicky překódovávané stránky neměnného obsahu - anebo
opačně používáme programově generované stránky i v adresářích jmen zcela
normálních, musíme pak zajistit, aby WWW-server předával ještě k tomu potřebné
položky do http-hlavičky.
RFC2068 [6]
popisující protokol 1.1 se rovněž zabývá spoluprací s proxy-servery
a také jejich samotnou činností. Kromě položky Cache-Control:
se zmiňuje například o položkách
Age: , Expires: ,
Vary:
Poslední z nich má příkladně instruovat proxy-server, aby při poskytnutí
WWW-stránky zohlednil i shodnost některých položek z hlavičky požadavku
zadaného WWW-klientem. Konkrétně
Vary: User-Agent, Accept-Charset
lze nalézt v hlavičkách WWW-stránek automaticky překódovávaných WWW-serverem
do kódu češtiny, jenž byl serverem zvolen podle obsahu zmíněných položek
v hlavičce požadavku. Je-li proxy-server v tomto směru znalý verze 1.1 ,
uchovává si s onou stránkou i potřebné informace o tvaru hlavičky toho
požadavku, kterým WWW-stránku získal. Sám pak WWW-stránku ( nebo přesněji
řečeno variantu oné WWW-stránky ) klientu poskytne při shodnosti určených
položek z hlavičky požadavku, kterým se klient na něj obracel.
Jak bylo dříve řečeno, proxy-server umí pracovat jako klient i jako server.
Většina WWW-klientů, jak jistě známo, ovšem umí spolupracovat nejen
s WWW-servery, ale též s Gopher-servery, s anonymními FTP-servery, případně
zná i další internetovské funkce. A tak převážná většina proxy-serverů se umí
rovněž obracet na Gopher-servery a anonymní FTP-servery.
Obecně může požadavek na proxy-server od WWW-klienta obsahovat v uri
také jiné funkce než jen http .
Například lze po proxy-serveru takto požadovat Gopher-Menu rozebírané
v minulé kapitole:
GET gopher://alfa.vse.cz/11/kizi/iksy/BEZ/ZAJIMAVE_PRIKLADY HTTP/1.0
prázdný řádek
Pokud proxy-server tuto funkci akceptuje, postupuje tak, že sám získá toto menu
Gopheru a WWW-stránku, kterou by jako WWW-klient z obdrženého
souboru vygeneroval, kdyby toto menu zprostředkovával uživateli, zašle potom
pomocí http-protokolu onomu klientu. Následující požadavek (jiného)
klienta na toto menu již může uspokojit tak, že okamžitě zašle uložené
vygenerované menu, aniž by se obracel znovu na Gopher-server.
To zároveň vysvětluje, proč při použití stejného WWW-klienta může stejné
Gopher-Menu vypadat někdy jinak. Podle toho, zda WWW-klient menu sám
interpretoval uživateli, anebo tak za něj učinil ( trochu odlišně ) proxy-server.
Ke zcela analogické situaci může dojít i třeba pro adresáře na FTP-serverech podle toho, zda se WWW-klient obracel na proxy-server či nikoliv. A to může ( na první pohled paradoxně ) záviset na tom, zda uživatel zadal doménové jméno počítače anebo jeho IP-adresu. Například na VŠE mívají klienti ve standardní konfiguraci stanoveno, pro která (doménová) jména, například pro všechna jména končící vse.cz , se nemají obracet na proxy-server. Pro všechny počítače jiných tvarů jmen - včetně tedy IP-adres, a to i v rámci VŠE - se naopak na proxy-server obracejí. ( Toho je konečně možno i někdy vhodně využívat, pokud se u použitého klienta objevují problémy ve spolupráci s nějakým WWW-serverem.)
WWW-klient se na proxy-server obrací jako na odlišný ( předem určený ) server, tedy na program pracující na určitém počítači a určitém portu. Porty výše zmiňovaných serverů jsou { votrok.vse.cz 8080 } , { jmcache.vse.cz 3128 } . Implicitně určený port pro proxy-servery není, i když uvedené dva porty jsou používány asi nejčastěji.
Proxy-server může pracovat i na portu 80 , také ale poněkud odlišným způsobem.
Mohou na něj být IP-routerem ( spíše tedy firewallem ) směrovány všechny
datagramy určené pro WWW-servery v rámci určité sítě, pro zvolené WWW-servery,
pro všechny servery některé organizace a podobně. Takovýto proxy-server pak
může mít zabudovány i jisté ochrany, které mu dovolují poskytovat WWW-stránky
jenom z určitých míst takto chráněné sítě.
Hlavním důvodem používání takovýchto proxy-serverů bývá ovšem snaha snížit
nároky na přenosové kapacity, a to nezávisle na tom, zda si uživatelé explicitně
stanovili proxy-server používat či nepoužívat. WWW-klient v tomto případě
ani neví, zda se svým požadavkem obrací na WWW-server nebo na proxy-server.
I to je jeden z důvodů, proč v http 1.1 byla k požadavku
klienta přidána položka Host: ( která vždy snadno umožňuje odvodit
absolutní uri ).
Například v síti TEN34-CZ se svého času objevil takovýto "tajný" proxy-server,
především pro snížení přenosových nároků vně této sítě.
c-engine1.ten34.ces.net , ( c-engine2.ten34.ces.net , ..?.) byla adresa onoho
proxy-serveru. Pokud by z nějakého důvodu bylo toto místo sítě mimo provoz, je
pak obtížné se dostat k jakékoliv informaci na WWW-serveru vně TEN34-CZ .
Jedině lze asi hledat vhodný proxy-server mimo TEN34-CZ , který ovšem
z našeho počítače neodmítne požadavek, a využitím jiného portu tak "tajný"
proxy-server obejít.
Zároveň je patrné, že proxy-servery toho typu s sebou nesou i jisté nebezpečí v záměrné dezinformaci. Třebaže žádnou stránku na konkrétním WWW-serveru nikdo nepřepsal ani jinak nezměnil, může být v některých místech sítě Internet klientům poskytována stránka úmyslně změněná, protože někdo cíleně ovlivnil činnost takovéhoto proxy-serveru.
Převážně ale proxy-servery přinášejí spíše výhody v rychlosti získání
informací. Jedině je za škodlivé pokládají provozovatelé WWW-serverů, kteří
si vydělávají vystavováním reklam na svých WWW-stránkách. Ne že by si uživatelé
reklamu pomaleji stahovali a četli, to naopak, ale svým objednavatelům
nemohou z logu WWW-serveru prokázat, jak obrovský počet počítačů již ovlivnili.
Rozšířit anebo měnit položky v http-hlavičkách serverem zasílaných stránek (souborů) může jejich tvůrce obvykle jen pomocí některých programových prostředků. Ty zdaleka nebývají všude povoleny k používání při odpovědích WWW-serveru. Základní princip tvorby takovýchto stránek spočívá v tom, že se vytvoří vlastně program, který WWW-server aktivuje vždy, když obdrží požadavek od klienta. Výsledkem činnosti tohoto programu je zpravidla zdrojový text WWW-stránky zasílaný jako odpověď klientu. O takovýchto WWW-stránkách, možná přesněji o programech, které tyto stránky dynamicky tvoří, se hovoří jako o cgi-scriptech . ( Zkratka cgi znamená "common gateway interface", rozhraní z pohledu WWW-serveru, díky kterému může WWW-server aktivovat programy v operačním prostředí systému.)
Může přitom jít o několik příkazů pro vhodný interpreter, ale také třeba o aktivaci textového prohlížeče ( WWW-klienta ), jehož (upravený) výstup pak WWW-server odesílá. Takovéto WWW-stránky někdy mívají právě koncovku .cgi , ale mohou býti i úplně bez koncovky - to zpravidla bývá jen v určitém (význačném) adresáři, jméno kterého bývá často cgi-bin , anebo může WWW-server onu stránku zprostředkovat pro odkaz končící jménem adresáře - přitom tvůrce ale musel vytvořit podle konvencí WWW-serveru v tomto adresáři soubor určitého jména, například index.cgi .
V operačním systému Unix, typickém pro provoz WWW-serverů, se často cgi-scripty píší v jazyce Perl. Proto se lze setkat u těchto stránek i se suffixem .pl . V Perlu byl také napsán script ladeni [17] použitý zde pro výpis položek uváděných v hlavičce požadavku od klienta. Program je určen pro doladění automatické volby české diakritiky především pro prostředí konkrétní (místní) sítě. Alespoň v té by měl být schopen pro instalované WWW-klienty vždy rozhodnout správně. Variantu své volby pak vypisuje na posledním řádku.
Při tvorbě takovéhoto programu musí tvůrce kromě výstupu zdrojového textu
WWW-stránky uvést nejprve i některé ( všechny či jen vybrané ) řádky
http-hlavičky ( podle pravidel instalovaného WWW-serveru). A jeden
prázdný řádek navíc, za kterým poté následuje zdrojový text stránky.
Takto lze také vytvořit hlavičku pro odpověď serveru s kódem
301 anebo 302 Moved ...
směrující klienta na jiné místo.
( Právě tak je například z "ladění" odvozen program "auto" pro
volbu české diakritiky.)
Je-li to v systému povoleno, lze si popsaným způsobem "inteligentně" ( myšleno jen za určitých podmínek ) přesměrovat vlastní home-stránku z jednoho počítače na jiný počítač. Ale použití cgi-scriptů nebývá na uživatelských home-stránkách zpravidla povolováno - a když, tak jen po kontrole správcem serveru. Důvodem bývá nejen obava před nevhodným využíváním výpočetní kapacity počítače, ale i možnost volně tím pro kohokoliv zpřístupnit některé neveřejné informace na onom počítači. Dokonce je známo, při jakých (úmyslných) chybách volně šiřitelných scriptů lze třeba v Unixu k takovýmto informacím proniknout.
Ještě ale existuje jeden důvod, který nesouvisí s mezerami v ochranách systému. Bohužel si ho někdy neuvědomují ani profesionální tvůrci programů. Pokud se například WWW-server při každém požadavku rozhoduje (znovu) o volbě kódu české diakritiky, může zpět WWW-klientu vybraný kód sdělovat opět v hlavičce odpovědi. WWW-klient ale podle toho může opravit své vlastní nastavení kódové tabulky, a pokud si z jakkoliv nevhodného (algoritmického) důvodu vyžaduje stránku pro interpretaci od serveru znovu, nemusí již být naplnění položek v tomto jeho požadavku stejné. ( Třeba proto, že původně vybraný kód neznal.) A teď WWW-server vybere pro změnu jiný kód, což může způsobit, že WWW-klient se přepne do svého původního stavu, a takto pak můžeme pokračovat stále dál. ( Zvláště když ještě někteří tvůrci WWW-stránek k tomu ponechají rozpornou informaci o původním kódu dokumentu ve specifikaci <META>.)
Obdobně jako pro Java-scripty existují v Internetu i knihovny připravených cgi-scriptů [18]. ( Jako třeba pro textové vyhledávání [19] v Hytelnetu.)
Syntaxi URL popisuje často citované ( například též Standardy Státního informačního systému ) RFC1738 [21], k němuž se pak objevilo několik doplňků rozšiřujících okruh využitelných funkcí. Snaha po jednotnosti pravidel pro vytváření úplných i relativních odkazů vedla až k RFC2396 [22], kde se obecně hovoří o URI chápaném zde jako Uniform Resource Identifier. V tomto duchu je pak zcela správně obecný tvar požadavku WWW-klienta, ve kterém se uvádí uri .
Syntaxi (úplného) URL-odkazu můžeme zhruba vyjádřit následujícím
schématem:
funkce://uživatel:heslo@počítač:port/cesta_k_souboru
Pro odkazy na WWW-serverech se jako funkce uvede http . Většina WWW-klientů zná rovněž funkce gopher a ftp , neboli umí spolupracovat také s Gopher-servery a rovněž získávat soubory pomocí FTP . Pro některé z konkrétních funkcí, kterých je v RFC1738 uváděno asi 10 , se tato obecně přijatá syntaxe může drobně lišit. Pro pět nejtypičtějších funkcí Internetu ( v RFC1738 označovaných slovem "scheme" ) se URL-odkazy mají psát takto:
ftp://uživatel:heslo@počítač:port/adr1/adr2/../soubor;type={a,i,d}Vždy je nutno specifikovat počítač , pomocí doménového jména nebo IP-adresou. Nemusí být uváděn uživatel , ten se pak implicitně rozumí anonymous , a rovněž heslo není nutno uvádět. Místo něj má WWW-klient použít E-mailovou adresu toho, kdo klienta aktivoval. Pokud však byl specifikován uživatel , klient si chybějící heslo v případě potřeby sám vyžádá.
adr1/adr2/../soubor má znamenat cestu k souboru, tak jak
se postupuje přes adresář adr1 , adr2 , .. a tak
postupně, až se dostaneme nakonec k souboru, jehož jméno je uváděno jako
poslední. Za ním následující výraz ;type= se
(zatím) příliš nepoužívá, a dokonce pak někteří WWW-klienti ani nemusí být
schopni celé specifikaci rozumět.
WWW-klient totiž pracuje stejně, jako by člověk pracoval s FTP přesně podle
tohoto protokolu. Pro přechod do podadresáře zadává příkaz cd ,
pro získání souboru pak příkaz get . Skončí-li přitom v adresáři,
většinou si příkazem dir nechá zobrazit jeho obsah.
A stejně také celá cesta v této URL-specifikaci nemusí končit jménem souboru,
WWW-klient potom zobrazí obsah onoho adresáře. Samozřejmě se nedá podle struktury
koncového jména vyvozovat, zda jde o soubor či adresář. ( I když bývá
zvykem, že jména obsahující tečky se dávají souborům, a jména adresářů
většinou tečku neobsahují.) A právě tuto situaci má jednoznačně řešit
doplnění type=d , jako directory ,
vztahující se k poslednímu jménu cesty.
Při přenosu souboru podle protokolu FTP má být všude zaručeno, že uživatel
do svého systému správně získá textový soubor, v němž jsou do jeho prostředí
správně převedeny znaky z první poloviny ASCII-tabulky. ( V souboru jsou
rovněž převáděny konce řádků do formy standardní v příslušném systému.)
Tímto režimem práce se buď implicitně začíná, anebo jej uživatel zadává
příkazem ascii .
Netextové soubory ( jako programy, obrázky, nějakými prostředky
komprimované soubory apod. ) takto není možno přenášet, protože by se v nich
mohly vyskytovat takové kombinace bitů, které by vedly ( v tomto případě )
k nevhodným konverzím. ( Jako
je například konverze konce řádků '0D 0A' mezi MS-DOSem a Unixem '0A' .)
Pro přenos těchto souborů je třeba používat režim binary , který zajistí
přenesení souboru s přesně takovou bitovou posloupností po sobě následujících
znaků (bytů), jako byla na originálním počítači. Samozřejmě je pak věcí
uživatele, aby takovýto obrázek, soubor uměl ve svém (jiném) prostředí
zobrazit, byl schopen ho dekomprimovat atd.
Zrovna tak se musí i WWW-klient rozhodnout, zda soubor přenášet v režimu ascii nebo binary. Zpravidla se rozhoduje podle koncovky jména souboru ( a mnohdy se podle toho také snaží odpovídajícím způsobem soubor uživateli přímo zobrazit ). A to opět nemusí učinit vždycky správně, pokud ovšem tak není explicite specifikováno pomocí type=a , odpovídající ascii-režimu, anebo type=i pro režim binary.
Popisovaná funkce ftp je uživatelsky dosti podobná funkci gopher. Někteří WWW-klienti dokonce používají i shodné grafické prostředky při zprostředkování adresáře koncovému uživateli a při interpretaci Gopher-Menu. Jako u WWW je vlastně vždy hlavní činností přenos souboru. Při použití protokolu FTP je však jedna podstatná odlišnost, klient musí využívat spolupráci spojovanou. URL-specifikace popisuje jen místo, kde lze informaci nalézt, a nikoliv činnost klienta při jejím získávání. Tedy nehovoří například o tom, jak a kdy má klient zrušit své připojení k FTP-serveru. ( Kdy klient vydá příkaz quit .) Někteří klienti tak mohou učinit okamžitě po získání souboru, jiní, pokud jsou stále aktivováni, až při jiném funkčním požadavku, nebo dokonce až při FTP-požadavku na odlišný počítač. Jsou tak sice schopni případný další požadavek na původní FTP-server zpracovat rychleji, ale zase tím může být ( v podstatě bezdůvodně ) snadno někdy vyčerpán počet povolených připojení na určitém anonymním FTP-serveru. V tomto směru je mnohem flexibilnější spolupráce s Gopher-servery.
gopher://počítač:port/TypePathTspecifikaceCesta v této specifikaci vznikne spojením údaje Type a (celého) požadavku, který má klient zaslat Gopher-serveru. Ten je zde vyjádřen jako: PathTspecifikace
Neboť pro většinu Gopher-serverů pole Path obsahuje na začátku rovněž informací o Typu , lze snadno pochopit, proč celá cesta v URL-specifikaci začíná nejčastěji buď znaky 00/ ( pro soubor ) nebo 11/ ( pro menu ). Za nimi pak již následuje obvyklá struktura adresářů, jak je známá třeba z využívání FTP . V zásadě se dá říci, že podle prvního znaku celé cesty volí WWW-klient ( pro funkci gopher ) způsob interpretace získaného souboru. Pro 1 obvykle nějak vygeneruje HTML-stránku, kterou pak zobrazuje uživateli jako menu. Naopak pro 0 soubor jako textový uživateli jenom zobrazí. Teoreticky tedy můžeme WWW-klientu měnit tento první znak, aniž tím jakkoliv ovlivníme činnost Gopher-serveru.
Například tedy
gopher://počítač/01/
zobrazí (textově) úvodní menu tak, jak vypadá při přenosu ze serveru.
Vzhledem k podobnosti spolupráce klienta s Gopher-serverem a protokolu
http 0.9 je možno WWW-klientu zadat i takovouto specifikaci
gopher://počítač:80/0GET /
( již zmíněnou v souvislosti s virtuálními servery ). Klient v tomto případě
zašle na port 80 , na němž pracuje standardně WWW-server, jako svůj požadavek
znakový řetězec, který následuje za Typem , a to je
GET / ( ale mohlo by takto být i zadáno
GET /cesta ). Neboli, klient při takovéto
URL-specifikaci komunikuje s WWW-serverem přesně podle protokolu 0.9 ,
získaný (textový) soubor pak klient uživateli zobrazí ve zdrojovém tvaru.
Neboť požadavek byl bez jakýchkoliv http-hlaviček, je tak možno
vidět třeba na virtuálním serveru originální WWW-stránku ( viz výše ) anebo
získat stránku vhodněji (univerzálněji) překódovanou.
Problémy se přitom mohou vyskytnout na dvou místech. Jednak WWW-server nemusí
být ochoten akceptovat protokol 0.9 a jednak může klientu vadit
mezera v zadání URL-specifikace. Tu by sice bylo možno zapsat jako %20 ,
ale klient ji WWW-serveru ( v tomto případě ) musí zasílat skutečně jako
mezeru.
Někteří klienti, jak již výše zmiňováno, při používání
funkce gopher rozumějí také (neoficiálnímu)
typu h , který znamená, že soubor má být
"hypertextově interpretován". Potom je možno, aby WWW-stránku poskytoval i
Gopher-server, anebo je možno, aby třeba tímto zadáním v Gopher-Menu
WWW-klient přešel na spolupráci s WWW-serverem:
Name=Prechod na WWW
Type=h
Path=GET /~jjkastl/W-L/
Host=alfa.vse.cz
Port=80
http://počítač:port/cesta?specifikace#fragmentTakto lze vyjádřit syntaxi pro funkci http , tedy pro odkazy na WWW-serverech. Uváděná cesta vypadá stejně jako pro ftp, přičemž může končit jak adresářem tak jménem souboru. ( O správné poskytnutí odpovědi se nyní postará WWW-server.) WWW-klient zasílá WWW-serveru ( jako uri ) údaje /cesta?specifikace . Otazníkem oddělovaná specifikace má stejný význam jako pro Gopher, specifikuje další informace, které WWW-server potřebuje pro (programově) vytvářenou odpověď v onom místě cesty. V popisované syntaxi pochopitelně může být tato část ( i s otazníkem ) vynechána.
Pomocí oné části URL-odkazu, která následuje za ? , se často řešívá spolupráce s nějakým informačním systém. Příslušná specifikace obvykle obsahuje jednak parametry pro nastavení správného prostředí a jednak ( nebo hlavně ) určitý způsob lokalizace oné informace ve využívaném informačním systému ( v nejdokonalejších aplikacích třeba i pomocí dotazovacího jazyka ). Tak se samozřejmě nevyhneme situacím, že je potřeba někde uvést i znak s českou diakritikou. Syntaxe URL ale takové znaky nepřipouští.
Velmi stručně lze říci, že v URL-specifikacích můžeme bez problémů využívat (jen) znaky ASCII-1 alfanumerické. Některé zvláštní znaky jako / : @ ; ? # % musí mít ze syntaktického hlediska, jak je zřejmé již z předešlého, nějak vyhrazené použití, aby se totiž daly jednotlivé části vždy bez problémů rozlišit. Další zvláštní znaky jako + = & , $ mezera mohou ovlivňovat syntaxi podrobnějších pravidel ( třeba při spojování jednotlivých parametrů do zmíněné specifikace předávané informačnímu systému ) anebo mohou některému klientu působit problémy při konstrukci požadavku zasílaného WWW-serveru, kdy se právě mezerou odděluje uri . Všechny nepatřičné znaky je nutno ve všech (zadatelných) částech URL-specifikací uvádět (kódovat) jako %xy , kde xy je hexadecimální hodnota takového znaku.
Na rozdíl od jiných funkcí, kde transformaci do správného 8-bitového tvaru takovéhoto znaku musí vždy provádět klient, pro funkci http by takovouto konverzi ( alespoň v cestě ) měl být schopen provést i WWW-server. A tak je relativně bezproblémové, když jsou takto zakódovány i znaky povolené, anebo když přímo v požadavku na WWW-stránku zakódujeme takto znak, který nemůžeme snadno napsat na klávesnici. ( Viz známý problém se znakem ~ na české klávesnici, místo kterého lze psát %7E .)
Pro české znaky s diakritikou, které jsou takto zapsány v nějakém URL-odkazu,
je nevýhodné to, že jednoznačně nelze říci, o jaký znak vlastně jde, protože
explicitně není uvedeno jméno kódu české diakritiky.
WWW sice v obecnosti
předpokládá, že všechny znaky z druhé poloviny ASCII-tabulky se vztahují
k (západoevropskému) kódu ISO-Latin1, ale takto bychom nikdy nerozkódovali
třeba české znaky s háčkem. Pro spolupráci s WWW-serverem problém až tak
podstatný ovšem není, neboť stejně jako jména adresářů v cestě k určitému
(známému) souboru závisí na konkrétní konfiguraci WWW-serveru, tak i použitá
tabulka kódu je odvislá od způsobu konkrétní implementace na straně WWW-serveru.
Je třeba zdůraznit, že může býti jedině nezbytné při spolupráci
s WWW-serverem, aby se české znaky s diakritikou mohly vyskytovat
ve specifikační části za otazníkem. Je krajně nevhodné pojmenovávat v české
diakritice třeba soubory zasílané WWW-serverem. Zvláště "oblíbené" znaky
ž, š, ť v kódu Windows-1250, kde jsou umístěny
ve sloupcích 8 a 9 , mohou způsobit některým klientům nepřekonatelné
potíže. Tabulka ISO-Latin1 v těchto sloupcích neobsahuje žádné textově
interpretovatelné znaky, a tak je klient může v nezakódovaném tvaru pokládat
za rozšíření znaků řídících.
telnet://uživatel:heslo@počítač:port/Pouze toto lze specifikovat pro funkci telnet . Obdobně jako pro získání souboru pomocí FTP nemusí být vůbec uváděno uživatel:heslo@ anebo lze jen vynechat :heslo . Implicitně pak není žádné uživatelské jméno ani heslo použito.
TELNET na rozdíl od Gopheru a WWW předpokládá spojovanou spolupráci s cílovým počítačem. ( Zde se pak použije jméno uživatel a uvedené heslo .) Toto je zcela analogické FTP , jež je ovšem zaměřeno především na přenos jednotlivých souborů. Proto FTP-přenos obvykle umí zajistit i ( souborově orientovaný ) WWW-klient, ale funkci telnet sám obvykle neřeší. Zpravidla se obrací na tuto nainstalovanou funkci v systému, ve kterém pracuje. Bohužel pak takto na cílový počítač už nezajistí předání žádného textového řetězce, i uživatelské jméno a heslo z URL-odkazu je nutno napsat ručně. Při kliknutí na nějaký takovýto odkaz WWW-klient vlastně jen umožní aktivaci TELNETu, v lepším případě k tomu ještě zobrazuje, jaké uživatelské jméno a heslo se má při tom použít.
Syntaxe pro tuto funkci ani nepočítá se situacemi, že by zadáním nějakého (jednořádkového) příkazu šlo lokalizovat určitou informaci. Tím je tato URL-specifikace využitelná více méně jen k navigaci na informační zdroj, a to zcela obdobně jako funkce následující.
mailto:uživatel@počítačZde se, pozor, nepíší lomítka. Tato URL-specifikace vlastně uvádí jen internetovou E-mailovou adresu, na kterou lze poslat dopis ( obsahu nikterak blíže nespecifikovaného ). Na rozdíl od TELNETu ovšem řada klientů ( při kliknutí na tento odkaz ) nejen zabezpečí editaci dopisu, ale umí také zabezpečit jeho transport, a to třeba přímo podle protokolu SMTP.
RFC1738 kromě těchto nejpoužívanějších funkcí popisuje
ještě další, jako třeba news a nntp pro
spolupráci s on-line diskusními skupinami. O některých funkcích pak
předpokládá, že budou zavedeny v budoucnu. Jako třeba tn3270
( což se ovšem nestalo ) nebo z39.50
( což učinilo
RFC2056
[24] ).
Naopak funkci pop
( Post Office Protocol
- Version 3
[25] )
sloužící k přenášení pošty na lokální počítač byli někteří WWW-klienti
schopni realizovat, ale URL-specifikace k tomu chyběla. Až posléze se objevila
v RFC2384 [26].
Ještě jednu zvláštní URL-specifikaci lze někdy s výhodou využít při práci s WWW-klientem -- zvláště při ladění WWW-stránek. A tou je ( systémově závislá ) funkce file , jež má ( prostřednictvím WWW-klienta ) umožnit přístup k souborům v prostředí vlastního operačního systému. Způsob jejich interpretace pak klient odvozuje ze struktury jmen. URL-specifikace mají obecně vypadat takto:
file://systém/cesta_k_souboruJak cesta_k_souboru tak i systém jsou odvislé od konvencí daného operačního prostředí. Někdy lze i oba údaje vynechat. Pokud tedy klient akceptuje file:/// při uživatelově zadání, může být někdy využíván i jako manager souborů.
Při vytváření WWW-stránek se většina odkazů tímto způsobem ale nepíše. WWW-klient si totiž pamatuje jakou funkcí a z jakého počítače WWW-stránku získával a jaká přitom k ní vedla cesta, přesněji z jakého adresáře si stránku vyžádal. V tomto duchu je tak možno URL-odkazy v jednotlivých HTML-specifikacích zkracovat. O těchto odkazech pak hovoříme jako o relativních URI ( na rozdíl od dosud popisovaných absolutních URL ).
Pravidlo "relativnosti" odkazu se dá naformulovat asi takto. Začíná-li odkaz dvěma lomítky // , doplňuje si WWW-klient funkci ( kterou onu stránku získal ). Začíná-li odkaz jedním lomítkem / , doplní si klient funkci a počítač, přesněji řečeno všechny údaje až k začátku cesty. ( Ta teď bude uvedena znovu celá.) Pakliže odkaz žádným lomítkem nezačíná, vztahuje se cesta ( nejčastěji tedy jen jméno souboru ) k adresáři, ze kterého byla stránka s tímto odkazem získána.
RFC2396 [22] se podrobněji šíří například též o použití teček v cestách. V odkazech třeba připouští uvádět ../ pro cesty z nadřazeného adresáře. Pro nejednoznačnost případně rozporuplnost se ale negativně staví k používání zkrácených doménových jmen počítačů při HTML-odkazech, anebo odvození funkce z tvaru doménové adresy, což ovšem mnozí klienti umožňují při přímém zadání URL-odkazu uživatelem.
Při převodu WWW-stránek na jiný server, při jejich opravách, při přechodu z jiných funkcí do WWW je někdy potřebné, aby klient zapomněl informace o tom, jak stránku získal, a použil jiné. K tomu lze v HTML-hlavičce využít specifikaci <BASE HREF=odkaz> obsahující absolutní URL-odkaz. Klient je tak instruován, aby předpokládal, že se ke stránce dostal přes určený odkaz , a od něj pak také odvozuje všechny relativní URI.
Opravovaná stránka pak může být zpřístupněna třeba funkcí file .
Aniž je třeba přenést na vhodné místo obrázky a soubory anebo změnit odkazy
na absolutní, lze WWW-stránku zcela "zprovoznit" přidáním specifikace
<BASE> , která bude odkazovat na původně zvolené místo svého
uložení.
Takto (klient) Lynx sám v úvodu vždy doplní
<BASE> , pokud stránku "tiskne" ve zdrojovém tvaru.
Stejným způsobem je pomocí <BASE> nutno klientu změnit předpokládanou funkci ( pro úspěšné zakomponování obrázků ) na funkci http , byl-li na tuto stránku navigován výše zmíněnou možností přechodu z Gopheru.