-

-

Installatie

Folders

In tegenstelling met Xitami worden er weinig folders aangemaakt. Voor extra mogelijkheden moet je de folders zelf aanmaken.

• console De console folder bevat alle grafische elementen van de console (de web interface waarmee je het programma aanpast).
• docs Dit is de documentatiefolder
  
• htdocs Dit is de default "webpages" folder. Het is aangeraden een aparte folder te gebruiken (liefst op een andere partitie), zodat als je de windows opstartpartitie hebt moeten herinstalleren (met verlies van alle data) de websites toch blijven bestaan
• lang Bevat de vertalingen van de belangrijkste configuratieschermen (console)
• log Bevat de server logs. Zoals bij de meeste servers zijn de logfiles continu in gebruik zolang de server draait: de files kunnen dus niet automatisch geroteerd worden (wat bij Xitami wel mogelijk is). Je moet de service stoppen, de files hernoemen en de service herstarten
  NET STOP AbyssWebServer
  Ren *.log *.txt
  NET START AbyssWebServer
  door middel van een taak dat iedere dag om middernacht uitgevoerd wordt.

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

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.

Xitami	Abyss
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!

Individuele landingspage bezoekers: