<!--
    Wt Configuration File.

    The Wt configuration file manages, for every Wt application, settings
    for session management, debugging, directory for runtime information
    such as session sockets, and some security settings.

    Settings may be specified globally, or for a single application path.

    The path should be as configured in the Wt build process, where it
    defaults to /etc/wt/wt_config.xml. It can be overridden in the environment
    variable WT_CONFIG_XML, or with the -c startup option of wthttpd.

    The values listed here are the default values, which are used when the
    declaration is missing or no configuration file is used.
  -->

<server>

    <!-- Default application settings

      The special location "*" always matches. See below for an example
      of settings specific to a single application.
      -->
    <application-settings location="*">

        <!-- Session management. -->
	<session-management>
            <!-- Every session runs within a dedicated process.

	       This mode guarantees kernel-level session privacy, but as every
	       session requires a seperate process, it is also an easy target
	       for DoS attacks if not shielded by access control.

               It is also a convenient mode during development, as it is easy
	       to enable disable debugging using valgrind, and it always starts
	       the latest deployed executable for a new session.
	   
	       Note: currently only supported using the FastCGI connector
              -->

	    <!--
	       <dedicated-process>
		 <max-num-sessions>100</max-num-sessions>
	       </dedicated-process>
	      -->

	    <!-- Multiple sessions within one process.

	       This mode spawns a number of processes, and sessions are
	       allocated randomly to one of these processes (you should not
	       use this for dynamic FCGI servers, but only in conjunction
	       with a fixed number of static FCGI servers.

	       This requires careful programming, as memory corruption in one
	       session will kill all of the sessions in the same process. You
	       should debug extensively using valgrind. Also, it is your
	       responsibility to keep session state not interfering and
	       seperated.

	       On the other hand, sessions are inexpensive, and this mode
	       suffers far less from DoS attacks than dedicated-process mode.
	       Use it for non-critical and well-debugged web applications.

	       Note: wthttpd always uses exactly one process
              -->
	    <shared-process>
	        <num-processes>1</num-processes>
	    </shared-process>

	    <!-- Session tracking strategy.

	       Possible values:
		 Auto: cookies is available, otherwise URL rewriting
		 URL:  only URL rewriting
	      -->
	    <tracking>URL</tracking>

	    <!-- How reload should be handled.

	       When reload should (or rather, may) spawn a new session, then
	       even in the case cookies are not used for session management,
	       the URL will not be cluttered with a sessionid.
	       However, WApplication::refresh() will never be called.
	      -->
	    <reload-is-new-session>true</reload-is-new-session>

	    <!-- Session timeout (seconds).

	       When a session remains inactive for this amount of time, it is
	       cleaned up.
	      -->
	    <timeout>600</timeout>

	    <!-- Server push timeout (seconds).

               When using server-initiated updates, the client uses
               long-polling requests. Proxies (including reverse
               proxies) are notorious for silently closing idle
               requests; the client therefore cancels the request
               periodically and issues a new one. This timeout sets
               the frequency.
	      -->
	    <server-push-timeout>50</server-push-timeout>
	</session-management>

	<!-- Settings that apply only to the FastCGI connector.

	   To configure the wthttpd connector, use command line options, or
	   configure default options in /etc/wt/wthttpd
	  -->
	<connector-fcgi>
	    <!-- Valgrind path

               If debugging is enabled and this path is not empty, then valgrind
	       will be started for every shared process, or for every session
	       which has ?debug appended to the command line.

	       The variable is slighly misnamed. Not only a path can be set,
	       but also options, like for example:

                 /usr/bin/valgrind - -leak-check=full
             -->
	    <valgrind-path></valgrind-path>

	    <!-- Run directory

               Path used by Wt to do session management.
	      -->
	    <run-directory>${RUNDIR}</run-directory>

	    <!-- Number of threads per process

               This configures the size of the thread pool. You may
               want to change this value if you would like to support
               reentrant event loops, where you block one event loop
               using WDialog::exec() or related static
               methods. Everytime you enter such an event loop, one
               thread is blocked, and therefore the total number of
               sessions that reliably can do this is limited to the
               number of thread you have (minus one to unblock).

	       For the built-in http connector, there is a similar
	       config option that is specified in the whttpd config
	       file or on the command line (-t).

               The default value is 1.
	      -->
	    <num-threads>1</num-threads>

	</connector-fcgi>

        <!-- Enable debug

	     When enabled,
	     - JavaScript errors are not caught to display an error message.
	  -->
	<debug>false</debug>

	<!-- Log file

	   When the log file is empty, or omitted, logging is done to
	   stderr. This may end up in the web server error log file
	   (e.g. for apache + fastcgi module), or on stderr (e.g. for
	   the built-in httpd).
         -->
	<log-file></log-file>

	<!-- Maximum HTTP request size (Kb) -->
	<max-request-size>128</max-request-size>

	<!-- Session id length (number of characters) -->
	<session-id-length>16</session-id-length>

	<!-- Send the XHTML mime type when appropriate

	   Wt renders XHTML1 (XML variant of HTML) that is backward-compatible
	   with HTML. Using XHTML, Wt is capable of supporting XHTML-only
	   features such as embedded SVG or MathML.

	   When enabled, JWt sets an XHTML mime-type
	   (application/xhtml+xml) when the browser reports support
	   for it. Most notably, Internet Explorer does not support
	   it.  Because XHTML and HTML are slightly different with
	   respect to default CSS rules, you may want to disable
	   sending the XHTML mime-type alltogether, at least if you
	   are not using SVG (used by the WPaintedWidget).  -->
	<send-xhtml-mime-type>false</send-xhtml-mime-type>

	<!-- Do strict serialization of events.

	   By default events are queued at the client-side, and
	   transmitted to the server so that at any time only one
	   request/response is pending. This scheme has a quality that
	   resembles TCP: on a low-latency link you allow the
	   transmission of many smaller requests, while on a high
	   latency link, events will be propagated less often, but in
	   batches.

	   In any case, this scheme does not drop events, no matter
	   how quickly they are generated.

	   In rare cases, the scheme may result in unwanted behaviour,
	   because the client-side is allowed to be slighly out of
	   sync at the time an event is recorded with the server-side
	   (and more so on high-latency links). The drastic
	   alternative is to discard events while a response is
	   pending, and can be configured by setting this option to
	   true.
	  -->
	<strict-event-serialization>false</strict-event-serialization>

	<!-- Redirect message shown for browsers without JavaScript support

	   By default, Wt will use an automatic redirect to start the
	   application when the browser does not support
	   JavaScript. However, browsers are not required to follow
	   the redirection, and in some situations (when using XHTML),
	   such automatic redirection is not supported.

	   This configures the text that is shown in the anchor which
	   the user may click to be redirected to a basic HTML version
	   of your application.
          -->
	<redirect-message>Load basic HTML</redirect-message>

	<!-- Whether we are sitting behind a reverse proxy 

	   When deployed behind a reverse proxy (such as Apache or Squid),
	   the server location is not read from the "Host" header,
	   but from the X-Forwarded-For header, if present.
	  -->
	<behind-reverse-proxy>false</behind-reverse-proxy>

	<!-- Whether inline CSS is allowed.

           Some Wt widgets will insert CSS rules in the the inline
           stylesheet when first used. This can be disabled using this
	   configuration option.

           Note: some widgets, such as WTreeView, dynamically
           manipulate rules in this stylesheet, and will no longer
           work properly when inline-css is disabled.
	  -->
	<inline-css>true</inline-css>

	<!-- Ajax user agent list

            Wt considers three types of sessions:
	    - AJAX sessions: use AJAX and JavaScript
	    - plain HTML sessions: use plain old server GETs and POSTs
	    - bots: have clean internal paths and no persistent sessions

            By default, Wt does a browser detection to distinguish between
	    the first two: if a browser supports JavaScript (and has it
	    enabled), and has an AJAX DOM API, then AJAX sessions are chosen,
	    otherwise plain HTML sessions.

            Here, you may indicate which user agents should or should
            not receive an AJAX session regardless of what they report as
	    capabilities.

            Possible values for 'mode' or "white-list" or "black-list". A
	    white-list will only treat the listed agents as supporting AJAX,
	    all other agents will be served plain HTML sessions. A black-list
	    will always server plain HTML sessions to listed agents and
	    otherwise rely on browser capability detection.

            Each <user-agent> is a regular expression.
	  -->
	<user-agents type="ajax" mode="black-list">
	  <!-- <user-agent>.*Crappy browser.*</user-agent> -->
	</user-agents>

	<!-- Bot user agent list

            Here, you can specify user agents that should be should be
            treated as bots.

            Each <user-agent> is a regular expression.
	  -->
	<user-agents type="bot">
	  <user-agent>.*Googlebot.*</user-agent>
	  <user-agent>.*msnbot.*</user-agent>
	  <user-agent>.*Slurp.*</user-agent>
	  <user-agent>.*Crawler.*</user-agent>
	  <user-agent>.*Bot.*</user-agent>
	  <user-agent>.*ia_archiver.*</user-agent>
	  <user-agent>.*Twiceler.*</user-agent>
	</user-agents>

	<!-- Whether the progressive bootstrap is used.

	     The default bootstrap method first senses whether there is AJAX
	     support, and only then creates the application.

	     The progressive bootstrap method first renders a plain HTML
	     version and later upgrades to an AJAX version.
	  -->
	<progressive-bootstrap>false</progressive-bootstrap>

	<!-- Runtime Properties
     
           These properties may be used to adapt applications to their
	   deployment environment. Typical use is for paths to resources
	   that may or may not be shared between several applications.
	  -->
	<properties>
            <!-- resourcesURL property

	       The URL at which the resources/ folder is deploeyd that
	       comes distributed with Wt and contains auxiliary files
	       used to primarily for styles and themes.

	       The default value is 'resources/'
              -->
	    <property name="resourcesURL">resources/</property>

	    <!-- extBaseURL property

               Used in conjunction with Ext:: widgets, and points to the
	       URL of Ext JavaScript and resource files (css, images).
	       See the documentation for the Ext namespace for details.

	       The default value is 'ext/'
              -->
	    <property name="extBaseURL">ext/</property>

	    <!-- favicon property

	       By default, a browser will try to fetch a /favicon.ico icon
	       from the root of your web server which is used as an icon
	       for your application. You can specify an alternative location
	       by setting this property, or for an individual application
	       entry point by passing a location to WServer::addEntryPoint().
	      -->
	    <!-- <property name="favicon">images/favicon.ico</property> -->

	    <!-- oldInternalPathAPI property

	       Since wt 2.99.3, the internal path API has been simplified.
	       The API functions are still the same, but the semantics have
	       changed. To keep using the old semantics (which are deprecated
	       but still implemented) you can set this property.
	      -->
	    <!-- <property name="oldInternalPathAPI">true</property> -->
	</properties>

    </application-settings>


    <!-- Override settings for specific applications.

       Location refers to physical filesystem location of the
       application. The application prints this location (which
       corresponds to argv[0]) to the log file on startup, and this
       should match exactly.
      -->
    <!--
    <application-settings
       location="/var/www/localhost/wt-examples/hello.wt">
    </application-settings>
    -->
</server>