Seanox Application Developing
Copyright (C) 2004 Seanox
Devwex 1.2004.0124
Thanks Jörg Schlapinski for the translation.
 

 
Index  
•   General
•   Licence Agreement
•   Features
•   System Requirements
•   Installation
•   Configuration File
•   Basisoptionen
•   Server
•   Virtual Hosts
•   Baseoptionen
•   SSL / TLS
•   Virtual Directories
•   Basic Authentication
•   System References
•   Common Gateway Interfaces
•   Environment Variables
•   Filters
•   Modules
•   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]
 

 
General   Devwex is a widely configurable Java based Webserver for the command line (command shell). The ca. 29k sized Java binary supports virtual hosts, IP/Port Sharing, Remote Access/Control, Index Service, Multithreading, Filtering, Modules, DCGI/CGI1.1, SSL/TLS and more.
 

 
Licence Agreement   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
 

 
Features   Type   Description
 
  virtual Hosts   Devwex supports virtual hosts for IP/Port sharing.
 
  IP/Port sharing   Due to the global declaration of virtual hosts in the configuration file all virtual hosts can be used by all physical hosts, which make the virtual hosts available to different IP addresses and ports.
 
  Remote Access   Devwex allows a free configurable remote access for state requests, restart and stop commands.
 
  Index Service   System directories are automatically accessible as navigable HTML documents. Templates for this service can be individually designed for all physical and virtual hosts.
 
  Multithreading   Devwex supports the configuration of multiple independent physical and virtual hosts. Furthermore applicable is the inheritance of specific host configurations.
 
  Filtering   Accesses to physical and virtual hosts can be controlled by individually defined rules.
 
  Modules   Functionality can be added, expanded or changed by external components with the help of the integrated modularconcept of the server.
 
  HTTP   Based on specifications for HTTP 1.0 Devwex supports GET, POST, HEAD, PUT and DELETE. Further methods can be provided by additional modules and by DCGI or CGI. A response supports server status 200, 201, 300, 302, 304, 400, 401, 403, 404, 405, 406, 411, 424, 500 and 503. This can be modified or expanded by provided interfaces.
 
  SSL   For secure data transfers Devwex supports Secure Socket Layer - SSL and Transport Layer Security - TLS. The certificate assignment can be handled for every physical host, in groups by inheritance or globally.
 
  DCGI   DCGI has been especially developed for Devwex. DCGI is derived from CGI 1.1 and supplies the Webserver with an open interface to different programming languages such as Java, VB, VB(A) and more.
 
  CGI   Devwex supports the Common Gateway Interface specification 1.1 including PHP, Perl, Phyton and more.
 

 
System Requirements   Software   Java Runtime 1.2.x to 1.3.x optional with JSSE
Java Runtime 1.4.x or higher
 
  Hardware
(Minimum)
 
Processor     200   MHz
Memory     64   MB
Network     10   MB/s
 

 
Installation   After unpacking the installation directory can be put anywhere in the file system.

The Java Secure Socket Extension (JSSE) is used for SSL and TLS. This extension is part of the Java runtime environment (JRE) and Java development kit (JDK) from version 1.4.0. For Java versions 1.2.x to 1.3.x the runtime environment must be updated. Therefore the files jcert.jar, jnet.jar and jsse.jar from the directory ./devwex/libraries must be copied to the directory ./java/jre/lib/ext/ or must become part of the Devwex classpath.

Further information for the Java extension can be found under http://java.sun.com/products/jsse

The usage of JSEE libaries is optional. Devwex can be used without this extension.
Only Secure Layer will not be supported in this case.

Starting Devwex
 
  Java Archiv   java -cp devwex.jar [-Dparameter=value] com.seanox.devwex.Service [OPTION]
 
  Startscript   devwex.bat [OPTION]
devwex.sh  [OPTION]
 
  Option   Description
 
  RESTART   ends all active servers and restarts with the given configuration
  START   starts with the given configuration
  STATE   shows the starting and current time and all running servers
  STOP   terminates Devwex with all running servers
  TIME   shows the starting and current time
 
 
 
  TIP - Using the startscript for call of the server. This script takes over all libraries in the directory ./devwex/libraries and all important variables of the system environment.
 
  TIP - Devcox as a web based administration tool can be used for configuring and administrating Devwex. The ca. 80k Byte large Java binary is provided in English and installed, configured easily
 
  TIP - For Remote Control/Access via Telnet a server connection configured in in BASEOPTIONS:REMOTEADDRESS and the referring BASEOPTIONS:REMOTEPORT can be used. Command are applied from the command line options.

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 - Host names are resolved quicker if the server IP addresses and the used network resources i.e. databases are written into the windows host file (Exp. C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS) or the Unix host file (Exp. /etc/hosts).
 

 
Configuration File
General
  The Configuration file is organized in six areas.
 
  Area   Description
 
  [BASEOPTIONS]   general server options such as remote access and other global options for modules
 
  [INITIALIZE]   module initialization with (re)starting the service
 
  [SERVER]   the configuration area for the server contains all properties for the hosts
 
  [VIRTUALHOST]   the configuration area for the virtual host properties
 
  [RESPONSECODES]   definition of the information used by the response codes
 
  [MIMETYPES]   useable mimetypes can be found here
 
 
 
  The Devwex Ini file (configuration file) has been enhanced using the common form of older versions. In different block segments parameters are assigned to values line by line. Upper and lower case is not applied in names of blocks and parameters. Multiple or repeated declarations will be put together: already existing entries will be overwritten and new entries added. For that reason it is possible to separate blocks in the configuration file, although this proceeding could complicate clarity.

The semicolon (;) is interpreted as commentary sign. Following characters will not become part of value assignments or declarations. The option [+] at the end of a parameter or value assignment will skip any given commentary sign in the line. So the semicolon can be used for assigning values.

A value assignment can be fixed or variable. With the help of the option [?] at the end of a parameter the referred value will first be determined using the system properties of the JAVA environment. If this fails the optionally given value will be used.

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

Line 001 - The block named "PARAMETER" is defined. The characters after the semicolon are interpreted as comment.

Line 002 - The value "VALUE-1" is assigned to the parameter "PARAM-A". The characters after the semicolon are interpreted as comment.

Line 003 - The values "VALUE-2; VALUE-3" are assigned to the parameter "PARAM-B". The option [+] skips the commentary function of the semicolon. All values are used. It is not possible to put are comment in this line.

Line 004 - Similar to line 003 the values "VALUE-2; VALUE-3" are assigned to the parameter "PARAM-C". The option [+] skips the commentary function of the semicolon. All values are used. It is not possible to put are comment in this line.

Line 005 - The value assignment for the parameter "PARAM-D" is handled dynamically. The value will first be determined using the system properties of the JAVA environment. Therefore the parameter must be part of the current runtime environment or must be handed over to Devwex during the start using the form -Dparameter=value. Upper and lower case will not be applied. Parameter which are defined in this way are recognized with the complete value assignment. Comments are not supported with this option. If a value for the parameter can not be determined using the system properties then the given values "VALUE-6; VALUE-7" are used. Comments can not be used with the option [+].

Line 006 - Similar to line 005 the parameter "PARAM-E" will be determined using the system properties of JAVA. If this fails the optionally given value will be used. Without the option [+] a comment can be used.

Line 007 - Similar to the lines 005 and 006 the parameter "PARAM-F" will be determined using the system properties of JAVA. If this fails no value will be assigned. Without the option [+] a comment can be used.
 

 
[BASEOPTIONS]
General
  General server options such as remote access and other global options for modules can be defined here. The definition of the base options is global and is used for all physical and virtual hosts.
 
  Parameter   Value   Description
 
  REMOTEADDRESS   127.0.0.1   server address for remote access
 
  REMOTEPORT   25000   server port for remote access
 

 
[INITIALIZE]
General
  With (re)starting the service will initialize the defined modules and informed about certain events. During the initialization searched for com.seanox.devwex.Container automatically. This module does not need to be registered.

Syntax for building modul definition

NAME = RESOURCE

Example for the modul definition

Example   CONTAINER = com.seanox.devwex.Container
 

 
[SERVER]
General
  Server as physical hosts offer network access to a specific IP address and a specific port. By starting Devwex all in the configuration file defined servers are started. All running server are accessed directly.

Syntax for building server

[SERVER:NAME:BLOCKNAME]

Block names used in the configuration blocks can be chosen and used independently from the [SERVER:X:BAS] NAME

The server configuration consists of 6 blocks.
 
  Blockname   Description
 
  [SERVER:X:BAS]   basis configuration
  [SERVER:X:REF]   virtual directories
  [SERVER:X:ENV]   environment variables
  [SERVER:X:CGI]   CGI assignment und configuration
  [SERVER:X:FLT]   filter configuration
  [SERVER:X:MOD]   module configuration
 

 
[VIRTUALHOST]
General
  Virtual hosts are available to the servers. It applies that all virtual hosts can be used by all servers. Therefore IP- and Port Sharing is applicable for all virtual hosts. The virtual host uses the configuration of the calling server. But all parameters defined for the virtual host will override the configuration of the calling server. The usage of the virtual hosts depends on the incoming request to the server. According to the for the server defined hosts a virtual host with the same name will be used.

Example for a 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


Block entries must be defined in the configuration file according to the example.
 
  Blockname   Description
 
  [VIRTUALHOST:WWW.XXX.ZZZ:BAS]   basis configuration
  [VIRTUALHOST:WWW.XXX.ZZZ:REF]   virtual directories
  [VIRTUALHOST:WWW.XXX.ZZZ:ENV]   environment variables
  [VIRTUALHOST:WWW.XXX.ZZZ:CGI]   CGI assignment und configuration
  [VIRTUALHOST:WWW.XXX.ZZZ:FLT]   filter configuration
  [VIRTUALHOST:WWW.XXX.ZZZ:MOD]   module configuration
 
  The virtual host configuration is similar to the server configuration. Only entries for ADDRESS, SOCKET and PORT are not defined.
 

 
[VIRTUALHOST:X:BAS]
[SERVER:X:BAS]
Baseoptions
  This block contains the general configuration for the servers and virtual hosts. Both configurations are similar to each other but the parameter ADDRESS, PORT, SOCKET and SERVICE are not used for virtual hosts.
 
  Parameter   Value   Description
 
  IMPLEMENTS   SERVER ..., VIRTUALHOST ...   implements the configuration of the following server or virtual host
 
  CONNECTOR   ...   connector definition, optional can be used [SERVER:X:MOD] SERVER:CONNECTOR
 
  ADDRESS   AUTO, LOCALHOST, IP, NAME   the local address of the Servers AUTO uses all in the system applicable IP addresses
 
  PORT   ...   the local server port
 
  SOCKET   NORMAL, SECURE   the transfer scheme, SECURE activates the use of certificates for data encryption
 
  SERVICE   ...   modul defintion for request processing, optional can be used [SERVER:X:MOD] SESSION:SERVICE
 
  IDENTIFY   ON, OFF   option for the transfer of server name with the CGI
 
  MAXACCESS   100   maximum number of parallel sessions
 
  BLOCKSIZE   65535   processing size of the data blocks in bytes
 
  INTERRUPT   10   interruption period for system processes in milliseconds
 
  TIMEOUT   300000   maximum time for an empty data stream in milliseconds, which leads to a timeout value 0 ignores a timeout
 
  METHODS   GET, POST, HEAD, PUT, DELETE   allowed methods for the server
 
  COMMAND   ...   process or system command which starts by accessing, optional it can be configured like CGI
 
  ACCESSLOG   ../system/access.log   access logging file, without an entry the standard IO will be used for output
 
  SYSROOT   ../system   path for system files
 
  DOCROOT   ../documents   path for web documents
 
  INDEX   ON, OFF   option for the indexservice for directories
 
  MIMETYPE   application/octet-stream   standard mimetype, will be used if demanded mimetype is not in the mimetype list
 
  DEFAULT   index.htm, index.html ...   standard document for directory calls
 
 
 
Secure Socket Layer
Transport Layer Security
SSL / TLS
  Devwex supports Secure Socket Layer - SSL und Transport Layer Security - TLS for secure transfers. Certificates can be assigned for each physical host or using inheritance groupwise or global.
  Parameter   Value   Description
 
  SSL:PROTOCOL   TLS, SSL, ...   the Secure Layer Protocol, SSL Secure Socket Layer, TLS Transport Layer Security, standard if nothing else set is TLS
 
  SSL:ALGORITHM   SunX509, ...   encryption algorithm, standard if nothing else set is SunX509
 
  SSL:CLIENTAUTH   ON, OFF   ON activates the client authorization, standard if not set is OFF
 
  KEYSTORE:FILE   ...   path for the keystore file
 
  KEYSTORE:TYPE   JKS, ...   type of keystores, standard if not set set is JKS
 
  KEYSTORE:PASSWORD   ...   Password for the keystore
 
  The Java Secure Socket Extension (JSSE) is used for SSL and TLS. This extension is part of the Java runtime environment (JRE) and Java development kit (JDK) from version 1.4.0. For Java versions 1.2.x to 1.3.x the runtime environment must be updated. Therefore the files jcert.jar, jnet.jar and jsse.jar from the directory ./devwex/libraries must be copied to the directory ./java/jre/lib/ext/ or must become part of the Devwex classpath.

Further information for the Java extension can be found under http://java.sun.com/products/jsse

Creating a certificate (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               

If no destination directory is defined in -keystore then the user generated certificate will be saved as .keystore file in the user directory. Depending on the operating system different user directories are used. i.e. C:\documents and properties\[user]\.keystore for Windows 2000/XP or /home/[benutzer]/.keystore for Unix based systems.

The generated keystore file can be renamed and moved to another location.

Certificate configuration, with the keystore file located in the Devwex working directory ./devwex/program and the JSSE available. The port can be chosen, 443 is the standard port for HTTPS.

[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 
  ...                         

Due to automatically set standard values the following configuration is sufficient in most cases.

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

For activating Secure Layers the server SOCKET must be set to SECURE.
 

 
[VIRTUALHOST:X:REF]
[SERVER:X:REF]
Virtual Directories
  This block contains the configuration for the virtual directories and system references.

Syntax for building virtual directories

NAME = VIRTUAL >> PHYSICAL [OPTION]
 
  Option   Description
 
  [A]   Absolute - all requested directories which path contains the virtual or physical directory will be using the physical directory that has been set.
 
  [C]   Cancel - access to the virtual or physical directory will be blocked.
 
  [R]   Redirection - access to the virtual directory will automatically be redirected to the physical directory or http address that has been set.
 
  [M]   Module - with this option a module as web application is included. The path processing is handled like an absolute directory and transferred to the application.
 
  Examples for using the virtual directory
 
 
DIRECTION:A = /system  >> ../system
  the physical directory ../system will be used for the requested directory /system
 
 
DIRECTION:B = /doc     >> ../documents [A]
  for the following requests
/documents
/documentation
/doc/test.cgi?cmd=123
the physical directory
../documents will be used without naming a certain file
 
 
DIRECTION:C = /program >> ../program [C]
  access to the requested directory /program will be denied
 
 
DIRECTION:D = /test    >> http://www.xxx.zzz [R]
  the request to the directory /test will be redirected to http://www.xxx.zzz
 
 
DIRECTION:E = /control >> example.Connector [M]
  with requesting the directory /control the class Connector of the Packages example, which is defined in the classpath of the server, is executed as module
 
 
 
Basic Authentication   Syntax for building User

NAME = VIRTUAL DIRECTORY [ACCESS:USER:PASSWORD:TEXT]

Setting a text for the login dialog is optional. It is sufficient to set this text only once in case more users are defined in the directory.

Examples for 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]                      

The directory /access und all subdirectories are only available to selected user via password, except for the directory /access/public and the subdirectories.
 
  USER:A   With the login "ua" and the password "pa" access to the directory /access and all subdirectories is granted. The subdirectory /access/section can be accessed including the subdirectory expect for the directory /access/section/protected. The directory /access/section/protected with all subdirectory is not available to this user.
 
  USER:B   This user is treated as USER:A, with the exception that for /access/section the login "ub" and the password "pbb" has to be used.
 
  USER:C   The directory /access except for the subdirectory /access/section can be accessed completely. Below /access/section/protected complete access is possible.
 
  NONE   The Basic Authentication for the directory /access/public is cancelled and can be accessed without login and password, subdirectories can be supplied with Basic Authentication.
 
 
 
  NOTE - Upper and lower case are applied for proceeding users and passwords. Colon : and brackets [] can not be used for usernames or passwords.
 
  NOTE - Basic Authentication can even be applied to files. Although this features is not supported by every browser.
 
 
 
System References   Syntax for building system references

SYSTEM:NAME = REFERENCE [OPTION]
 
  Option   Description
 
  [R]   Redirection - with the help of this option the system file will reference a given address. This option can be used for all error codes except for the 302 error which is used for response as a redirection.
 
  Example for using the system References
 
 
SYSTEM:INDEX = ../service/directory.html
  template for generating the directory will be ../service/directory.html
 
 
SYSTEM:404   = ../service/error.404.html
  template for generating the error information 404 will be ../service/error.404.html
 
 
SYSTEM:404   = http://www.xxx.zzz/404.php [R]
  in case error 404 occurs a redirection to the address http://www.xxx.zzz/404.php will result
 

 
[VIRTUALHOST:X:CGI]
[SERVER:X:CGI]
Common Gateway Interfaces
  CGI1.1 and DCGI1.1 applications are configured in this block. DCGI has been especially developed for Devwex. DCGI is derived from CGI 1.1 and supplies the Webserver with an open Common Gateway Interfaces interface to different programming languages such as Java, VB, VB(A) and more.

Syntax for using the Common Gateway Interfaces

FILE EXTENSION = METHODS >> APPLICATION [OPTION]

Example for the options
 
  [I]   uses the DCGI
 
  [C]   example .../applications/test.cgi
  [P]   example .../applications/
  [F]   example test
  [E]   example .cgi
 
  Examples for the configuration of the Common Gateway Interfaces
 
 
CGI = POST GET >> c:/application.exe
  the application application.exe will be started, the path of the script file has been set in the environment variable
 
 
CGI = POST GET >> c:/application.exe [C]
  the application application.exe will be started, the path of the script file will be given as argument
 
 
CGI = POST GET >> c:/application.exe [I]
  the application application.exe will be started by using DCGI
 
  Examples for using PHP, Perl, Java und executable Binaries
 
 
PHP = POST GET >> c:/php/php.exe
  the file extension *.php will be assigned to PHP as executing CGI application
 
 
CGI = POST GET >> c:/perl/bin/perl.exe [C]
  the file extension *.perl will be assigned to Perl as executing CGI application
 
 
JAR = POST GET >> java -jar [P][F].jar [I]
  the file extension *.jar will be assigned to Java as executing CGI application
 
  or
 
 
JAR = POST GET >> java -jar [C] [I]
  the file extension *.jar will be assigned to Java as executing CGI application
 
 
EXE = POST GET >> [C] [I]
  the file extension *.exe is defined as executing DCGI application
 
 
EXE = POST GET >> [C]
  the file extension *.exe is definded as executing CGI application
 
  Example for the usage of modules
 
 
JSP = POST GET >> com.seanox.jsp.Connector [M]
  the file extension *.jsp will be assigned to the module com.seanox.jsp.Connector located in the classpath
 
 
 
  TIP - If the parameter or the assigned value in the init- file ends with [+] then the content of the whole line will be used.

Example   PATH     = ./documents;./libraries;./system [+]
          PATH [+] = ./documents;./libraries;./system    
 
  TIP - The working directory of CGI applications equals the Devwex working directory. So if i.e. Ini- files are used they should be found in the same directory.
 
  TIP - The php configuration file php.ini has to be in the working directory of Devwex. For PHP version 4.x the environment variable REDIRECT_STATUS = 200 has to be set in the Devwex configuration [SERVER:XXX:ENV] or cgi.force_redirect = 0 has to be set in the php.ini file. It is necessary to set cgi.rfc2616_headers = 1 in the php.ini file to get the PHP-function header(); to work correctly for PHP version 4.3.x or higher.
 
  TIP - CGI and DCGI application and scripts can be used in all DOCROOT directories. A special CGI-BIN directory is not necessary.
 
  TIP - Executable Windows binaries (*.exe, *.com) can be used with a different file extension under windows. If i.e. CGI or DCGI applications are used as Windows binary (*.exe or *.com) without configuring these file extensions for CGI or DCGI applications, file extensions can be chosen.
 
  Example application.exe is renamed to application.wex, the referring entry in the configuration file looks like:
WEX = POST GET >> [C]
 
  TIP - The method entry ALL will proceed all incoming methods.
 

 
[VIRTUALHOST:X:ENV]
[SERVER:X:ENV]
Environment Variables
  Apart from server environment variables this block is used for defining additional environment variables needed for CGI.

Syntax for building environment variables

PARAMETER = VALUE

Examples for the configuration of environment variables
 
  WEBSERVER = DEVWEX   the environment variables WEBSERVER is declared and assigned the value DEVWEX
 
 
 
  NOTE - If CGI applications use system resources i.e. database functions the system resources will be determined using the environment variables. Due to this environment variables like PATH, SYSTEMDRIVE, SYSTEMROOT and PHP REDIRECT_STATUS = FALSE should be set in the devwex.ini file. Environment variables without value will not be considered.

TIP - With the option [?] Devwex tries to assign a dynamic value from the system properties during program start. System environment variables i.e. PATH, SYSTEMDRIVE or SYSTEMROOT can be handed over dynamically. Please find more details in the configuration file section.
 

 
[VIRTUALHOST:X:FLT]
[SERVER:X:FLT]
Filters
  For controlling accesses to the servers and the virtual hosts Devwex offers filter functions which can be defined by the user. Requests will only be answered according these predefined filters conditions i.e. access could be denied to certain clients and services.

Syntax for using filters

NAME = METHOD CONDITION FUNCTION PARAMETER VALUE [A] ... >> REFERENCE [R]

(where the usage of REFERENCE is optional)
 
  Option   Description
 
  [A]   AND - logical AND for conditions
 
  [R]   redirection - points to a certain reference address and starts a redirection. An error page will not be generated.
 
  [M]   module - this option links a module.
 
  Name   Value   Description
 
  NAME   ...   can be chosen
  METHODE   GET, POST, PUT, ALL, ...   method to react to
  BEDINGUNG   IS, NOT   condition for filtering
  FUNKTION   EQUALS, INDEX, STARTS, ENDS   method for comparing the values
  PARAMETER   ...   affected parameter
  VALUE   ...   the value to be checked
 
  The following parameters can be used for filtering: all parameters from the request header, parameters from CGI and some additional parameters. Upper and lower case is not checked for parameters or values.

Example for a 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

Parameters and values are dependent on the content of the request header.
 
  Parameter   Value   Description
 
  FIRSTLINE   GET /directory/file.cgi?value=123 HTTP/1.1
  PROTOCOL   HTTP   the protocol
  VERSION   1.1   the version of the protocol
  METHOD   GET   the method
  QUERY   value=123   the query string
  PATH   /directory/file.cgi   the path in the request string
 
  Examples for filtering
 
  FILTER:A = GET NOT EQUALS ACCEPT-LANGUAGE EN   the method GET will be denied if the request parameter accept-language does not equal EN
 
  FILTER:B = GET NOT INDEX ACCEPT-LANGUAGE EN   the method GET will be denied if the request parameter accept-language does not contain EN
 
  FILTER:C = GET IS EQUALS ACCEPT-LANGUAGE EN   the method GET will be denied if the request parameter accept-language equals EN
 
  FILTER:D = GET IS INDEX ACCEPT-LANGUAGE EN   the method GET will be denied if the request parameter accept-language contains EN
 
  FILTER:E = GET IS STARTS REMOTE_ADDR 192.168.   the method GET will be denied if the CGI parameter REMOTE_ADDR starts with 192.168.
 
  FILTER:F = GET IS ENDS SCRIPT_URL .dat   the method GET will be denied if the CGI Parameter SCRIPT_URL ends with .dat
 
  FILTER:G = GET IS INDEX PATH /documents [A] GET IS EQUALS REFERER NULL
 
  the method GET will be denied if the parameter PATH contains /documents and the parameter referrer is empty
 
  FILTER:H = GET IS INDEX PATH /private >> ../system/error.403.html
 
  the method GET will be denied if the parameter PATH contains /private; template for generating the error information 404 will be the file ../system/error.403.html
 
  FILTER:I = GET IS INDEX PATH /private >> http://www.xxx.zzz/403.php [R]
 
  the method GET will be denied if the parameter PATH contains /private, redirection to http://www.xxx.zzz/403.php will follow
 
  FILTER:J = GET IS ENDS PATH .do >> example.Connector [M]
 
  the method GET will be executed by the module Connector which is located in the server Classpath
 

 
[VIRTUALHOST:X:MOD]
[SERVER:X:MOD]
Modules
  Server functionality can be added, expanded or changed by external components with the integrated modular concept. Modules are loaded on demand during runtime. This helps keeping track of system resources.
 
  Module definition   Description
 
  SERVER:CONNECTOR   This module definition includes a new server to implementation of new protocols or services. This can only be used by the server and not by the virtual hosts.

Example   SERVER:CONNECTOR = com.seanox.devwex.Server
 
  SERVER:INITIALIZE   On starting the server this point can be used to initialize modules. Resources will be loaded into the runtime environment and the constructor will be called. This module definition can only be used by the server and is not available for virtual hosts.

Example   SERVER:INITIALIZE = com.seanox.devwex.Modul
 
  SESSION:SERVICE   This module definition includes a new service for request proceeding, i.e. adding a new protocol to the server. This can only be used by the server and not by the virtual hosts.

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

Optional can be used [SERVER:X:BAS] SERVICE.
 
  SESSION:FILTER   Access to physical or virtual hosts can be controlled by defined filtering rules. This module definition can be used to override already in Devwex included filtering functions.

Example   SESSION:FILTER = com.seanox.devwex.Filter
 
  SESSION:COMMAND   This module definition will be called for every incoming request (server or virtual hosts) and can be used for asynchronous processes during request processing

Example   SESSION:COMMAND = com.seanox.devwex.Command
 
  SESSION:PROCESS   DCGI and CGI applications are executed by PROCESS. This module definition will override the already in Devwex included functionality for controlling and proceeding processes; will override Process.

Example   SESSION:PROCESS = com.seanox.devwex.Process
 
  SESSION:METHOD   Already existing HTTP methods can be overridden or new methods added with the help of this module definition. The methods must be added to SERVER:BAS:METHODS to be supported.

Example   SESSION:METHOD:GET = com.seanox.devwex.MethodGet
          SESSION:METHOD:XYZ = com.seanox.devwex.MethodXyz
 
  SESSION:LISTING   The creation of navigable HTML documents for directories of the file system is a sub function of the standard GET method. Already existing functionality can be overridden with the help of this module defintion.

Example   SESSION:LISTING = com.seanox.devwex.Listing
 
  SESSION:STATUS   For every server status unequal 200, except for DCGI and CGI generated, an accordingly response with the status is generated. This functionality can be overridden using this module definition.

Example   SESSION:STATUS = com.seanox.devwex.Status
 
  SESSION:LOGGING   The already existing protocolling functionality can be overriden using this module definition.

Example   SESSION:LOGGING = com.seanox.devwex.Logging
 
  Scheme of Request proceeding

[•]SERVICE           
     |               
   REQUEST           
     |               
[•]FILTER            
     |               
[•]COMMAND           
     |               
     +- [•]PROCESS   
     |               
     +- [•]METHOD    
     |               
     +- METHOD GET   
     |     |         
     |  [•]INDEX     
     |               
     +- METHOD PUT   
     +- METHOD DELETE
     +- METHOD HEAD  
     |               
[•]STATUS            
     |               
[•]LOGGING           
 
  Modules can be defined under a module definition for the [•] marked places. Please find detailed information and source code downloads under http://www.seanox.de/projects.devwex.php
 

 
[RESPONSECODES]
General
  The information used for the response codes are defined here. Response codes are defined globally and are therefore used by all servers and virtual hosts.

Syntax for building response codes

CODE = TEXT

Example for declaring the response codes
 
  200 = OK   response header
HTTP/1.0 200 OK
 
  404 = Document Not Found   response header
HTTP/1.0 404 Document Not Found
 

 
[MIMETYPES]
General
  Mimetypes are assigned to the file extensions to be used by browsers and CGI applications. Browsers and CGI applications use mimetypes for data recognition. Mimetypes are defined globally and are therefore used by all servers and virtual hosts.

Syntax for building mimetypes

MIMETYPE = FILE EXTENSION, FILE EXTENSION, ...

Example for assigning mimetypes
 
  application/octet-stream = com, exe, class   files with the extensions *.com, *.exe and *.class will be assigned to the mimetype application/octet-stream
 

Seanox Application Developing