Seanox Application Developing
Copyright (C) 2004 Seanox
Devwex 1.2004.0124
 

 
Inhalt  
•   Allgemeines
•   Lizenzbedingungen
•   Leistungsspektrum
•   Systemanforderung
•   Installation
•   Konfigurationsdatei
•   Basisoptionen
•   Server
•   virtuelle Hosts
•   Basisoptionen
•   SSL / TLS
•   Virtuelle Verzeichnisse
•   Basic Authentication
•   Systemreferenzen
•   Common Gateway Interfaces
•   Umgebungsvariablen
•   Filter
•   Module
•   Responsecodes
•   Mimetypes
  •   [BASEOPTIONS]
•   [INITIALIZE]
•   [SERVER]
•   [SERVER:X:BAS]
•   [SERVER:X:REF]
•   [SERVER:X:CGI]
•   [SERVER:X:ENV]
•   [SERVER:X:FLT]
•   [SERVER:X:MOD]
•   [RESPONSECODES]
•   [MIMETYPES]
  •   [VIRTUALHOST]
•   [VIRTUALHOST:X:BAS]
•   [VIRTUALHOST:X:REF]
•   [VIRTUALHOST:X:CGI]
•   [VIRTUALHOST:X:ENV]
•   [VIRTUALHOST:X:FLT]
•   [VIRTUALHOST:X:MOD]
 

 
Allgemein   Devwex ist ein auf Java basierender Webserver für die Kommandozeile, der über eine umfangreiche Konfiguration verfügt. Das ca. 29k Java Binary unterstützt unter anderem virtuelle Hosts, IP/Port Sharing, Remote Access/Control, Indexservice, Multithreading, Filtering, Module sowie DCGI/CGI1.1 und SSL/TLS.
 

 
Lizenzbedingungen   NOTE - Main part of the Licence Agreement is the german Licence Agreement (Lizenzbedingungen).
Place of jurisdiction is Germany. Language of jurisdiction is german.


Seanox Application Developing ist ein Oliver Schmuhl Projekt, im Folgenden kurz Seanox genannt. Diese Software unterliegt den folgenden Lizenzbedingungen von Seanox.

Seanox übernimmt keine Haftung für Schäden jeglicher Art, auch nicht für Neben-, Folge- oder indirekten Schäden welche sich aus der Benutzung der Software oder der beiliegenden Dokumentation ergeben können, und zwar ungeachtet der Schadensursache und der Grundlage des Haftungsanspruchs. Installationen und Benutzung der Software sind kostenfrei sowohl im privaten als auch im kommerziellen Umfeld. Wenn Sie das Projekt finanziell unterstützen wollen, wenden Sie sich bitte direkt an Seanox. Die private nichtkommerzielle Weitergabe der Software auf Datenträgern ist gestattet. Die Veröffentlichung oder Spiegelung auf WWW- und FTP- Servern sowie die Bereitstellung auf Medien jeglicher Art bedarf der schriftlichen Zustimmung durch Seanox. Die kommerzielle Verwertung oder Verteilung der Software ist nur mit schriftlicher Zustimmung durch Seanox gestattet.

Sie nehmen zur Kenntnis, dass Seanox sowohl Urheber als auch Eigentümer der Software ist. Sämtliche Rechts- und Eigentumsansprüche bleiben Seanox vorbehalten. Sie erkennen an, dass die Lizenzgewährung keinen Verkauf der Software darstellt und Ihnen aus dem oben aufgeführten Vertrag in bezug auf die Software keinerlei Ansprüche auf Patente, Kopien, Branchengeheimnisse sowie Marken- oder andere Rechte erwachsen.

HINWEIS - Die enthaltene Distribution von Java und/oder der JSSE unterliegen den Lizenzbestimmungen von Sun Microsystems (java.sun.com).

Oliver Schmuhl
Berlin, 2003-04-15
oliver.schmuhl@seanox.de
 

 
Leistungsspektrum   Art   Beschreibung
 
  virtuelle Hosts   In der Konfiguration von Devwex werden virtuelle Hosts für IP/Port Sharing unterstützt.
 
  IP/Port Sharing   Durch die globale Präsents der virtuellen Hosts innerhalb der Konfigurationsdatei stehen diese allen physischen Hosts zur Verfügung wodurch die virtuellen Hosts unter mehren IP Adressen und Ports zur Verfügung stehen.
 
  Remote Access   Devwex gestattet per Telnet einen frei konfigurierbaren Fernzugriff für Statusabfragen, Restart und Stop.
 
  Indexservice   Verzeichnisse des Dateisystems werden automatisch als navigierbare HTML Dokumente dargestellt. Durch die Verwendung von Templates können diese individuell für alle physischen und virtuellen Hosts gestaltet werden.
 
  Multithreading   In der Konfiguration von Devwex können mehrfach unabhängige physische und virtuelle Hosts definiert werden. Unter anderem wird dabei auch eine Vererbung der Host Konfigurationen unterstützt.
 
  Filtering   Die Zugriffe auf die physischen und virtuellen Hosts kann über speziell definierte Regeln gesteuert werden. Individuelle Fehlerseiten und automatische Weiterleitungen werden dabei unterstützt.
 
  Modules   Über das integrierte Modulkonzept können einzelne Funktionalitäten des Servers durch externe Komponenten geändert, erweitert oder neu hinzugefügt werden.
 
  HTTP   Basierend auf der Spezifikation 1.0 des HTTP werden neben GET, POST und HEAD auch PUT und DELETE des HTTP 1.1 unterstützt. Weitere Methoden können über Module und über das DCGI bzw. CGI bereitgestellt werden. Beim Response wird der Serverstatus 200, 201, 300, 302, 304, 400, 401, 403, 404, 405, 406, 411, 424, 500 sowie 503 unterstützt, wobei auch diese über die bereitstehenden Schnittstellen erweitert und modifiziert werden können.
 
  SSL   Zur gesicherten Übertragung von Daten unterstütz Devwex unter anderem Secure Socket Layer - SSL und Transport Layer Security - TLS. Die Zuweisung der Zertifikate kann für jeden physischen Hosts einzeln und durch Vererbung in Gruppen oder global erfolgen.
 
  DCGI   DCGI wurde speziell für Devwex entwickelt und stellt eine offene, an das CGI 1.1 angelehnte, Schnittstelle für verschiedenste Programmiersprachen wie Java, VB, VB(A) und andere zum Webserver zur Verfügung.
 
  CGI   Devwex unterstütz die Spezifikation 1.1 des Common Gateway Interfaces und somit PHP, Perl, Python und andere.
 

 
Systemanforderung   Software   Java Runtime 1.2.x bis 1.3.x optional mit JSSE
Java Runtime 1.4.0 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 Version 1.4.0 ist diese Erweiterung Bestandteil der Java Laufzeitumgebung (JRE) bzw. der Java Entwicklungsumgebung (JDK). Für die Java Versionen 1.2.x bis 1.3.x muss die Java Laufzeitumgebung erweitert werden. Dazu werden die im Verzeichnis ./devwex/libraries enthaltenen Dateien jcert.jar, jnet.jar und jsse.jar in das Verzeichnis ./java/jre/lib/ext/ der Java Laufzeitumgebung kopiert oder in den Classpath von Devwex aufgenommen.

Weitere Informationen zu der Java Erweiterung stehen unter http://java.sun.com/products/jsse zur Verfügung.

Die Verwendung der JSSE Bibliotheken ist optional.
Devwex kann auch ohne diese Erweiterung eingesetzt werden unterstützt dann aber keine Secure Layer.

Start von Devwex
 
  Java Archiv   java -cp devwex.jar [-Dparameter=value] com.seanox.devwex.Service [OPTION]
 
  Startskript   devwex.bat [OPTION]
devwex.sh  [OPTION]
 
  Option   Beschreibung
 
  RESTART   beendet alle aktiven Server und startet entsprechend der Konfiguration neu
  START   startet entsprechend der Konfiguration
  STATE   zeigt die Start- und die aktuelle Systemzeit sowie alle laufenden Server
  STOP   beendet Devwex mit allen aktiven Servern
  TIME   zeigt die Start- und die aktuelle Systemzeit
 
 
 
  TIP - Durch die Verwendung der Startskripte werden beim Aufruf des Servers die Bibliotheken aus dem Verzeichnis ./devwex/libraries und wichtige Umgebungsvariablen vom System automatisch übernommen.
 
  TIP - Mit Devcox steht ein webbasiertes Administrationstool für den Devwex Webserver in englischer Sprache zur Verfügung, mit dem die Konfiguration und Administration direkt über den Webbrowser erfolgen kann. Das ca. 80k Byte grosse Java Binary ist in wenigen Sekunden installiert, konfiguriert und betriebsbereit.
 
  TIP - Zur Nutzung des Remote Control/Access über Telnet, ist eine Verbindung zu der in der Konfiguration festgelegten BASEOPTIONS:REMOTEADDRESS und dem entsprechendem BASEOPTIONS:REMOTEPORT zum Server herzustellen. Als Kommandos werden die Kommandozeilen Optionen verwendet.

Bsp.  telnet 127.0.0.1 25000   
                               
      STATE                    
      TIME: 2002-10-23 06:00:00
      TIUP: 2002-10-23 06:00:00
                               
      SERV: 192.168.10.10:80   
 
  TIP - Durch den Eintrag der IP Adressen der Server und verwendeter Netzwerkressourcen wie z.B. Datenbanken, in der host Datei von Windows (Bsp. C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS) bzw. von Unix o.ä. (Bsp. /etc/hosts) kann die Ermittlung der Hostnamen beschleunigt werden.
 

 
Konfigurationsdatei
Allgemein
  Die Konfigurationsdatei ist in sechs Bereiche untergliedert.
 
  Bereich   Beschreibung
 
  [BASEOPTIONS]   allgemeine Server Optionen wie für den Fernzugriff oder andere Module
 
  [INITIALIZE]   Modulinitialisierung mit dem (Re)Start des Service
 
  [SERVER]   der Konfigurationsbereich für die Server enthält alle Einstellungen für die betriebenen Hosts
 
  [VIRTUALHOST]   der Konfigurationsbereich für die virtuellen Hosts enthält alle dafür benötigen Einstellungen
 
  [RESPONSECODES]   die für Responsecodes zur verwendenden Informationen werden hier definiert
 
  [MIMETYPES]   die zu verwendenden Mimetypes sind in diesem Bereich enthalten
 
 
 
  Die für die Konfiguration von Devwex verwendete Ini-Datei wurde im Format zur klassischen Form erweitert. Die Gliederung erfolgt wie gewohnt in Blöcken denen nachfolgend und zeilenweise Parameter mit Wertzuweisung zugeordnet werden. Bei den Namen von Blöcken und Parametern wird die Gross- und Kleinschreibung nicht unterschieden. Mehrfache Deklarationen werden zusammengeführt wobei bereits vorhandene Einträge überschrieben und neue hinzugefügt werden. Dadurch können Blöcke in der Konfiguration auch geteilt werden, was die Übersichtlichkeit aber meist erschwert.

In den einzelnen Zeilen wird das Semikolon als Kommentarzeichen interpretiert. Nachfolgende Zeichen werden so nicht in die Wertzuweisung oder Deklaration einbezogen. Mit der Option [+] am Ende eines Parameters und/oder einer Wertzuweisung kann die Kommentarfunktion für die Wertzuweisung der entsprechenden Zeile abgeschalten werden. Somit kann auch das Semikolon in der Wertzuweisung verwendet werden.

Eine Wertzuweisung kann fest oder variable erfolgen. Durch die Option [?] am Ende eines Parameters wird versucht für diesen eine Wertzuweisung über die System Properties der JAVA Umgebung zu ermitteln. Kann zum diesem Parameter kein Wert ermittelt werden, wird der optional eingetragene zugewiesen.

Bsp.  001 [PARAMETER]                           ;Kommentar
      002   PARAM-A         = WERT-1            ;Kommentar
      003   PARAM-B         = WERT-2; WERT-3 [+]          
      004   PARAM-C     [+] = WERT-4; WERT-5              
      005   PARAM-D  [?][+] = WERT-6; WERT-7              
      006   PARAM-E  [?]    = WERT-8            ;Kommentar
      007   PARAM-F  [?]                        ;Kommentar

Zeile 001 - Der Block mit dem Namen "PARAMETER" wird definiert. Die nachfolgenden Zeichen werden ab dem Semikolon als Kommentar interpretiert.

Zeile 002 - Dem Parameter "PARAM-A" wird der Wert "WERT-1" zugewiesen. Die nachfolgenden Zeichen werden ab dem Semikolon als Kommentar interpretiert.

Zeile 003 - Dem Parameter "PARAM-B" wird der Wert "WERT-2; WERT-3" zugewiesen. 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.

Zeile 004 - Ähnlich der Zeile 003 wird dem Parameter "PARAM-C" der Wert "WERT-2; WERT-3" zugewiesen. Durch die Option [+] am Ende des Parameters wird der Zeilenkommentar abgeschaltet und alle Zeichen für die Wertzuweisung verwendet. Die Eingabe eines Kommentars ist in dieser Zeile nicht möglich.

Zeile 005 - Die Wertezuweisung für den Parameter "PARAM-D" erfolgt dynamisch. Dabei wird versucht, den Parameter über die System Properties der JAVA Umgebung aufzulösen. Dazu muss dieser Bestandteile der aktuellen Laufzeitumgebung sein oder kann mit dem Programmstart von Devwex in der Form -Dparameter=wert übergeben werden. Die Gross- und Kleinschreibung des Parameters kann unbeachtet bleiben. So übergebene Parameter werden mit der kompletten Wertzuweisung berücksichtigt, Kommentare werden hierbei nicht unterstützt. Kann für den Parameter kein Wert über die System Properties ermittelt werden wird die eingetragene Wertzuweisung "WERT-6; WERT-7" verwendet. Ein Kommentar ist durch Verwendung der Option [+] nicht möglich.

Zeile 006 - Ähnlich der Zeile 005 wird auch hier der Parameter "PARAM-E" dynamisch über die System Properties der JAVA Umgebung aufgelöst. Ist dies nicht möglich wird die eingetragene Wertzuweisung verwendet. Ohne die Option [+] kann in dieser Zeile auch ein Kommentar verwendet werden.

Zeile 007 - Wie in den Zeilen 005 und 006 wird auch hier der "PARAM-F" dynamisch über die System Properties der JAVA Umgebung aufgelöst. Ist dies nicht möglich wird der Parameter ohne Wertzuweisung verarbeitet. Ohne die Option [+] kann in dieser Zeile auch ein Kommentar verwendet werden.
 

 
[BASEOPTIONS]
Allgemein
  Allgemeine Server Optionen wie für den Fernzugriff oder andere Module werden hier festgelegt. Die Einrichtung der Basisoptionen erfolgt global und wird von allen physischen und virtuellen Hosts verwendet.
 
  Parameter   Wert   Beschreibung
 
  REMOTEADDRESS   127.0.0.1   Serveradresse für den Remote Access
 
  REMOTEPORT   25000   Serverport für den Remote Access
 

 
[INITIALIZE]
Allgemein
  Hier eingetragene Module werden mit dem (Re)Start des Service initialisiert und über bestimmte Ereignisse informiert. Bei der Initialisierung wird automatisch immer nach dem Modul com.seanox.devwex.Container gesucht, womit dieses nicht eingetragen werden muss.

Das Schema zur Formulierung der Modulinitialisierung

NAME = RESSOURCE

Beispiel für die Modulinitialisierung

CONTAINER = com.seanox.devwex.Container
 

 
[SERVER]
Allgemein
  Server stellen als physischer Host, den Zugriffe im Netzwerk für eine spezielle Adresse an einem speziellen Port zur Verfügung. Mit dem Start von Devwex werden alle in der Konfigurationsdatei angegebenen Server gestartet. Auf die gestarteten Server wird immer direkt zugegriffen.

Das Schema zur Formulierung der Server

[SERVER:NAME:BLOCKNAME]

Der in den Konfigurationsblöcken verwendete Blockname ist frei wählbar und kann unabhängig vom [SERVER:X:BAS] NAME verwendet werden.

Die Konfiguration des Servers setzt sich aus sechs Blöcken zusammen.
 
  Blockname   Beschreibung
 
  [SERVER:X:BAS]   Basiskonfiguration
  [SERVER:X:REF]   virtuelle Verzeichnisse
  [SERVER:X:ENV]   Umgebungsvariablen
  [SERVER:X:CGI]   CGI Zuweisung und Konfiguration
  [SERVER:X:FLT]   Filterkonfiguration
  [SERVER:X:MOD]   Modulkonfiguration
 

 
[VIRTUALHOST]
Allgemein
  Die virtuellen Hosts stehen den Servern zur Verfügung. Dabei gilt, alle virtuellen Hosts können von allen Servern genutzt werden. Somit ist IP- und Port Sharing für die virtuellen Hosts möglich. Bei der Konfiguration gilt, dass der virtuelle Host alle Konfigurationen des aufrufenden Servers verwendet. Alle Parameter die für den virtuellen Host angegeben werden, überschreiben die vom Server vorgegebenen. Die Verwendung der virtuellen Hosts richtet sich nach dem beim Server eintreffenden Request. Entsprechend dem dort enthaltenen Host wird der namensgleiche virtuelle Host verwendet.

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


Entsprechend dem Beispiel müssen die Blockeinträge für den virtuellen Host wie folgt in der Konfigurationsdatei angelegt werden.
 
  Blockname   Beschreibung
 
  [VIRTUALHOST:WWW.XXX.ZZZ:BAS]   Basiskonfiguration
  [VIRTUALHOST:WWW.XXX.ZZZ:REF]   virtuelle Verzeichnisse
  [VIRTUALHOST:WWW.XXX.ZZZ:ENV]   Umgebungsvariablen
  [VIRTUALHOST:WWW.XXX.ZZZ:CGI]   CGI Zuweisung und Konfiguration
  [VIRTUALHOST:WWW.XXX.ZZZ:FLT]   Filterkonfiguration
  [VIRTUALHOST:WWW.XXX.ZZZ:MOD]   Modulkonfiguration
 
  Die Konfiguration der virtuellen Hosts gleicht der, der Server. Die Einträge für ADDRESS, SOCKET und PORT entfallen hier.
 

 
[VIRTUALHOST:X:BAS]
[SERVER:X:BAS]
Basisoptionen
  Dieser Block stellt die allgemeine Konfiguration für Server und virtuelle Hosts zur Verfügung. Beide Konfigurationen gleichen sich, wobei die Parameter ADDRESS, PORT, SOCKET und SERVICE von den virtuellen Hosts nicht berücksichtigt werden.
 
  Parameter   Wert   Beschreibung
 
  IMPLEMENTS   SERVER ..., VIRTUALHOST ...   implementiert die Konfiguration des folgenden Servers oder virtuellen Hosts
 
  CONNECTOR   ...   die Definition des Connectors, optional kann auch [SERVER:X:MOD] SERVER:CONNECTOR verwendet werden
 
  ADDRESS   AUTO, LOCALHOST, IP, NAME   die lokale Adresse des Servers AUTO verwendet hierbei alle im System verfügbaren IP Adressen
 
  PORT   ...   der lokale Port des Servers
 
  SOCKET   NORMAL, SECURE   das Transferschema, SECURE aktiviert die Verwendung von Zertifikaten zur Datenverschlüsselung
 
  SERVICE   ...   Moduldefinition zur Requestverarbeitung, optional kann auch [SERVER:X:MOD] SESSION:SERVICE verwendet werden
 
  IDENTIFY   ON, OFF   Option zur Übermittlung vom Server-Namen mit dem CGI
 
  MAXACCESS   100   maximale Anzahl der gleichzeitigen Sessions
 
  BLOCKSIZE   65535   die Grösse in Bytes in der Datenblöcke verarbeitet werden
 
  INTERRUPT   10   Unterbrechungsdauer für Systemprozesse in Millisekunden
 
  TIMEOUT   300000   maximale Datenstromleerlaufzeit in Millisekunden die bei überschreiten ein Timeout auslösen - der Wert 0 ignoriert das Timeout
 
  METHODS   GET, POST, HEAD, PUT, DELETE   Methoden die der Server verarbeiten darf
 
  COMMAND   ...   Prozess oder Systemkommando das mit dem Zugriff gestartet wird, optional kann dieser wie das CGI oder DCGI verwendet werden
 
  ACCESSLOG   ../system/access.log   Logdatei der Zugriffe, wird keine Angabe gemacht wird zur Datenausgabe der Standard IO genutzt
 
  SYSROOT   ../system   Pfadangaben für die Systemdateien
 
  DOCROOT   ../documents   Pfadangaben für die Web Dokumente
 
  INDEX   ON, OFF   Option für den Indexservice der Verzeichnisse
 
  MIMETYPE   application/octet-stream   Standard Mimetype, dieser wird verwendet wenn der geforderte Mimetype nicht in der Mimetypeliste enthalten ist
 
  DEFAULT   index.htm, index.html ...   die beim Aufruf von Verzeichnissen zu verwendeten Standard Dokumente
 
 
 
Secure Socket Layer
Transport Layer Security
SSL / TLS
  Zur gesicherten Übertragung von Daten unterstütz Devwex unter anderem Secure Socket Layer - SSL und Transport Layer Security - TLS. Die Zuweisung der Zertifikate kann für jeden physischen Hosts einzeln und durch Vererbung in Gruppen oder global erfolgen.
  Parameter   Wert   Beschreibung
 
  SSL:PROTOCOL   TLS, SSL, ...   das Secure Layer Protokoll, SSL Secure Socket Layer, TLS Transport Layer Security, Standard wenn nicht angegeben TLS
 
  SSL:ALGORITHM   SunX509, ...   Verschlüsselung Algorithmus, Standard wenn nicht angegeben SunX509
 
  SSL:CLIENTAUTH   ON, OFF   ON aktiviert die Clientauhtenisierung, Standard wenn nicht angegeben OFF
 
  KEYSTORE:FILE   ...   Pfad der Keystore Datei
 
  KEYSTORE:TYPE   JKS, ...   Art des Keystores, Standard wenn nicht angegeben JKS
 
  KEYSTORE:PASSWORD   ...   Passwort für den Keystore
 
  Für SSL und TLS wird die Java Secure Socket Extension (JSSE) verwendet. Ab Version 1.4.0 ist diese Erweiterung Bestandteil der Java Laufzeitumgebung (JRE) bzw. der Java Entwicklungsumgebung (JDK). Für die Java Versionen 1.2.x bis 1.3.x muss die Java Laufzeitumgebung erweitert werden. Dazu werden die im Verzeichnis ./devwex/libraries enthaltenen Dateien jcert.jar, jnet.jar und jsse.jar in das Verzeichnis ./java/jre/lib/ext/ der Java Laufzeitumgebung kopiert.

Weitere Informationen zu der Java Erweiterung stehen unter http://java.sun.com/products/jsse zur Verfügung.

Die Erstellung des Zertifikates (Keystore).

./java/bin/keytool -genkey -alias devwex -keystore keystore -keyalg RSA -validity 365
                                                                                     
Geben Sie das Keystore-Passwort ein: default                                         
                                                                                     
Wie lautet Ihr Vor- und Nachname?                                                    
 [Unknown]:  Peter Mustermann                                                        
Wie lautet der Name Ihrer organisatorischen Einheit?                                 
 [Unknown]:  -                                                                       
Wie lautet der Name Ihrer Organisation?                                              
 [Unknown]:  -                                                                       
Wie lautet der Name Ihrer Stadt oder Gemeinde?                                       
 [Unknown]:  -                                                                       
Wie lautet der Name Ihres Bundeslandes oder Ihrer Provinz?                           
 [Unknown]:  -                                                                       
Wie lautet der Landescode (zwei Buchstaben) für diese Einheit?                  
 [Unknown]:  DE                                                                      
Ist CN=Peter Mustermann, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=DE richtig? 
 [Nein]:  ja                                                                         
                                                                                     
Geben Sie das Passwort für <devwex> ein.                                
(EINGABETASTE, wenn Passwort dasselbe wie für Keystore):  default               

Wird beim Keytool kein Zielverzeichnis mit -keystore angegeben, wird das generierte Zertifikat wird 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 des Zertifikates. 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:XXX:BAS]              
  ...                         
  SOCKET            = SECURE  
  PORT              = 443     
                              
  SSL:PROTOCOL      = TLS     
  SSL:ALGORITHM     = SunX509 
  SSL:CLIENTAUTH    = OFF     
                              
  KEYSTORE:FILE     = keystore
  KEYSTORE:TYPE     = JKS     
  KEYSTORE:PASSWORD = default 
  ...                         

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

[SERVER:XXX:BAS]              
  ...                         
  SOCKET            = SECURE  
  PORT              = 443     
                              
  KEYSTORE:FILE     = keystore
  KEYSTORE:PASSWORD = default 
  ...                         

Zur Aktivierung des Secure Layers muss der SOCKET des Servers auf SECURE gesetzt sein.
 

 
[VIRTUALHOST:X:REF]
[SERVER:X:REF]
Virtuelle Verzeichnisse
  Zur Konfiguration der virtuellen Verzeichnisse und Systemreferenzen stellt dieser Datenblock die entsprechenden Definitionen zur Verfügung.

Das Schema zur Formulierung der virtuellen Verzeichnisse

NAME = VIRTUELL >> PHYSISCH [OPTION]
 
  Option   Beschreibung
 
  [A]   Absolute - mit dieser Option verwenden alle angeforderten Verzeichnisse die das virtuelle oder physische Verzeichnis im Pfad enthalten das angegebene physische Verzeichnis
 
  [C]   Cancel - mit dieser Option kann das entsprechende virtuelle oder physische Verzeichnis für den Zugriff gesperrt werden
 
  [R]   Redirection - mit dieser Option wird für das entsprechende virtuelle oder physische Verzeichnis eine automatische Weiterleitung zu der angegebenen Adresse eingerichtet
 
  [M]   Modul - mit dieser Option werden Module als Webanwendung eingebunden. Die Pfadverarbeitung erfolgt dabei wie bei absoluten Verzeichnissen und werden der Anwendung übergeben.
 
  Beispiele für den Einsatz virtueller Verzeichnisse
 
 
DIRECTION:A = /system  >> ../system
  für das angeforderte Verzeichnis /system wird das physische Verzeichnis ../system verwendet
 
 
DIRECTION:B = /doc     >> ../documents [A]
  für die folgenden Anforderungen
/documents
/documentation
/doc/test.cgi?cmd=123
wird auf das physische Verzeichnis ../documents ohne Dateiangabe zugegriffen
 
 
DIRECTION:C = /program >> ../program [C]
  der Zugriff auf das angeforderte Verzeichnis /program wird verweigert
 
 
DIRECTION:D = /test    >> http://www.xxx.zzz [R]
  die Anforderung des Verzeichnisses /test wird an http://www.xxx.zzz weitergeleitet
 
 
DIRECTION:E = /control >> example.Connector [M]
  mit der Anforderung des Verzeichnisses /control wird die Klasse Connector des Packages example welches sich im Classpath des Servers befinden muss, als Modul ausgeführt
 
 
 
Basic Authentication   Das Schema zur Formulierung von Benutzern

NAME = VIRTUELLES VERZEICHNIS [ACCESS:USER:PASSWORD:TEXT]

Die Angabe eines Textes für den Anmeldedialog ist optional. Bei der Verwendung von mehreren Benutzern genügt die einmalige Angabe in einer beliebigen Deklaration für das entsprechende Verzeichnis.

Beispiele für Basic Authentication

USER:A:A = /access [access:ua:pa:Section-A]                  
USER:B:A = /access [access:ub:pb]                            
USER:C:A = /access [access:uc:pc]                            
                                                             
USER:A:B = /access/section [access:ua:pa:Section-B]          
USER:B:B = /access/section [access:ub:pbb]                   
                                                             
USER:C:D = /access/section/protected [access:uc:pd:Section-C]
                                                             
NONE     = /access/public [access:none]                      

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.
 
  USER:A   Mit dem Login "ua" und dem Passwort "pa" darf auf das Verzeichnis /access und auf alle enthaltenen Unterverzeichnisse zugegriffen werden. Im Unterverzeichnis /access/section kann der Benutzer bis auf /access/section/protected auch hier auf alle enthaltenen Verzeichnisse und Unterverzeichnisse zugreifen. Das Verzeichnis /access/section/protected mit den enthaltenen Unterverzeichnissen ist für diesen Benutzer nicht zugänglich.
 
  USER:B   Dieser Benutzer wird wie Benutzer USER:A behandelt, mit der Ausnahme das er für das Verzeichnis /access/section mit seinem Login "ub" das weitere Passwort "pbb" für den Zugang verwenden muss.
 
  USER:C   Mit dieser Konfiguration kann das Verzeichnis /access mit der Ausnahme des Unterverzeichnisses /access/section komplett verwendet werden. Unterhalb von /access/section/protected ist dann auch hier wieder der komplette Zugriff möglich.
 
  NONE   Für das Verzeichnis /access/public wird die Basic Authentication aufgehoben und kann ohne Login und Passwort genutzt und Unterverzeichnisse wieder mit Basic Authentication versehen werden.
 
 
 
  HINWEIS - Die Verarbeitung von Benutzern und Passwörtern berücksichtigt die Gross- und Kleinschreibung. Doppelpunkte : sollten für Benutzer und Passwörter nicht verwendet werden. Die Benutzung von eckigen Klammern [ ] ist nicht möglich.
 
  HINWEIS - Die Basic Authentication lässt sich bis auf Dateien anwenden was jedoch nicht von allen Browsern problemlos unterstützt wird.
 
 
 
Systemreferenzen   Das Schema zur Formulierung von Systemreferenzen

SYSTEM:NAME = REFERENZ [OPTION]
 
  Option   Beschreibung
 
  [R]   Redirection - mit dieser Option verweist die Systemdatei auf eine entsprechende Referenzadresse. Diese Option steht allen Fehlercodes ausser 302 zur Verfügung, da dieser für den Response als Redirection verwendet wird.
 
  Beispiele für den Einsatz Systemreferenzen
 
 
SYSTEM:INDEX = ../service/directory.html
  als Tempalte für die Generierung des Verzeichnisses wird die Datei ../service/directory.html verwendet
 
 
SYSTEM:404   = ../service/error.404.html
  als Tempalte für die Generierung der Fehlerinformation 404 wird die Datei ../service/error.404.html verwendet
 
 
SYSTEM:404   = http://www.xxx.zzz/404.php [R]
  beim Auftreten des Fehlers 404 erfolgt eine Weiterleitung zur Adresse http://www.xxx.zzz/404.php
 

 
[VIRTUALHOST:X:CGI]
[SERVER:X:CGI]
Common Gateway Interfaces
  CGI1.1 und DCGI1.1 Anwendungen werden in diesem Datenblock konfiguriert. DCGI wurde speziell für Devwex entwickelt und stellt eine offene, an das CGI 1.1 angelehnte, Schnittstelle für verschiedenste Programmiersprachen wie Java, VB(A) und andere zum Webserver zur Verfügung.

Das Schema zur Formulierung der Common Gateway Interfaces

DATEIERWEITERUNG = METHODEN >> ANWENDUNG [OPTION]

Beispiele für die Optionen
 
  [I]   verwendet das DCGI
 
  [C]   Bsp. .../applications/test.cgi
  [P]   Bsp. .../applications/
  [F]   Bsp. test
  [E]   Bsp. .cgi
 
  Beispiele für die Einrichtung von Common Gateway Interfaces
 
 
CGI = POST GET >> c:/application.exe
  die Anwendung Application wird gestartet, der Pfad der Scriptdatei ist in den Umgebungsvariablen enthalten
 
 
CGI = POST GET >> c:/application.exe [C]
  die Anwendung Application wird gestartet, der Pfad der Scriptdatei wird als Argument übergeben
 
 
CGI = POST GET >> c:/application.exe [I]
  die Anwendung Application wird unter Verwendung des DCGI gestartet
 
  Beispiel für den Einsatz von PHP, Perl, Java und ausführbare Binaries
 
 
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
 
  oder
 
 
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
 
 
JSP = POST GET >> com.seanox.jsp.Connector [M]
  die Dateierweiterung *.jsp wird dem im Classpath befindlichen Modul com.seanox.jsp.Connector zugewiesen
 
 
 
  TIP - Endet der Parameter oder die Wertezuweisung in der Init- Datei mit [+], wird der Inhalt der kompletten Zeile verwendet.

Bsp. PATH     = ./documents;./libraries;./system [+]
     PATH [+] = ./documents;./libraries;./system    
 
  TIP - Das Arbeitsverzeichnis der CGI Anwendungen ist das von Devwex. Sollen z.B. Ini- Dateien wie die php.ini berücksichtigt werden, sollten diese Ini- Dateien in diesem Verzeichnis eingerichtet werden.
 
  TIP - Bei der Installation von PHP muss die Konfigurationsdatei php.ini in das Arbeitsverzeichnis von Devwex gestellt werden. Mit der PHP Version 4.x muss zusätzlich die Umgebungsvariable REDIRECT_STATUS = 200 in der Devwex Konfiguration [SERVER:XXX:ENV] oder cgi.force_redirect = 0 in der php.ini eingetragen werden. Weiter ist ab PHP Version 4.3.x für eine korrekte Arbeitsweise der PHP-Funktion header(); der Eintrag cgi.rfc2616_headers = 1 in der php.ini notwendig.
 
  TIP - CGI und DCGI Anwendungen sowie Skripte können in allen Verzeichnissen der DOCROOT genutzt werden. Ein spezielles CGI-BIN ist nicht vorgesehen.
 
  TIP - Ausführbare Windows Binaries (*.exe, *.com) können unter Windows auch mit einer alternativen Dateiendung verwendet werden. Wenn z.B. CGI oder DCGI Anwendungen als Windows Binary (*.exe oder *.com) einsetzten werden ohne die entsprechenden Dateierweiterung als DCGI oder CGI Anwendung einzutragen, kann eine beliebige vergeben und verwenden werden.
 
  Bsp. application.exe wird umbenannt in application.wex, der entsprechende Eintrag in der Konfiguration gestaltet sich dann wie folgt: WEX = POST GET >> [C]
 
  TIP - Mit dem Methodeneintrag ALL werden alle eingehenden Methoden verarbeitet.
 

 
[VIRTUALHOST:X:ENV]
[SERVER:X:ENV]
Umgebungsvariablen
  Als Erweiterung der servereigenen Umgebungsvariablen, werden in diesem Datenblock für das CGI benötigte zusätzliche 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 = 200, als Umgebungsvariablen in der devwex.ini Datei gesetzt werden. Umgebungsvariablen ohne Wert werden nicht berücksichtigt.

TIP - Mit der Option [?] am Ende eines Parameters kann diesem ein dynamischer Werte zugewiesen werden welcher mit den System Properties beim Programmstart festgelegt wird. Auf diese Weise können z.B. systemrelevante Umgebungsvariablen wie PATH, SYSTEMDRIVE und SYSTEMROOT für Windows dynamisch übergeben werden. Detailliertere Informationen stehen im Abschnitt der Konfigurationsdatei zur Verfügung.
 

 
[VIRTUALHOST:X:FLT]
[SERVER:X:FLT]
Filter
  Für die Steuerung der Zugriffe auf die Server und virtuellen Hosts, stehen für den Devwex frei formulierbare Filterfunktionen zur Verfügung. Requests werden nur dann noch entsprechend beantworte, wenn diese bestimmten Bedingungen entsprechen. So kann z.B. bestimmten Clients und Diensten der Zugriff verwehrt werden.

Das Schema zur Formulierung der Filter

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

Die Angabe einer Referenz für die einzelnen Filterdefinitionen ist optional.
 
  Option   Beschreibung
 
  [A]   AND Verknüpfung der Bedingungen
 
  [R]   Redirection - verweist auf eine entsprechende Referenzadresse und leitet eine Weiterleitung ein.
Eine Fehlerseite wird nicht generiert.
 
  [M]   Modul - mit dieser Option wird ein Modul eingebunden.
 
  Name   Wert   Beschreibung
 
  NAME   ...   kann freigewählt werden
  METHODE   GET, POST, PUT, ALL, ...   auf die zu reagierende Methode
  BEDINGUNG   IS, NOT   die Bedingung für den Filter
  FUNKTION   EQUALS, INDEX, STARTS, ENDS   die Art des Wertevergleichs
  PARAMETER   ...   der betroffene Parameter
  WERT   ...   der zu kontrollierende Wert
 
  Für die Filterfunktion stehen alle im Header des Request enthaltene und einige erweiterte Parameter sowie diese aus dem CGI Umfeld zur Verfügung. Die Gross und Kleinschreibung wird bei den Parametern 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 Parameter und Werte sind abhängig vom Inhalt des Requestheaders.
 
  Name   Wert   Beschreibung
 
  FIRSTLINE   GET /directory/file.cgi?value=123 HTTP/1.1
  PROTOCOL   HTTP   das Protokoll
  VERSION   1.1   die Version des Protokolls
  METHOD   GET   die Methode
  QUERY   value=123   der Querystring
  PATH   /directory/file.cgi   der Path im Requeststring
 
  Beispiele für den Filtereinsatz
 
  FILTER:A = GET NOT EQUALS ACCEPT-LANGUAGE EN   die Methode GET wird verweigert wenn der Request Parameter Accept-Language nicht EN entspricht
 
  FILTER:B = GET NOT INDEX ACCEPT-LANGUAGE EN   die Methode GET wird verweigert wenn der Request Parameter Accept-Language nicht EN enthält
 
  FILTER:C = GET IS EQUALS ACCEPT-LANGUAGE EN   die Methode GET wird verweigert wenn der Request Parameter Accept-Language EN entspricht
 
  FILTER:D = GET IS INDEX ACCEPT-LANGUAGE EN   die Methode GET wird verweigert wenn der Request Parameter Accept-Language EN enthält
 
  FILTER:E = GET IS STARTS REMOTE_ADDR 192.168.   die Methode GET wird verweigert wenn der CGI Parameter REMOTE_ADDR mit 192.168. beginnt
 
  FILTER:F = GET IS ENDS SCRIPT_URL .dat   die Methode GET wird verweigert wenn der CGI Parameter SCRIPT_URL mit .dat endet
 
  FILTER:G = GET IS INDEX PATH /documents [A] GET IS EQUALS REFERER NULL
 
  die Methode GET wird verweigert wenn der Parameter PATH /documents enthält und der Parameter REFERER leer ist
 
  FILTER:H = GET IS INDEX PATH /private >> ../system/error.403.html
 
  die Methode GET wird verweigert wenn der Parameter PATH /private enthält, als Tempalte für die Generierung der Fehlerinformation 403 wird die Datei ../system/error.403.html verwendet
 
  FILTER:I = GET IS INDEX PATH /private >> http://www.xxx.zzz/403.php [R]
 
  die Methode GET wird verweigert wenn der Parameter PATH /private enthält, darauf hin erfolgt eine Weiterleitung zur Adresse http://www.xxx.zzz/403.php
 
  FILTER:J = GET IS ENDS PATH .do >> example.Connector [M]
 
  die Methode GET wird vom Modul Connector des Packages example welches sich im Classpath des Server befinden muss, ausgeführt wenn der Pfad in der URI mit .do endet
 

 
[VIRTUALHOST:X:MOD]
[SERVER:X:MOD]
Module
  Über das integrierte Modulkonzept können einzelne Funktionalitäten des Servers durch externe Komponenten geändert, erweitert oder neu hinzugefügt werden. Die Module werden erst bei Bedarf zur Laufzeit geladen wodurch ein sparsamer Umgang mit den Systemressourcen gewährleistet wird.
 
  Moduleinsprung   Beschreibung
 
  SERVER:CONNECTOR   Über diesen Moduleinsprung kann ein neuer Server definiert werden womit neue Protokolle und Dienste implementiert werden kφnnen. Dieser Moduleinsprung stehen nur den Servern und nicht den virtuellen Hosts zur Verfügung.

Bsp. SERVER:CONNECTOR = com.seanox.devwex.Server
 
  SERVER:INITIALIZE   Mit dem Start des Servers können über diesen Einsprung Module initialisiert werden. Dabei werden die Ressourcen in die Laufzeitumgebung geladen und der Konstruktor aufgerufen. Dieser Moduleinsprung stehen nur den Servern und nicht den virtuellen Hosts zur Verfügung.

Bsp. SERVER:INITIALIZE = com.seanox.devwex.Modul
 
  SESSION:SERVICE   Über diesen Moduleinsprung kann ein neuer Service zur Requestverarbeitung definiert werden womit der Server auch um neue Protokolle erweitert werden kann. Dieser Moduleinsprung stehen nur den Servern und nicht den virtuellen Hosts zur Verfügung.

Bsp. SESSION:SERVICE = com.seanox.devwex.Session

Optional kann dieser Einsprung auch über [SERVER:X:BAS] SERVICE definiert werden.
 
  SESSION:FILTER   Die Zugriffe auf die physischen und virtuellen Hosts kann über speziell definierte Regeln gesteuert werden. Durch diesen Moduleinsprung kann die bereits vorhandene Filterfunktion überschrieben werden.

Bsp. SESSION:FILTER = com.seanox.devwex.Filter
 
  SESSION:COMMAND   Dieser Moduleinsprung wird mit jedem beim Server und virtuellen Host eingehenden Request angesprochen und kann für asynchrone Prozesse während der Requestverarbeitung verwendet werden.

Bsp. SESSION:COMMAND = com.seanox.devwex.Command
 
  SESSION:PROCESS   DCGI und CGI Anwendungen werden durch Process ausgeführt. Durch diesen Moduleinsprung kann die bereits bestehende Funktionalität zur Steuerung und Verarbeitung des Prozesse überschrieben werden.

Bsp. SESSION:PROCESS = com.seanox.devwex.Process
 
  SESSION:METHOD   Mit diesem Moduleinsprung können die bereits vorhandenen HTTP Methoden überschrieben und neue hinzugefügt werden. Zur Unterstützung dieser müssen die Methoden in SERVER:BAS:METHODS eingetragen werden.

Bsp. SESSION:METHOD:GET = com.seanox.devwex.MethodGet
     SESSION:METHOD:XYZ = com.seanox.devwex.MethodXyz
 
  SESSION:LISTING   Eine Unterfunktion der Standard GET Methode, ist die Erstellung navigierbarer HTML Dokumente von Verzeichnisse des Dateisystems. Über diesen Moduleinsprung kann die bereits vorhandene Funktionalität überschrieben werden.

Bsp. SESSION:LISTING = com.seanox.devwex.Listing
 
  SESSION:STATUS   Für jeden Serverstatus ungleich 200, ausgenommen über DCGI oder CGI generierte, wird mit Status der entsprechende Response generiert und ausgegeben. Über diesen Moduleinsprung kann die bereits vorhandene Funktionalität überschrieben werden.

Bsp. SESSION:STATUS = com.seanox.devwex.Status
 
  SESSION:LOGGING   Durch diesen Moduleinsprung kann die bereits vorhandene Protokollierung der Zugriffe überschrieben werden.

Bsp. SESSION:LOGGING = com.seanox.devwex.Logging
 
  Schema der Requestverarbeitung.

[•]SERVICE           
     |               
   REQUEST           
     |               
[•]FILTER            
     |               
[•]COMMAND           
     |               
     +- [•]PROCESS   
     |               
     +- [•]METHOD    
     |               
     +- METHOD GET   
     |     |         
     |  [•]INDEX     
     |               
     +- METHOD PUT   
     +- METHOD DELETE
     +- METHOD HEAD  
     |               
[•]STATUS            
     |               
[•]LOGGING           
 
  Für die mit [•] gekennzeichneten Stellen können Module für den entsprechenden Moduleinsprung defniert werden. Detaillierte Informationen und Beispiele mit Sourcecode stehen als Download unter http://www.seanox.de/projects.devwex.php zur Verfügung.
 

 
[RESPONSECODES]
Allgemein
  Die für Responsecodes zur verwendenden Informationen werden hier definiert. Die Einrichtung der Responsecodes erfolgt global und wird von allen Servern und virtuellen Hosts verwendet.

Das Schema zur Formulierung der Responsecodes

CODE = TEXT

Beispiele für die Deklaration des Responsecodes
 
  200 = OK   der Header des Response
HTTP/1.0 200 OK
 
  404 = Document Not Found   der Header des Response
HTTP/1.0 404 Document Not Found
 

 
[MIMETYPES]
Allgemein
  In der Dateitypenzuordnung wird den Dateierweiterungen ein bestimmter Mimetype zugeordnet der von den Browsern und den CGI Anwendungen zur Datenbestimmung benötigt wird. Die Einrichtung der Mimetypes erfolgt global und wird von allen Servern und virtuellen Hosts verwendet.

Das Schema zur Formulierung der Mimetypes

MIMETYPE = DATEIERWEITERUNG, DATEIERWEITERUNG, ...

Beispiel für die Mimetypezuweisung
 
  application/octet-stream = com, exe, class   die Dateien mit der Dateierweiterung *.com, *.exe und *.class werden dem Mimetype application/octet-stream zugeordnet
 

Seanox Application Developing