wsgischema.xml

<schema prefix="Zope2.Startup.datatypes"
        datatype=".root_wsgi_config"
        handler="root_wsgi_handler">

  <!-- type definitions -->

  <import package="ZODB"/>
  <import package="tempstorage" condition="tempstorage"/>

  <sectiontype name="environment"
               datatype=".environment"
               keytype="identifier">
    <description>
     A section which allows you to define simple key-value pairs which
     will be used as environment variable settings during startup.
    </description>
    <key name="+" attribute="environ">
      <description>
        Use any key/value pair, e.g. 'MY_PRODUCT_ENVVAR foo_bar'
      </description>
    </key>
  </sectiontype>

  <sectiontype name="zodb_db" datatype=".ZopeDatabase"
               implements="ZODB.database" extends="zodb">

    <description>
      We need to specialize the database configuration section for Zope
      only by including a (required) mount-point argument, which
      is a string.  A Zope ZODB database can have multiple mount points,
      so this is a multikey.
    </description>
    <multikey name="mount-point" required="yes" attribute="mount_points"
              datatype=".mount_point">
      <description>
       The mount point is a slash-separated path to a 
       'Products.ZODBMountPoint.Mount.MountPoint' instance in Zope. If 
       such an instance exists, it can mount an object (the mounted 
       object) into Zope.
       By default, the object will be mounted at the same path in Zope (i.e.
       '/foo/bar' in the database will be mounted at '/foo/bar' in Zope).

       The object can be mounted at a different point using the
       'virtual_path:real_path' syntax (e.g.  'mount-point /foo/bar:/bar' 
       will mount the object at '/bar' in the database to '/foo/bar' in 
       Zope). The name of the mount point ('bar') must be the same as 
       the mounted object.

       It is also possible to specify the root that should be used in the
       mounted database by using the syntax
       'virtual_path:~real_root:real_path'. The root defaults to 'Application'
       and should not normally be changed.
      </description>
    </multikey>

    <key name="connection-class" datatype=".importable_name">
      <description>
       Change the connection class a database uses on a per-database basis to
       support different connection policies.  Use a Python dotted-path
       name to specify the connection class.
      </description>
    </key>

    <key name="container-class" datatype="string">
      <description>
       Change the container class a (mounted) database uses on a
       per-database basis to support a different container than a plain
       Folder. Use a Python dotted-path name to specify the container class.
      </description>
    </key>

  </sectiontype>

  <sectiontype name="dos_protection">

    <description>Options for DOS attack protection.

       These options limit the amount of memory and disk resources for
       the request processing by Zope itself
       (in contrast to that by the application or the frontend WSGI server).

       Note that the WSGI server (or WSGI middleware) may already have 
       consumed similar resources. Those resources, too, should
       likely get limited by corresponding configuration options.

       Zope's own request processing consists of the determination
       of the request parameters and access to the request body.

       Request parameters can come from a query string and
       the body of POST requests with content type
       "application/x-www-form-urlencoded" or "multipart/form-data".
       The options limit essentially the resources used
       for parameter values from those POST requests.
       form-urlencoded requests are assumed to contain only
       small parameter values; for them, the complete body size is limited.
       "multipart/form-data" requests are typically used
       to upload (potentially) large files. For them,
       small values are held in memory while large values
       are stored on disk. An option controls when to switch
       from memory to disk storage. Other options limit
       the total memory and disk amount for the parameter values.

       The protection options limit the resources used
       for the raw request parameter values. For non file values
       Zope maintains in addition preprocessed values;
       they usually need memory resources in the same order
       as the corresponding raw parameter values.

       Zope provides access to the request body via
       `request["BODY"]` and `request["BODYFILE"]`. The former
       accesses the body as bytes and is limited; the latter
       provides access via a file API and is not limited.
    </description>

    <key name="form-memory-limit" datatype="byte-size" default="1MB">
      <description>
       Limits the total amount of memory for all parameter values held in
       memory.
       Limits the size of form-urlencoded request bodies.
       Limits the size of request bodies accessed via `request["BODY"]`.
      </description>
    </key>

    <key name="form-disk-limit" datatype="byte-size" default="1GB">
      <description>
       Limits the total amount of disk space used for parameter values
       stored on disk.
      </description>
    </key>

    <key name="form-memfile-limit" datatype="byte-size" default="4KB">
      <description>
       Specifies the parameter value size at which its storage
       switches from memory to disk.
      </description>
    </key>

    <key name="form-part-limit" datatype="integer" default="1024">
      <description>
        Limits the maximum number of parameters or form fields. Larger
        forms are blocked by the underlying field parser.
      </description>
    </key>
  </sectiontype>


  <!-- end of type definitions -->

  <!-- schema begins  -->

  <section type="environment" attribute="environment" name="*">
    <description>
     A section which allows a user to define arbitrary key-value pairs for
     use as environment variables during Zope's run cycle.  It
     is not recommended to set system-related environment variables such as
     PYTHONPATH within this section.
    </description>
  </section>

  <key name="instancehome" datatype="existing-directory"
       required="yes">
    <description>
      The top-level directory which contains the "instance" data for the
      application server. It may also contain "etc", "bin", "log",
      and "var" directories depending on how you've configured your Zope
      instance.
    </description>
  </key>

  <key name="clienthome" datatype="existing-directory">
    <description>
      The directory used to store the default filestorage file used to
      back the ZODB database, as well as other files used by the
      Zope applications server during runtime.
    </description>
    <metadefault>$instancehome/var</metadefault>
  </key>

  <key name="debug-mode" datatype="boolean" default="off">
    <description>
    A switch which controls several aspects of Zope operation useful for
    developing under Zope.  When debug mode is on:

     - Errors in product initialization will cause startup to fail
       (instead of writing error messages to the event log file).

     - Filesystem-based scripts such as skins, PageTemplateFiles, and
       DTMLFiles can be edited while the server is running and the server
       will detect these changes in real time.  When this switch is
       off, you must restart the server to see the changes.

     Setting this to 'off' when Zope is in a production environment is
     encouraged, as it speeds execution (sometimes dramatically).
    </description>
    <metadefault>off</metadefault>
  </key>

  <key name="debug-exceptions" datatype="boolean" default="off">
    <description>
    This switch controls how exceptions are handled. If it is set to
    "off" (the default), Zope's own exception handling is active.
    Exception views or a standard_error_message are used to handle them.

    If set to "on", exceptions are not handled by Zope and can propagate
    into the WSGI pipeline, where they may be handled by debugging
    middleware.

    This setting should always be "off" in production. It is useful for
    developers and while debugging site issues.
    </description>
    <metadefault>off</metadefault>
  </key>

  <key name="locale" datatype="locale" handler="locale">
    <description>
     Locale name to be used. See your operating system documentation for locale
     information specific to your system. If the requested locale is not
     supported by your system, an error will be raised and Zope will not start.
    </description>
    <metadefault>unset</metadefault>
  </key>

  <key name="datetime-format" datatype=".datetime_format"
       handler="datetime_format" default="us">
    <description>
     Set this variable either to "us" or "international" to force the
     DateTime module to parse date strings either with
     month-before-days-before-year ("us") or
     days-before-month-before-year ("international").  The default
     behaviour of DateTime (when this setting is left unset) is to
     parse dates as US dates.
    </description>
    <metadefault>us</metadefault>
  </key>

  <key name="python-check-interval" datatype="integer" default="1000">
    <description>
      Value passed to Python's sys.setcheckinterval() function.  The
      higher this is, the less frequently the Python interpreter
      checks for keyboard interrupts.  Setting this to higher values
      also reduces the frequency of potential thread switches, which
      can improve the performance of a busy server.
    </description>
  </key>

  <key name="http-realm" default="Zope">
    <description>
     The HTTP "Realm" header value sent by this Zope instance. This value
     often shows up in basic authentication dialogs.
    </description>
    <metadefault>Zope</metadefault>
  </key>

  <key name="automatically-quote-dtml-request-data" datatype="boolean"
       default="on" handler="automatically_quote_dtml_request_data">
     <description>
     Set this directive to 'off' in order to disable the autoquoting of
     implicitly retrieved REQUEST data by DTML code which contains a '&lt;'
     when used in &lt;dtml-var&gt; construction. When this directive is 'on',
     all data implicitly retrieved from the REQUEST in DTML (as opposed to
     addressing REQUEST.somevarname directly) that contains a '&lt;' will be
     HTML-quoted when interpolated via a &lt;dtml-var&gt; or &amp;dtml-
     construct. This mitigates the possibility that DTML programmers will
     leave their sites open to a "client-side trojan" attack.
     </description>
     <metadefault>on</metadefault>
  </key>

  <key name="zmi-bookmarkable-urls" datatype="boolean"
       default="on">
     <description>
     Set this directive to 'on' to cause Zope to show the ZMI right hand
     frame's URL in the browser navigation bar as opposed to the static
     '/manage'. The default is 'on'. To restore the behavior of Zope 2
     where the URL was always static unless you opened the right-hand frame in
     its own browser window, set this to off.
     </description>
     <metadefault>on</metadefault>
  </key>

  <key name="pid-filename" datatype="existing-dirpath">
    <description>
      The full path to which the Zope process will write its
      OS process id at startup.
    </description>
    <metadefault>$clienthome/Z4.pid</metadefault>
  </key>

  <multikey name="trusted-proxy" datatype="ipaddr-or-hostname"
       attribute="trusted_proxies">
     <description>
     Define one or more 'trusted-proxies' keys, each of which is a
     hostname or an IP address.  The set of definitions comprises a list
     of front-end proxies that are trusted to supply an accurate
     X_FORWARDED_FOR header to Zope (security-related).
     </description>
     <metadefault>unset</metadefault>
  </multikey>

  <key name="max-conflict-retries" datatype="integer" default="3"
       attribute="max_conflict_retries">
    <description>
      The maximum number of retries on a conflict error
    </description>
  </key>

  <key name="security-policy-implementation"
       datatype=".security_policy_implementation"
       default="C">
     <description>
     The default Zope "security policy" implementation is written in C.
     Set this key to "PYTHON" to use the Python implementation
     (useful for debugging purposes); set it to "C" to use the C
     implementation.
     </description>
     <metadefault>C</metadefault>
  </key>

  <key name="skip-authentication-checking" datatype="boolean"
       default="off">
     <description>
     Set this directive to 'on' to cause Zope to prevent Zope from
     attempting to authenticate users during normal operation.
     Potentially dangerous from a security perspective.  Only works if
     security-policy-implementation is set to 'C'.
     </description>
     <metadefault>off</metadefault>
  </key>

  <key name="skip-ownership-checking" datatype="boolean"
       default="off">
     <description>
     Set this directive to 'on' to cause Zope to ignore ownership checking
     when attempting to execute "through the web" code. By default, this
     directive is off in order to prevent 'trojan horse' security problems
     whereby a user with less privilege can cause a user with more
     privilege to execute code which the less privileged user has written.
     </description>
     <metadefault>off</metadefault>
  </key>

  <key name="verbose-security" datatype="boolean"
       default="off">
     <description>
     Set this directive to 'on' to enable verbose security exceptions.
     This can help you track down the reason for Unauthorized exceptions,
     but it is not suitable for public sites because it may reveal
     unnecessary information about the structure of your site.  Only
     works if security-policy-implementation is set to 'PYTHON'.
     </description>
     <metadefault>off</metadefault>
  </key>

  <multisection type="ZODB.Database" name="+" attribute="databases">
    <description>
       Zope ZODB databases must have a name, and they are required to be
       referenced via the "zodb_db" database type because it is
       the only kind of database definition that implements
       the required mount-point argument.  There is another
       database sectiontype named "zodb", but it cannot be used
       in the context of a proper Zope configuration (due to
       lack of a mount-point).
    </description>
  </multisection>

  <key name="default-zpublisher-encoding"
       datatype=".default_zpublisher_encoding"
       default="utf-8">
     <description>
       This key controls what character set is used to encode unicode
       data that reaches ZPublisher without any other specified encoding.
     </description>
  </key>

  <abstracttype name="zope.product.base">
    <description>
      Base type for product-specific configuration sections.

      Specific products should implement configuration sections by
      defining section types that implement this abstract type and
      using their own schema component to define meaningful settings.

    </description>
  </abstracttype>

  <sectiontype name="product-config" implements="zope.product.base">
    <description>
    Product-specific configuration, expressed as arbitrary name-value pairs.
    </description>

    <key name="+"
         attribute="mapping"
         required="no"
         />
  </sectiontype>

  <multisection type="zope.product.base" name="+"
                attribute="product_config">
   <description>
    Product-specific configuration stanzas.

    Products may use the &lt;product-config&gt; section type, or may supply
    a component.xml which defines section types with their own schemas.

    All sections for this multisection will be collected into the
    'product_config' attribute of the configuration object.
   </description>
  </multisection>

  <key name="webdav-source-port" datatype="integer" default="0">
    <description>
      This value designates a network port number as WebDAV source port.

      WebDAV requires special handling for GET requests. A WebDAV
      client expects to receive the un-rendered source in the returned
      response body, not the rendered result a web browser would get.

      If this value is set to a positive integer, any GET request coming into
      Zope via the designated port will be marked up to signal that this is a
      WebDAV request. This request markup resembles what ZServer did for
      requests coming though its designated WebDAV source server port, so it is
      backwards-compatible for existing code that offers WebDAV handling under
      ZServer.

      Please note that Zope itself has no server capabilities and cannot open
      network ports. You need to configure your WSGI server to listen on the
      designated port.
    </description>
  </key>

  <key name="enable-ms-public-header"
       datatype="boolean"
       handler="enable_ms_public_header"
       default="off">
   <description>
    Set this directive to 'on' to enable sending the "Public" header
    in response to an WebDAV OPTIONS request - but only those coming from
    Microsoft WebDAV clients.

    Though recent WebDAV drafts mention this header, the original
    WebDAV RFC did not mention it as part of the standard. Very few
    web servers out there include this header in their replies, most
    notably IIS and Netscape Enterprise 3.6.

    Documentation about this header is sparse. Some versions of
    Microsoft Web Folders after 2005 apparently require its presence,
    but most documentation links have expired.
   </description>
   <metadefault>off</metadefault>
  </key>

  <key name="enable-xmlrpc" datatype="boolean" default="on">
    <description>
     Turn Zope's built-in XML-RPC support on or off.

     Zope has built-in support for XML-RPC requests. It will attempt to use
     XML-RPC for POST-requests with Content-Type header 'text/xml'. By
     default the XML-RPC request support is enabled.

     Due to the limited use of XML-RPC nowadays and its potential for abuse
     by malicious actors you can set this directive to 'off' to turn off
     support for XML-RPC. Incoming XML-RPC requests will be refused with
     a BadRequest (HTTP status 400) response.
    </description>
    <metadefault>on</metadefault>
  </key>

  <section type="dos_protection" handler="dos_protection"
           name="*" attribute="dos_protection" />

</schema>