Protokoly požadavku na URL URL je odkaz na konkrétní prostředek na Internetu v konkrétním umístění a má následující standardní

D Požadavky a odpovědi HTTP HTTP (Hypertext Transfer Protocol) je protokolem aplikační úrovně pro distribuované hypermediální informační systémy. Je to obecný nestavový protokol, který lze mimo jeho použití pro hypertext použít pro mnoho dalších úloh. Funkcí HTTP je vypisování a přenos reprezentace dat, která umožňuje systémům nezávislost na přenášených datech. První verzí HTTP, označovanou jako HTTP/0.9, byl jednoduchý protokol pro základní přenos dat po internetu. HTTP/1.0, jak bylo definováno v RFC 1945, vylepšilo protokol o přenos dat ve formátu MIME, aby mohl obsahovat metainformace o přenášených datech a modifikátory sémantiky požadavků a odpovědí. Aktuální verze, HTTP/1.1 prvně deklarovaná v RFC 2068 a později v RFC 2616, přinesla zvýšení výkonu tím, že se všechna spojení stala trvalými, a tím, že podporuje absolutní URL v požadavcích. Protokoly požadavku na URL URL je odkaz na konkrétní prostředek na Internetu v konkrétním umístění a má následující standardní formát: Protokol Název serveru Cesta k souboru Za tímto účelem jsou těmito třemi prvky protokol, použitý pro přístup k serveru, název serveru a umístění prostředku na serveru. Například: http://www.mojedomena.cz/ https://www.mojedomena.cz:8080/ ftp://ftp.mojedomena.cz/priklad.txt mailto:ja@nekde.cz file:///c: Windows/win.exe 1

PHP Programujeme profesionálně Název serveru a cesta k souboru jsou plně závislé na tom, kde jsou soubory uloženy na vašem serveru a na tom, jak je voláte, ale existuje standardní sada protokolů, které byste měli znát: http: Normální požadavky HTTP na dokumenty. https: Zabezpečené požadavky HTTP. Konkrétní chování závisí na bezpečnostních certifikátech a šifrovacích klíčích, které nastavíte. JavaScript: Provádí kód JavaScriptu uvnitř aktuálního dokumentu. ftp: Zpřístupňuje dokumenty ze serveru FTP (File Transfer Protocol). file: Načítá soubory uložené na místním (klientském) počítači. Může také ukazovat na vzdálené servery, ale neurčuje konkrétní přenosový protokol vzdáleného systému souborů. news: Používá se pro přístup k datům z diskusních skupin Usenet. nntp: Sofistikovanější přístup k serverům s diskusními skupinami. mailto: Umožňuje odeslání e-mailu z prohlížeče. telnet: Otevírá interaktivní relaci se serverem. gopher: Předchůdce WWW (World Wide Web). Tato kniha pojednává výhradně o prvních pěti z nich. Základy HTTP Každý požadavek klienta HTTP (webového prohlížeče) a odpově serveru mají tři části: řádek požadavku nebo odpovědi, hlavičky a tělo entity. Požadavek klienta Klient iniciuje přenos webové stránky požadavek klienta na stránku a odpově serveru následujícím způsobem. Klient se připojí na server HTTP na daném portu (implicitně 80) a odešle požadavek HTTP uvedením příkazu HTTP, který se nazývá metoda, následovaným adresou dokumentu a číslem verze HTTP. Formát řádku požadavku je: Např.: Metoda Požadované URI Protokol GET /index.htm HTTP/1.0 používá pro požadavek na dokument /index.htm metodu GET pomocí verze 1.0 protokolu. Plný seznam metod požadavků HTTP uvedeme později. Dále klient odešle serveru volitelné informace o své konfiguraci a formátu dokumentu, který bude akceptovat v hlavičkách. Všechny informace v hlavičkách jsou odeslány po řádcích, každá s názvem a hodnotou hlavičky ve formátu: Např.: Klíčové slovo: Hodnota User-Agent: Lynx/2.4 libwww/5.1k Accept: image/gif, image/x-xbitmap, image/jpeg, */* 2

Příloha D Požadavky a odpovědi HTTP Řádek požadavku a následné řádky hlaviček jsou všechny ukončeny sekvencí CRLF (\r\n). Na konci všech hlaviček klient odešle prázdný řádek. K plnému popisu každé hodnoty záhlaví HTTP se vrátíme později. Konečně, po odeslání požadavku a záhlaví, klient může odeslat další data. Tato data jsou používána programy CGI pomocí metody POST. Tato další informace se nazývá tělo požadavku. Požadavek zakončuje prázdný řádek. Kompletní požadavek by mohl vypadat takto: GET /index.htm HTTP/1.0 Accept: */* Connection: Keep-Alive Host: www.w3.org User-Agent: Generic Metody požadavku HTTP Metody požadavků HTTP by neměly být zaměňovány s protokoly URL. Používají se pro instruování webového serveru, jak má zpracovat příchozí požadavek, přičemž nověji definuje to, jak spolu klient a server komunikují. Ve verzi 1.1 protokolu HTTP existuje sedm základních metod požadavků HTTP: Metoda OPTIONS GET HEAD POST PUT DELETE TRACE Popis Používá se pro dotaz na možnosti serveru. Dotazy mohou být obecné nebo na konkrétní prostředky. Požaduje na serveru vrácení těla dokumentu identifikovaného URI požadavku. Odpovídá podobně jako GET, s výjimkou toho, že nikdy není vraceno tělo obsahu. Je způsobem, jak zjistit, zda byl dokument od posledního požadavku aktualizován. Používá se pro přenos bloku dat obsaženého v těle požadavku na server. Doplňuje požadavek GET a uchovává tělo obsahu na místě daném požadovaným URI. Podobá se odesílání souboru přes FTP. Umožňuje odstranění dokumentu ze serveru. Dokument, který má být odstraněn, je dán URI požadavku. Používá se pro sledování cesty požadavku skrze firewally a více serverů proxy. Je užitečná při ladění komplexních problémů se sítí a podobá se nástroji traceroute. Odpověď serveru Odpově serveru také obsahuje 3 části. Nejprve server vrací stavový řádek, skládající se ze tří částí: verze HTTP, stavového kódu a popisu stavového kódu v následujícím formátu: Protokol Stavový kód Popis 3

PHP Programujeme profesionálně Například stavový řádek: HTTP/1.0 200 OK indikuje, že server ve své odpovědi používá protokol HTTP/1.0. Stavový kód 200 znamená, že byl požadavek klienta úspěšný. Po řádku odpovědi server odesílá v hlavičkách klientovi informace o sobě a o požadovaném dokumentu. Všechny informace záhlaví jsou odesílány po řádcích, každá ve formátu: Klíčové slovo: Hodnota Například: HTTP/1.1 200 OK Date: Wed, 19 May 1999 18.20:56 GMT Server: Apache/1.3.6 (Unix) PHP / 3.0.7 Last-Modified: Mon, 17 May 1999 15:46:21 GMT ETag: "2da0dc-2870-374039cd" Accept-Ranges:bytes Content-Length: 10352 Connection: close Content-Type: text/html; charset=iso-8859-1 Řádek odpovědi a jednotlivé řádky záhlaví jsou ukončeny sekvencí CRLF (\r\n). Pro ukončení hlaviček server odešle prázdný řádek. K přesnému významu těchto hlaviček HTTP se vrátíme opět později. Pokud byl požadavek klienta úspěšný, jsou odeslána požadovaná data. Tato data mohou být kopií souboru nebo odpovědí programu CGI. Tento výsledek se nazývá tělo odpovědi. Pokud nemohl být požadavek klienta splněn, mohou další data obsahovat vysvětlení toho, proč server nemohl požadavek splnit, v čitelné podobě. Vlastnosti těchto dat (druh a délka) jsou odeslány v záhlavích. Záhlaví odpovědi nakonec ukončuje prázdný řádek (\r\n\r\n). Kompletní odpově by mohla vypadat takto: HTTP/1.1 200 OK Date: Wed, 19 May 1999 18.20:56 GMT Server: Apache/1.3.6 (Unix) PHP/3.0.7 Last-Modified: Mon, 17 May 1999 15:46:21 GMT ETag: "2da0dc-2870-374039cd" Accept-Ranges:bytes Content-Length: 10352 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-/ /W3C/ /DTD HTML 4.0 Transitional //EN" "http: //www.w3.org/tr/rec-html40/loose.dtd"> <html>... </html> V HTTP/1.0 poté, co server dokončil odesílání odpovědi, se server odpojí od klienta a, pokud klient neodeslal záhlaví Connection: KeepAlive, transakce je ukončena. V HTTP/1.1 je spojení spra- 4

Příloha D Požadavky a odpovědi HTTP vováno tak, že klient může vytvářet další požadavky, dokud klient neodešle explicitně záhlaví Connection: Close. Jelikož mnohé dokumenty HTML obsahují jiné vložené dokumenty jako vložené obrázky, applety a rámy, může funkce trvalého spojení protokolu HTTP/1.1 ušetřit režii, která vzniká, když se klient opakovaně přihlašuje ke stejnému serveru, aby načetl jednotlivou stránku. HlavičkyHTTP Tato záhlaví se mohou objevit v požadavcích i odpovědích. Některé řídí chování serveru, některé jsou pro servery proxy a jiné mohou ovlivnit, co bude prohlížeč dělat s obdrženou odpovědí. Pokud vás zajímá kompletní popis HTML/1.1, podívejte se do jeho specifikace. Můžete ji stáhnout z: ftp://ftp.ici.edu/in-notes/rfc2616.txt Ověřování je podrobněji popsáno v: ftp://ftp.ici.edu/in-notes/rfc2617.txt Užitečné mohou být i jiné dokumenty RFC ze stejného zdroje. Tato tabulka shrnuje nejobvyklejší hlavičky. Existují i jiné, ale ty řídí, jak server spravuje požadavky a nebudeme je v prostředí CGI potřebovat. Záhlaví Požadavek Odpověď Popis Accept: v Obsahuje typy, se kterými klient umí pracovat. Accept-Charset: v Obsahuje znakové sady, se kterými klient umí pracovat. Accept-Encoding: v Obsahuje přijatelná kódování nebo žádná. Vynechání této hlavičky znamená, že jsou akceptovatelná všechna kódování. Accept-Language: v Obsahuje akceptovatelné jazyky. Age: v Záhlaví pro řízení mezipaměti, které indikuje stáří těla odpovědi. Allow: v Určuje dostupné metody, na které může prostředek identifikovaný pomocí URI reagovat. Authorization: v Data pro autorizaci. Více informací o ověřování najdete v dokumentu RFC2617. Cache-Control: v v Sofistikované záhlaví pro řízení proxy. Může být použito pro stanovení toho, jak budou servery proxy nakládat s požadavky a odpově mi. Content-Base: v Používá se pro překlad relativních URL uvnitř těla vráceného dokumentu. Je nadřazené záhlaví Content-Location. Content-Encoding: v Určuje kódování, které bylo použito pro tělo před přenosem. Content-Language: v Určuje přirozený jazyk obsahu odpovědi 5

PHP Programujeme profesionálně Záhlaví Požadavek Odpověď Popis Content-Length: v Zde by měla být umístěna délka těla v bajtech. Odpovědi CGI se mohou podřídit webovému serveru a umožnit mu vložení tohoto záhlaví. Content-Location: v Aktuální umístění entity vrácené v odpovědi. To může být užitečné při rozšiřování prostředků, které mohou být vráceny několika způsoby. Může být identifikována a přímo vyžádána specificky vybraná verze. Content-MD5: v Toto je způsob výpočtu kontrolního součtu pro tělo entity. Přijímající prohlížeč může porovnat svou vypočítanou hodnotou pro zjištění toho, zda nebylo tělo v průběhu přenosu změněno. Content-Type: v Tímto záhlavím je dán druh dat vrácených v odpovědi. Tyto typy jsou uvedeny dále v této příloze. Expires v Datum, po kterém by měla být tato odpově považována za zastaralou. From: v V tomto záhlaví je odesílána e-mailová adresa klienta. Host: v V tomto záhlaví je definován cílový virtuální hostitel. Hodnota je převzata z původního URL, kdy požadavek vznikl. Last-Modified: v Toto indikuje, kdy byl vrácený obsah naposledy modifikován. U statických souborů může server používat časová razítka. U dynamicky generovaných stránek byste možná chtěli spíše uvést datum poslední úpravy položky databáze. Jiná sofistikovanější záhlaví pro řízení mezipaměti najdete ve specifikaci HTTP. Detaily najdete v RFC 2616. Location: v Používá se k přesměrování. Může být použito jako součást inteligentního CGI pro zpracování chyb. Referrer: v Zde je uveden zdroj původního požadavku. Toto by byla stránka, ze které byl přijat požadavek, tzn. odkaz. Můžete tak určit, na které adrese byl uveden odkaz, který vedl na vaše stránky. A to včetně parametrů vyhledávacích mechanismů, pokudbyl odkaz na vaše stránky v některém takovém nalezen. 6

Příloha D Požadavky a odpovědi HTTP Záhlaví Požadavek Odpověď Popis User-Agent: v Toto je pole podpisu prohlížeče. Pomocí tohoto pole můžete obejít omezení jednotlivých prohlížečů. Seznamte se s některými hodnotami, které se mohou objevit v tomto záhlaví. Warning: v Toto záhlaví se používá pro přenos dalších informací o odpovědi a informací o tom, kde jsou možná rizika s odpovědí spojená. Proměnné prostředí serveru Celkem vzato, hlavičky v požadavku korespondují s proměnnými prostředí, které jsou přítomny, když se provádí CGI. Ne všechna záhlaví ale odpovídají prostředí CGI. Některá mohou být pohlcena servery proxy, některá cílovým webovým serverem. Některé proměnné prostředí jsou vytvářeny podle potřeb samotného webového serveru bez převodu hodnot záhlaví. Zde je shrnutí proměnných prostředí, které pravděpodobně obdržíte. Mohou zde být další, které na serveru nakonfiguroval jeho správce nebo pokud byl adaptér CGI upraven tak, aby je předával. Pro přístup k nim můžete použít funkci Clib.getenv(). (Poznámka vydavatelství Wrox: tento seznam byl vytvořen s ohledem na autory skriptů CGI ScriptEase. Proměnné prostředí jsou dostupné i z ASP v sadě Request.ServerVariables. Tyto poznámky mohou být využity i ve skriptech ASP.) AUTH_TYPE Hotdnota této proměnné prostředí závisí na druhu ověření použitého serverem a na tom, zda je skript chráněn serverem. To se týká nastavení serveru a závisí na jeho druhu a také na použitém protokolu. Tato hodnota nemůže být definována, pokud stránka není zabezpečená. Pokud je zabezpečená, hodnota indikující druh ověření může být nastavena až po ověření uživatele. Příkladem hodnoty AUTH_TYPE je BASIC. CONTENT_LENGTH Pokud požadavek použil metodu POST, mohou být další informace uvedeny v těle. Tato je předána interpretu CGI na jeho standardní vstup. Samozřejmě, ScriptEase se vám přizpůsobí, extrahuje případné řetězce dotazu z těla a dekóduje je do proměnných pro konvenční přístup k nim. CONTENT_TYPE Datový druh nějakého obsahu přeneseného v těle požadavku. Pomocí něj můžete zpracovat standardní vstup ze součástí obsahu, které jsou jiného druhu než data formuláře. Toto je relativně neprozkoumaná oblast, a proto může hodně záviset na serveru a jeho platformě. Pokud to funguje, můžete si zvolit čtecí mechanismus založený na druhu obsahu a pak použít ostatní hlavičky pro zpracování binárních dat v těle. Pro přenos souborů na server je lepší použít HTTP/1.1, které podporuje metodu PUT, jež je lepší technikou a je zpracována uvnitř serveru. 7

PHP Programujeme profesionálně DOCUMENT_ROOT Toto je plná cesta ke kořenu dokumentů webového serveru. Pokud jsou používání virtuální hostitelé a pokud sdílí některé skripty CGI, může být kořen dokumentů pro každého virtuálního hostitele jiný. Pokud sídla opravdu úzce nesouvisí, je dobré udržovat adresáře cgi-bin oddělené. Například webové sídlo s obrázky a webové sídlo s hrami by mohly mít oddělené adresáře cgi-bin. Tři rozdělené verze sídla s obrázky mohou mít jiné kořeny dokumentů, ale společný adresář cgibin. Na některých serverech to může způsob identifikace toho, který virtuální hostitel je používán. FROM Pokud uživatel patřičně nakonfiguroval svůj prohlížeč, bude tato proměnná prostředí obsahovat jeho e-mailovou adresu. Pokud je uvedena, je to dobrý způsob identifikace uživatele, samozřejmě za předpokladu, že je majitelem počítače, který používá. GATEWAY_INTERFACE Můžete určit číslo verze použitého rozhraní CGI. Toto by mohlo být užitečné pokud jste závislí na funkcích dostupných v pozdější verzi rozhraní CGI, ale chcete spravovat jediný skript používaný ve více prostředích. HTTP_ACCEPT Toto je seznam přípustných typů MIME, které prohlížeč bude akceptovat. Tyto hodnoty závisí na použitém prohlížeči a na tom, jak je nastaven a jsou jednoduše předány webovému serveru. Pokud chcete být obzvláště chytří a udělat dobrou věc, zkontrolujte tuto hodnotu dříve, než se pokusíte vrátit neodpovídající data jiná než čisté HTML. Prohlížeč tím říká, s čím si umí poradit a pokud se pokusíte odeslat nějaká neočekávaná data, můžete způsobit kolizi u uživatele. HTTP_ACCEPT_LANGUAGE Zde nesmí být hodnota uvedená v proměnné prostředí. Pokud zde je, bude seznam definován prohlížečem. HTTP_CONNECTION Toto bude indikovat dispozici spojení HTTP. Mohlo by obsahovat hodnotu Keep-Alive nebo Close, ale skutečně, z pohledu CGI řízeného ScriptEase:WSE, nemáte žádné možnosti. Možná budete potřebovat vědět, zda spojení s prohlížečem zůstane otevřené, ale jelikož SE:WSE nyní nebude podporovat triky s datovými proudy, nebude to podstatné. HTTP_COOKIE Hodnoty cookie odeslané zpět prohlížečem jsou shromážděny a všechny dostupné společně v této proměnné prostředí. Budete muset rozdělit jednotlivá cookie a extrahovat jejich hodnoty. Která cookies obdržíte závisí na kořenu dokumentů sídla a na ostatních vlastnostech cookies. HTTP_HOST Na webovém serveru s více virtuálními hostiteli bude obsahovat název hostitele, který byl použit v požadavku. Můžete pak přizpůsobit výstup tak, aby odpovídal různým variacím sídel. Např. můžete prezentovat jiná loga a pozadí v www.domena.cz a test.domena.cz. Může vám pomoci vyře- 8

Příloha D Požadavky a odpovědi HTTP šit hodně problémů, když nastavíte označující rozdělení pro prezentaci vašeho obsahu skrze více portálových sídel. HTTP_PRAGMA Toto je něco v této chvíli neschváleného, ale bude pravděpodobně obsahovat hodnotu no-cache. Řízení mezipaměti je zpracováno flexibilněji v nových záhlavích odpovědí dostupných v HTTP/1.1. Ukládání do mezipaměti a činnost serveru proxy se mohou stát komplexnějšími. Více informací naleznete ve specifikaci HTTP - ftp://ftp.isi.edu/in-notes/rfc2616.txt HTTP_REFERER Toto je kompletní URL stránky, která byla zobrazena v prohlížeči a z níž vedl odkaz na naši stránku, který vyvolal daný požadavek. Pokud byl stránkou vyhledávací mechanismus, také může obsahovat některé zajímavé informace dotazu, které byste mohli extrahovat a dozvědět se tak, jak lidé našli vaše webové sídlo. Existují některé situace, kdy bude toto záhlaví prázdné. Např. když uživatel napíše URL do pole adresy. Toto záhlaví může být prázdné také když odkaz na naše sídlo vedl ze souboru uloženého v počítači uživatele. Také existují některé problémy, které závisí na druhu prohlížeče. Některé verze programu Internet Explorer od firmy Microsoft nepodávají toto záhlaví, když odkaz vede ze stránek s rámy. Pokud máte informace v tomto záhlaví, může to být užitečné, ale jindy může být toto záhlaví prázdné. HTTP_USER_AGENT Toto záhlaví obsahuje zkrácený název prohlížeče. Je to nezbytné, protože stránka nemusí být vždy vyžádána prohlížečem. Může být také vyžádána robotem. Také může být vyžádána programy pro prohlížení obsahu offline nebo monitorujícími službami a u generátorů statických stránek není neobvyklé, že se používají v sídle, které bylo původně navrženo jako dynamické. Raději, než počítat se všemi variantami prohlížečů, byste se měli zaměřit na určení toho, zda o vaše stránky žádá prohlížeč nebo robot. Tímto způsobem můžete, když je to nutné, poskytovat stránky určené robotům. Můžete stránky například učinit atraktivnějšími pro komunitu uživatelů, kteří používají např. pouze textové prohlížeče, jako je např. Lynx. Pak byste místo toho poskytovali graficky horší stránky, ale bohaté na text. Když sledujete toto, mějte na paměti, že v hodnotách vracených některými prohlížeči existují určité zvláštnosti. To může být záměrné nebo náhodné, ale jelikož byly uvolněny zdrojové kódy Netscape, vývojáři začali vyvíjet přizpůsobené prohlížeče. Některé z nich odešlou záhlaví User-Agent obsahující řídící znaky a binární data. I když je to pokus o využití chyb webových serverů, prostředí CGI nebo software pro analýzu protokolů od toho odrazují. V tomto záhlaví se setkáte s e-mailovými adresami, adresami URL, instrukcemi příkazového řádku a dokonce s celými webovými stránkami. PATH Toto je seznam adresářů, ve kterých se budou hledat příkazy, které můžete zkoušet a provádět v mechanismu CGI. Ten je odvozen od nadřazeného prostředí, které tento mechanismus vytvořilo. Je závislý na platformě a používá se v unixových systémech. V ostatních se vyskytovat nemůže. PATH_INFO Toto je způsob extrahování dalších informací o cestě z požadavku. Např. URL: http://www.domena.cz/cgi-bin/cesta.jsh/slozka1/soubor. Vyvolá skript SE:WSE, který se nazývá cesta.jsh a v pro- 9

PHP Programujeme profesionálně měnné prostředí PATH_INFO uchovává hodnotu /slozka1/soubor. Toto může být dalším způsobem předávání parametrů ze stránky HTML do skriptu na straně serveru. PATH_TRANSLATED Toto záhlaví je implementováno pouze v některých serverech a na jiných může být implementováno pod jinak nazvanou proměnnou prostředí. Vrací celou fyzickou cestu k prováděnému skriptu. To by mohlo být užitečné pokud máte sdílený kód, který vkládáte do více skriptů. QUERY_STRING Řetězec dotazu je ten text, který je v URL uveden za otazníkem. Tato proměnná prostředí bude obsahovat tento text. SE:WSE bude jej bude rozdělovat po jednotlivých prvcích do proměnných, ke kterým máte přímý přístup. REMOTE_ADDR Toto je vzdálená adresa IP počítače klienta, která vyvolala požadavek. Mohli byste ji použít pro řízení toho, co bude zobrazeno nebo pro zamítnutí přístupu klientům, kteří nepatří do vaší domény. REMOTE_HOST Tato hodnota bude pravděpodobně prázdná. Vyžaduje, aby webový server přeložil adresu IP pomocí DNS na název. Zad to bude dělat závisí na tom, jestli je uživatelův počítač uveden v databázi DNS. Toto záhlaví je často vypnuté, protože má za následek výrazné snížení výkonu, protože webový server musí provádět vyhledávání v DNS při každém požadavku. Pokud to budete potřebovat, měli byste vytvořit místní DNS a provozovat je odděleně. A přesto to bude mít za následek prodlevu ve zpracování požadavku a základem všeho čas je čas. REMOTE_IDENT Toto je neschválená funkce. Závisí na tom, zda klient i server podporuje RFC 931, jelikož koncový uživatel může nastavit hodnotu jako chce a šance, že to bude nějak užitečné, je opravdu malá. Nejlepší je zřejmě vyhnout se ji úplně a museli byste mít velké štěstí. abyste se u ní setkali se smysluplnou hodnotou. Samozřejmě, v odděleném intranetu, který můžete lépe řídit, byste to použít mohli. REMOTE_USER Pokud byl uživatel ověřen a splnil kritéria, bude tato proměnná obsahovat ověřené uživatelské jméno. Jinak budou tato proměnná a AUTH_TYPE pravděpodobně prázdné. Když je požadován dokument z nezabezpečené oblasti, může být tato hodnota prázdná dokonce i po ověření. REQUEST_METHOD Toto je metoda požadavku HTTP. Pravděpodobně zde najdete pouze POST nebo GET. Obvykle nebudete potřebovat jiné verze dokumentů založených na této hodnotě, ale mohlo by to být důležité pro ověření toho, zda byl přístup proveden korektně a ze stránky s korektní metodou. Mimo velikosti dat, která jsou větší u POST, existuje další rozdíl mezi GET a POST. Použití GET více než jednou by mělo mít za následek stejný výsledek. Stejné použití POST bude mít za následek vytvoření více transakcí. Například zadání objednávky více než jednou pomocí nového odes- 10

Příloha D Požadavky a odpovědi HTTP lání formuláře. Toto je jediný moment, kdy tlačítko Zpět pracuje proti vám a kdy budete chtít toto zablokovat ve vašem kódu, abyste zabránili duplicitním finančním transakcím. Měli byste si být vědomi toho, že toto se děje, když prohlížeč zobrazí varovnou zprávu, ve které se ptá, zda chcete znovu odeslat stejná data formuláře. SCRIPT_FILENAME V podstatě totéž jako proměnná prostředí PATH_TRANSLATED. Představuje plnou cestu k prováděnému skriptu. Jakmile stanovíte kterou z proměnných bude váš server používat. měli byste s ní vystačit. SCRIPT_NAME Toto je logický název skriptu. Normálně je to část URI požadavku na adresu URL, která byla původně odeslána. Je to plná cesta ke skriptu bez kořene dokumentů a bez mapování aliasu skriptu. Může být přenositelné mezi různými virtuálními hostiteli, což hodnoty SCRIPT_FILE- NAME/PATH_TRANSLATED nemohou. Užitečné také při vytváření přenositelných skriptů. Tuto hodnotu můžete použít pro nové sestavení formuláře tak, aby volal znovu stejný skript. Výsledkem je pak to, že skript neobsahuje pevnou cestu, kterou by bylo třeba po přesunutí nebo přejmenování upravovat. SERVER_ADMIN Pokud je nastaveno, je v této proměnné obsažena e-mailová adresa správce serveru. Měli byste ji použít v zabezpečovacích mechanismech, abyste správce upozornili na detekovaný potenciální průlom. Bu te opatrní, abyste nezahrnuli správce serveru tisíci zpráv. SERVER_NAME Toto je název serveru a v některých systémech může být ekvivalentní hodnotě HTTP_HOST. Může být užitečný při vytváření odkazů někam jinam v rámci sídla nebo při detekování názvu sídla, abyste mohli vytvářet různé verze stránky pro různá sídla. SERVER_PORT Zde je uloženo číslo portu, na který přišel požadavek. Většina webových sídel pracuje na portu 80. Ty, co nemohou být pokusnými sídly nebo mohou pracovat uvnitř firewallu. Pomocné servery mohou pracovat na jiných číslech portů, když běží na stejném počítači jako hlavní webový server. Většina webových serverů umožňuje nastavení čísla portu. V případě webového serveru Apache můžete nastavit na odlišné porty jednotlivé virtuální hostitele. To znamená, že byste mohli vyvinout pokusné sídlo a tuto hodnotu použít pro aktivování dalšího ladění, které bude na hlavním sídle vypnuté. SERVER_PROTOCOL Toto je verze protokolu zpracovávaného požadavku. Tato oblast je ve specifikacích a vydaných knihách lehce nejednoznačná. Prohlížeč může indikovat preferovaný protokol, kterému se může přizpůsobit. Toto je hodnota, kterou dává na řádek požadavku. Samozřejmě, server může tuto hodnotu ignorovat a zpracovat požadavek s podmnožinou funkcí, které odpovídají dřívější úrovni protokolu. Konfigurace serveru může určit shodu prohlížeče a interně ji ignorovat nebo může být požadavek zpracován protokolem HTTP/1.0 i když prohlížeč indikuje, že umí pracovat s protokolem HTTP/1.1. Z pohledu skriptování CGI je nepravděpodobné, že byste potřebovali podle 11

PHP Programujeme profesionálně této hodnoty vytvářet různé verze stránky. Můžete podle toho určovat, zda máte používat média s datovými proudy, ale tato technika není v SE:WSE aktuálně nijak podporována. SERVER_SOFTWARE Například Apache/1.3.6, ale závisí na serveru. UNIQUE_ID Toto je dostupné v prostředích CGI běžících pod webovým serverem Apache, který byl sestaven s modulem unique_id. Mohli byste si zvolit první z nich, který přijde v relaci a použít jej potom jako klíč relace jako jiný alternativní způsob generování unikátních klíčů relací. Mohlo by také poskytovat některé užitečné možnosti sledování uživatelů. 12