Na een tiental jaren gewerkt te hebben met Xitami ben ik overgestapt op Abyss. De voornaamste reden was dat Xitami niet meer bijgewerkt werd. Abyss kan niet veel meer dan Xitami (en in mijn geval: zelfs minder, ik heb veel kode moeten herschrijven). Maar Abyss is een compacte webserver, en er worden extra features beloofd. We zitten aan versie 2.5 en versie 2.6 zal native gzip compressie aan boord hebben, een must als je een webserver runt op een gewone internet-aansluiting (met een beperkte uploadsnelheid).

Configuratie van Abyss

Index
Installatie
De download is een installer, zodat je weinig problemen zal ondervinden met de installatie. De server installeert zichzelf als "service" dat automatisch opgestart wordt als de computer start (dus zonder gebruikers-interventie). Mocht de server niet opstarten, gewoon klikken op de executable: die zal een foutboodschap geven waarom ie niet kan starten. meestal is dat omdat de listening port reeds gebruikt wordt door een ander programma. De algemene verschillen tussen Xitami en Abyss worden hier besproken.
Folders
In tegenstelling met Xitami worden er weinig folders aangemaakt. Voor extra mogelijkheden moet je de folders zelf aanmaken.
Bestanden
De root bevat ook heel weinig: het programma, en de configuratiefile in XML-formaat. In tegenstelling met een ini-file is de configuratiefile van Abyss niet gemakkelijk te wijzigen en ben je aangewezen op de console. Bij Abyss zitten alle configuratieparameters in één configuratiefile. Bij Xitami wordt er met een standaard-file gewerkt (dat de default-waarden bevat), en extra configuratiefiles die enkel de verschillen ten opzichte van de default moeten bevatten. Meestal zal je één extra configuratiefile nodig hebben voor de standaard-host, en één configuratiefile voor iedere virtuele host, waarbij hier ook de config-file enkel de verschillen bevat ten opzichte van de parent config. Dit vormt een automatisch vangnet, bij het verwijderen van een parameter kom je automatisch terug op de default-configuratie. Bij herinstalleren van Xitami wordt enkel de default-file opnieuw aangemaakt: wijzigingen blijven dus behouden.

Een CGI-directory kan enkel aangemaakt worden in de webpages-directory: je bent dus verplicht een CGI-directory aan te maken voor iedere VHOST. Dit is een beperking van Abyss. Het gebeurt soms dat Abyss de kluts kwijt is en in plaats van de resultaat van de script-aanroep door te geven de script zelf doorstuurt, wat een duidelijke security breach is.

Een ander probleem is dat Abyss problemen heeft met pipelining (verschillende bestanden over eenzelfde verbinding sturen). In de praktijk betekent dit dat als je pagina veel elementen bevat (meerdere CSS aanroepen, verschillende externe javascripts en veel grafische elementen) je sommige elementen niet krijgt. Dit gebeurt het meest als compressie ingeschakeld wordt, of als de pagina opgemaakt wordt met een cgi-aanroep. Het is browser-afhankelijk, want Internet Explorer schakelt blijkbaar pipelining automatisch uit als het merkt dat de server deze mogelijkheid niet aankan.


CGI
Bij CGI moet er communicatie zijn met de gebruiker. De gebruiker zal bijvoorbeeld een formulier invullen. De script verwerkt het formulier en stuurt een resultaat. Xitami kan zowel met files als met pipes werken voor zijn input/output met de user, Abyss kan enkel werken met pipes.

Werken met files is betrouwbaarder, het zit ingebakken in het systeem (en je kan altijd een "dump" vragen, dat wil zeggen dat de files niet automatisch door Xitami gewist worden na het uitvoeren van de script. Pipes zijn afkomstig van de Unix wereld en de implementatie in Windows is maar gebrekkig. Maar pipes werken sneller, en de output wordt direkt naar de gebruiker gestuurd, de webserver wacht niet totdat de script afgelopen is.

XitamiAbyss
Inlezen van de data
OPEN ENVIRON$("CGI_STDIN") FOR BINARY AS #1
GET$#1, LOF(1), a$: CLOSE #1

De input zit in een file dat ingelezen wordt
STDIN LINE a$
De stream wordt in één keer ingelezen. Opgelet, er zitten bugs in windows, waardoor het werken met pipes niet vanzelfsprekend is.
Bij beide webservers wordt de input url-gecodeerd doorgegeven: je zal de data moeten decoderen voor je er iets mee kan doen. Dit is een standaard-formaat van de webbrowser, en dezelfde decoderingsalgeritme kan dus gebruikt worden.
Output van de html
OPEN ENVIRON$("CGI_STDOUT") for output as #3
PRINT #3, ...
PRINT #3, ...
CLOSE #3

Xitami ondersteunt zowel klassieke html-output (de output is een gewone webpagina) als NHP-output (Non Parsed Headers): de script schrijft zelf de headers.
STDOUT "HTTP/1.1 200 OK"
STDOUT "Content-Type: text/html"
STDOUT
STDOUT ... data ...

Bij Abyss moet je minstens de statuscode eerst doorsturen, anders geeft de script een 500- Server error door aan de browser. Per definitie ondersteunt Abyss dus niet de gewone klassieke HTML output. De gegenereerde output is dan meestal ook niet 100% compliant, want je hebt (in de meeste gevallen) geen Content-length-header voorzien!

Xitami probeert alles uit te voeren dat in zijn executable directory staat. Bij klassieke exe-files moet je zelf de extensie niet vermelden, wat de veiligheid van het systeem ten goede komt (de bezoeker weet niet welk soort programma uitgevoerd wordt).
<a href=/cgi-bin/forum>Bezoek ons forum</a>
is dus een geldig aanroep voor een executable (forum.exe) dat in de cgi-directory gelegen is.

Bij Abyss moet je de volledige naam van de executable geven. De aanroep wordt dus:
<a href=/cgi-bin/forum.exe>Bezoek ons forum</a>
Overgaan van Abyss naar Xitami is dus gemakkelijker dan omgekeerd!

Index

Individuele landingspage bezoekers: