<server>
    <application-settings location="*">
	<session-management>

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

	    <shared-process>
	        <num-processes>1</num-processes>
	    </shared-process>

	    <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>300</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>

        <!-- Javascript debug options

	     Values:
	     - naked: JavaScript errors are not caught at all
	     - false: JavaScript errors are caught and a simple error message
	              is printed to indicate that something is terribly wrong
	     - stack: equivalent to 'false'
	     - true: JavaScript errors are rethrown after server-side logging

             Unless the value is 'naked',
	     WApplication::handleJavaScriptError() is called which by
	     default logs the error and terminates the session.
	  -->
	<debug>true</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>

	<!-- Logger configuration

	   This configures the logger. With the default configuration,
	   everything except for debugging messages are logged.

	   The configuration is a string that defines rules for
	   enabling or disabling certain logging. It is a white-space
	   delimited list of rules, and each rule is of the form:

	     [-]level : enables (or disables) logging of messages of
	     the given level; '*' is a wild-card that matches all
	     levels

	     [-]level:scope : enables (or disables) logging of
	     messages of the given level and scope; '*' is a wild-card
	     that matches all levels or scopes.  The default
	     configuration is "* -debug", i.e. by default everything
	     is logged, except for "debug" messages.

	   Some other examples:

	     "* -debug debug:wthttp": logs everything, including
	     debugging messages of scope "wthttp", but no other
	     debugging messages.

	     "* -info -debug": disables logging of info messages
	     in addition to debugging messages.

	   Note debugging messages are only emitted when debugging
	   has been enabled while building Wt.
	  -->
	<log-config>* -info</log-config>

	<!-- Maximum HTTP request size (Kb)

           Maximum size of an incoming POST request. This value must be
           increased when the user is allowed to upload files.
         -->
	<max-request-size>128</max-request-size>

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

	<!-- DoS prevention: limit plain HTML sessions

           This is a simple measure which avoids Denial-of-Service
           attacks on plain HTML sessions, which are easy to mount in
           particular in the case of progressive bootstrap mode.

           This setting may be used to keep the ratio of plain HTML
           versus Ajax sessions under a certain ratio. Typically, most
           of your sessions will be Ajax sessions, and only a tiny
           fraction (e.g. less than 5%) will be plain HTML
           sessions. This ratio is only enforced when more than 20 sessions
	   have been created.
	  -->
	<plain-ajax-sessions-ratio-limit>1</plain-ajax-sessions-ratio-limit>

	<!-- DoS prevention: adds a puzzle to validate Ajax sessions

           This is a simple measure which avoids Denial-of-Service
           attacks on Ajax sessions.

           When enabled, a puzzle needs to be solved in the first Ajax
           request which eliminates agents that do not build a proper
           DOM tree.
	  -->
	<ajax-puzzle>false</ajax-puzzle>

	<strict-event-serialization>false</strict-event-serialization>

	<web-sockets>false</web-sockets>

	<webgl-detection>false</webgl-detection>

	<redirect-message>Load basic HTML</redirect-message>

	<behind-reverse-proxy>false</behind-reverse-proxy>

	<inline-css>true</inline-css>

	<!-- The timeout before showing the loading indicator.

	   The value is specified in ms.
          -->
	<indicator-timeout>1000</indicator-timeout>

	<!-- The timeout for processing a double click event.

	   The value is specified in ms.
          -->
	<double-click-timeout>200</double-click-timeout>

	<!-- 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>

	<UA-Compatible></UA-Compatible>

	<progressive-bootstrap>false</progressive-bootstrap>

	<session-id-cookie>false</session-id-cookie>

	<!-- Configure cookie checks

         By default, Wt will test for cookie support using JavaScript.
	 Because cookie manipulation from JavaScript is a common security
	 risk vector, some prefer to disable these checks.

	 -->
	<cookie-checks>true</cookie-checks>

	<!-- Configure meta headers

         The user-agent allows optional filtering based on the
         user-agent, using a regular expression. You can have multiple
         set-meta-headers definitions.

	 -->
	<meta-headers user-agent=".*MSIE.*">
	  <meta name="robots" content="noindex" />
	</meta-headers>

	<!-- 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>
	    <!-- baseURL property

	       The absolute URL at which the application is deployed
	       (known to the user). This is needed only in two scenarios.

	       a) use of relative URLs in included XHTML

	       When you use relative URLs for images, etc... in
	       literal XHTML fragments (e.g. in WTemplate), which need
	       to resolve against the deployment path of the
	       application. This will not work as expected in the
	       presence of an internal application path.  This URL is
	       set as base URL in the HTML, against which relative
	       URLs are resolved so that these work correctly
	       regardless of the internal path. It is also used
	       explicitly in any URL generated by the library.

	       b) widgetset mode deployments

	       Another situation in which you need to define the baseURL is
	       when deploying a widgetset mode application behind a reverse
	       proxy. A widgetset mode application uses only absolute URLs
	       because it may be hosted in a web page from an entirely
	       different domain.

	       By default, no baseURL is specified, in which case Wt will
	       avoid using absolute URLs. Relative URLs passed in API calls
	       will be "fixed" so that they resolve against the location of the
	       application deploy path, even in the presence of an
	       internal path.
	      -->
	    <!-- <property name="baseURL">"http://mysite.com/app</property> -->

            <!-- resourcesURL property

	       The URL at which the resources/ folder is deployed 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> -->
	</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>
