Configuring ZimWeb

5 out of 5 stars

1 rating

5 Stars		100%
4 Stars		0%
3 Stars		0%
2 Stars		0%
1 Stars		0%

If you are using Tomcat, and have installed the ZimWeb in the manner described in the installation instructions, then the servlet configuration (servlet initialisation parameters) will be in the web.xml file in the [TOMCAT_ROOT]/webapps/ZII/WEB-INF directory. If you are using a different servlet engine, then you will have to consult its documentation to see how to configure it.

Here are the configuration parameters, organized by function type:

Automatic servlet loading
load-on-startup (Tomcat configuration parameter)	This controls whether the ZII servlet is loaded automatically when the Tomcat Java servlet engine starts. This means that the servlet is loaded and ready to run when the first client request arrives. Read the Tomcat documentation for more details on this subject. Note: This is not an initialisation parameter for the ZII servlet – it is a configuration parameter for the servlet. If you are using a different servlet engine then consult its documentation.
Automatically starting database connections
auto-start	This controls whether the ZII will automatically start the Zim Server agent sessions when the ZII servlet is loaded. If this equals `yes` (the default), then they are; it it is `no`, then they are not. If the ZII receives a client request, and the agents are not started, then the client will receive an error indicating that the database connection have not been started.
Configuration and log files
config-file	This gives the file name of the Zim Server agent configuration file – the same file that the ZimCGI uses. Consult the ZimCGI documentation and Configuration file extensions for more details on this subject.
log-file	This gives the file name of the log file that the ZII write – equivalent to the zimcgisrv.log file that the ZimCGI generates. Consult the ZimCGI documentation for more for more details on this subject.
verbose	This controls whether certain aspects of the logging features of the ZII are more verbose than usual (and necessary!). If it is yes, then the logging is more verbose. If it is no (the default), then your logs are not so verbose. Consult the ZimCGI documentation for more for more details on this subject.
Controlling XSLT processing
use-xslt-output-type	This controls how the ZII sets the mime content type of the response, if the output is passed through the XSLT processor and there is no content-type: command. If it is no (the default), then the content type is assumed to be `text/html`. If it is yes, then the XSLT processor will extract the content type from the clause in the stylesheet. If you set this to yes and you do not have an clause in the XSLT stylesheets, then the XSLT processor will usually assume the content type is XML (text/xml), which may not be what you want. I don’t think there is a good reason for you not to put an clause in all of your XSLT stylesheets. N.B. for more details on this subject please see documentation on XSLT.
Session and cookie management
default-session-timeout	This is the default session timeout in seconds. If not specifed, ZII will default to a 1 hour timeout. This can be overridden for a particular session by using the session-timeout: command.
default-cookie-timeout	This is the default cookie expiry time in seconds. If not specifed, ZII will default to a 1 year expiry. This can be overridden for a particular cookie by using the cookie-timeout: command.
Persistent Zim sessions
zim-session-security	This controls the security of persistent Zim sessions; the various options are:- `open` – insecure, as with the previous ZimCGI – the client can initiate a Zim session through the SESSIONID parameter without restriction. `disable-start` – ignore requests to start a persistent Zim session in the input parameters (i.e. a blank SESSIONID parameter). You can start the persistent Zim session with the `start-zim-session` command instead. `restrict-start` – ignore requests to start a persistent Zim session in the input parameters (i.e. a blank SESSIONID parameter) if the parameter TEMPLATE does not include the SESSIONID parameter. This is the default setting, which should work with existing ZimCGI applications. This should be combined with specifying all the parameter templates in the “Security” declarations in the configuration file, of course. `restrict-continue` – prevent starting or continuing a persistent Zim session in the input parameters (i.e. a SESSIONID parameter – blank or not – without also an ENDSESSION or CANCELSESSION parameter) if the parameter TEMPLATE does not include the SESSIONID parameter. `http-session` – the input parameters SESSIONID, ENDSESSION and CANCELSESSION are ignored; instead, ZimWeb stores the SESSIONID automatically in the HTTP session; and it is the exclusive responsibility of the Zim application to start and stop persistent Zim sessions through the start-zim-session, end-zim-session and cancel-zim-session commands; also, it is not necessary to have the SESSIONID in the parameter TEMPLATE, nor output the SESSIONID into a hidden field. `disable` – the input parameters SESSIONID, ENDSESSION and CANCELSESSION are ignored.
Debugging
allow-debug	This is the default state of the client debug capability. If `yes` then the client debug capability will initially be enabled when the ZII is started; if `no` (the default value) them it will initially be disabled.

Configuration File Extensions

Specified parameter templates

Security With ZimCGI, you can specify the Zim procedures that may be executed in a list following the Security tag(s) for each connection.
In addition, the ZII allows you to specify the parameter template in parentheses after the procedure name.
e.g. Security MyProc(CC) specifies that MyProc is an allowed procedure, and that the parameter template is (CC), eliminating the need to specify a TEMPLATE parameter.
If a parameter template is specifed in the configuration file, this will override any TEMPLATE parameter in the request.

Specified parameter templates
Security	With ZimCGI, you can specify the Zim procedures that may be executed in a list following the Security tag(s) for each connection. In addition, the ZII allows you to specify the parameter template in parentheses after the procedure name. e.g. Security MyProc(CC) specifies that MyProc is an allowed procedure, and that the parameter template is (CC), eliminating the need to specify a TEMPLATE parameter. If a parameter template is specifed in the configuration file, this will override any `TEMPLATE` parameter in the request.

19 June 2020

Updated25 March 2022

ByJason Lee

Was this article helpful?

5 out of 5 stars

1 rating

5 Stars		100%
4 Stars		0%
3 Stars		0%
2 Stars		0%
1 Stars		0%

Configuring ZimWeb