pro autory webu a webmastery
Mark Nottingham
Český překlad textu Caching Tutorial for Web Authors and Webmasters.
Originally Caching Tutorial for Web Authors and Webmasters by Mark Nottingham. Czech translation by Dušan Janovský.
Toto je informační dokument. Přestože je přirozeně technický, snaží se pojmout pochopitelné a použitelné situace z reálného světa. Kvůli tomu jsou některé aspekty tématu zjednodušené nebo vynechané, aby to bylo srozumitelnější. Zajímají-li vás detaily, projeďte si na konci článku odkazy a další informace.
Poznámka překladatele: pro anglický výraz "cache" jsem po poradě v konferencích zvolil překlad "keš" (rodu ženského) a jeho odvozeniny. Není to ideální, ale je to to nejlepší, na co jsme přišli. V překladech odborných termínů jsem se snažil držet zažitých překladů; nejsem ovšem serverový specialista a je možné, že nějaký termín překládám špatně.
Webová keš sedí mezi jedním nebo mnoha webovými servery (říká se jim původní servery) a klientem nebo mnoha klienty, sleduje požadavky na HTML stránky, obrázky a soubory (dohromady označované jako objekty), sbírá je a ukládá si pro sebe kopie. Potom, jakmile přijde nějaký jiný požadavek na tentýž objekt, keš použije kopii, kterou už má, místo aby znovu o totéž žádala původní server.
Jsou dva hlavní důvody, proč se používají webové keše:
Když prozkoumáte dialogy nastavení každého moderního prohlížeče (jako např. Internet Explorer nebo Netscape), pravděpodobně si všimnete nastavení "cache" nebo "Dočasné soubory internetu". Tato nastavení vám umožní zarezervovat část vašeho pevného disku na ukládání objektů, které jste už viděli, jenom pro vás. Prohlížečová keš pracuje na základě přísně jednoduchých pravidel. Obvykle jednou za session (to je jednou při každém spuštění prohlížeče) se u každého objektu ujistí, že je objekt čerstvý. (V Internet Exploreru se dá frekvence kontroly přenastavit, ale přenastavuje to málokdo, pozn. překl.)
Tato keš je užitečná, když uživatel.mačká tlačítko "zpět", aby se dostal na stránku, kterou už viděl, . Také, pokud používáte stejné navigační obrázky v celém svém webu, budou obslouženy z prohlížečové keše téměř okamžitě.
Keše webových proxyn fungují na stejném principu, ale v mnohem větším měřítku. Proxy obsluhuje stovky nebo tisíce uživatelů stejným způsobem. Velké firmy a poskytovatelé internetového připojení často nastavují proxy na svých firewallech, nebo jako samostatná zařízení (známé jako prostředníci).
Protože proxy keše nejsou částí klienta ani původního serveru, nýbrž jsou v síti někde jinde, požadavek k nim musí být nějak dostat. Jedním způsobem, jak se to dělá, je ruční nastavení proxyny v prohlížeči, prostě se nastaví, jaká proxy se bude používat. Jiný způsob je použití prostředníka. Všechny požadavky směřující z vnitřní sítě do webu jsou ve skutečnosti přesměrovány na transparentní proxy, která má odpovídat sama (může k tomu použít keš nebo původní server), takže klienti nemusejí nic nastavovat a dokonce o ničem nevědí.
Proxy keše jsou typem sdílených keší. Mají obvykle velký počet uživatelů, než aby je používal jeden uživatel, proto jsou velmi dobré na zmenšování zpoždění a síťového přenosu. Je to tím, že se populární objekty používají mnohokrát.
Jsou také známé jako "reverzní proxy keše" nebo jako "náhradní keše". Keše na branách jsou také prostředníci, ale místo toho, aby byly nasazeny administrátory sítě na ušetření přenosu, jsou typicky nasazovány samotnými webmastery, kteří se snaží mít web dostupnější, spolehlivější a funkčnější.
Požadavky mohou být na keše na branách routovány mnoha metodami, ale typicky je nějaká forma vyvažování přenosu používaná na to, aby to pro klienta vypadalo, že jedna nebo více těchto keší je původní server.
Sítě na poskytování obsahu (Content delivery networks) - CDN - distribuují reverzní proxy keše celým Internetem (nebo jeho částí) a prodávají kešování provozovatelům webů, kteří o to mají zájem. Příkladem CDN jsou Speedera a Akamai.
Tento návod se zaměřuje zejména na prohlížečové a proxy keše, přestože některé z informací jsou vhodné pro ty, kdo se také zajímají o keše na branách.
Webové kešování je jedna z nejvíce nepochopených technologií na Internetu. Webmasteři se obzvláště bojí, že ztratí kontrolu nad svými weby, protože keš před nimi může "ukrýt" jejich uživatele, a tak činí obtížným sledovat, kdo web používá.
Ale I kdyby se žádné webové cache nikde nepoužívaly, na Internetu naneštěstí pro webmastery existuje příliš mnoho proměnlivých faktorů, než aby bylo možno udělat si detailní obrázek o tom, jak přesně uživatelé weby procházejí. Pokud se o to zajímáte, tento dokument vás naučí, jak získat potřebné statistiky, aniž byste svůj web učinili nepřátelský ke keším.
Jiná věc je, že keše mohou poskytovat obsah, který je zastaralý nebo shnilý. Nicméně tento návod vám může ukázat, jak to mít pod kontrolou a zároveň jak svůj server nakonfigurovat, aby byl lépe kešovatelný.
Na druhou stranu pokud svůj web plánujete dobře, keše vám mohou pomoci urychlit natahování a ušetřit přenos na lince z vašeho serveru do Internetu. Rozdíl může být dramatický; nahrávání stránky z těžko kešovatelného webu může zabrat několik sekund, zatímco jiný web využívající výhodu kešování se může zdát v porovnání s ním bleskový. Uživatelé ocení rychle nahrávaný web a budou se častěji vracet.
Přemýšlejte o téhle cestě; mnoho velkých internetových společností utrácí milióny dolarů nastavováním serverových farem po celém světě, aby nakopírovaly obsah a učinily svoje weby pro uživatelé tak rychlé, jak to jen jde. Keše pro vás dělají to samé, dokonce jsou ke koncovým uživatelům blíže. A co je nejlepší: nemusíte za ně platit.
Faktem zůstává, že keše se budou používat, ať už si to budete přát, nebo ne. Jestliže kešování na svém serveru sami správně nenakonfigurujete, bude obsah kešován všemi možnými způsoby, jaká si určí správci keší.
CDN jsou zajímavá vymoženost, protože narozdíl od proxy keší se jejich keše na branách řídí zájmem majitele webových stránek, takže u nich tento problém není vidět. Ovšem i když používáte CDN, musíte stále brát v úvahu vliv proxy a prohlížečových keší.
Všechny keše mají sadu pravidel, kterou používají k určení toho, kdy nějaký dostupný objekt poskytnout z keše. Některá z těchto pravidel jsou nastavena v protokolech (HTTP 1.0 a 1.1) a některá jsou nastavena administrátory keše (buď uživatelem prohlížeče, nebo administrátorem proxyny).
Obecně řečeno, toto jsou nejobecnější pravidla, která jsou dodržována pro jednotlivé požadavky (netrapte se, pokud nerozumíte detailům, budou vysvětleny níže):
Čerstvé dokumenty jsou poskytovány přímo z keše bez komunikace s původním serverem.
Dohromady jsou čerstvost a validace nejdůležitější způsoby, kterými keše pracují s obsahem. Čerstvé objekty budou k dispozici okamžitě z keše, zatímco pro validované objekty nebude z původního serveru vyžadován vlastní obsah objektů, pokud nebyly změněny.
Webdesigneři a webmasteři mohou na jemné vyladění způsobů, jak budou keše nakládat s jejich webovými stránkami, používat několik nástrojů. Možná to bude při konfiguraci serveru znamenat malé zašpinění rukou, ale výsledek bude stát za to. Detaily použití těchto nástrojů naleznete níže v sekci Implementace.
Autoři HTML stránek mohou meta tagy umístit do hlavičky <HEAD>, která popisuje atributy dokumentu. Tyto meta tagy jsou obvykle používány v dobré víře, že mohou označit dokument jako nekešovatelný, nebo zaručit vypršení platnosti v daný čas.
Meta tagy se snadno používají, ale nejsou moc efektivní. Jsou totiž akceptovány pouze prohlížečovými kešemi (které HTML skutečně čtou), nikoli proxy kešemi (které téměř nikdy HTML dokument nečtou). Jakkoli může svádět plácnout na domovskou stránku meta tag Pragma: no-cache, nebude nutně zapříčiňovat to, že bude stránka udržována čerstvá, pokud prochází přes sdílenou keš.
Na druhou stranu vám skutečné HTTP hlavičky dávají hodně možností regulace toho, jak budou oba druhy keší zacházet s vašimi objekty. Nejsou vidět v HTML a obvykle jsou automaticky generovány webovým serverem. Můžete je ovšem do určité míry řídit, podle toho, jaký server používáte. V následující sekci uvidíte, které HTTP hlavičky jsou zajímavé a jak se dají na vašich stránkách použít.
HTTP hlavičky jsou posílány serverem před samotnou HTML stránkou, vidí je pouze prohlížeč a nějaké mezilehlé keše. Typická hlavička odpovědi HTTP 1.1 vypadá nějak takhle:
HTTP/1.1 200 OK Date: Fri, 30 Oct 1998 13:19:41 GMT Server: Apache/1.3.3 (Unix) Cache-Control: max-age=3600, must-revalidate Expires: Fri, 30 Oct 1998 14:19:41 GMT Last-Modified: Mon, 29 Jun 1998 02:28:12 GMT ETag: "3e86-410-3596fbbc" Content-Length: 1040 Content-Type: text/html
Vlastní HTML dokument by následoval tyto hlavičky, oddělen jedním prázdným řádkem. Informace o HTTP hlavičkách naleznete v sekci Implementace.
Jestliže je váš web hostován nějakým ISP (internet service providerem) nebo hostingovou farmou, která vám nedává možnost nastavení libovolných HTTP hlaviček (jako Expires a Cache-Control), hodně nahlas si stěžujte. Jsou to nástroje nezbytné k vykonávání vaší práce.
Mnoho lidí věří, že uvedením HTTP hlavičky Pragma: no-cache učiní objekt nekešovatelný. To nemusí být pravda; specifikace HTTP neuvádí žádná doporučení pro hlavičky odpovědí Pragma; ve specifikaci jsou zmiňovány spíše hlavičky požadavků Pragma (hlavičky, které prohlížeč posílá serveru). Třebaže některé keše mohou tuto hlavičku zohledňovat, většina ji nezohlední a hlavička nebude mít žádný efekt. Použijte namísto ní hlavičky zmíněné níže.
HTTP hlavička Expires je základní prostředek pro ovládání keší; říká všem keším, po jak dlouho je objekt čerstvý; po tomto čase se keše vždy zeptají původního serveru, zda byl dokument změněn. Hlavička Expires je podporována prakticky všemi klienty.
Většina webových serverů vám dovolí nastavit odpovědi hlavičku Expires několika různými způsoby. Obecně umožní nastavení vypršení čerstvosti na nějaký absolutní čas, na čas odvozený z času posledního shlédnutí objektu (poslední access time), nebo na čas odvozený od posledního času, kdy se dokument na vašem serveru změnil (poslední modification time).
Hlavičky Expires jsou obzvláště dobré pro nastavení kešování statických obrázků (jako jsou navigační proužky a tlačítka). Protože se moc nemění, můžete jim nastavit extrémně dlouhý čas expirace (tj. vypršení čerstvosti), takže se váš web bude uživatelům jevit jako pružněji reagující. Hlavičky Expires jsou také užitečné na ovládání kešování stránek, které jsou pravidelně měněny. Když například aktualizujete stránku s novinkami každý den v šest ráno, můžete nastavit objekt pro vypršení v tomto čase, takže keše budou vědět, kdy si vzít čerstvou kopii bez toho, aby si uživatel musel stránku sám aktualizovat.
Jediná správná hodnota jakékoli hlavičky Expires je HTTP datum; cokoli jiného bude s největší pravděpodobností interpretováno jako "v minulosti", takže objekt bude nekešovatelný. Pamatujte také na to, že čas v HTTP datu je Greenwichský hlavní čas (GMT), nikoli lokální čas.
Například:
Expires: Fri, 30 Oct 1998 14:19:41 GMT
Přestože je hlavička Expires užitečná, má některá omezení. Zaprvé kvůli tomu, že obsahuje datum, hodiny na serveru a keš musejí být synchronizovány. Pokud mají rozdílné představy o čase, nebude dosaženo patřičných výsledků a keše mohou chybně považovat starý obsah za čerstvý.
Takže pokud používáte hlavičku Expires, je důležité zajistit, aby byl systémový čas na serveru přesný. Jedním ze způsobů, jak se to dá udělat, je použít Network Time Protocol (NTP). Správce systému by vám měl říci více.
Jiný problém s Expires je, že snadno zapomenete, že jste pro nějaký obsah nastavili, že má vypršet v přesný čas. Jestliže před uplynutím tohoto času hlavičku Expires nezaktualizujete, každý požadavek půjde zpět na váš server, což zvýší přenos a odezvu.
HTTP 1.1 přináší novou třídu hlaviček odpovědí Cache-Control, které dovolují autorům webu definovat, jak mají keše se stránkami zacházet. Vkládají instrukce deklarující, co by mělo být kešovatelné, co může být kešemi ukládáno, změny expiračního mechanizmu (tj. vyprchávání čerstvosti) a ovládání revalidace a obnovování.
Mezi zajímavé Cache-Control hlavičky odpovědí patří:
Například:
Cache-Control: max-age=3600, must-revalidate
Pokud plánujete použít hlavičky Cache-Control, měli byste věnovat pozornost excelentní dokumentaci k návrhu HTTP 1.1, vizte Reference a další informace.
V části Jak cache pracují je řečeno, že validaci servery a keše používají ke komunikaci, když se nějaký objekt změnil. Použitím objektu sice keše zabrání stahování celého objektu, jehož lokální kopii už mají, ale nemohou si být jisté, že je ten objekt čerstvý.
Validační údaje jsou velmi důležité; jestliže nejsou přítomny a není dostupná žádná informace o čerstvosti (Expires nebo Cache-Control), většina keší vůbec nebude objekt ukládat. (Prohlížečové cache ale ukládají asi vždy, pokud se jim to nezakáže, pro účely aktuální seance. Pozn. překl.)
Nejobvyklejší validační údaj je čas, kdy se dokument naposledy změnil, to je Last-Modified čas. Jestliže má keš uložený nějaký objekt obsahující hlavičku Last-Modified, může ji použít pro dotaz, zda byl objekt změněn od posledního času, kdy byl objekt viděn. To je dotaz If-Modified-Since (pozn. překl.: nepřekládá se, znamená něco jako pokud se změnil od...).
HTTP 1.1 přinesl nový druh validačního údaje nazvaný ETag. ETagy jsou unikátní identifikátory generované serverem a měněné pokaždé, když se objekt změní. Protože způsob generování ETagů kontroluje server, mohou si být keše jistější, že pokud ETag při dotazu typu If-None-Match souhlasí, tak že je ten objekt opravdu úplně ten samý.
Téměř všechny keše používají při zjišťování, zda je objekt čerstvý, časy poslední změny (Last-Modified). Jak se stále více keší řídí protokolem HTTP/1.1, budou se používat také ETagy.
Většina moderních webových serverů bude generovat validační údaje automaticky: jak ETag, tak Last-Modified; nebudete muset dělat nic. Ale zase ty servery nemají dost informací o dynamickém obsahu (jako CGI, ASP nebo databázové stránky), aby validační údaje generovaly, vizte Psaní skriptů respektujících keše.
Kromě používání validace a informací o čerstvosti existuje ještě mnoho dalších věcí, které můžete udělat pro svůj web, aby lépe respektoval keše.
Ve výchozím nastavení nebude většina skriptů vracet validační údaje (např. HTTP hlavičky Last-Modified nebo ETag) nebo informace o čerstvost (Expires nebo Cache-Control). Zatímco některé skripty jsou opravdu dynamické (což znamená, že vracejí odlišnou odpověď na každý jeden požadavek), mnoho jiných skriptů (jako vyhledávače nebo weby založené na databázích) mohou získávat tím, že budou snadno kešovatelné.
Obecně řečeno, pokud skript produkuje výstup, který je později reprodukovatelný stejným dotazem (ať už je to o minuty nebo o dny později), měl by být kešovatelný. Pokud obsah výstupu skriptu závisí pouze na tom, co je v URL, je to kešovatelné. Pokud výstup závisí na cookie, na autentifikaci nebo na jiném externím kritériu, pravděpodobně to kešovatelné nebude.
Pár dalších tipů:
Podrobnější informace hledejte u Implementačních poznámek.
Dobrá strategie je zjistit si nejčastěji stahované a největší objekty (zejména obrázky) a napřed pracovat s nimi.
Většině kešovatelných objektů nastavit dlouhý čas čerstvosti. Jinak validace sice pomáhá redukovat čas, který poskytnutí objektu zabere, ale keš musí stále kontaktovat původní server, aby se ujistila, zda je to čerstvé. Jestliže keš už ví, že to čerstvé je, může objekt poskytnout přímo.
Jestliže potřebujete pokaždé zjistit, že se někdo na stránku podíval, zvolte JEDEN malý objekt na stránce (nebo samotnou stránku) a za pomoci patřičných hlaviček jej učiňte nekešovatelným. Například můžete na každou stránku vložit průhledný nekešovatelný obrázek s rozměry 1x1. Hlavička s referrerem bude obsahovat informaci o tom, jaká stránka si objekt vyžádala.
Pamatujte, že ani vypnutí kešování vám nedá přesné statistiky o vašich uživatelích, navíc je to pro vaše uživatele nepříjemné; vytváří to nepotřebný přenos dat a nutí lidi čekat, než se ty nekešované objekty stáhnou. Více informací o tomto tématu najdete jako Interpretace statistik přístupů v odkazech.
Většina webových prohlížečů vám ukáže hodnoty hlaviček Expires a Last-Modified v dialogu "vlastnosti stránky", "informace o stránce" nebo něco podobného. Je-li to možné, dostanete také tabulku s informacemi o všech objektech načítaných do stránky (jako jsou obrázky) společně s jejich detaily.
Abyste viděli celé hlavičky objektů, musíte se ručně připojit na webový server klientem Telnet. Podle toho, jakého klienta používáte, můžete vypsat port do odděleného políčka, nebo se připojíte na www.můjserver.cz:80 nebo www.můjserer.cz 80 (všimněte si mezery). Více informací hledejte v dokumentaci ke klientu Telnetu. Až otevřete spojení na server, vypište požadavek na objekt. Například pokud chcete hlavičky pro http://www.myhost.com/foo.html, připojte se na www.myhost.com, port 80, a napište:
GET /foo.html HTTP/1.1 [enter] Host: www.myhost.com [enter][enter]
Stiskněte Enter pokaždé, kdy je v příkladu vypsáno [enter]; na konci je to dvakrát. Vypíše to hlavičky a potom celý objekt. Chcete-li vidět pouze hlavičky, nahraďte GET zápisem HEAD.
Výchozí nastavení je takové, že stránky chráněné HTTP autentifikací jsou označeny jako soukromé (private); nebudou sdílenými kešemi ukládány. Můžete ovšem autentifikované stránky označit jako veřejné (public) pomocí hlavičky Cache-Control; HTTP 1.1 - ochotné keše je potom povolí ukládat.
Jestliže chcete mít stránky kešovatelné, ale stále pro každého uživatele autentifikované, zkombinujte Cache-Control: public s hlavičkami no-cache. To keši řekne, že musí na původní server odeslat nové informace o autentifikaci klienta, ještě než objekt z keše uvolní. Vypadá to takhle:
Cache-Control: public, no-cache
Ať už to tak uděláte nebo ne, vždy je nejlepší minimalizovat použití autentifikace. Pokud například nemáte obrázky tajné, uložte je do odlišného adresáře a nastavte server tak, aby pro tento adresář nevyžadoval autentifikaci. Tím pádem budou tyto obrázky kešovatelné přirozeně.
SSL stránky nejsou proxy kešemi kešovány (nebo dešifrovány), takže se toho nemusíte bát. Protože keše ovšem ukládají ne-SSL dotazy a objekty stažené do SSL stránek (např. obrázky), buďte si vědomi stavu bezpečnosti nezabezpečených stránek; nějaký bezohledný administrátor keše by mohl schraňovat informace o vašich uživatelích.
Je pravda, že jakýkoliv síťový administrátor mezi vaším serverem a vašimi klienty může tento typ informací shromažďovat. Další část problému nastává, pokud CGI skripty přidávají uživatelské jméno a heslo přímo do samotného URL; pak už je to pro síťové administrátory triviální, prostě cizí jména a hesla najdou a mohou použít.
Jestliže se o oblast webové bezpečnosti staráte obecně, neměly by pro vás proxy cache znamenat žádné překvapení nebo ohrožení.
To je různé. Obecně řečeno, čím komplexní to řešení je, tím složitější je kešovat jej. Nejhorší jsou taková řešení, která veškerý obsah generují dynamicky a neposkytují validační údaje; pak to může být zcela nekešovatelné. Promluvte si o tom s technickým personálem distributora řešení a také si níže prostudujte implementační poznámky.
Hlavičky Expires nelze obejít; dokud se keš (ať už prohlížečová nebo proxy keš) nepodívá na původní server a objekt nesmaže, do té doby se bude používat nakešovaná verze.
Nejlepší řešení je soubory přejmenovat; tím pádem se z nich stanou nové objekty a natáhnout se ze svého původního serveru čerstvé. Pamatujte ale, že stránka, která objekt načítá, může být také kešovaná. Kvůli tomu je nejlepší dělat statické obrázky a podobné objekty velmi kešovatelné, zatímco HTML stránky je lepší držet trochu zkrátka.
Jestliže chcete znovu načíst nějaký objekt uložený v konkrétní keši, buď můžete udělat tvrdý reload (v Netscape stisknout Shift a dát reload [Shift + F5 v Exploreru, pozn. překl.] a provede se to pomocí hlavičky požadavku Pragma: no-cache), takže se to nebude brát z cache. Nebo můžete jako administrátor ze svého rozhraní keše objekt smazat.
Jestliže používáte Apache, povolte uživatelům použití souboru .htaccess a poskytněte jim příslušnou dokumentaci.
Nebo můžete na každém virtuálním serveru zavést předurčené oblasti pro ukládání objektů, které se mají odlišně kešovat. Například můžete specifikovat adresář /cache-1m, jehož obsah bude kešován měsíc od stažení, a adresář /no-cache, jehož obsah bude opatřen hlavičkami, které keším budou říkat, aby nic z toho nekešovaly.
Ať už jste schopni cokoliv z toho udělat, nejlepší je na kešování začít pracovat se svým největším zákazníkem. Největší úspora (v přenosu dat a v loadu z vašeho serveru) se pravděpodobně udělá na velkoobjemových stránkách.
Keše nemají povinnost podržet objekt a znovu jej použít; mají pouze povinnost jej za určitých okolností nepoužívat. Všechny keše provádějí rozhodnutí o udržování kopií podle velikosti objektu, jeho typu (např. zda je to obrázek nebo html) nebo podle toho, kolik na ukládání kopií zbývá místa. Vaše keš možná nepovažuje ukládání vašich stránek za výhodné, v porovnání s častěji požadovanými nebo většími objekty.
Některé keše svým administrátorům dovolují nastavovat priority ohledně toho, jaké druhy objektů mají být ukládány, případně nastavit objekty, které mají být v keši uloženy za všech okolností.
Obecně řečeno, je nejlepší používat poslední verzi jakéhokoli webového serveru, který jste si vybrali k použití. Ne jenom protože budou s větší pravděpodobností obsahovat keším příznivé vlastnosti, ale taky že nové verze obvykle mají důležitá bezpečnostní a výkonnostní zdokonalení.
Apache používá volitelné moduly pro vkládání hlaviček, včetně Expires a Cache-Control. Oba moduly jsou k dispozici v distribuci 1.2 a vyšší.
Moduly je potřeba do Apache zabudovat. Třebaže jsou vloženy v distribuci, jsou ve výchozím nastavení vypnuté. Ke zjištění, jestli jsou moduly na serveru povolené, najděte binárku a spusťte httpd -l; to by mělo vypsat seznam dostupných modulů. Moduly, které hledáme, jsou mod_expires a mod_headers.
Jakmile máte Apache s příslušnými moduly, můžete mod_expires použít na specifikování, kdy má objektům vypršet platnost, buďto v souborech .htaccess nebo v serverovém souboru access.conf. Můžete vypršení nadefinovat buď podle času přístupu, nebo podle času změny; dá se to nastavit podle typu souboru nebo jako výchozí vypršení. Více informací naleznete v dokumentaci k modulu mod_expires, v případě problémů se poraďte se svým apachovským guru.
Abyste mohli použít hlavičky Cache-Control, budete potřebovat modul mod_headers, který vám pro každý zdroj dovolí specifikovat libovolné hlavičky. Podívejte se do dokumentace mod_headers.
Zde je příklad souboru .htaccess, který demonstruje užití některých hlaviček.
### aktivace modulu mod_expires ExpiresActive On ### Soubory typu .gif vyprší 1 měsíc poté, co byly staženy ### (je to v sekundách, A jako access=stažení, M jako modification=změna, pozn. překl.) ExpiresByType image/gif A2592000 ### Všechno ostatní vyprší 1 den od chvíle, kdy to bylo naposledy změněno ### (jde o použití alternativního zápisu) ExpiresDefault "modification plus 1 day" ### Na soubor index.html se aplikuje hlavička Cache-Control <Files index.html> Header append Cache-Control "public, must-revalidate" </Files>
Apache 2.0 má konfiguraci velmi podobnou verzi 1.3; pro více informací se podívejte do dokumentace mod_expires a mod_headers.
Na Microsoftím serveru Internet Information Server je velmi snadné nastavit čemukoli hlavičky pružným způsobem. Pamatujte, že to je možné jenom na verzi 4, která běží pouze na NT serverech (a asi i pro vyšší verze, pozn. překl.).
Nastavení hlaviček nějaké oblasti webu se dělá v rozhraní Administration Tools výběrem oblasti a zvolením vlastností (Properties). Po zvolení záložky HTTP Headers byste měli vidět dvě zajímavé oblasti; Enable Content Expiration a Custom HTTP headers. To první by mělo být jasné na první pohled a to druhé se dá použít na přidání hlaviček Cache-Control.
Níže se podívejte na sekci ASP a dozvíte se, jak nastavit hlavičky na Active Server Pages. Hlavičky se také dají nastavovat z ISAPI modulů; detaily hledejte na MSDN.
Ačkoli je to už verze 3.6, Enterprise Server nenabízí žádný samozřejmý způsob nastavení hlaviček Expires. Od verze 3.0 ovšem podporuje vychytávky HTTP 1.1. To znamená, že keše používající HTTP 1.1 (proxy keše i prohlížečové) budou schopny využít výhody nastavení Cache-Control.
Hlavičky Cache-Control se dají použít v administraci serveru v Content Management | Cache Control Directives. Potom zvolte adresář, ve kterém chcete hlavičky nastavit. Po nastavení hlaviček klikněte 'OK'. Více informací hledejte v manuálu NES.
Protože to podstatné na serverově generovaných stránkách je proměnlivý obsah, nejsou opravdu kešovatelné, i kdyby se obsah kešovat dal. Jestliže se obsah vaší stránky mění často, ale ne při každém přístupu, zvažte nastavení hlavičky Cache-Control: max-age; většina uživatelů přistupuje na stránky v relativně krátkých časových periodách. Když například uživatelé používají tlačítko 'zpět' a není dostupný žádný validátor nebo údaj o čerstvosti, budou muset čekat a neuvidí nic, dokud se stránka opět stáhne ze serveru.
Vždycky myslete na to, že může být jednodušší nastavit HTTP hlavičky na svém webserveru, než to nastavovat ve skriptovacím jazyce. Zkuste obojí.
CGI skripty jsou jedním z nejoblíbenějších způsobů generování obsahu. Můžete HTTP hlavičky odpovědí jednoduše přidat před výstup a odeslat to. Většina implementací takové připojení vždy vyžaduje pro hlavičku Content-Type. Například v Perlu:
#!/usr/bin/perl print "Content-type: text/html\n"; print "Expires: Thu, 29 Oct 1998 17:04:19 GMT\n"; print "\n"; ### the content body follows...
Protože je to všechno text, můžete snadno generovat Expires a jiné časové hlavičky pomocí zabudovaných funkcí. Dokonce je ještě jednodušší použít hlavičku Cache-Control: max-age:
print "Cache-Control: max-age=600\n";
Tento zápis učiní skript kešovatelný po deset minut od odeslání požadavku, takže pokud uživatel použije tlačítko 'zpět', požadavek se nebude znovu odesílat.
CGI specifikace také nechává zpřístupňovat v prostředí skriptu jako proměnné hlavičky požadavku, které přicházejí od klienta; každá proměnná má má před svým jménem přeřazeno HTTP_. Takže jestliže klient udělá požadavek If-Modified-Since, může to vypadat jakoby takhle:
HTTP_IF_MODIFIED_SINCE = Fri, 30 Oct 1998 14:19:41 GMT
Podívejte se také na knihovnu cgi_buffer (odkaz přestal fungovat), která automaticky zařizuje generování ETagu a validace, generuje Content-Length a gzip Content-Encoding pro CGI skripty v Perlu a Pythonu a dělá se to jednořádkovým includem. Pythonovská verze může být také použita na libovolné obalení CGI skriptů.
SSI (obvykle používané s příponou .shtml) byl jeden z prvních způsobů, jakým mohli autoři na stránkách webu vytvářet dynamický obsah. Použitím speciálních tagů ve stránkách se dalo v HTML omezeně skriptovat.
Většina implementací SSI nenastavuje validátory, takže kvůli tomu nejsou kešovatelné. Apačovská implementace ovšem uživateli umožňuje specifikovat, které SSI soubory mohou být kešovány. Dělá se to nastavením práv skupiny na spouštění určitých souborů v kombinaci s XbitHack full directive. Více informací hledejte v dokumentaci k dokumentaci k mod_include.
PHP je serverový skriptovací jazyk, který (pokud je serverem podporován) může být použit na vkládání skriptů do HTML stránek. Dost se to podobá SSI, ale PHP má mnohem větší možnosti. PHP může být na libovolném serveru (Unix i Windows) spouštěno jako CGI, nebo v Apache jako modul.
Ve výchozím nastavení nemají objekty vystupující z PHP přidělené validátory, takže jsou kvůli tomu nekešovatelné. Vývojáři ovšem mohou nastavit HTTP hlavičky požitím funke Header().
Tento příklad vytvoří hlavičku Cache-Control a také hlavičku Expires nastavenou na tři dny do budoucnosti:
<?php
Header("Cache-Control: must-revalidate");
$offset = 60 * 60 * 24 * 3;
$ExpStr = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
Header($ExpStr);
?>
Pamatujte, že funkce Header() MUSÍ předcházet jakémukoliv výstupu.
Jak můžete vidět, HTTP datum pro hlavičku Expires si musíte vytvořit "ručně". PHP nenabízí funkci, která by to za vás udělala. Nejsnazší je samozřejmě nastavit hlavičku Cache-Control: max-age, která je stejně pro většinu situací dostatečná.
Více informací naleznete v sekci manuálu o header.
Také se podívejte na knihovnu cgi_buffer (odkaz přestal fungovat), která pro PHP skripty pomocí jednořádkového zápisu automaticky vytvoří Etag a validaci, Content-Length a gzip Content-Encoding.
Cold Fusion, od firmy Macromedia je komerční serverový skriptovací jazyk, který je podporován několika webovými servery na Windows, Linuxu a na některých druzích Unixu.
V Cold Fusion se nastavení příslušných HTTP hlaviček dělá relativně snadno pomocí tagu CFHEADER. Naneštěstí použití funkcí souvisejících s datem není v Cold Fusion tak jednoduché, jak se dokumentace snaží předstírat. Jejich příklad nastavení hlavičky Expires, jak je vypsáno níže, nefunguje:
<CFHEADER NAME="Expires" VALUE="#Now()#">
Nefunguje to z toho důvodu, že čas (chvíle provádění požadavku) není převeden na platné HTTP datum. Namísto toho je vypsáno jako reprezentace Date/Time objektu v Cold Fusion. Většina klientů takovou hodnotu buď zaignoruje, nebo to převede na výchozí čas, jako třeba 1. ledna 1970.
Funkce na formátování data v Cold Fusion neumožňují snadné vytvoření data, které by bylo pro HTTP platné. Buď musíte kombinovat DateFormat, Hour, Minute a Second, nebo nastavit nějaké svoje datum. Můžete samozřejmě tag CFHEADER stále použít na nastavení Cache-Control: max-age a dalších hlaviček.
Také pamatujte na to, že hlavičky na serveru procházejí nějakými implementačními vrstvami (jako třeba CGI); podívejte se na ty svoje a zjistěte si, jestli tyto vrstvy nemůžete použít ve svůj prospěch tak, že nastavíte hlavičky přímo na serveru, místo abyste je nastavovali v Cold Fusion.
Active Server Pages jsou zabudované do IIS a je také dostupné pro jiné webové servery. ASP vám také umožňují nastavit HTTP hlavičky. Například na nastavení času vypršení (expirace) můžete použít vlastnosti objektu Response:
<% Response.Expires=1440 %>
kde nastavujete počet minut od požadavku do vypršení objektu. Stejně tak může být nastaven absolutní čas vypršení (ujistěte se, že svoje datum formátujete pro HTTP správně) takto:
<% Response.ExpiresAbsolute=#May 31,1996 13:30:15 GMT# %>
Hlavičky Cache-Control mohou být přidány tímto způsobem:
<% Response.CacheControl="public" %>
Když nastavujete v ASP HTTP hlavičky, ujistěte se, že umisťujete volání metody Response před jakýmkoli HTML výstupem, nebo použijte Response.Buffer. Také myslete na to, že některé verze ISS posílají u ASP ve výchozím nastavení hlavičku Cache-Control:private, takže aby se to dalo kešovat na sdílených keších, musí se to přenastavit na public.
V ASP.Net je už objekt Response.Expires zavržený. Správný způsob nastavení kešovacích hlaviček používá Response.Cache:
Response.Cache.SetExpires ( DateTime.Now.AddMinutes ( 60 ) ) ; Response.Cache.SetCacheability ( HttpCacheability.Public ) ;
Více informací hledejte v MSDN documentaci (nefunkční odkaz odstraněn).
Specifikace HTTP 1.1 přináší pro nastavování kešování mnohá vylepšení a je to autoritativní zdroj pro implementaci protokolu. Zaměřte se na sekce 13, 14.9, 14.21 a 14.25.
Výborný úvod do konceptů kešování, odkazy na jiné on-line zdroje. (již nefunkční)
Vyzkoušejte webové stránky, abyste určili, jak budou interagovat s webovými kešemi. Program je dobrým vývojovým nástrojem a tvoří doplněk tohoto návodu.
Jednořádkové zápisy do Perlových CGI, Pythonových CGI a PHP skriptů automaticky zařídí generování Etagu, validaci, vytvoření Content-Length a gzip Content Encoding -- a správně. Pythonovská verze může být také použita jako obal některých CGI skriptů.
This document is Copyright © 1998-2004 Mark Nottingham <[email protected]>. This work is licensed under a Creative Commons License. Czech translation © 2004 by Dušan Janovský <[email protected]>.
Tento dokument je chráněn copyrightem © 1998-2004 Mark Nottingham <[email protected]>. Tato práce je licencována pod Creative Commons License. Český překlad s laskavým svolením autora © 2004 Dušan Janovský <[email protected]>.
Všechny zmíněné obchodní známky jsou vlastnictvím jejich oprávněných držitelů.
Přestože autor (a překladatel) věří, že obsah je v době vydání přesný, nenesou žádnou odpovědnost za obsah samotný, za jeho použití nebo jiné okolnosti vzniklé jeho použitím. Pokud naleznete nepřesnosti, chyby nebo potřebu vysvětlení, prosím kontaktujte neprodleně autora. Chyby v překladu posílejte překladateli.
Aktuální verze tohoto dokumentu je vždy k nalezení na adrese https://www.mnot.net/cache_docs/
Překlad jsem zařadil mezi články na Jak psát web.
Translation of Version 1.60 from February 15, 2004