+"""WSGI handler for serving chained WSGI modules from physical files
+
+The WSGI handler in this module ensures that the SCRIPT_FILENAME
+variable is properly set in every request and points out a file that
+exists and is readable. It then dispatches the request in one of two
+ways: If the header X-Ash-Python-Handler is set in the request, its
+value is used as the name of a handler object to dispatch the request
+to; otherwise, the file extension of the SCRIPT_FILENAME is used to
+determine the handler object.
+
+The name of a handler object is specified as a string, which is split
+along its last constituent dot. The part left of the dot is the name
+of a module, which is imported; and the part right of the dot is the
+name of an object in that module, which should be a callable adhering
+to the WSGI specification. Alternatively, the module part may be
+omitted (such that the name is a string with no dots), in which case
+the handler object is looked up from this module.
+
+By default, this module will handle files with the extensions `.wsgi'
+or `.wsgi2' using the `chain' handler, which chainloads such files and
+runs them as independent WSGI applications. See its documentation for
+details.
+
+This module itself contains both an `application' and a `wmain'
+object. If this module is used by ashd-wsgi(1) or scgi-wsgi(1) so that
+its wmain function is called, arguments can be specified to it to
+install handlers for other file extensions. Such arguments take the
+form `.EXT=HANDLER', where EXT is the file extension to be handled,
+and HANDLER is a handler name, as described above. For example, the
+argument `.fpy=my.module.foohandler' can be given to pass requests for
+`.fpy' files to the function `foohandler' in the module `my.module'
+(which must, of course, be importable). When writing such handler
+functions, you may want to use the getmod() function in this module.
+"""
+
+import sys, os, threading, types, logging, getopt