Seanox Devwex 1.2013.0707
Copyright (C) 2013 Seanox Software Solutions
Alle Rechte vorbehalten.

Seanox Software Solutions

Devwex - Advanced Server Developing

Dokumentation

Dokumentation zu Seanox Devwex
Stand 1.2013.0707

Copyright © 2013 Seanox Software Solutions

Alle Rechte vorbehalten.

Wichtiger Hinweis

Die im Buch genannten Software- und Hardwarebezeichnungen sowie die Markennamen der jeweiligen Firmen unterliegen im Allgemeinen warenzeichen-, marken- oder patent-rechtlichem Schutz.

Inhalt

Allgemeines
Lizenzbedingungen
Merkmale
Systemanforderung

Installation

Konfigurationsdatei
Basisoptionen
Initialisierung

Server
Virtuelle Hosts
Fernüberwachung
Serverkonfiguration
Secure Socket Layer / Transport Layer Security
Virtuelle Verzeichnisse
Systemreferenzen
Basic- / Digest- Access Authentication
Common Gateway Interfaces
Umgebungsvariablen
Filter
Module

Statuscodes
Mimetypes








[COMMON]
[INITIALIZE]

[SERVER]

[SERVER:REMOTE:BAS]
[SERVER:X:BAS]
[SERVER:X:SSL]
[SERVER:X:REF]
[SERVER:X:REF]
[SERVER:X:ACC]
[SERVER:X:CGI]
[SERVER:X:ENV]
[SERVER:X:FLT]


[STATUSCODES]
[MIMETYPES]












[VIRTUAL]

[VIRTUAL:X:BAS]

[VIRTUAL:X:REF]
[VIRTUAL:X:REF]
[VIRTUAL:X:ACC]
[VIRTUAL:X:CGI]
[VIRTUAL:X:ENV]
[VIRTUAL:X:FLT]


Hinweis - Die folgende Dokumentation bezieht sich mit Ausnahme der allgemeinen Abschnitte Lizenzbedingungen, Systemanforderung, Installation, Konfigurationsdatei, Basisoptionen und Initialisierung vorrangig auf die mit dem Server bereitgestellte HTTP(S)-Instanz. Details zur modularen Architektur, Startsequenz und APIs sind in der Dokumentation des zum Devwex verfügbaren SDK enthalten.

Allgemeines

Devwex ist ein minimalistischer Webserver mit einer modularen Architektur. Die bereits enthaltenen Server-Instanzen unterstützen das HTTP unter anderem mit virtuellen Hosts, IP/Port-Sharing, Directory Index, Filtering, Module, SSL/TLS, DCGI/CGI1.1 und einen auf Telnet basierenden Fernzugriff zur Serverkontrolle. Weitere Server-Instanzen und Module lassen sich über die verfügbaren APIs einbinden. Der Server selbst ist eine reine Java Umsetzung für die Kommandozeile und kann durch entsprechende Java Laufzeitumgebung unter vielen Betriebssystemen eingesetzt werden.

Lizenzbedingungen

Seanox Software Solutions ist ein Open-Source-Projekt, im Folgenden Seanox Software Solutions oder kurz Seanox genannt.

Diese Software unterliegt der Version 2 der GNU General Public License.

Copyright (C) 2013 Seanox Software Solutions

This program is free software; you can redistribute it and/or modify it under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

Merkmale

Architektur

Devwex ist ein multithreading-fähiger Container für (Server-)Module, welche über die bereitgestellte Server- und Modul-API eingebunden werden. Bereits enthalten sind ein auf Telnet basierender Fernzugriff und ein HTTP(S)-Server, welcher eine speziell für Web-Anwendungen erweiterte Modul-API zur Verfügung stellt. Der eigene ClassLoader unterstützt dabei das Laden und Entladen von Servern und Modulen zur Laufzeit.

Customizing

Fehlerseiten und die Listenansicht der Verzeichnisse (Directory Index), inklusive der Symbole, welche zur visuellen Unterstützung, den unterschiedlichen Datentypen zugeordneten werden, basieren auf Templates und lassen sich für alle physischen und virtuellen Hosts individuell anpassen.

Erweiterbarkeit

Die modulare Architektur und zahlreichen Schnittstellen ermöglichen das Ändern, Erweitern und Hinzufügen von Funktionalitäten.

Konfiguration

Diese basiert auf einer zentralen Datei. Alle Server, Module und andere globale Einstellungen werden dort in einem erweiterten INI-Format, welches dynamische Werte und Vererbung unterstützt, konfiguriert.

Kontrolle

Funktionen wie Statusabfrage, Restart und Stop sind über den frei konfigurierbaren Fernzugriff per Telnet zugänglich. Alternativ stellt Devwex selbst einen entsprechenden Client zur Verfügung.

Schnittstellen

(Fast)CGI - Zum Datenaustausch sowie zur Anbindung externer Laufzeitumgebungen und Anwendungen, wird die Spezifikation 1.1 des Common Gateway Interfaces und somit PHP, Perl, Python und andere unterstütz. Optional steht auch FastCGI zur Verfügung.

DCGI - Eine speziell für Devwex entwickelte und an das CGI 1.1 angelehnte Schnittstelle für verschiedenste Programmiersprachen, wie Java, VB, VB(A) und andere, welche die Anbindung von multithreading-fähigen Umgebungen oder Anwendungen ermöglicht, welche keine eigenständige Laufzeitumgebung besitzen.

Server- und Modul-API - Über diese lassen sich bestehende Funktionen ändern oder neu hinzufügen. Die Verwaltung und Steuerung erfolgen über den Module-Container, der auch Änderungen zur Laufzeit erlaubt und angebundene Module über eintretende Ereignisse informiert.

HTTP(S) - Basierend auf der Spezifikation 1.0 werden neben GET, POST und HEAD auch OPTIONS, PUT sowie DELETE vom HTTP 1.1 unterstützt. Weitere Methoden lassen sich über Module, DCGI bzw. CGI bereitstellen.

Telnet - Zur Steuerung und Überwachung ist eine auf Telnet basierende Server- sowie Client-Lösung, inklusive einer API für Java, verfügbar.

WebSocket - Ein auf TCP basierendes Netzwerkprotokoll, welches bidirektionale Verbindung zwischen Webanwendungen und dem Web-Server unterstützt.

Sicherheit

Für eine gesicherte Übertragung von Daten werden unter anderem Secure Socket Layer (SSL) und Transport Layer Security (TLS) mit Server- und Client-Zertifikaten unerstützt. Zertifikate können dabei für jeden physischen Host einzeln, durch Vererbung in Gruppen oder global zugewisen werden.

Der Zugriff auf Verzeichnisse und Dateien kann mit Basic- sowie Digest-Access-Authentication, welche die Administration von Gruppen unterstützen, versehen werden. Zudem kann der Zugriff über Filter gesteuert werden, welche frei definierbare Regeln, individuelle Fehlerseiten, automatische Weiterleitungen und Module unterstützen.

Virtualisierung

IP-, Port- und Namen-basiertes (Virtual Domain) Hosting werden unterstützt.

Systemanforderung

Software

Java Runtime 1.4.x oder höher

Hardware (Minimum)

Prozessor 200 MHz
Speicher 64 MB
Netzwerk 10 MB/s

Installation

Nach dem Entpacken kann die komplette Verzeichnisstruktur an einer beliebigen Stelle im Dateisystem abgelegt werden.

Für SSL und TLS wird die Java Secure Socket Extension (JSSE) verwendet. Ab Java Version 1.4.0 ist diese Erweiterung Bestandteil der Java Laufzeitumgebung (JRE) bzw. der Java Entwicklungsumgebung (JDK)

Zum Starten wird nach dem öffnen der Konsole (Shell/Eingabeaufforderung) in das Arbeitsverzeichnis ./devwex/program gewechselt und der Server direkt als Java-Binary oder über die verfügbaren Startskripte aufgerufen.

Java-Binary

java -cp devwex.jar [-Dlibraries=value] [-Dparameter=value] com.seanox.devwex.Service [option]

Startskript Windows (Eingabeaufforderung)

devwex.bat [option]

Startskript Unix/Linux (Shell)

devwex.sh [option]
Option
Beschreibung
start
startet entsprechend der Konfiguration
state
zeigt Start- und aktuelle Systemzeit sowie alle laufenden Server
restart
beendet alle aktiven Server und startet entsprechend der Konfiguration neu
stop
beendet Devwex mit allen aktiven Servern
*
aktiviert die erweiterte Ausgabe (Bsp. start*)

Tipp - Devwex erweitert beim Start automatisch den Klassenpfad um alle Dateien der Verzeichnisse, welche durch den Startparameter -Dlibraries angegeben wurden.
Tipp - Mit Devcox steht ein webbasierte Administration für Devwex in englischer Sprache zur Verfügung, mit der die Konfiguration und Administration direkt über den Webbrowser erfolgen kann.
Tipp - Der Fernzugriff zur Serversteuerung erfolg per Telnet. Die meisten Betriebssysteme enthalten bereits einen entsprechenden Client der sich über die Konsole (Shell/Eingabeaufforderung) wie folgt verwenden lässt.

Bsp. telnet 127.0.0.1 25000   
                              
     STATE                    
     VERS: 1.2013.0707       
                              
     TIME: 2013-07-07 06:00:00
     TIUP: 2013-07-07 06:00:00
                              
     SERV: TCP 127.0.0.1:25000
     SERV: TCP 127.0.0.1:80   
     SERV: TCP 127.0.0.1:443  
Tipp - Durch den Eintrag von IP-Adressen in die host-Datei vom Betriebssystem, wie Windows (Bsp. c:\windows\system32\drivers\etc\hosts) oder Unix (Bsp. /etc/hosts), kann die Ermittlung der Hostnamen und damit der Zugriff auf Netzwerkressourcen, wie z.B. Server und Datenbanken, beschleunigt werden.

Konfigurationsdatei

Die Konfigurationsdatei devwex.ini ist in sechs Sektionen unterteilt und wird immer aus dem aktuellen Arbeitsverzeichnis, aus dem der Server gestartet wurde, verwendet. Nach der Installation liegt im Verzeichnis ./devwex/program die bereits vorkonfigurierte devwex.ini vor.
Sektion
Beschreibung
[COMMON]
allgemeine Anwendungsoptionen
[INITIALIZE]
Modulinitialisierung mit dem (Re)Start des Service
[SERVER]
Konfigurationsbereich der physischen Server
[VIRTUAL]
Konfigurationsbereich von virtuellen Hosts für HTTP-Server
[STATUSCODES]
Statuscodes der HTTP-Server
[MIMETYPES]
Zuordnung von Medien- und Datentypen

Das für die Konfiguration von Devwex verwendete INI-Format wurde zur klassischen Form erweitert. Die Unterteilung erfolgt auch hier in Sektionen, in denen zeilenweise Schlüssel, im Nachfolgenden auch Parameter genannt, mit zugehörigen Werten abgelegt sind. Beim Namen von Sektion und Schlüssel wird die Gross- und Kleinschreibung nicht berücksichtig. Mehrfache Deklarationen werden zusammengeführt, bereits vorhandene Schlüssel überschrieben und neue hinzugefügt. Dadurch können Sektionen auch geteilt werden, was die Übersichtlichkeit aber meist erschwert.

Als Erweiterung zum Originalformat lassen sich Sektionen vererben. Dazu wird einer Sektion das Schüsselwort EXTENDS, gefolgt vom Namen der referenzzierenden Sektion, nachgestellt. Damit übernimmt die so abgeleitete Sektion alle Schlüssel und Werte der referenzzierten Sektion und kann diese erweitern oder überschreiben.

Das Zuweisen eines Wertes zu einem Schlüssel erfolgt über das Gleichheitszeichen. Abweichend vom Originalformat, kann die Zuweisung in der Folgezeile ohne erneute Angabe des Schlüssels und durch die Verwendung des Pluszeichens fortgesetzt werden. Werte lassen sich zudem fest, variabel und optional zuweisen. Durch die zusätzliche Option [?] am Ende eines Schlüssels, wird versucht für diesen ein Wert über die System-Properties der Java-Laufzeitumgebung zu ermitteln. Kann kein Wert ermittelt werden, wird der optional eingetragene zugewiesen. Ohne Wert gilt ein Schlüssel mit der Option [?] als nicht angegeben und wird damit ignoriert.

Für Kommentare wird das Semikolon verwendet. Wiederum Abweichend vom Originalformat kann ein Kommentar an einer beliebiger Stelle der Zeile verwendet werden. Die nachfolgenden Zeichen sind somit kein Bestandteil von Sektion, Schlüssel oder Wert. Zusätzlich zum Originalformat, lässt sich die Kommentarfunktion für eine Zeile mit der Option [+] am Ende von Schlüssel oder Wert abgeschalten. Somit kann auch das Semikolon als Zeichen verwendet werden.

Bsp. 1: [SECTION] EXTENDS SECTION-A           ;Kommentar
     2:   PARAM-A         = WERT-1            ;Kommentar
     3:   PARAM-B         = WERT-2; WERT-3 [+]          
     4:                   + WERT-4; WERT-5 [+]          
     5:   PARAM-C     [+] = WERT-6; WERT-7              
     6:   PARAM-D  [?][+] = WERT-8; WERT-9              
     7:   PARAM-E  [?]    = WERT-0            ;Kommentar
     8:   PARAM-F  [?]                        ;Kommentar

Zeile
Erklärung
1
Die Sektion mit dem Namen "SECTION" wird definiert. Die Option EXTENDS verweist auf die Ableitung von der Sektion "SECTION-A". Somit werden bei der Anforderung der Sektion "SECTION" alle über EXTENDS direkt und/oder indirekt angegebenen Sektionen einbezogen. Ab dem Semikolon werden die nachfolgenden Zeichen als Kommentar interpretiert.
2
Dem Schlüssel "PARAM-A" wird der Wert "WERT-1" zugewiesen. Die nachfolgenden Zeichen werden ab dem Semikolon als Kommentar interpretiert.
3
Dem Schlüssel "PARAM-B" wird der Wert "WERT-2; WERT-3" zugewiesen. Durch die Option [+] am Ende des Werts wird der Zeilenkommentar abgeschaltet und alle Zeichen für die Wertzuweisung verwendet. Die Eingabe eines Kommentars ist in dieser Zeile nicht möglich.
4
Die Wertzuweisung von Zeile 003 wird fortgesetzt und der Wert "WERT-4; WERT-5" dem bestehenden Wert vom Schlüssel "PARAM-B" hinzugefügt. Durch die Option [+] am Ende der Wertzuweisung wird der Zeilenkommentar abgeschaltet und alle Zeichen für die Wertzuweisung verwendet. Die Eingabe eines Kommentars ist in dieser Zeile nicht möglich. Weitere vorangestellte Optionen werden nicht unterstützt.
5
Ähnlich der Zeile 003 wird dem Schlüssel "PARAM-C" der Wert "WERT-2; WERT-3" zugewiesen. Durch die Option [+] am Ende des Schlüssels wird der Zeilenkommentar abgeschaltet, womit alle Zeichen für die Wertzuweisung verwendet werden. Die Eingabe eines Kommentars ist in dieser Zeile nicht möglich.
6
Die Wertzuweisung für den Schlüssel "PARAM-D" erfolgt dynamisch. Dabei wird versucht, zu diesem ein Wert über die System-Properties der Java-Laufzeitumgebung zu ermitteln. Dazu muss dieser Schlüssel ein Bestandteile der Laufzeitumgebung sein oder kann mit dem Programmstart in der Form -Dname=wert übergeben werden. Die Gross- und Kleinschreibung vom Namen kann dabei unbeachtet bleiben. So übergebene Werte werden komplett zugewiesen. Kommentare werden hierbei nicht unterstützt. Kann für den Schlüssel kein Wert über die System-Properties ermittelt werden, wird die eingetragene Wertzuweisung "WERT-8; WERT-9" verwendet. Ein Kommentar ist durch Verwendung der Option [+] nicht möglich.
7
Ähnlich der Zeile 006 wird auch hier der Wert für den Schlüssel "PARAM-E" dynamisch über die System-Properties der Java-Laufzeitumgebung aufgelöst. Ist dies nicht möglich, wird die eingetragene Wertzuweisung verwendet. Ohne die Option [+] ist in dieser Zeile auch ein Kommentar anwendbar.
8
Wie in den Zeilen 006 und 007 erfolgt auch hier die Zuweisung vom Wert für den Schlüssel "PARAM-F" dynamisch über die System-Properties der Java-Laufzeitumgebung. Ist dies nicht möglich, wird der Schlüssel nicht übernommen.

Basisoptionen

[COMMON]

Allgemeine und global verfügbare Optionen für Server, Hosts und Module werden hier festgelegt.
Parameter
Wert
Beschreibung
CLEANUP
5000
Intervall in Millisekunden für die intelligente Bereinigung der Ressourcen. Dabei wird der Garbage Collector von Java angestossen, wenn auch freizugebene Ressourcen zu erwarten sind.
RELOAD
ON|OFF
Option für das Überwachen der Konfigurationsdatei und automatische Neuladen und Durchstarten bei Änderungen.

Initialisierung

[INITIALIZE]

Hier eingetragene Module werden mit dem (Re)Start des Service initialisiert und über bestimmte Ereignisse informiert. Optional können auch Argumente übergeben werden.

Das Schema zur Formulierung der Modulinitialisierung

NAME = RESSOURCE [OPTION] [OPTION] ...

Beispiel für die Modulinitialisierung

CONTAINER = com.seanox.module.Container [SIZE:256] [TYPE:FIFO]

Mit der Option [*] kann ein Modul als optional gekennzeichnet werden. Ist das Modul im Fall der Initialisierung nicht vorhanden, führt das mit dieser Option zu keiner Fehlerausgabe.

Beispiel für die optionale Modulinitialisierung

CONTAINER = com.seanox.module.Container [SIZE:256] [TYPE:FIFO] [*]

Server

Server stellen als physischer Host den Zugriffe auf Dienste im Netzwerk über definierte Adresse und Port zur Verfügung. Mit dem Start von Devwex werden alle Server in der Konfigurationsdatei über das Muster [SERVER:*:BAS] im Namen der Sektion ermittelt und gestartet.

Das Schema zur Formulierung der Server

[SERVER:NAME:SEKTION]

Der Name vom Server ist frei wählbar und kann beliebig gesetzt werden.

Die Konfiguration des Servers setzt sich aus sieben Sektionen zusammen.
Sektion
Beschreibung
[SERVER:X:BAS]
Basiskonfiguration
[SERVER:X:REF]
virtuelle Verzeichnisse
[SERVER:X:ACC]
Zugriffssteuerung (Access Control List)
[SERVER:X:ENV]
Umgebungsvariablen
[SERVER:X:CGI]
CGI Zuweisung und Konfiguration
[SERVER:X:FLT]
Filterkonfiguration

Virtuelle Hosts

Die virtuellen Hosts stehen allen Servern für ein Namen-basiertes (Virtual Domain) Hosting zur Verfügung, was ein IP- und Port-Sharing ermöglicht. Bei der Konfiguration leitet sich diese vom aufgerufenen Server ab und kann dann durch die Konfiguration des virtuellen Hosts gezielt überschrieben. Die Verwendung der virtuellen Hosts richtet sich nach dem beim Server eintreffenden Request. Entsprechend dem dort enthaltenen Host wird dann der namensgleiche virtuelle Host verwendet.

Beispiel eines Request für einen virtuellen Host

GET /directory/file.cgi?value=123 HTTP/1.1
Accept-Encoding: gzip, deflate            
Accept-Language: de                       
Accept: */*                               
User-Agent: Browser                       
Host: www.xxx.zzz                         

Entsprechend dem Beispiel müssen die Sektionen für den virtuellen Host wie folgt in der Konfigurationsdatei angelegt werden.
Sektion
Beschreibung
[VIRTUAL:WWW.XXX.ZZZ:BAS]
Basiskonfiguration
[VIRTUAL:WWW.XXX.ZZZ:REF]
virtuelle Verzeichnisse
[VIRTUAL:WWW.XXX.ZZZ:ACC]
Zugriffssteuerung (Access Control List)
[VIRTUAL:WWW.XXX.ZZZ:ENV]
Umgebungsvariablen
[VIRTUAL:WWW.XXX.ZZZ:CGI]
CGI Zuweisung und Konfiguration
[VIRTUAL:WWW.XXX.ZZZ:FLT]
Filterkonfiguration

Die Konfiguration der virtuellen Hosts gleicht der, der Server. Die Einträge für CONNECTOR, ADDRESS, PORT SERVICE, BACKLOG, MAXACCESS und ISOLATION entfallen hier.

Fernüberwachung

[SERVER:REMOTE:BAS]

Funktionen wie Statusabfrage, Restart und Stop sind über den frei konfigurierbaren Fernzugriff per Telnet zugänglich. Server wie auch Client sind in Devwex enthalten und werden hier konfiguriert.
Parameter
Wert
Beschreibung
CONNECTOR
...
als Connector zu verwendende Java-Klasse
ADDRESS
AUTO|LOCALHOST|IP|NAME
lokale Adresse des Servers AUTO verwendet hierbei alle im System verfügbaren IP-Adressen
PORT
...
lokaler Port des Servers

Der Fernzugriff zur Serversteuerung erfolg per Telnet. Die meisten Betriebssysteme enthalten bereits einen entsprechenden Client der sich über die Konsole (Shell/Eingabeaufforderung) verwenden lässt. Alternativ ist ein entsprechender Client auch in Devwex enthalten.
Kommando
Beschreibung
state
zeigt Start- und aktuelle Systemzeit sowie alle laufenden Server
restart
beendet alle aktiven Server und startet entsprechend der Konfiguration neu
stop
beendet Devwex mit allen aktiven Servern

Beispiel mit einem Telnet-Client

telnet 127.0.0.1 25000   
                         
STATE                    
VERS: 1.2013.0707       
                         
TIME: 2013-07-07 06:00:00
TIUP: 2013-07-07 06:00:00
                         
SERV: TCP 127.0.0.1:25000
SERV: TCP 127.0.0.1:80   
SERV: TCP 127.0.0.1:443  

Bei der Verwendung vom Devwex-Client werden die Verbindungsdaten aus der Server-Konfiguration devwex.ini, welche sich im Arbeitsverzeichnis befinden muss, ermittelt.

Beispiel mit dem Devwex-Client über das Startskript unter Windows

devwex.bat state         
                         
VERS: 1.2013.0707       
                         
TIME: 2013-07-07 06:00:00
TIUP: 2013-07-07 06:00:00
                         
SERV: TCP 127.0.0.1:25000
SERV: TCP 127.0.0.1:80   
SERV: TCP 127.0.0.1:443  

Beispiel mit dem Devwex-Client über das Startskript unter Unix/Linux

devwex.sh state          
                         
VERS: 1.2013.0707       
                         
TIME: 2013-07-07 06:00:00
TIUP: 2013-07-07 06:00:00
                         
SERV: TCP 127.0.0.1:25000
SERV: TCP 127.0.0.1:80   
SERV: TCP 127.0.0.1:443  

Beispiel mit dem Devwex-Client per Java

java -cp devwex.jar com.seanox.devwex.Service state
                                                   
VERS: 1.2013.0707                                 
                                                   
TIME: 2013-07-07 06:00:00
TIUP: 2013-07-07 06:00:00
                                                   
SERV: TCP 127.0.0.1:25000                          
SERV: TCP 127.0.0.1:80                             
SERV: TCP 127.0.0.1:443                            

Serverkonfiguration

[SERVER|VIRTUAL:X:BAS]

Diese Sektion stellt die allgemeine Konfiguration für Server und virtuelle Hosts zur Verfügung. Beide Konfigurationen gleichen sich, wobei die Parameter CONNECTOR, ADDRESS, PORT, SERVICE, BACKLOG, MAXACCESS und ISOLATION bei virtuellen Hosts nicht berücksichtigt werden.
Parameter
Wert
Beschreibung
CONNECTOR
...
als Connector zu verwendende Java-Klasse
ADDRESS
AUTO|LOCALHOST|IP|NAME
lokale Adresse des Servers, AUTO verwendet hierbei alle im System verfügbaren IP-Adressen
PORT
...
lokaler Port des Servers
SERVICE
...
Modul zur Request-Verarbeitung
IDENTITY
ON|OFF
Option zur Übermittlung vom Server-Namen mit dem CGI und dem Response
MAXACCESS
100
maximale Anzahl gleichzeitiger Verbindungen
BACKLOG
500
maximale Anzahl zurückgestellter Verbindungen, wenn die Anzahl der gleichzeitigen Verbindungen ausgeschöpft ist
ISOLATION
250
maximale Leerlaufzeit für den Verbindungsaufbau in Millisekunden
BLOCKSIZE
65535
maximale Grösse der Datenblöcke beim Datentransfer in Bytes
INTERRUPT
10
Dauer der Unterbrechung für Systemprozesse in Millisekunden
TIMEOUT
30000 [S]
maximale Leerlaufzeit des Datenstroms in Millisekunden, beim Überschreiten wird ein Timeout ausgelöst, mit der Option [S] (strickt) wirkt die Begrenzung der Leerlaufzeit auch auf ausgehende Server-Datenströme, der Wert 0 ignoriert das Timeout;
DURATION
500000
maximale Laufzeit von (D)CGI Prozessen in Millisekunden, beim Überschreiten wird der Prozess durch den Server beendet, der Wert 0 ignoriert die Laufzeit
SLICING
15000
maximale Dauer zur Initiierung des Request in Millisekunden, beim Überschreiten wird der Request abgebrochen, der Wert 0 ignoriert die Dauer
METHODS
GET POST HEAD OPTIONS PUT DELETE ...
Methoden die der Server verarbeiten darf, durch Leerzeichen getrennte Liste
ACCESSLOG
../system/access.log
Logdatei zur Protokollierung der Zugriffe, ohne Angabe wird der Standard-I/O verwendet, mit OFF wird die Protokollierung deaktiviert
SYSROOT
../system
Pfadangaben des Verzeichnis der Systemdateien
DOCROOT
../documents
Pfadangaben des Verzeichnis der Dokumente
INDEX
ON|OFF
Option für die Ausgabe von Verzeichnissen als navigierbare Listenansicht (Directory Index), mit dem Zusatz [S] können versteckte Einträge des Dateisystems für die Anzeige unterdrückt werden
MIMETYPE
application/octet-stream
Standard Mimetype, dieser wird verwendet, wenn der geforderte Mimetype nicht in der Liste der Mimetypes (Sektion [MIMETYPES]) enthalten ist
DEFAULT
index.htm index.html ...
beim Aufruf von Verzeichnissen anzuzeigende Standarddokumente, durch Leerzeichen getrennte Liste

Tipp - Im Dateinamen vom Zugriffsprotokoll werden auch einige Symbole der Zeit unterstützt. Die Angabe erfolgt in eckigen Klammern.

Bsp. ACCESSLOG = ../system/access.[yyyy.MMdd].log

Liste der Symbole zur Formatierung der Zeit (nach US Standard).
Symbol
Beschreibung
Datentyp
Beispielwert
G
Ära
Text
AD
y
Jahr
Numerisch
1998
M
Monat im Jahr
Numerisch
7
MM
Monat im Jahr mit 0
Numerisch
07
MMM
Monat im Jahr kurz
Text
Sep
MMMM
Monat im Jahr lang
Text
September
d
Tag im Monat
Numerisch
26
h
Stunde (1-12)
Numerisch
9
H
Stunde am Tag (0-23)
Numerisch
0
m
Minute der Stunde
Numerisch
13
s
Sekunde der Minute
Numerisch
22
S
Millisekunde
Numerisch
257
E
Tag der Woche kurz
Text
Wed
EEEE
Tag der Woche lang
Text
Wednesday
D
Tag im Jahr
Numerisch
304
F
Tag der Woche im Monat
Numerisch
3
w
Woche im Jahr
Numerisch
12
W
Woche im Monat
Numerisch
3
a
AM- und PM-Text
Text
AM
k
Stunde am Tag (1-24)
Numerisch
24
K
Stunde (0-11)
Numerisch
0
z
Zeitzone
Text
GMT+02:00

Secure Socket Layer / Transport Layer Security

[SERVER:X:SSL]

Zur gesicherten Übertragung von Daten werden Secure Socket Layer (SSL) und Transport Layer Security (TLS) unterstützt. Die Zuweisung der Zertifikate ist für die physischen Hosts einzeln und gemeinsam möglich.
Parameter
Wert
Beschreibung
PROTOCOL
TLS|SSL|...
Protokoll, SSL (Secure Socket Layer), TLS (Transport Layer Security), Standard wenn nicht angegeben TLS
ALGORITHM
SunX509|...
Algorithmus der Verschlüsselung, Standard wenn nicht angegeben SunX509
CLIENTAUTH
ON|OFF
Option zur Aktivierung der der Client-Autorisierung, Standard wenn nicht angegeben OFF
STORE
...
Pfad der Keystore-Datei
TYPE
JKS|...
Art des Keystores, Standard wenn nicht angegeben JKS
PASSWORD
...
Passwort für den Keystore

Für SSL und TLS wird die Java Secure Socket Extension (JSSE) verwendet. Ab Java Version 1.4.0 ist diese Bestandteil der Java Laufzeitumgebung (JRE) bzw. der Java Entwicklungsumgebung (JDK).

Die Erstellung des Zertifikates im Keystore.

./java/bin/keytool -genkey -keyalg RSA -validity 365                     
                   -alias devwex -dname "CN=127.0.0.1, C=DE"             
                   -keystore keystore -keypass default -storepass default

Wird beim Keytool kein Zielverzeichnis mit -keystore angegeben, wird das generierte Zertifikat als .keystore Datei im Benutzerverzeichnis abgelegt. Je nach Betriebssystem werden unterschiedliche Benutzerverzeichnisse verwendet. z.B. c:\Dokumente und Einstellungen\[Benutzer]\.keystore unter Windows 2000/XP oder /home/[benutzer]/.keystore auf Unix-basierenden System.

Die erstellte Keystore-Datei kann beliebig umbenannt und im Dateisystem verschoben werden.

Die Konfiguration und Verwendung der Zertifikate, ausgehend davon, dass sich die Keystore-Datei im Devwex-Arbeitsverzeichnis ./devwex/program befindet und die JSSE zur Verfügung steht. Der Port kann frei gewählt werden, wobei 443 als Standard-Port für HTTPS verwendet wird.

[SERVER:X:BAS]         
  PORT       = 443     
  ...                  
                       
[SERVER:X:SSL]         
  PROTOCOL   = TLS     
  ALGORITHM  = SunX509 
  CLIENTAUTH = OFF     
                       
  STORE      = keystore
  TYPE       = JKS     
  PASSWORD   = default 
  ...                  

Durch die automatisch vergebenen Standardwerte genügt meist die folgende Konfiguration.

[SERVER:X:BAS]         
  PORT       = 443     
  ...                  
                       
[SERVER:X:SSL]         
  STORE      = keystore
  PASSWORD   = default 
  ...                  

Virtuelle Verzeichnisse

[SERVER|VIRTUAL:X:REF]

Virtuelle Verzeichnisse sind ein Alias für physische Verzeichnisse des Dateisystems. Mit diesen können unabhängig von der Quellstruktur neue Verzeichnisstrukturen aufgebaut oder bestehende verändert werden.

Das Schema zur Formulierung der virtuellen Verzeichnisse

NAME = VIRTUELL > PHYSISCH [OPTION]
Option
Beschreibung
[A]
Absolute - Definiert einen virtuellen Teilpfad der auf physische Verzeichnisse oder Dateien verweist. Beginnt der Pfad einer Anfrage mit diesem virtuellen Teilpfad, wird die so definierte Ressource verwendet. Handelt es sich dabei um ein Skript oder Modul, kann dieses die zusätzlichen Pfadinformationen auswerten und anwenden.
[C]
Forbidden - Mit dieser Option kann der Zugriff auf virtuelle und physische Verzeichnis sowie Dateien gesperrt werden.
[R]
Redirect - Option mit der für virtuelle und physische Verzeichnis sowie Dateien eine automatische Weiterleitung zur angegebenen Adresse eingerichtet wird.
[M]
Module - Legt einen virtuellen Teilpfad für Module fest. Beginnt der Pfad einer Anfrage mit diesem virtuellen Teilpfad, wird das so definierte Modul verwendet, womit HTTP-Module als Webanwendung eingebunden werden. Module können die zusätzlichen Pfadinformationen auswerten und anwenden.
[X]
Extension - Nur in Verbindung mit der Option [M] kann die Modulnutzung erweitert werden, womit dann unabhängig vom Server-Parameter METHODS alle angefragten HTTP-Methoden an das Modul weitergereicht werden. Hilfreich ist diese Option, wenn ein Modul die bestehenden HTTP-Methoden erweitert.
[D]
Verwendet die Digest Access Authentication, wenn ein ACC-Eintrag angegeben wurde.
[ACC:...]
Basic / Digest Access Authentication - Optionale Angabe von Access-Conntrol-List-Einträgen (ACC)
[REALM:...]
Basic / Digest Access Authentication - Optionale Angabe der Beschreibung des geschützten Bereichs.

Beispiele für den Einsatz virtueller Verzeichnisse

DIRECTION:A = /system > ../system

bei Anfragen mit dem Pfad /system wird das physische Verzeichnis ../system verwendet
DIRECTION:B = /doc > ../documents [A]

bei Anfragen mit den Pfaden /documents, /documentation und /doc/test.cgi?cmd=123 wird auf das physische Verzeichnis ../documents ohne Dateiangabe verwendet
DIRECTION:C = /test > http://www.xxx.zzz [R]

bei Anforderung vom Verzeichnis /test erfolgt eine Weiterleitung zu http://www.xxx.zzz
DIRECTION:D = /control > example.Connector [M]

mit der Anforderung vom Verzeichnis /control wird die Klasse Connector aus dem Paket example, welches sich im Klassenpfad des Servers befinden muss, als Modul ausgeführt
DIRECTION:E = /program [C]

der Zugriff auf das Verzeichnis /program wird verweigert

Systemreferenzen

[SERVER|VIRTUAL:X:REF]

Systemreferenzen sind Verweise für die vom Server verwendete Ressourcen. Diese lassen sich hier festlegen oder umleiten.

Das Schema zur Formulierung von Systemreferenzen

SYSTEM:NAME = VERWEIS [OPTION]
Option
Beschreibung
[R]
Redirection - Diese Option verweist auf eine automatische Weiterleitung. Diese ist für alle Statuscodes ausser 302 verfügbar.

Beispiele für den Einsatz von Systemreferenzen

SYSTEM:INDEX = ../service/directory.html

als Template für die Generierung der Listenansicht von Verzeichnissen wird die Datei ../service/directory.html verwendet
SYSTEM:404   = ../service/error.404.html

als Template für die Generierung der Statusinformation 404 wird die Datei ../service/error.404.html verwendet
SYSTEM:404   = http://www.xxx.zzz/404.php [R]

beim Auftreten des Status 404 erfolgt eine Weiterleitung zur Adresse http://www.xxx.zzz/404.php
Tipp - In allen Templates sind die für das CGI üblichen Umgebungsvariablen als Parameter verfügbar.
Tipp - In der Listenansicht der Verzeichnisse werden den Datentypen Symbole zugeordnet und angezeigt. Die Symbole, welche sich beliebig ändern und erweitern lassen, werden als Bibliothek in einer GIF-Datei zusammengefasst, Base64 kodiert, im Template ./devwex/system/index.html eingebettet, per CSS zugewiesen und qualifizieren sich über Datengruppe, Datentyp und Dateiendung, welche als CSS-Attribute eingetragen werden.

Basic- / Digest- Access Authentication

[SERVER|VIRTUAL:X:ACC]

Basic- und Digest Access Authentication sind zwei von verschiedenen Verfahren, mit denen sich ein Nutzer gegenüber einem Webserver bzw. einer Webanwendung authentisieren kann. Empfohlen wird hier die Verwendung der Digest Access Authentication, da diese im Unterschied zur Basic Access Authentication das Passwort nicht direkt, sondern zum Schutz vor Rekonstruktion nur in Form einer Prüfsumme bzw. eines Fingerabdrucks übermittelt.

Die Konfiguration der Basic / Digest Access Authentication erfolgt optional zu einem virtuellen bzw. physischen Pfad und setzt sich aus einer oder mehreren Referenzen von Zugangsdaten (Gruppen), bei der Digest Access Authentication der Option [D] sowie der optionalen Angabe vom Bereich (Realm) zusammen. Daher ist die Konfiguration in den Sektionen REF und ACC erforderlich. In der Sektion REF wird der virtuelle Pfad, zu dem optional ein physischer Pfad angegeben werden kann, mit der Basic Authentication eingetragen. Die Angabe der Zugriffsrechte erfolgt dann in der Sektion ACC. Hier werden die Benutzer und deren Passwörter vorgehalten.

Die Referenz [acc:none] stellt dabei eine Sonderfunktion dar, da diese Angabe die übergeordnete Autorisierung für den angegebenen und alle untergeordneten Pfade aufhebt. Werden in der selben Definition weitere gültige Referenzen angeben, werden diese ignoriert.

Beispiele für Basic Access Authentication

[SERVER:X:REF]                                                          
  ACCESS:A = /access                     [acc:group:a] [realm:Section-A]
  ACCESS:B = /access/section             [acc:group:b] [realm:Section-B]
  ACCESS:C = /access/section/protected   [acc:group:c] [realm:Section-C]
  ACCESS:N = /access/public              [acc:none]                     

  ACCESS:X = /access/example... > ... [acc:...] [acc:...] ... [realm:...] [...

Beispiele für Digest Access Authentication (nur die Option [D] macht den Unterschied)

[SERVER:X:REF]                                                              
  ACCESS:A = /access                     [acc:group:a] [realm:Section-A] [D]
  ACCESS:B = /access/section             [acc:group:b] [realm:Section-B] [D]
  ACCESS:C = /access/section/protected   [acc:group:c] [realm:Section-C] [D]
  ACCESS:N = /access/public              [acc:none]                         

  ACCESS:X = /access/example... > ... [acc:...] [acc:...] ... [realm:...] [D] [...

Beispiele für Definition der Zugangsdaten

[SERVER:X:ACC]                             
  GROUP:A = ua:pa ub:pb uc:pc              
  GROUP:B = ua:pa ub:pbb                   
  GROUP:C = uc:pcc                         

  GROUP:X = user:password user:password ...

Das Verzeichnis /access und alle enthaltenen Unterverzeichnissen sind nur für ausgewählte Benutzer und mit Passwort zugänglich. Ausgenommen davon ist das Verzeichnis /access/public und dessen Unterverzeichnisse.
Beispiel
Erklärung
ACCESS:A
Auf das Verzeichnis /access können nur die Benutzer "ua" und dem Passwort "pa", "ub" und dem Passwort "pb" sowie "uc" mit dem Passwort "pc" zugreifen. Auch der Zugriff auf alle Unterverzeichnisse, ist mit Ausnahme von /access/section und /access/section/protected, nur für diese Benutzer möglich.
ACCESS:B
Das Verzeichnis /access/section mit allen Unterverzeichnissen kann von den Benutzern "ua" mit dem Passwort "pa" und "ub" mit dem Passwort "pbb" verwendet werden.
ACCESS:C
Der Zugriff auf das Verzeichnis /access/section/protected ist ausschliesslich für den Benutzer "uc" mit dem Passwort "pcc" möglich.
ACCESS:N
Für das Verzeichnis /access/public wird die Basic / Digest Access Authentication aufgehoben und kann ohne Login und Passwort genutzt und Unterverzeichnisse wieder mit Basic Access Authentication versehen werden.

Hinweis - Bei Benutzern und Passwörtern wird Gross- und Kleinschreibung berücksichtigt. Die Verwendung von Doppelpunkt und Leerzeichen ist nicht möglich.
Hinweis - Die Basic / Digest Access Authentication lässt sich bis auf Dateien anwenden. Bei einigen Browsern führt dies jedoch zur erneuten Nachfrage auf Verzeichnisebene.

Common Gateway Interfaces

[SERVER|VIRTUAL:X:CGI]

Zum Datenaustausch sowie zur Anbindung externer Laufzeitumgebungen und Anwendungen wird die Spezifikation 1.1 des Common Gateway Interfaces und somit PHP, Perl, Python und andere unterstütz. Optional steht auch FastCGI zur Verfügung.

Optional ist mit dem DCGI eine weitere an das CGI angelehnte Schnittstelle zu Anbindung externen Anwendungen und Laufzeitumgebungen verfügbar. Grundprinzip und Arbeitsweise entsprechen denen des CGIs. Auch beim DCGI erfolgt die Kommunikation über den Standard-I/O und die serverrelevanten Informationen werden als Umgebungsvariablen übermittelt. Hier unterscheidet sich jedoch die Form der Übermittlung. Werden diese beim CGI mit dem Aufruf der externen Anwendung oder Laufzeitumgebung als Systemvariablen übergeben, sind die Umgebungsvariablen beim DCGI ein Bestandteil vom Datenstrom. So beginnt der Datenstrom vom DCGI mit der Steuerzeichenfolge 0x07 0x07, danach folgen die Umgebungsvariablen bis zum ersten Auftreten vom Steuerzeichen 0x01. Ab hier wird der für das CGI typische Request-Body übertragen.

Der Vorteil vom DCGI liegt in der einfachen Weitergabe der Umgebungsvariablen. Somit können auch Systeme und Umgebungen genutzt werden, welche keine exklusive Umgebung besitzen oder keinen Zugriff auf die Umgebungsvariablen vom Betriebssystem haben.

Beispiel eines DCGI-Requests

[0x07][0x07]                                       
SERVER_PORT=80                                     
SERVER_PROTOCOL=HTTP/1.0                           
SERVER_SOFTWARE=Seanox-Devwex/1.2013.0707
CONTENT_LENGTH=7                                   
REQUEST_METHOD=POST                                
...                                                
[0x01]Test...                                      

Das Schema zur Formulierung der Common Gateway Interfaces

DATEIERWEITERUNG = METHODEN > ANWENDUNG [OPTION]

Übersicht der verfügbaren Optionen
Option
Beispielwert
Beschreibung
[I]
-
verwendet das DCGI
[C]
.../applications/test.cgi
voller Pfad inkl. Dateiname und Dateiendung
[P]
.../applications/
Pfad
[F]
test
Dateiname ohne Endung
[E]
.cgi
Dateiendung

Beispiele für die Einrichtung von Common Gateway Interfaces

CGI = POST GET > c:/example.exe

die Dateiendung cgi wird der Anwendung Example zugewiesen, welche bei Anfragen mit der Dateiendung cgi im Pfad gestartet wird, der Pfad zur Scriptdatei wird hier über die Umgebungsvariablen SCRIPT_FILENAME und PATH_TRANSLATED übergeben
CGI = POST GET > c:/example.exe [C]

die Dateiendung cgi wird der Anwendung Example zugewiesen, welche bei Anfragen mit der Dateiendung cgi im Pfad gestartet wird, der Pfad zur Scriptdatei wird hier der Anwendung als Startargument übergeben
CGI = POST GET > c:/example.exe [I]

die Dateiendung cgi wird der Anwendung Example zugewiesen, welche bei Anfragen mit der Dateiendung cgi im Pfad unter Verwendung vom DCGI gestartet wird, der Pfad zur Scriptdatei wird auch hier über die Umgebungsvariablen SCRIPT_FILENAME und PATH_TRANSLATED übergeben

Beispiel für den Einsatz von PHP, Perl, Java und native Web-Anwendungen

PHP = POST GET > c:/php/php.exe

der Dateierweiterung php wird PHP als auszuführende CGI-Anwendung zugewiesen
CGI = POST GET > c:/perl/bin/perl.exe [C]

der Dateierweiterung cgi wird Perl als auszuführende CGI-Anwendung zugewiesen
JAR = POST GET > java -jar [P][F].jar [I]

der Dateierweiterung jar wird Java als auszuführende DCGI-Anwendung zugewiesen.
JAR = POST GET > java -jar [C] [I]

der Dateierweiterung jar wird Java als auszuführende DCGI-Anwendung zugewiesen
EXE = POST GET > [C] [I]

die Dateierweiterung exe wird als auszuführende DCGI-Anwendung definiert
EXE = POST GET > [C]

die Dateierweiterung exe wird als auszuführende CGI-Anwendung definiert

Beispiele für die Einrichtung von Modulen

SSX = POST GET > com.seanox.ssx.Connector [M]

die Dateierweiterung ssx wird dem im Klassenpfad befindlichen Modul com.seanox.ssx.Connector zugewiesen

Übersicht bereitgestellter Umgebungsvariablen (Auswahl)
Umgebungsvariable
Beispielwert
Beschreibung
CONTENT_LENGTH
1000
Menge der mit dem Request-Body übertragenen Daten in Bytes
CONTENT_TYPE
text/plain
MIME-Typ der mit dem Request übergebenen Daten
DOCUMENT_ROOT
.../devwex/documents
physischer Pfad vom Wurzelverzeichnis der Web-Dokumente
GATEWAY_INTERFACE
CGI/1.1
vom Server unterstützte Version der CGI-Schnittstelle
HTTP_ACCEPT
*/*
mit dem Request übermittelte Liste der MIME-Typs, die vom Client unterstützt werden
HTTP_ACCEPT_ENCODING
gzip, deflate
mit dem Request übermittelte Liste der Kodierungsmethoden, die vom Client unterstützt werden
HTTP_ACCEPT_LANGUAGE
de
mit dem Request übermittelte Liste der vom Client unterstützten Landessprachen
HTTP_CONNECTION
Keep-Alive
mit dem Request übermittelte Informationen über den Status der HTTP-Verbindung zwischen Server und Client
HTTP_HOST
experimental.seanox.com
mit dem Request übermittelte Domain-Namen oder IP-Adresse der vom Client angeforderten Zieladresse
HTTP_USER_AGENT
Mozilla/4.0 (compatible; ...)
mit dem Request übermittelte Produkt- und Versionsinformationen des Clients
MODULE_OPTS
...ssi.Connector [allow:all] [M]
Informationen zum Modulaufruf mit allen Parametern
PATH
...
allgemeine Liste von Pfaden für die Suche nach Ressourcen und Anwendungen, wird optional über [SERVER:X:ENV] gesetzt
PATH_ABSOLUTE
/example.ssi
reale Pfadangabe der URL bei absoluten Pfaden
PATH_BASE
/example.ssi/folder/...
komplette Pfadangabe der URL
PATH_INFO
/folder/...
erweiterte Pfadangabe der URL bei absoluten Pfaden
PATH_TRANSLATED
.../devwex/documents/example.ssi
physischer Pfad der aufgerufenen Ressource im Dateisystem
QUERY_STRING
parameter=name
Liste der mit dem Request-URI übergebenen Parameter
REMOTE_ADDR
sirius.seanox.com
Name oder IP-Adresse des aufrufenden Clients
REMOTE_PORT
1573
Port des aufrufenden Clients
REQUEST_METHOD
POST
mit dem Request übermittelte HTTP-Anfragemethode
REQUEST_URI
/example.ssi/...?parameter=name
mit dem Request übermittelter HTTP-Pfad der aufgerufenen Ressource inklusive übergebener Parameter
SCRIPT_FILENAME
.../devwex/documents/example.ssi
physischer Pfad der aufgerufenen Ressource im Dateisystem
SCRIPT_NAME
/example.ssi/...
HTTP-Pfad der aufgerufenen Ressource
SCRIPT_URI
http://...seanox.com/example.ssi/...
kompletter HTTP-Pfad der aufgerufenen Ressource
SCRIPT_URL
/example.ssi
relativer HTTP-Pfad der aufgerufenen Ressource
SERVER_NAME
experimental.seanox.com
Name oder IP-Adresse des Servers im Netzwerk
SERVER_PORT
80
eingerichteter Port des Servers
SERVER_PROTOCOL
HTTP/1.0
Version des vom Server unterstützten HTTP-Protokolls
SERVER_SOFTWARE
Seanox-Devwex/...
Produktbezeichnung der installierten Server-Software
SYSTEMDRIVE
C:
allgemeine Angabe vom Laufwerk des Betriebssystem, wird für Microsoft Windows optional über [SERVER:X:ENV] gesetzt
SYSTEMROOT
C:\WINDOWS
allgemeine Angabe vom Pfad des Betriebssystem, wird für Microsoft Windows optional über [SERVER:X:ENV] gesetzt
UNIQUE_ID
FEK2VFTY26DHI584C5
auf den Request bezogene eindeutige Identifikationsnummer

Tipp - Endet in der Konfigurationsdatei ein Parameter oder Wert mit [+], wird der komplette Inhalt einer Zeile verwendet.

Bsp. PATH     = ./documents;./libraries;./system [+]
     PATH [+] = ./documents;./libraries;./system    
Tipp - Das Arbeitsverzeichnis der CGI-Anwendungen ist das von Devwex. Sollen z.B. Konfigurationsdateien wie die php.ini berücksichtigt werden, sollten diese in diesem Verzeichnis abgelegt werden.
Tipp - Zur Installation von PHP muss die Konfigurationsdatei php.ini in das Arbeitsverzeichnis von Devwex abgelegt oder dem PHP der Pfad mit dem Startparameter -c mitgeteilt werden. Ab Version 4.x von PHP sind die Einträge cgi.rfc2616_headers = 1 für die korrekte Arbeitsweise der PHP-Funktion header(); und für die Ausführungssicherheit cgi.force_redirect = 0 und cgi.redirect_status_env = 302 erforderlich. Letzteres kann alternativ in der Sektion [SERVER:X:ENV] der Konfigurationsdatei devwex.ini durch Eintrag REDIRECT_STATUS = 302 gesetzt werden.
Tipp - CGI- und DCGI- Anwendungen sowie Skripte können in allen Verzeichnissen vom DOCROOT genutzt werden. Ein spezielles CGI-BIN ist nicht vorgesehen.
Tipp - Ausführbare Windows-Anwendungen (*.exe, *.com) können unter Windows auch mit einer alternativen Dateiendung verwendet werden. Wenn z.B. CGI- oder DCGI-Anwendungen als Windows-Anwendungen (*.exe oder *.com) einsetzten werden, kann für diese eine beliebige Dateiendung vergeben und verwenden werden. So lässt sich zum Beispiel die Datei example.exe in example.cgi umbennen und verwenden. Die Konfiguration gestaltet sich dann wie folgt: CGI = POST GET > [C]
Tipp - Mit dem Methodeneintrag ALL werden alle eingehenden Methoden verarbeitet.

Umgebungsvariablen

[SERVER|VIRTUAL:X:ENV]

Umgebungsvariablen stellen externen Anwendungen und Laufzeitumgebungen essentielle und zusätzliche Informationen zum Betriebssystem bereit.

Als Erweiterung der servereigenen Umgebungsvariablen, werden in dieser Sektion für das CGI und DCGI zusätzlich benötigte Umgebungsvariablen definiert.

Das Schema zur Formulierung der Umgebungsvariablen

PARAMETER = WERT

Beispiele für die Einrichtung Umgebungsvariablen

WEBSERVER = DEVWEX

die Umgebungsvariable WEBSERVER wird mit dem Wert DEVWEX eingerichtet
Hinweis - CGI-Anwendungen ermitteln Systemressourcen z.B. für Datenbank oder Netzwerk meist über die Umgebungsvariablen. Daher sollten PATH, SYSTEMDRIVE, SYSTEMROOT und für PHP REDIRECT_STATUS = 302, als Umgebungsvariablen in der Konfigurationsdatei devwex.ini gesetzt werden. Ohne Wert werden Umgebungsvariablen nicht berücksichtigt.
Tipp - Mit der Option [?] am Ende eines Parameters, kann diesem ein dynamischer Wert zugewiesen werden, welcher beim Programmstart über Startargumente oder System-Properties festgelegt wird. Somit können z.B. systemrelevante Umgebungsvariablen, wie PATH, SYSTEMDRIVE und SYSTEMROOT für Windows, dynamisch übergeben werden. Weitere Informationen zu diesem Thema sind auch im Abschnitt zur Konfigurationsdatei enthalten.

Filter

[SERVER|VIRTUAL:X:FLT]

Die Zugriffe auf die Server und virtuellen Hosts können über speziell definierte Regeln gesteuert werden. Eingehende Anfragen (Requests) werden dabei vor der Verarbeitung behandelt. Individuelle Fehlerseiten und automatische Weiterleitungen werden dabei unterstützt.

Das Schema zur Formulierung der Filter

NAME = METHODE BEDINGUNG FUNKTION PARAMETER WERT [A] ... > VERWEIS [R]

Die Angabe von einem Verweises ist für die Filterdefinitionen optional.
Name
Wert
Beschreibung
NAME
...
kann freigewählt werden
METHODE
GET|POST|PUT|ALL|...
auf die zu reagierende HTTP-Methode
BEDINGUNG
IS|NOT|ALWAYS
Bedingung für den Filter
FUNKTION
STARTS|EQUALS|CONTAINS|ENDS|EMPTY
Art des Wertevergleichs
PARAMETER
...
zu prüfender Parameter
WERT
...
zu kontrollierende Wert
OPTION
[A]
Logische Und-Verknüpfung - Zur logischen Verknüpfung mehrerer Bedingungen.
[R]
Redirection - Verweist auf eine entsprechende Adresse und leitet eine Weiterleitung ein. Eine Fehlerseite wird nicht erstellt.
[M]
Module - Mit dieser Option wird auf ein HTTP-Modul verwiesen. Das Ansprechen der Module ist dabei kein finaler Schritt. Ein Beenden der Filtersequenz erfolgt hier nur, wenn ein Modul den Response-Status ändert oder Daten an den Client sendet.

Für die Filterfunktion sind alle im Header des Requests enthaltenen Felder und einige erweiterte Parameter sowie die Umgebungsvariablen aus dem CGI-Umfeld verfügbar. Die Gross- und Kleinschreibung wird bei den Parametern, Feldern und Werten nicht berücksichtigt.

Beispiel für einen Request

GET /directory/file.cgi?value=123 HTTP/1.1
Accept-Encoding: gzip, deflate            
Accept-Language: de                       
Accept: */*                               
User-Agent: Browser                       
Host: www.xxx.zzz                         

Die enthaltenen Felder, Parameter und Werte sind abhängig vom Inhalt des Requests. Der Request-Body wird bei Filtern nicht ausgelesen, womit Parameter, die wie bei der HTTP-Methode POST im Body übergeben werden, nicht zur Verfügung stehen.
Parameter
Wert
Beschreibung
REQUEST
GET /directory/file.cgi?value=123 HTTP/1.1
Request
METHOD
GET
HTTP-Methode
PATH
/directory/file.cgi
Pfad des Requests
QUERY
value=123
Query
PROTOCOL
HTTP
Protokoll
VERSION
1.1
Version des Protokolls

Beispiele für den Einsatz von Filtern

FILTER-A = GET NOT EQUALS ACCEPT-LANGUAGE EN

Die Methode GET wird verweigert, wenn im Request-Header das Feld Accept-Language nicht EN entspricht.
FILTER-B = GET NOT CONTAINS ACCEPT-LANGUAGE EN

Die Methode GET wird verweigert, wenn im Request-Header das Feld Accept-Language nicht EN enthält.
FILTER-C = GET IS EQUALS ACCEPT-LANGUAGE EN

Die Methode GET wird verweigert, wenn im Request-Header das Feld Accept-Language EN entspricht.
FILTER-D = GET IS CONTAINS ACCEPT-LANGUAGE EN

Die Methode GET wird verweigert, wenn im Request-Header das Feld Accept-Language EN enthält.
FILTER-E = GET IS STARTS REMOTE_ADDR 192.168.
Die Methode GET wird verweigert, wenn die CGI-Umgebungsvariable REMOTE_ADDR mit 192.168. beginnt.
FILTER-F = GET IS ENDS SCRIPT_URL .dat

Die Methode GET wird verweigert, wenn die CGI-Umgebungsvariable SCRIPT_URL mit .dat endet.
FILTER-G = GET IS CONTAINS PATH /documents [A] GET IS EMPTY REFERER

Die Methode GET wird verweigert, wenn im Request-Header der Parameter PATH /documents enthält und das Feld REFERER im Request-Header leer ist.
FILTER-H = GET IS CONTAINS PATH /private > ../system/error.403.html

Die Methode GET wird verweigert, wenn im Request-Header der Parameter PATH /private enthält, als Template für der Statusinformation 403 wird dabei auf die Datei ../system/error.403.html verwiesen.
FILTER-I = GET IS CONTAINS PATH /private > http://www.xxx.zzz/403.php [R]

Bei der Methode GET erfolgt, wenn im Request-Header der Parameter PATH /private enthält, die Weiterleitung zur Adresse http://www.xxx.zzz/403.php.
FILTER-J = GET IS ENDS PATH .do > example.Connector [A:...] [B:...] [M]

Bei der Methode GET und wenn im Request-Header der Parameter PATH mit .do endet, wird das Modul Connector mit den zusätzlichen Parametern A und B aus dem Paket example aufgerufen, welches sich im Klassenpfad des Server befinden muss.
FILTER-K = ALL ALWAYS > example.Connector [A:...] [B:...] [M]

Bei allen Anfragen wird das Modul Connector mit den zusätzlichen Parametern A und B aus dem Paket example aufgerufen, welches sich im Klassenpfad des Server befinden muss

Statuscodes

[STATUSCODES]

HTTP-Anfragen werden vom Server immer mit einem Statuscode beantwortet. Damit wird der Client darüber informiert, ob die Anfrage erfolgreich bearbeitet wurde, ein Fehler aufgetreten ist oder wo bzw. wie eine gewünschte Information erreichbar ist. Neben dem Statuscode wird zudem ein Statustext übermittelt. Dieser optionale Text wird hier für die einzelnen Statuscode definiert. Standardwerte sind bei Devwex nicht implementiert. Die Angabe erfolgt global und wird somit von allen Servern und virtuellen Hosts verwendet.

Das Schema zur Formulierung der Statuscodes

CODE = TEXT

Beispiele für die Deklaration des Statuscodes

200 = Success

Header des Response
HTTP/1.0 200 Success
404 = Document Not Found

Header des Response
HTTP/1.0 404 Document Not Found

Mimetypes

[MIMETYPES]

Über den MIME-Type (Multipurpose Internet Mail Extensions), auch Content-Type oder Internet-Media-Type genannt, werden die mit der Serverantwort (Response) übermittelten Daten klassifiziert. Die Datentypen werden hier den entsprechenden Medientypen und Subtypen zugeordnet. Standardwerte sind bei Devwex nicht implementiert. Die Angabe erfolgt global, durch Leerzeichen getrennt und wird somit von allen Servern und virtuellen Hosts verwendet.

Das Schema zur Formulierung der Mimetypes

MIMETYPE = DATEIERWEITERUNG DATEIERWEITERUNG ...

Beispiel für die Mimetype-Zuweisung

application/octet-stream = com exe class

Dateien mit der Dateierweiterung *.com, *.exe und *.class werden dem Mimetype application/octet-stream zugeordnet.
Seanox Software Solutions since 1996
Advanced Server Developing SEANOXDEVWEX