PythonPath directive sets the PythonPath. The path must be specified in Python list notation, e.g.
PythonPath "['/usr/local/lib/python1.5', '/usr/local/lib/site_python', '/some/other/place']".The path specified in this directive will replace the path, not add to it. Note that this directive should not be used as a security measure since the Python path is easily manipulated from within the scripts.
Forces the subinterpreter name to be name, instead of the name assigned by mod_python. Mod_python names subinterpreters by using full path of a directory thereby guaranteeing uniqueness. By using this directive, scripts located in different directories and that would by default be executed in different subinterpreters, can be forced to execute in the same subinterpreter.
Instructs mod_python to name subinterpreters using the directory of
the file in the request (request_rec->filename) rather
than the directory in which the Python*Handler directive currently in effect
was encountered. This means that scripts in different directories will
execute in different subinterpreters as opposed to the default policy
where scripts effected by the same Handler directive execute in the
same subinterpreter, even if they are in different directories.
Let's say you have a
/directory/subdirectory. /directory has an
.htaccess file with a PythonHandler directive.
/directory/subdirectory doesn't have an .htacess. By
default, scripts in /directory and
/directory/subdirectory would execute in the same
interpreter based on the directory where PythonHandler was
encountered. With PythonInterpPerDirectory, there would be two
different interpreters, one for each directory.
Normally, the traceback output resulting from uncaught Python errors is sent to the error log. With PythonDebug directive specified, the output will be sent to the client, except when the error is IOError while writing, in which case it will go to the error log.
A consequence of this directive being specified is that when multiple handlers are involved in processing the request, the processing will
This directive is very usefull during the development process. It is recommended that you do not use it production environment as it may reveal to the client sensitive security information.
Instructs mod_python not to check the modification date of the module file. By default, mod_python checks the timestamp of the file and reloads the module if the module's file modification date is later than the last import or reload.
This options is useful in production environment where the modules do not change, it will save some processing time and give a small performance gain.
Assigns a key value pair to a table that can be later retrieved by the
request.get_options() function. This is useful to pass information
between the apache configuration files (httpd.conf, .htaccess, etc) and the Python
programs.
NoneThis routine is called after the request has been read but before any other phases have been processed. This is useful to make decisions based upon the input header fields.
NoneThis routine gives allows for an opportunity to translate the URI into an actual filename, before the server's default rules (Alias directives and the like) are followed.
NoneThis handler is called to give the module a chance to look at the request headers and take any appropriate specific actions early in the processing sequence.
NoneThis routine is called to check for any module-specific restrictions placed upon the requested resource.
For example, this can be used to restrict access by IP numer. To do so, you would return HTTP_FORBIDDEN or some such to indicate that access is not allowed.
NoneThis routine is called to check the authentication information sent with the request (such as looking up the user in a database and verifying that the [encrypted] password sent matches the one in the database).
NoneThis routine is called to check to see if the resource being requested requires authorization.
NoneThis routine is called to determine and/or set the various document type information bits, like Content-type (via r->content_type), language, et cetera.
NoneThis routine is called to perform any module-specific fixing of header fields, et cetera. It is invoked just before any content-handler.
NoneThis is the main request handler. 99.99% of your applications will only provide this one handler.
NoneThis routine is called to perform any module-specific logging activities over and above the normal server things.