In order to activate the http(x) server you need to include the http(x) plug-in into the extension library configuration.
The http(x) plug-in is provided by the dynamic link library httpxlib.
Windows:
<EXTLIBS>
<LIB>httpxlib.dll</LIB>
</EXTLIBS>
Unix:
<EXTLIBS>
<LIB>libhttpx.so</LIB>
</EXTLIBS>
Within the http(x) protocol the Content-Type header field is used to indicate the format of the entity-body transferred.
When a file is transferred the media type of the file needs to be determined to set the header field accordingly.
The ICS general configuration tag
<MIMETYPESFILE>
allows to specify a file which contains mappings between the mime type and the standard file extensions that these files carry.
Please see ICS General Settings - Mime Types for more information.
If no mime type configuration is available some standard mappings are loaded.
The TEMPLATES tag as child of the DEFAULTS tag or the LISTENER tag defines the mapping for requests which can not be related to a host like 400 bad request responses.
If the host has been determined the TEMPLATES configuration attached to the HOST tag is used. If the host has no TEMPLATES configuration, the configuration of the respective listener is used. If the listener does not have a configuration the TEMPLATES configuration from the DEFAULTS section is used if available.
<httpx:TEMPLATES DIR="/srv/ics/static-templates" LANGUAGES="en, de, cn" />
The TEMPLATES tag comprises two attributes
The DIR attribute specifies the directory where the templates are stored. This should be a directory outside of the document path.
Note: if you reference style-sheets in templates these must reside in the document path configured by a respective node configuration. The proposed solution is to use in-place style instructions.
The LANGUAGES attribute is a comma separated list of the languages installed, while the first language listed is the default language, which is used if none of the languages provided by the Accept-Language request header field is available.
If a http error response is generated a corresponding template for the status code and extented internal error code is retrieved.
The template to retrieve from the template directory is determined by the status code, the extended error code and the language extension, e.g. for status code 400, an internal extended error code 65343 and language english the template with name 400_65343-en.iht is retrieved.
If there is no template with the internal error code available the template with the status code and the language extension is used e.g. 400-en.iht.
Note: The templates are cached on first usage, thus template changes will only become effective after triggering reconfiguration.
ICS delivers a number of default templates, that can be adjusted and copied for localization.
The directory listing of the default handler retrieves the template: directory-<language extension>.iht.
The default handler has several settings which can be set by the <httpx:DEFAULTHANDLER> tag which is a child of the <DEFAULTS> tag.
The http(x) default handler caches directory listings. There are two type of caches
Each cache can hold a maximum of ENTRIES entries in the cache up to a max. memory size of MEM for a max. time of EXPIRE seconds.
Thus an entry can be discarded either if the memory is exceeded by a new entry being inserted, the number of entries in the cache are exceeded or if an entry is not accessed anymore for EXPIRE seconds.
<DIRCACHE>
<LIST MEM="5242880" ENTRIES="128" EXPIRE="600"/>
<VAR MEM="5242880" ENTRIES="128" EXPIRE="600"/>
</DIRCACHE>
The VAR cache keeps references to LIST objects, thus even if a LIST object has been discarded from the cache but there are still VAR objects referencing the LIST object, the LIST object is not deleted from memory.
A host configuration defines a set of related server directories or services that are served via HTTP or HTTPS protocol for one or multiple network interfaces.
A host configuration is represented by the <httpx:HOST> tag.
The host configuration and all nodes contained within the host tag is read by the http(x) protocol implementation.
The Host configurations introduced by the <httpx:HOST> tag are children of the <LISTENER> tag.
Multiple hosts can be configured and are valid for all interfaces defined for the context of the corresponding listener.
The host tag
<httpx:HOST ROOT="/srv/ics/default" TYPE="VIRTUAL" NAME="myhost" ALIAS="*.myhost">
comprises four attributes
The ROOT attribute defines the root directory of the host and represents a directory on the servers storage. Each host must have a root directory configured. All nodes configured (see below) are relative to the root directory.
The TYPE attribute specifies the type of the host. There are two types of host configurations
Virtual hosts define a set of related web nodes that are only served if the Host header field of the http request matches the value defined in attribute NAME.
Default Hosts define a set of related web nodes that are served independent of the value of the Host header field read from the http request.
The NAME attribute defines the name of the virtual host.
The allowfrom configurations introduced by the <ALLOWFROM> tag are children of the <httpx:HOST> tag and define for which source addresses the host is served.
This is not implemented yet and will be revisited at a later point in time.
The templates configuration introduced by the <httpx:TEMPLATES> tag can also be specific for the <httpx:HOST> tag.
See Templates for more information.
The Node configurations introduced by the <NODE> tag are children of the <HOST> tag and define the nodes that are served for this host. Multiple nodes can be configured.
The NODE tag also configures how the default handler processes requests if no other handler is processing the request.
<NODE DIR="/srv/ics/default" ALIAS="" BROWSEABLE="" USEINDEXFILE="">
It comprises four attributes:
The DIR attribute specifies a directory on the servers storage where the files are located that should be served by the host.
<NODE DIR="/srv/ics/default">
The root directory specified in the HOST tag must be configured as node in order to serve files from this directory.
<HOST ROOT="/srv/ics/default" TYPE="VIRTUAL" NAME="myhost">
<NODE DIR="/srv/ics/default">
</NODE>
</HOST>
All requests for the root / will be served files from the servers directory /srv/ics/default.
All subdirectories of the node directory will have the same configuration applied. E.g. for a request to /manual the same configuration will be applied.
In order to apply a different configuration for a subdirectory a further node configuration must be introduced.
<HOST ROOT="/srv/ics/default" TYPE="VIRTUAL" NAME="myhost">
<NODE DIR="/srv/ics/default">
</NODE>
<NODE DIR="/srv/ics/default/manual">
</NODE>
</HOST>
All requests to /manual will now have a separate configuration applied.
The directory specified must match the root directory specified in the host tag otherwise it is ignored. If a directory outside of the root directory space needs to be served the alias attribute must be specified.
The ALIAS attribute specifies a web path for which the files are served that are located on the servers directory named by the DIR attribute or by a service. E.g. the configuration
<HOST ROOT="/srv/ics/default" TYPE="VIRTUAL" NAME="myhost">
<NODE DIR="/usr/local/manual" ALIAS="/manual/">
</NODE>
</HOST>
will serve for all requests to /manual from the servers directory /usr/local/manual
Note: If you want to set aliases for files you need to utilize the rewrite module.
The BROWSEABLE attribute indicates whether the directory and its subdirectories are browsable (YES) or not (other value).
If a directory is specified as browsable the files contained in the directory will be returned if an access to the directory is performed. E.g. for the configuration
<NODE DIR="/usr/local/manual" ALIAS="/manual/" BROWSABLE="YES">
a request to /manual/ will serve the list of files contained within the directory /usr/local/manual/ and provide the means to navigate to any subdirectory contained.
The USEINDEXFILE attribute specifies which file should be returned when an access to a directory is requested.
If the file specified in USEINDEXFILE does not exist or no index file is specified the directory content is listed when BROWSEABLE attribute is set to YES. If the BROWSEABLE attribute is not set a 404 error is returned if USEINDEXFILE is not specified or does not exist.
If USEINDEXFILE is specified the server will return the index file specified. Only file names must be specified.
Please be aware that the USEINDEXFILE statement applies to all subdirectories.
Accesses to directories without trailing slash will result in a redirect send to the client with the correct directory, thus a request to http://host/dir will result into a 301 response with the location header field being set to http://host/dir/.
Note: This redirection will not be applied to virtual directories e.g. directories specified with ALIAS attribute if the directory does not exist in the space of the root directory. Thus if the redirection should be applied to ALIAS directories as well the directory needs to be created on the servers storage specified as root directory.
The handler configurations introduced by the <HANDLER> tag are children of the <NODE> tag and define the handlers that should be executed for a NODE. Multiple handlers can be configured. The respective handlers are executed when an object of the respective node is requested. If no handlers are configured the http default request handler is executed.
The handler tag
<HANDLER TYPE="REQ" NAME="">
comprises two attributes:
The TYPE attribute specifies the type of the handler. There are two types of handlers supported
Authentication handlers are always executed before the request handlers and request handlers are only executed if all of the previously executed authentication handler have not returned an error response.
The Authentication handlers are executed in the configured sequence.
The Request handlers are executed in order of configuration and the next handler in the sequence is executed only if the previous request handler returns a not responsible status.
If all configured handlers return a not responsible status the default handler is executed.
Within the handler tags the handler specific configuration is contained.
<HANDLER>
...handler specific configuration
</HANDLER>
See the http(x) plug-in extensions for the respective handler configuration.
A FILES configuration defines a set of file patterns for which a certain configuration should be applied.
A FILES configuration is represented by the <httpx:FILES> tag.
The FILES configuration and all tags contained within the FILES tag is read by the http(x) protocol implementation.
The FILES configuration introduced by the <httpx:FILES> tag can be a child of the <DEFAULTS>, the <LISTENER>, the <HOST> or the <NODE> tag and defines configuration for the default handler that should be applied to specific file patterns.
<httpx:FILES>
<MATCHING PATTERN="*.js">
<ETAG ENABLE="OFF" />
<LASTMODIFIED ENABLE="OFF" />
<EXPIRES ENABLE="OFF" />
<ADDHEADERS>
<HEADER NAME="Custom-Header" VALUE="Custom-Value" />
</ADDHEADERS>
</MATCHING>
<MATCHING PATTERN="*">
<ETAG ENABLE="ON" />
<LASTMODIFIED ENABLE="ON" />
<EXPIRES ENABLE="ON" BASE="ACCESS" YEARS="0" MONTHS="0" DAYS="1" HOURS="0" MINUTES="0" SECONDS="0" />
<ADDHEADERS>
<HEADER NAME="Custom-Header" VALUE="Custom-Value" />
<HEADER NAME="max-age" VALUE="20" />
</ADDHEADERS>
</MATCHING>
</httpx:FILES>
The files matching pattern configuration introduced by the <MATCHING> tag can be a child of the <httpx:FILES> tag, and defines the file patterns for which the contained configuration should be applied. Multiple <MATCHING> tags can be defined. The handler processes the matching configurations in order of occurrence in the configuration file and uses the configuration when a pattern match is found. Thus general patterns should be placed at the end of the configuration while specific patterns should be listed first.
<MATCHING PATTERN="*">
...
</MATCHING>
The MATCHING tag comprises one attribute
The PATTERN attribute lists (comma separated) the file patterns for which the contained configuration should be applied. If the PATTERN should also apply to the directory either . or * must be specified.
The etag cache control configuration introduced by the <ETAG> tag can be a child of the <MATCHING> tag, and enables ETag header field being added to responses. The ETag response-header field provides the current value of the entity tag for the requested file or directory.
<MATCHING PATTERN="*">
<ETAG ENABLE="ON" />
</MATCHING>
The ETAG tag comprises one attribute
The ENABLE attribute set to ON enables the ETag response header field being set.
The last modified cache control configuration introduced by the <LASTMODIFIED> tag can be a child of the <MATCHING> tag, and enables Last-Modified header field being added to responses. The Last-Modified entity-header field indicates the date and time at which the file or directory served was last modified.
<MATCHING PATTERN="*">
<LASTMODIFIED ENABLE="ON" />
</MATCHING>
The LASTMODIFIED tag comprises one attribute
The ENABLE attribute set to ON enables the Last-Modified response header field being set.
The expires cache control configuration introduced by the <EXPIRES> tag can be a child of the <MATCHING> tag, and enables Expires header field being added to responses. The Expires entity-header field gives the time after which the response is considered stale.
<MATCHING PATTERN="*">
<EXPIRES ENABLE="ON" BASE="ACCESS" YEARS="0" MONTHS="0" DAYS="1" HOURS="0" MINUTES="0" SECONDS="0" />
</MATCHING>
The EXPIRES tag comprises eight attribute
The ENABLE attribute set to ON enables the Expires response header field being set.
The BASE attribute can be set to ACCESS or MODIFICATION. ACCESS calculates the expire time from the current access time. MODIFICATION calculates the expire time from the last modification time of the file or directory being served.
The YEARS attribute can hold a number of years that should be added to the BASE during the calculation of the Expire time.
The MONTHS attribute can hold a number of MONTHS that should be added to the BASE during the calculation of the Expire time.
The DAYS attribute can hold a number of DAYS that should be added to the BASE during the calculation of the Expire time.
The HOURS attribute can hold a number of HOURS that should be added to the BASE during the calculation of the Expire time.
The MINUTES attribute can hold a number of MINUTES that should be added to the BASE during the calculation of the Expire time.
The SECONDS attribute can hold a number of SECONDS that should be added to the BASE during the calculation of the Expire time.
The additional headers configuration introduced by the <ADDHEADERS> tag can be a child of the <MATCHING> tag, and enables additional static header fields being added to responses. The header fields to be added are specified by <HEADER> tag. Multiple HEADER tags can be specified.
<MATCHING PATTERN="*">
<ADDHEADERS>
<HEADER NAME="Custom-Header" VALUE="Custom-Value" />
<HEADER NAME="max-age" VALUE="20" />
</ADDHEADERS>
</MATCHING>
The HEADER tag comprises two attribute
The NAME attribute specifies the Header Field Name being set.
The VALUE attribute specifies the Header Field Value being set - the value can be empty.
The stream handler configuration introduced by the <httpx:STREAMHANDLER> tag can be a child of the <DEFAULTS>, the <LISTENER>, the <HOST> or the <NODE> tag and defines the handlers that should be executed.
<httpx:STREAMHANDLER TYPE="OUT" ONEOF="gzip, deflate" />
The httpx:STREAMHANDLER tag comprises two attributes
The TYPE attribute indicates whether an outbound stream handler (OUT) or an inbound stream handler (IN) should be executed.
The ONEOF attribute lists (comma separated) the stream handlers of which at most one is executed. The handlers are executed in the order they are listed.
Multiple httpx:STREAMHANDLER tags can be specified. They are executed in order of configuration.
To enable compression for all responses specify the httpx:STREAMHANDLER tag and the httpx:COMPRESSION tag within the DEFAULTS tag.
<DEFAULTS>
<httpx:STREAMHANDLER TYPE="OUT" ONEOF="gzip, deflate" />
<httpx:COMPRESSION ENABLE="gzip, deflate" VARY="ON">
<GZIP LEVEL="5">
<ENABLE>
<MIMETYPES>text/*,application/x-javascript</MIMETYPES>
</ENABLE>
<DISABLE>
<AGENTS>*MSIE 4*,*MSIE 5*,*MSIE 6*</AGENTS>
</DISABLE>
</GZIP>
<DEFLATE LEVEL="5">
<ENABLE>
<MIMETYPES>text/*,application/x-javascript</MIMETYPES>
</ENABLE>
<DISABLE>
<AGENTS>*MSIE 4*,*MSIE 5*,*MSIE 6*</AGENTS>
</DISABLE>
</DEFLATE>
</httpx:COMPRESSION>
</DEFAULTS>
The negotiation of the compression algorithm used is server driven by the order of the stream handlers in the ONEOF attribute. For example if a clients sends the accept encoding header field with gzip deflate but the configuration of the stream handler ONEOF attribute lists the compression algorithm in order deflate gzip, then deflate will be choosen.
See the respective documentation
for more information.
One log file is created
innotecsol.net 80 77.0.219.121 - - 2013-12-09 08:05:39 "GET /icon.png HTTP/1.1" 200 1022 "http://www.innotecsol.net/yasi/ics/index.html" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36"