Seanox Application Developing Copyright (C) 2004 Seanox Devwex 1.2004.0124 |
|||||||||||||||||||||
Inhalt | |||||||||||||||||||||
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) |
|
||||||||||||||||||||
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 | |||||||||||||||||||||