WWW, HTTP servery

Ondřej Výborný, xvyborny@fi.muni.cz


Obsah


HTTP protokol

Protokol http (HyperText Transfer Protokol) je protokolem aplikační vrstvy (vlastní přenos zajišťují nižší vrstvy), který slouží ke komunikaci mezi klientem a WWW serverem. Definuje tvar dat, která jsou přenášena, a pravidla dotazů a odpovědí komunikujících stran. Obvykle je spuštěn na portu 80.

První verze protokolu, HTTP 0.9, byla velmi jednoduchá a sloužila pouze k posílání dat po Internetu bez dalších informací o jejich obsahu a klient musel podle přípon odhadovat, o jaký typ dat se jedná. Zpočátku to postačovalo, jelikož přenášenými daty byly jen textové a hypertextové dokumenty, ale jakmile se začal protokol používat i k přenosu obrazových, zvukových a dalších typů dat, bylo nutné protokol upravit. Problémy byly nejen s obtížným určováním typu dat, ale také s neznalostí jejich celkové velikosti během přenosu (klient musel číst, dokud server neukončil spojení a nevědě, jak dlouho to bude trvat), či zjišťováním poslední aktualizace dokumentu (toto protokol neumožňoval a tak musel klient daný dokument vždy znovu stáhnout, pokud chtěl mít jistotu, že je aktuální).

V následující verzi (HTTP 1.0, RFC 1945) byl formát dotazu a odpovědi doplněn podle standardu MIME (Multipurpose Internet Mail Extension, RFC 1521) o hlavičky, popisující typ a atributy přenášených dat, další hlavičky obsahují pomocné informace či parametry předávané mezi klientem a serverem.

S rozvojem Internetu se oběvovali další požadavky na http protokol, jako jsou hierarchická struktura proxy, využívání cache, trvalé spojení mezi klientem a serverem, nebo požadavky na virtuální servery. Tyto požadavky řeší další verze protokolu, HTTP 1.1 (RFC 2068).


Jak HTTP funguje?

Existence různých protokolů sebou přináší problémy s kompatibilitou. Pokud máme server podporující novější verzi protokolu a staršího klienta (nebo naopak), mohou nastat problémy. Proto se zavedlo rozlišování verze protokolů na straně klienta připsáním této verze za jméno požadovaného souboru a na straně serveru u novějšího protokolu připsáním řetězce "verze_protokolu kód_odpovědi" na první řádek odpovědi.

Popíšeme si zde základní principy protokolů verze 1.0 a 1.1:

HTTP 1.0

Tento protokol je založen na modelu dotaz - odpověď. Klient pošle na server dotaz, server mu odpoví a ukončuje komunikaci. Pro získání dalších dat musí klient navázat nové spojení. Uchovávání všech informací, souvisejících s komunikací (jako která data už klient požadoval a podobně) jsou ponechaána zcela na klientovi a tento protokol je tedy bezstavový.

Pokud chce klient získat od serveru server soubor, odešle dotaz ve tvaru:

GET /cesta/soubor HTTP/1.0

Server mu jako dpověď pošle tento soubor, nebo chybové hlášení. V dotazu se nespecifikuje jméno ani adresa serveru. IP adresa je používána protokolem nižší vrstvy a protokol http pracuje na již navázaném spojení.

HTTP 1.1

HTTP 1.0 přináší několik rozšíření. Jde zejména o možnost trvalého spojení mezi klientem a serverem (V předchozích verzích bylo pro každé URL navazováno zvláštní TCP spojení, což například u obrázků vložených do html stránky výrazně zvyšovalo zatížení serveru). Při trvalém spojení (které je u verze 1.1 implicitní pro všechny HTTP spojení) posílá klient všechny dotazy na daný server po tomto spojení server mu po něm vrací všechny odpovědi. Spojení se ukončuje zasláním hlavičky Contention:close. Požadavek obsahující tuto hlavičku je poslední na daném spojení. Všechny požadavky poílané při trvalém spojení musí mít definovanou délku v hlavičce Message-length. Je také umožněno zřetězené zpacování, při kterém klient, který podporuje trvalé spojení, může dotazy zřetězit a posílat je serveru, aniž by čekal na odpověď. Server pak musí odpovědi na tyto dotazy zasílat v pořadí, ve kterém je obdržel.

Dalším rozšířením je používání virtuálních serverů. Ve verzi 1.0 se předpokládalo, že každé IP adrese patří jeden WWW server a proto s pojmy IP adresa či jméno počítače nepracoval. HTTP 1.1 zavádí hlavičku Host. Pokud tato hlavička chybí, vrací chybu. Server pomocí této hlavičky může na různá jména počítače vracet různé odpovědi.

Verze 1.1 zavádí také tzv. vyjednávání o obsahu. Snží se na dotaz vrátt dokument, který by nnejlépe odpovídal požadavkům klienta (pokud tedy existuje více variant, například různé kódování dokumentu, komprese apod.). Pro tuto službu poskytuje protokol 1.1 dva mechanismy. Serverem řízené dohadování pracuje na straně serveru a vychází z informací, ketré server získá z hlaviček dotazu (tyto hlavičky jsou Accept, Accept-Charset, Accept-Encoding, Accept-Language, User-Agent). Při klientsky řízeném dohadování vybírá nejlepší variantu klient po obdržení první odpovědi od serveru. V odpovědi sjou v hlavičce Alternates nebo v tele odpovědi jako seznam URL uvedeny existující varianty dokumentu. Aby klient získal požadovný dokument, je potřeba provést druhý dotaz (což lze brát jako nevýhodu tohoto přístupu).


Metody protokolu HTTP

Metoda je druh služby, kterou klient od serveru požaduje, píše se velkými písmeny. Server nemusí všechny metody podporovat a při dotazu na nepodporovnaou metodu pak vrací chybovou hlášku. Metody jsou:
OPTIONS
Metoda OPTIONS představuje dotaz na možnosti komunikace spojené s uvedeným URL. Metoda umožňuje klientovi určit možnosti a omezení spojené se zdrojem nebo schopnostmi serveru. Pokud je URL v dotazu ve tvaru "*", pak se jedná o dotaz na možnosti serveru jako celku.
GET
Metoda GET představuje požadavek na poslání dokumentu určeného pomocí URL. V souvislosti s proxy se může metoda GET změnit na "podmíněný GET", který požaduje poslat dokument pouze za určitých podmínek definovaných v hlavičce dotazu.
HEAD
HEAD metoda je identická s metodou GET, server však nemusí posílat tělo odpovědi. Metodu je možné použít k získání doplňkových informací o dokumentu. Často se používá k testování hypertextových linek, jejich dostupnosti a poslední modifikace. Klient může získané hlavičky analyzovat a případně požádat o data novým dotazem GET.
POST
POST metoda se používá v případě, kdy má cílový server přijmout data z požadavku. Skutečná funkce metody závisí na URL s ní spojené. Výsledkem POST metody může být poslání mailu, předání dat do procesu, který data zpracuje, rozšíření databáze. Posílaná data nejsou nijak omezena a je možné v hlavičkách tělo zprávy popsat.
PUT
PUT metoda představuje požadavek na uložení posílaných dat pod specifikované URL na server. Takto uložená data budou dostupná např. následnými dotazy GET. Metoda PUT předpokládá, že uložení dat do souboru na server provádí přímo server a nikoli externí aplikace (CGI program).
DELETE
Požadavek na zrušení dokumentu na serveru. Rušený dokument je specifikován v URL.
TRACE
Metoda použitá k testování originalního serveru. Originalní server má vrátit klientovi kladnou odpoveď bez dat.

Formát dotazu a odpovědi

Každý dotaz odesílaný na server obsahuje dotazový řádek, hlavičky blíže popisující dotaz, prázdný řádek a tělo dotazu (které může být prázdné):

GET /index.html HTTP/1.0
Accept: text/html
Accept: image/gif
  * prazdny radek *
Odpovědi jsou zasílány se stavovým řádkem, hlavičkami popisujícími odpověď, prázdným řádkem a tělem odpovědi:

HTTP/1.0 200 OK
Server: Netscape-Enterprise/2.0a
Date: Thu, 06 Mar 1997 16:23:43 GMT
Accept-ranges: bytes
Last-modified: Fri, 22 Dec 1995 17:41:00 GMT
Content-length: 1032
Content-type: text/html

<HEAD>
    <TITLE> Obrazky ze sveta  </TITLE>
</HEAD>

<BODY>
<BODY BACKGROUND="/images/back1.gif" TEXT="#000000"

<H1><P ALIGN=CENTER> <B><I>
<FONT SIZE=+3>Obrazky ze sveta</B></H1>
</I></P> ....

Příklad záporné odpovědi:

HTTP/1.0 404 Not found
Server: Netscape-Enterprise/2.0a
Date: Thu, 06 Mar 1997 16:12:04 GMT
Content-length: 207
Content-type: text/html

<TITLE>Not Found<TITLE><H1>Not Found</H1>
The requested object does not exist on
this server. The link you followed
 is either outdated,
inaccurate, or the server
has been instructed not to let you have it.


Hlavičky protokolu HTTP

Vycházejí ze standardu MIME. Jejich syntax je následující:

název hlavičky: hodnota[;parametr=hodnota]

kde parametry jsou nepovinné a používají se jen u některých hlaviček. Každá hlavička začíná na novém řádku. Příklad:

Content-type: text/html; charset=ISO-8859-1
Content-lenght: 1032

Hlavičky mohou být obecné (univerzální informace o zprávě), dotazů a odpovědí, nebo těla (popis těla zprávy). Na jejich pořadí nezáleží, ale je doporučeno je dělit podle těchto kategorií v uvedeném pořadí.

Obecné hlavičky: Date, Pragma, Mime-version. U verze 1.1 jsou přidány hlavičky Connection, Transfer-Encoding, Via.

Hlavičky dotazu: Authorization, From, If-Modified-Since, Referer, User-Agent. U verze 1.1 jsou přidány hlavičky Accept, Host, Accept-Charset, Accept-Encoding.

Hlavičky odpovědi: Location, Server, WWW-Authenticate. U verze 1.1 je přidána hlavička Retry-After.

Hlavičky těla: Allow, Expires, Last-Modified, Content-Encoding, Content-Length, Content-Type. U verze 1.1 je přidána hlavička Content-Range.


Výsledkové kódy

Dělí se do pěti skupin podle své první číslice:
1xx - informační - Požadavek byl obdržen.
100 Continue
Klient může pokračovat v posílání požadavku. Jde o meziodpověď od serveru. Po obdržení celého požadavku ho server začne obsluhovat a pošle konečný výsledkový kód.
101 Switching Protokols
Server rozuměl požadavku a mění protokol podle specifikace v hlavičce Upgrade.

2xx - úspěch
200 OK
Dotaz byl obsloužen bez chyb. Server posílá odpověď.
201 Created
Výsledkem zpracování dotazu bylo vytvoření nového objektu, který lze identifikovat pomoci URL. URL vytvořeného dokumentu je posíláno v těle odpovědi.
202 Accepted
Dotaz byl přijat, jeho zpracováni však dosud neskončilo. Klient nemusí čekat na dokončení.
203 Non-Autoritative Information
Vrácené meta informace nejsou poslané z originalního serveru.
204 No Content
Dotaz byl akceptován a v pořádku obsloužen, nevznikla však žádná data, která by server klientovi poslal.
206 Reset Content
Server obsloužil požadavek a klient má nastavit původní obsah dokumentu, ktery předpokláda vloženi uživ. dat.

3xx - přesměrování - Klient musí provést další akce, aby získal požadovaný dokument.
300 Multiple Choices
Požadovaný dokument je dostupný na několika místech, klient musí vybrat jeden z dokumentů a znovu vyslat dotaz.
301 Moved Permanently
Objekt byl trvale prestěhován na nové URL (server je oznámí v hlavičce Location). Klient se musí zeptat na novém místě.
302 Moved Temporarily
Objekt byl dočasně přesunut jinam. Klient se musí obrátit na nové místo, neměl by si však například přepisovat URL objektu ve svych záložkach, protože přemístění je jen dočasné.
303 See Other
Odpověď je dostupná na jiném URL. Není však náhradou za URL původní.
304 Not Modified
Server odpoví tímto kódem, pokud klient poslal podmíněný dotaz GET na dokument, který má uložený v cache a odpovídající dokument na originalním serveru nebyl modifikován.
305 Use Proxy
Požadavek musí být znovu poslán prostřednictvím proxy uvedené v URL.

4xx - klientova chyba - Klient položil chybný dotaz nebo nemá oprávnění získat dokument požadovaný v dotazu.
400 Bad Request
Chybná syntax dotazu.
401 Unauthorized
Obsloužení dotazu je vázáno na určité identifikační požadavky, které klient nesplnil.
402 Payment Required
Tento kód je rezervován pro budoucí použití.
403 Forbidden
Server má od správce zakázáno odpovídat na dotaz.
404 Not Found
Objekt s požadovaným URL neexistuje. Tento chybový kód je nejčastější. Příčinou může být buď překlep v URL, nebo zánik objektu.
405 Method Not Allowed
Použitá metoda neni pro uvedené URL povolena.

5xx - chyba serveru - Server není z nějakého důvodu schopen obsloužit požadavek.
500 Internal Server Error
Během zpracování dotazu došlo v programu serveru k blíže neurčené chybě.
501 Not Implemented
Server nepoznal metodu, kterou je poslán požadavek.
502 Bad Gateway
Chybu 502 pošle zprostředkující server, pokud na váš dotaz dostal od původního serveru špatnou odpověď.
503 Service Unavailable
Server momentálně nedokáže váš dotaz obsloužit - například je přetížen, nebo právě probíhá jeho údržba.
504 Gateway Timeout
Server pracující s proxy nebo gateway nedostal včas odpověď, aby mohl vyřdit váš požadavek.
505 HTTP Version Not Supported
Server nepodporuje verzi protokolu použitou v požadavku.

Server Apache

Projekt Apache (A PAtCHy server) vznikl v letech 1995 z v té době nejužívanějšího serveru httpd, terý byl vyvíjen v NCSA (National Center for Supercomputing Applications) na univerzitě v Illinois. V té době se server httpd příliš nevyvíjel a správci sítí si pro své potřeby vytvářeli k httpd mnoho patchů, protože nároky uživatelů Internetu rychle rostly. Skupina těchto spráců se rozhodla, že z původního httpd 1.3 a těchto patchů vytvoří nový HTTP server (odtud název apache). První verze, 0.6.2 vyšla v dubnu 1995. V té době NCSA začalo opět vyvíjet svůj httpd a po dohodě o společném vývoji obě organizace spolupracují.
Od verze 0.8.8 změnil dosavadní strukturu a dal přednost modulární. První "úplná" verze (tj. s plnou dokumentací, otestovaná,...), 1.0, byla vydána v prosinci 1995. Od roku 1996 je to podle netcraft.com ve světě vůbec nejpoužívanější sever, který podporuje velkou většinu operačních systémů (Unixu, OS/2, Windows, Netware 5.x). Další informace o serveru Apache lze nalézt na jeho domovské stránce apache.org.

Instalace a kofigurace

Momentálně jsou vyvíjeny dvě verze serveru apache - 1.3 (poslední je 1.3.29) a 2.0 (2.0.48). Moduly vyvíjené pro verzi 2.0 nejsou spětně kompatibilní s verzí 1.3.

Instalace

Pro instalaci Serveru Apache nejdříve stáhneme námi požadovanou verzi z www.apache.org a po rozbalení zdrojových kódů můžeme instalovat (je také samozřejmě možné instalovat Apache pomocí rpm balíčků Vaší oblíbené distribuce). Použijeme klasický postup
$ ./configure --prefix=PREFIX
$ make
$ make install
$ PREFIX/bin/apachectl start
Apache je nyní nainstalován v adresáři PREFIX, což je implicitně /usr/local/apache.
Při konfiguraci můžeme použít přepínače, které zjistíme pomocí
$ ./configure --help
důležité jsou zejména:
  --enable-module=NAME     Povolí modul jménem NAME
  --enable-shared=NAME     Modul jménem NAME povolí zkompilovat jako zaveditelný DSO modul
Moduly můžeme zkompilovat do jeho jádra (jsou pak rychlejší, ale při zavádění novější verze tohoto modulu musíme překompilovat celé jádro), nebo jako DSO (Dynamic Shared Object) moduly (pouští se při startu apache, jejich výhodou je flexibilita a snadné rozšíření o další moduly, nejsou však použitelné na všech platformách a zpomalují lehce start Apache).
Chceme-li moduly zkompilovat jako DSO moduly, musíme nainstalovat modul so(staticky) a pomocí parametru --enable-shared=MODUL uvedeme modul(y), který chceme zkompilovat jako DSO. Pokud chceme takto zkompilovat všechny moduly, použijeme parametr --enable-shared=max. Tím se všechny povolené moduly zkompilují jako DSO. Jestliže nechceme některý z nich zkompilovat jako DSO, stačí použít parametr --disable-shared=MODUL a on se zkompiluje staticky.
Pro modul který není součástí balíku, ale chceme ho zkompilovat s ostatními, použijeme parametr --activate-module=cesta_k_modulu/modul, případně parametr --add-module=cesta_k_modulu/modul, záleží na dokumentaci k tomuto modulu. Nějaký příklad kompilace:
./configure --prefix=/www --enable-module=all --enable-shared=max
make
make install
Zapne všechny moduly a zkompiluje je jako DSO. Instalace bude provedena do adresáře /www

Konfigurace

Hlavním konfiguračním souborem Apache je /PREFIX/etc/httpd.conf, ve kterém máme direktivy rozdělené do tří částí:
Poznámka: Pokud při nastavování cesty k souborům začneme tuto cestu "/", bude se brát explicitně tato cesta. Pokud "/" neuvedeme, doplní se před cestu hodnota proměnné ServerRoot.
Dalšími konfiguračními soubory Apache jsou access.conf a srm.conf
Příklady proměnných v httpd.conf:
ServerType - standalone - server je spouštěn samostatně
ServerRoot - cesta ke konfiguračním souborům
ServerName - jméno serveru
ServerAdmin - root@server
DocumentRoot - cesta ke kořenovému adresáři s dokumenty
ErrorLog - logs/error_log --cesta, kde se mají ukládat chybové hlášky Apache
LogLevel - nastavení priority logů (stejně jako u syslogu)
AccessFileName - jméno souboru, který se má v každém adresáři hledat kvůli povolení přístupu (typicky .htaccess)
Timeout - počet sekund do vypršení času
MaxClients - maximální počet klientů
Listen - adresa a port, na kterém server poslouchá
AddModule - aktivace načtených modulů,příp. zakompilovaných v apache
LoadModule - načtení modulů dynamických (např. LoadModule proxy_module modules/ApacheModuleProxy.dll)
httpd.conf je velmi dobře okomentován, takže zde nebudu vypisovat všechny jeho proměnné. Dále musíme definovat adresáře a jejich "práva":
Directory - označuje určitou skupinu, pro kterou budou platit nějaké pravidla (Options)
Options může nabývat hodnot:
None - žádné zvláštní práva a omezení
All - povoluje se vše kromě MultiViews - výchozí volba
ExecCGI - povoleno spouštění cgi skriptů
FollowSymLinks - server se bude odkazovat na symbolické linky v tomto adresáři
Indexes - pokud server nenajde soubor definovaný v DirectoryIndex
(většinou index.html, index.htm, index.php), je povolen výpis daného adresáře
Includes, IncludesNOEXEC, MultiViews, SymLinksIfOwnerMatch
Příklad:
<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>
Tyto volby povolují pouze odkazovat na symbolické odkazy a vypsat adresář při nenalezení DirectoryIndex. Např. uživatel z tohoto adresáře nemá právo spustit cgi skript.

Virtuální servery

Apache umožňuje, aby na jednom stroji běželo více serverů najdenou. Rozlišovat je můžeme pomocí jejich jmen (mají stejnou IP adresu), nebo jejich IP adresy (mají stejné jméno). Nastavování virtuálních serverů se dělá pomocí <VirtualHost> a </VirtualHost>. Budeme-li virtuální servery rozlišovat pomocí jejich jmen, je třeba jim přiřadit alespoň jednu IP adresu:

NameVirtualHost 192.164.100.5        // IP adresu lze v tomto případě nahradit "*"
<VirtualHost 192.168.1.11>
         ServerAdmin admin@web1.cz
         DocumentRoot /doc/web1
         ServerName www.web1.muj.cz
</VirtualHost>
<VirtualHost 192.168.1.11>
         ServerAdmin admin@web2.cz
         DocumentRoot /doc/web2
         ServerName www.web2.muj.cz
</VirtualHost> 
Server může mít i více jmen, např. uvedu-li direktivu <ServerAlias> neco.cz *.neco.cz v definici prvního virtuálního hostitele, bude každý požadavek na doménu neco.cz obsloužen tímto virtuálním serverem. Samozřejmě musí být také správně nakonfigurován DNS server, aby mapoval tato jména na nějakou IP adresu spojenou s naším serverem.

SSL vrstva

Proč se vůbec pokoušet rozběhat https protokol vedle standardního http? Důvod je jasný, jde o bezpečnost přenosu dat mezi serverem a prohlížečem, protože po protokolu http probíhá přenos nešifrovaně, pouze jako holý text. Naproti tomu protokol https šifruje data pomocí šifrovací vrstvy SSL (Secure Socket Layer). Příkladem může být přenos důvěrných dat např. číslo VISA karty, spojení s bankou či spojení s internetovým informačním systémem podniku nebo školy, vybírání pošty pomocí skriptů které spolupracují s jinak nešifrovaným protokolem POP3 a celá řada dalších. Vrstva SSL pracuj na principu symetrické kryptografie, využívá tedy jeden symetrický klíč. K jeho získání musí klient navázat spojení se serverem a po výměně informací o verzi SSL je pomocí veřejného klíče serveru vytvořen session_key, který je používán k další komunikaci. Abychom mohli používat v Apachi SSL, potřebujeme nějakou kryptovací knihovnu (nejlépe OpenSSL a přidat modul mod_ssl.
Instalace probíhá následovně (příklad): Stáhneme si mod_ssl a openssl,
$ cd openssl-0.9.7c                      # zkompilujeme OpenSSL
$ ./config
$ make
$ cd ../mod_ssl-2.8.16-1.3.29            # vytvoříme Apache s SSL
$ ./configure \
    --with-apache=../apache_1.3.29 \
    --with-ssl=../openssl-0.9.7c \
    --prefix=/usr/local/apache
$ cd ..
$ cd apache_1.3.29
$ make
$ make certificate
$ make install
Nyní máme certifikát, který jsme si sami podepsali, což není z hlediska důvěryhodnosti úplně ono. Lepší je vygenerovat si vlastní klíč a žádost o certifikát a tu poslat certifikační autoritě. Získaný certifikát pak implementovat do Apache.
$ openssl genrsa -des3 -out mujserver.key 2048
$ openssl req -new -key mujserver.key -out mujserver.csr
Pak by se Apache zkompiloval následovně:
...
$ cd ../mod_ssl-2.8.11-1.3.27
$ ./configure --with-apache=../apache_1.3.27 \
   --with-ssl=../openssl-0.9.6g \
   --with-crt=/cesta/k/mujserver.crt \
   --with-key=/cesta/k/mujserver.key \
   --prefix=/path/to/apache
...
SSL nakonfigurujeme v httpd.conf:
Port - port vyhražený pro SSL je 443
SSLCertificateFile - určuje cestu k veřejnému certifikátu serveru
SSLCertificateKeyFile - určuje cestu k tajnému klíči serveru
SSLEngine on - povoluje SSL
Apache pak spustíme příkazem:
$ PREFIX/bin/apachectl startssl

Apache_ssl

Apache_ssl je patch zdrojových kódů k Apache serveru a nelze ho tedy zaměňovat s mod_ssl (což je modul). Po rozbalení stáhnutého aktuálního patche (v adresáři se zdrojovými soubory Apache) upravíme pomocí skriptu ./FixPath zdrojové soubory Apache. Poté následuje klasické ./configure --parametry && make Po zkompilování je nutné vytvořit (pokud je již nemáte vytvořené předem) příkazem cd src; make certificate certifikáty a příkazem make install server nainstalovat. Úprava httpd.conf není tak jednoduchá jako u mod_ssl a je dobré držet se pokynů v README.SSL a přiložené dokumentaci.
Pokud použijeme Apache_ssl, máme server, který sám o sobě podporuje ssl bez nutnosti přidávat další moduly. Pro mod_ssl hovoří častější aktualizace.

CGI skripty

CGI skripty jsou programy, spouštěné na straně serveru, jejichž výstup je poté předán klientovi. Abychom je mohli použít, musíme upravit konfiguraci httpd.conf:
LoadModule cgi_module modules/mod_cgi.so # nahrání modulu pro cgi
AddModule mod_cgi.c                      # jeho aktivace
AddHandler cgi-script .cgi               # přípony cgi považuj za cgi skripty
ScriptAlias /cgi-bin/ "/var/www/cgi-bin" # pokud zavoláme cgi skript pomocí http://server/cgi-bin, bude nás to odkazovat na absolutní adresu daného stroje /var/www/cgi-bin
Je třeba také přidat možnost spouštět tyto skripty danému adresáři:

<Directory "/var/www/cgi-bin">
Options +ExecCGI
</Directory>

Alternativní servery

Další servery, které se používají (byť v daleko menším počtu) jsou například Tux, Roxen, Zeus.
Roxen je open-source server distribuovaný pod GPL licencí. Podporuje několik operačních systémů (windows, linux, solaris, Mac OS X). Konfigurace a administrace je prováděna pomocí internetových prohlížečů. Architektura nezávislá na platformě umožňuje snadné přenášení modulů. Roxen obsahuje MySQL databázi, umožňuje spouštět programy v RXML, Jave, Perlu, PHP, CGI a dalších.
TUX (Threaded linUX http layer) je kernelový http server. Je velmi rychlý, čehož dosahuje cachováním na síťové vrstvě a voláním CGI skriptů přímo z jádra. Bližší informace o jeho funkcích najdete zde.
Zeus je kromě jiného komerční webový server, který je rychlý, velmi bezpečný a spolehlivý (alespoň to o něm tvrdí jeho tvůrci ;). Používá ho například eBay. Administrace je také prováděna pomocí webového rozhraní a podporuje mnoho progamovacích jazyků.