Ebben a fejezetben a Webszerver konfigurációt általánossan tekintjük át, nem túl részletesen, inkább csak a fogalmak tisztázására, hogy ezt elolvasva az éppen alkalmazni akart Webszerver dokumentációja sokkal könyebben érthető legyen. Mivel azonban nem sok értelme lenne egy hipotetikus Webszerver konfigurációját tárgyalni, ezért úgy döntöttem, hogy két Webszerver szoftvert választok példának: az Apache-t, mert ezt használják a legtöbben, és az IIS-t mert ezt ismerem a legjobban, és ez alapján tudom a fogalmakat legjobban elmagyarázni.
Megjegyzés gyakorlott cgi programozóknak:
Tudom, hogy néhány mondat ebben a fejezetben kissé pongyola. Ez direkt van így, a túlzott precizitás néhol megzavarhatja a kezdő olvasót. Arra azért törekedtem, hogy hibás dolgot ne írjak le, legfeljebb egyszerüsítetten írok le dolgokat. Ha úgy gondolod, hogy valamit rosszul írtam le, mindenképpen szóljál.
Ahhoz, hogy egy CGI program fusson a Webszervernek azt el kell indítani. CGI programokat nem lehet lokálisan ellenőrizni olyan módon, mint HTML fájlokat, vagy Java, Java Script programokat. A CGI-hez Webszerver szoftver kell. Természetesen ez a szerver lehet ugyanazon a gépen Linux, WindowsNT Workstation, vagy akár Windows95 (esetleg szinte bármilyen más) operációs rendszer alatt, amelyik előtt a tesztelő ül. De nem lehet úgy betölteni a böngészőbe, ahogy egy HTML vagy GIF fájlt.
A Webszerver minden egyes http kérésre egy http választ ad. Ez a válasz úgy alakul ki, hogy
A Webszerver két dologról tudhatja, hogy egy fájl futtatandó CGI. Az egyik a fájl kiterjesztése, a másik pedig az, hogy melyik könyvtárban van, esetleg mindkettőről. A Microsoft IIS Webszerver programja grafikus felületen konfigurálható az Internet Service Manager programmal. (Természetesen bele lehet nyúlni a registry-be is, de nem ajánlott. Néha azonban kell, majd erről is lesz pár szó.) Ebben az anyagban az IIS3.0 webszervert vettük alapul. A szerver 4.0 verziójára a konfigurálása lényegesen változott, sokkal több mindent lehet állítani, sokkal összetettebb, és bonyolultabb. Ezért az IIS3.0 sokkal jobb egyszerű példának az alapfogalmak megértéséhez.
Ebben a programban lehet beállítani, hogy az egyes virtuális könyvtárakhoz, a diszken mely könyvtárak tartozzanak, és az egyes könyvtárak milyen tulajdonságúak legyenek. Első példaképp nézzük meg, hogy mit mond a gépemen a konfigurációs szoftver a /test virtuális könyvtárról:
A könyvtárhoz rendelt könyvtár a diszken a c:\InetPub\w3root könyvtár, és olvasási hozzáférése van a webszervernek, futtaási joga nincs. Ez azt jelenti, hogy minden olyan URL, amelyet a gépemen tesztelés közben úgy kezdek, hogy http://localhost/test/ egy fájlt fog visszadni (vagy hibajelzést), de nem indít el semmilyen cgi programot.
Most nézzük meg ugyanezt a /Scripts virtuális könyvtárra:
Látható, hogy itt csak futtatási hozzáférést kap a webszerver, még véletlenül sem küldheti le az itt található programok szövegét a böngészőnek. Ha ebben a könyvtárban egy futtatható exe fájl van, akkor azt elindítja, átadja neki a megfelelő cgi paramétereket környezeti változókban és a szabványos bemenetén, és a program szabványos kimenetéről érkező szöveget küldi vissza a böngészőnek.
UNIX alatt elég egyszerű a dolog, és fel sem merül az, ami NT alatt, hogy hogyan kell elindítani egy programot. Ott ebből a szempontból nincsen különbség exe és Perl, bat, tcl vagy bármilyen más script fájl között. Ott a rendszer felismeri a futtaható fájlokat, a scriptek első sora pedig #!/user/bin/sh alakú, amely megmondja, hogy a scriptet a /usr/bin/sh programmal kell futtatni.
Az NT ezt nem így csinálja. Ott a kiterjesztéshez van hozzárendelve a kezelő program, és a kiterjesztésből tudja, hogy ez egy Perl program, tcl, bat vagy valami más.
Az IIS esetében a kiterjesztések végrehajtó programhoz való rendelése nem ugyanaz, mint amit a fájlkezelőben megadhatunk!!! A script programok, és a kiterjesztések összerendeléséhez a registry-ben kell állítani paramétereket, illetve az IIS4.0-tól a menedzsment felületen kell az összerendelést megtenni.
Ez azt jelenti, hogy ha például egy Perl program forrására duplán rákkatintunk, és az gyönyörűen elindul egy DOS ablakban, és kiírja amit kell, attól még az IIS nem fogja tudni, hogy mit kezdjen vele. Szerencsére azonban az ActiveState Perl implementációja Windows NT alatt installáláskor automatikusan elvégzi a registry beállítást. Ez konkrétan azt jelenti, hogy a
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap
registry könyvtárban a .pl kulcshoz a C:\Perl\bin\Perl.exe %s %s vagy a C:\Perl\bin\PerlIS.dll értékek vannak rendelve attól függően, hogy az igazi CGI Perl futtatót akarjuk-e használni a pl kiterjesztésű fájlok futtatásához, vagy a gyorsabb, és Perl forrásszinten szintén CGI-ként működő, de új processzt nem indító ISAPI filterként megvalósított Perl interpretert. (És természetesen feltételezve, hogy a Perl éppen a C:\Perl könyvtárba lett installálva.)Az Apache webszerver esetén a virtuális könyvtárakat illetve azt, hogy azokat letöltendő, vagy futtatandó fájlok lelőhelyéül kell-e értelmezni a vi menedzsment szoftver segítségével lehet állítani. (bocs) A szövegszerkesztővel a httpd.conf és fájlokat kell szerkeszteni, és a szerkesztés után a webszervert a kill -s HUP xxx paranccsal lehet rávenni, hogy a konfigurációs fájljait újraolvassa, ahol xxx a httpd processz pid-je. Ha több ilyen is van, akkor lehet mindegyiknek HUP-olni (sport), vagy csak a legkisebb sorszámút is elég. (azért később még részletesebben is írok az Apache-ról.)