iframe-proxy | Sunbelt Computer Software

812 lines (665 loc) · 28.4 KB
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!-- $Id: pythonapi.html,v 1.14 2000/10/18 20:01:29 gtrubetskoy Exp $ -->
    <title>Python API</title>
  <body bgcolor="white">
    <h1>Python API</h1>
      <li><a href="#subinterpreters">Multiple Interpreters</a>
      <li><a href="#handler">Overview of a Handler</a>
      <li><a href="#apachemodule">Apache module</a>
	  <li><a href="#table">Table Object</a>
	  <li><a href="#request">Request Object</a>
	  <li><a href="#connection">Connection Object</a>
	  <li><a href="#server">Server Object</a>
	<li><a href="#debugging">Debugging</a>
    <a name="subinterpreters"><h3>Multiple Interpreters</h3></a>
    <blockquote>
      When working with mod_python, it is important to be aware of a feature of
      Python that is normally not used when using the language for writing scripts to be
      run from command line. This feature is not available from within Python itself
      (at least in 1.5.2) and can only be accessed through the C language API.
	Python C API provides the ability to create <em>subinterpreters</em>. A more
	detailed description of a subinterpreter is given in the documentation for the
	<a href="http://www.python.org/doc/current/api/initialization.html#l2h-439">Py_NewInterpreter</a> 
	function. For this discussion, it will suffice to say that each
	subinterpreter has its own separate namespace, not accessible from other
	subinterpreters.
	Subinterpreters are very useful to make sure that separate programs running 
	under the same Apache server do not &quot;step&quot; on each other.
	At server start-up or mod_python initialization time, mod_python 
	initializes the global interpreter. The global interpreter contains a 
	dictionary of subinterpreters. Initially, this dictionary is empty. With
	every hit, as needed, subinterpreters are created, and references to them
	are stored in this dictionary. The dictionary is keyed on a string, also
	known as <em>interpreter name</em>. This name can be anything, except
	&quot;global_interpreter&quot;, which is the name reserved for the 
	<em>global</em> interpreter.
	The way interpreters are named
	can be controlled by <code>PythonInterp</code> directives. Default behaviour
	is to name interpreters using the Apache virtual server name 
	(<code>ServerName</code> directive). 
	This means that all scripts in the
	same vrtual server execute in the same subinterpreter, but scripts in 
	virtual servers execute in different subinterpreters with completely separate
	namespaces. 
	<code>PythonIterpPerDirectory</code> and <code>PythonInterpPerDirective</code>
	directives alter the naming convention to use the absolute path of the
	directory being accessed, or the directory in which the 
	<code>Python*Handler</code> was encountered, respectively.
	Once created, a subinterpreter will be reused for subsequent requests, but
	it is never destroyed until the Apache child process dies. 
    </blockquote>
    <a name="handler"><h3>Overview of a handler</h3></a>
    <blockquote>
      A <em>handler</em> is a function that processes a particular
      phase of a request.  Apache processes requests in phases - read
      the request, process headers, provide content, etc. For every
      phase, it will call handlers, provided by either the Apache core
      or one of its modules, such as mod_python, which passes control
      to functions provided b the user and written in Python.  A
      handler written in Python is not any different than a handler
      written in C, and follows these rules:
	A handler function will always be passed a reference to a <code>request</code>
	Every handler can return
	<li><code>apache.OK</code>, meaning this phase of the request was handled by this
	  handler and no errors occurred.
	<li><code>apache.DECLINED</code>, meaning this handler refused to handle this
	  phase of the request and Apache needs to look for another handler.
	<li><code>apache.<em>HTTP_ERROR</em></code>, meaning an HTTP error occurred. 
	    <code><em>HTTP_ERROR</em></code> can be:
                HTTP_CONTINUE                     = 100
                HTTP_SWITCHING_PROTOCOLS          = 101
                HTTP_PROCESSING                   = 102
                HTTP_CREATED                      = 201
                HTTP_ACCEPTED                     = 202
                HTTP_NON_AUTHORITATIVE            = 203
                HTTP_NO_CONTENT                   = 204
                HTTP_RESET_CONTENT                = 205
                HTTP_PARTIAL_CONTENT              = 206
                HTTP_MULTI_STATUS                 = 207
                HTTP_MULTIPLE_CHOICES             = 300
                HTTP_MOVED_PERMANENTLY            = 301
                HTTP_MOVED_TEMPORARILY            = 302
                HTTP_SEE_OTHER                    = 303
                HTTP_NOT_MODIFIED                 = 304
                HTTP_USE_PROXY                    = 305
                HTTP_TEMPORARY_REDIRECT           = 307
                HTTP_BAD_REQUEST                  = 400
                HTTP_UNAUTHORIZED                 = 401
                HTTP_PAYMENT_REQUIRED             = 402
                HTTP_FORBIDDEN                    = 403
                HTTP_NOT_FOUND                    = 404
                HTTP_METHOD_NOT_ALLOWED           = 405
                HTTP_NOT_ACCEPTABLE               = 406
                HTTP_PROXY_AUTHENTICATION_REQUIRED= 407
                HTTP_REQUEST_TIME_OUT             = 408
                HTTP_CONFLICT                     = 409
                HTTP_LENGTH_REQUIRED              = 411
                HTTP_PRECONDITION_FAILED          = 412
                HTTP_REQUEST_ENTITY_TOO_LARGE     = 413
                HTTP_REQUEST_URI_TOO_LARGE        = 414
                HTTP_UNSUPPORTED_MEDIA_TYPE       = 415
                HTTP_RANGE_NOT_SATISFIABLE        = 416
                HTTP_EXPECTATION_FAILED           = 417
                HTTP_UNPROCESSABLE_ENTITY         = 422
                HTTP_LOCKED                       = 423
                HTTP_FAILED_DEPENDENCY            = 424
                HTTP_INTERNAL_SERVER_ERROR        = 500
                HTTP_NOT_IMPLEMENTED              = 501
                HTTP_BAD_GATEWAY                  = 502
                HTTP_SERVICE_UNAVAILABLE          = 503
                HTTP_GATEWAY_TIME_OUT             = 504
                HTTP_VERSION_NOT_SUPPORTED        = 505
                HTTP_VARIANT_ALSO_VARIES          = 506
                HTTP_INSUFFICIENT_STORAGE         = 507
                HTTP_NOT_EXTENDED                 = 510
      </ul>
	As an alternative to returning an HTTP error code,
	handlers can signal an error by raising the <code>apache.SERVER_RETURN</code> 
	exception, and providing an HTTP error code as the exception value, e.g.
          raise apache.SERVER_RETURN, apache.HTTP_FORBIDDEN
        </pre>
	Handlers can send content to the client using the <code>request.write()</code>
	function. Before sending the body of the response, headers must be sent
	using the <code>request.send_http_header()</code> function.
	Client data, such as POST requests, can be read by using the 
	<code>req.read()</code> function.
	<em>NOTE:</em>The directory of the Apache Python*Handler in
	effect is prepended to the Python Path. If the directive was
	specified in a server config file outside any
	&lt;Directory&gt;, then the directory is unknown and not prepended.
	An example of a minimalistic handler might be:
<pre>	  from mod_python import apache
	  def requesthandler(req):
              req.content_type = "text/plain"
	      req.send_http_header()
	      req.write("Hello World!")
	      return apache.OK</pre>
    </blockquote>
    <a name="apachemodule"><h3>apache module</h3></a>
    <blockquote>
    The Python Application Programmer interface to Apache internals is contained 
      in a module appropriately named <code>apache</code>, located 
      inside the <code>mod_python</code> package. This module provides some important
      objects that map to Apache internal structures, as well as some useful functions,
      all documented below.
      The <code>apache</code> module can only be imported by a script
      running under mod_python. This is because it depends on a
      built-in module <code>_apache</code> provided by mod_python. It
      is best imported like this:
      <pre>from mod_python import apache</pre>
      Mod_python's <code>apache</code> module defines the following objects and 
      functions. For a more in-depth look at Apache internals, see the 
      <a href="http://dev.apache.org/API.html">Shambhala API Notes</a>.
      <b>log_error(message, [level=level], [server=server])</b><br>
      An interface to the Apache <code>
      <a href="http://dev.apache.org/apidoc/apidoc_ap_log_error.html">ap_log_error</a>
      </code> function. <em>message</em> is a string with the error message, 
      <em>level</em> is one of the following constants:
      <pre>
                APLOG_EMERG
                APLOG_ALERT
                APLOG_CRIT
                APLOG_ERR
                APLOG_WARNING
                APLOG_NOTICE
                APLOG_INFO
                APLOG_DEBUG
                APLOG_NOERRNO
      </pre>
      <em>server</em> is a reference to a <code>server</code> object which is passed
      as a member of the request, <code>request.server</code>. If <em>server</em> is
      not specified, then the error will be logged to the default error log, otherwise
      it will be written to the error log for the appropriate virtual server.
      <b>make_table()</b><br>
	Returns a new empty <code>table</code> object.
      <a name="table"><h4>Table Object</h4></a>
      The <code>table</code> object is a Python mapping to the Apache <code>
	<a href="http://dev.apache.org/apidoc/apidoc_table.html">table</a>
      </code>. The <code>table</code> object performs just like
      a dictionary, with the only difference that key lookups are case
      insensitive.
	Much of the information that Apache uses is stored in tables. For
	example, <code>request.header_in</code> and 
	<code>request.headers_out</code>.
	All the tables that mod_python provides inside the <code>request</code>
	object are actual mappings to the Apache structures, so changing the Python
	table also changes the underlying Apache table.
	In addition to normal dictionary-like behavior, the table object also has
	an <b>add(string key, string val)</b> method. <em>Add()</em> allows for 
	creating duplicate keys, which is useful when multiple headers, such as 
	Set-Cookie are required.
      <a name="request"><h4>Request Object</h4></a>
      The <code>request</code> object is a Python mapping to the Apache <code>
	<a href="http://dev.apache.org/apidoc/apidoc_request_rec.html">request_rec</a>
      </code> structure.
	When a handler is invoked, it is always passed a single
	argument - the <code>request</code> object. Here are the
	attributes of the <code>request</code> object:
      <h4>Functions</h4>
      <blockquote>
	  <dt><b>add_handler(string htype, string handler [,string dir])</b>
	    Allows dynamic handler registration. <em>htype</em> is a name of any of 
	    the apache Python*Handler directives, e.g. 
	    <code>&quot;PythonHandler&quot;</code>. <em>handler</em> is the name
	    of the module and the handler function. Optional <em>dir</em> is the name
	    of the directory to be added to the python path. If no directory is
	    specified, then, if there is already a handler of the same type specified,
	    its directory is inherited, otherwise the directory of the presently
	    executing handler is used.
	      A handler added this way only persists throughout the life of the request.
	      It is possible to register more handlers while inside the handler of the
	      same type. One has to be careful as to not to create an infinite loop
	      this way.
	      Dynamic handler registration is a useful technique that allows the code
	      to take a decision on what will happen next. A typical example might
	      be a PythonAuthenHandler that will assign different PythonHandlers based
	      on the authrntication level, something like:
              if manager:
	          req.add_handler("PythonHandler", "menu::admin")
              else:
                  req.add_handler("PythonHandler", "menu::basic")
	    </pre>
	    Note: at this point there is no checking being done on the validity of the
	    handler name. If you pass this function an invalid handler it will simply
	    be ignored.
	  <dt><br><b>add_common_vars()</b>
	    Calls the Apache 
	    <a href="http://dev.apache.org/apidoc/apidoc_ap_add_common_vars.html">ap_add_common_vars</a>
	    function. After a call to this function,
	    <code>request.subprocess_env</code> will contain a lot of
	    CGI information.
	  <dt><br><b>child_terminate()</b>
	    Terminate a child process. This should terminate the current child 
	    process in a nice fashion.
	      This function does nothing in multithreaded environments (e.g. Windows).
	  <dt><br><b>get_basic_auth_pw()</b>
	    Returns a string containing the password when basic authentication is used.
	  <dt><br><b>get_config()</b>
	    Returns a reference to the <code>table</code> object containing the 
	    configuration in effect for this request. The table has directives as keys,
	    and their values, if any, as values.
	  <dt><br><b>get_dirs()</b>
	    Returns a reference to the
	    <code>table</code> object keyed by directives currently in
	    effect and having directory names of where the particular
	    directive was last encountered as values. For every key in
	    the table returned by get_config(), there will be a key in
	    this table. If the directive was in one of the server config
	    files outside of any &lt;Directory&gt;, then the value will
	    be an empty string.
	  <dt><br><b>get_remote_host(int type = apache.REMOTE_NAME)</b>
	    Returns the a string with the remote client's DNS name or IP or
	    None on failure. The first call to this function may entail a 
	    DNS look up, but subsequent calls will use the cached result
	    from the first call.
	      The optional <em>type</em> argument can specify the following:
	      <b>apache.REMOTE_HOST</b> Look
	      up the DNS name. Fail if Apache directive
	      <code>HostNameLookups</code> is <code>off</code> or the
	      hostname cannot be determined.
	      <b>apache.REMOTE_NAME</b> <em>(Default)</em> Return
	      the DNS name if possible, or the IP (as a string in
	      dotted decimal notation) otherwise.
	      <b>apache.REMOTE_NOLOOKUP</b> Don't perform a DNS lookup,
	      return an IP. Note: if a lookup was performed prior to this call,
	      then the cached host name is returned. 
	      <b>apache.REMOTE_DOUBLE_REV</b> Force a double-reverse
	      lookup. On failure, return None.
	  <dt><br><b>get_options()</b>
	    Returns a reference to the <code>table</code> object containing the options
	    set by the PythonOption directives.
	  <dt><br><b>read(int len)</b>
	    Reads <em>len</em> bytes directly from the client, returning a string with 
	    the data read. When there is nothing more to read, None is returned. To
	    find out how much there is to read, use the <code>Content-length</code>
	    header sent by the client, for example:
            len = int(req.headers_in["content-length"])
            form_data = req.read(len)
	    </pre>
	    This function is affected by the <code>Timeout</code> Apache configuration
	    directive. The read will be aborted and an IOError raised if the Timout
	    is reached while reading client data.
	  <dt><br><b>register_cleanup(callable function, data=None)</b>
	    Registers a cleanup. Argument <em>function</em> can be any callable object,
	    the optional argument <em>data</em> can be any object. At the very end of
	    the request, just before the actual request record is destroyed by Apache,
	    function <em>function</em> will be called with one argument, <em>data</em>.
	  <dt><br><b>send_http_header()</b>
	    Starts the output from the request by sending
	    the HTTP headers. This function has no effect when called more than
	    once within the same request. Any manipulation of 
	    <code>request.headers_out</code> after this function has been called is 
	    pointless since the headers have already been sent to the client.
	  <dt><br><b>write(string)</b>
	    Writes <em>string</em> directly to the client, then flushes the buffer.
      </blockquote>
      <h4>Other Members</h4>
      <blockquote>
	The request object contains most of the members of the underlying
	<code><a href="http://dev.apache.org/apidoc/apidoc_request_rec.html">request_rec</a></code>.
	  <dt><b>connection</b> <em>connection object, RO</em> 
	    A <code>connection</code> object associated with this request. See 
	    <a href="#connection">Connection Object</a> below for details.
	  <dt><br><b>server</b> <em>server object, RO</em>
	    A <code>server</code> object associate with this request. See
	    <a href="#server">Server Object</a> below for details.
	  <dt><br><b>next</b> <em>request object, RO</em>
	    If this is an internal redirect, the request object we redirect to.
	  <dt><br><b>prev</b> <em>request object, RO</em>
	    If this is an internal redirect, the request object we redirect from.
	  <dt><br><b>main</b> <em>request object, RO</em>
	    If this is a sub-request, pointer to the main request.
	  <dt><br><b>the_request</b> <em>string, RO</em>
	    First line of the request.
	  <dt><br><b>assbackwards</b> <em>int, RO</em>
	    Is this an HTTP/0.9 &quot;simple&quot; request?
	  <dt><br><b>header_only</b> <em>int, RO</em>
	    HEAD request, as opposed to GET.
	  <dt><br><b>protocol</b> <em>string, RO</em>
	    Protocol, as given by the client, or &quot;HTTP/0.9&quot;
	  <dt><br><b>proto_num</b> <em>int, RO</em>
	    Number version of protocol; 1.1 = 1001
	  <dt><br><b>hostname</b> <em>string, RO</em>
	    Host, as set by full URI or Host:
	  <dt><br><b>request_time</b> <em>long, RO</em>
	    When request started.
	  <dt><br><b>status_line</b> <em>string, RO</em>
	    Status line. E.g. &quot;200 OK&quot;.
	  <dt><br><b>status</b> <em>int, RW</em>
	    An integer, whose value will be used in building the status line of the
	    HTTP reply headers.
	  <dt><br><b>method</b> <em>string, RO</em>
	    Method - GET, HEAD, POST, etc.
	  <dt><br><b>method_number</b> <em>int, RO</em>
	    Method number. 
	  <dt><br><b>allowed</b> <em>int, RO</em>
	    A bitvector of the allowed methods. Used in relation with 
	    METHOD_NOT_ALLOWED.
	  <dt><br><b>sent_body</b> <em>int, RO</em>
	    Byte count in stream is for body. (?)
	  <dt><br><b>bytes_sent</b> <em>long, RO</em>
	    Bytes sent.
	  <dt><br><b>mtime</b> <em>long, RO</em>
	    Time the resource was last modified.
	  <dt><br><b>boundary</b> <em>string, RO</em>
	    Multipart/byteranges boundary.
	  <dt><br><b>range</b> <em>string, RO</em>
	    The Range: header.
	  <dt><br><b>clength</b> <em>long, RO</em>
	    The &quot;real&quot; content length. (I.e. can only be used
	    after the content's been read?)
	  <dt><br><b>remaining</b> <em>long, RO</em>
	    Bytes left to read. (Only makes sense inside a read operation.)
	  <dt><br><b>read_length</b> <em>long, RO</em>
	    Bytes that have been read.
	  <dt><br><b>read_body</b> <em>int, RO</em>
	    How the request body should be read. (?)
	  <dt><br><b>read_chunked</b> <em>int, RO</em>
	    Read chunked transfer coding.
	  <dt><br><b>headers_in</b>
	    A <code>table</code> object containing the headers send by the client.
	  <dt><br><b>headers_out</b>
	    A <code>table</code> object representing the headers to be sent to the
	    client. Note that manipulating this table after the 
	    <code>request.send_http_headers()</code> has been called is meaningless,
	    since the headers have already gone out to the client.
	  <dt><br><b>err_headers_out</b> <em>table</em>
	    These headers get send with the error response, instead of headers_out.
	  <dt><br><b>subprocess_env</b> <em>table</em>
	    A <code>table</code> representing the subprocess environment. See also
	    <code>request.add_common_vars()</code>.
	  <dt><br><b>notes</b> <em>table</em>
	    A place-holder for request-specific information to be used by 
	    modules.
	  <dt><br><b>content_type</b> <em>string, RW</em>
	    A string, representing the response content type.
	  <dt><br><b>headers_out</b> <em>table</em>
	    Headers going out to the client.
	  <dt><br><b>handler</b> <em>string, RO</em>
	    The hame of the handler currently being processed. In all
	    cases with mod_python, this should be &quot;python-program&quot;.
	  <dt><br><b>content_encoding</b> <em>string, RO</em>
	    Content encoding
	  <dt><br><b>vlist_validator</b> <em>string, RO</em>
	    Variant list validator (if negotiated)
	  <dt><br><b>no_cache</b> <em>int, RO</em>
	    No cache.
	  <dt><br><b>no_local_copy</b> <em>int, RO</em>
	    No local copy exists.
	  <dt><br><b>unparsed_uri</b> <em>string, RO</em>
	    The URI without any parsing performed.
	  <dt><br><b>uri</b> <em>string, RO</em>
	    The path portion of the URI
	  <dt><br><b>filename</b> <em>string, RO</em>
	    The file name being requested.
	  <dt><b><br>path_info</b> <em>string, RO</em>
	    What follows after the file name.
	  <dt><b><br>args</b> <em>string, RO</em>
	    QUERY_ARGS, if any
      </blockquote>
      <a name="connection"><h4>Connection Object</h4></a>
      <blockquote>
	The <code>connection</code> object is a Python mapping to the Apache <code>
	  <a href="http://dev.apache.org/apidoc/apidoc_conn_rec.html">conn_rec</a>
	</code> structure.
	  <dt><br><b>server</b> <em>server object, RO</em>
	    A <code>server</code> object associate with this connection. See
	    <a href="#server">Server Object</a> below for details.
	  <dt><br><b>base_server</b> <em>server object, RO</em>
	    A <code>server</code> object for the physical vhost that this connection
	    came in through.
	  <dt><br><b>child_num</b> <em>int, RO</em>
	    The number of the child handling the request. 
	  <dt><br><b>local_addr</b> <em>tuple, RO</em>
	    The (address, port) tuple for the server.
	  <dt><br><b>remote_iddr</b> <em>tuple, RO</em>
	    The (address, port) tuple for the client.
	  <dt><br><b>remote_ip</b> <em>string, RO</em>
	    The IP of the client.
	  <dt><br><b>remote_host</b> <em>string, RO</em>
	    The DNS name of the remote client. <code>None</code> if DNS has not
	    been checked, &quot;&quot; (empty string) if no name found.
	  <dt><br><b>remote_logname</b> <em>string, RO</em>
	    Remote name if using RFC1413 (ident).
	  <dt><br><b>user</b> <em>string, RO</em>
	    If an authentication check is made, this will hold the user name. 
	    <em>NOTE:</em> You must call <code>get_basic_auth_pw()</code> before
	    using this value.
	  <dt><br><b>ap_auth_type</b> <em>string, RO</em>
	    Authentication type. (None == basic?)
	  <dt><br><b>keepalives</b> <em>int, RO</em>
	    The number of times this connection has been used. (?)
	  <dt><br><b>local_ip</b> <em>string, RO</em>
	    The IP of the server.
	  <dt><br><b>local_host</b> <em>string, RO</em>
	    The DNS name of the server.
      </blockquote>
      <a name="server"><h4>Server Object</h4></a>
      The <code>request</code> object is a Python mapping to the Apache <code>
	<a href="http://dev.apache.org/apidoc/apidoc_request_rec.html">request_rec</a>
      </code> structure. The server structure describes the server (possibly
      virtual server) serving the request.
      <h4>Functions</h4>
      <blockquote>
	  <dt><br><b>register_cleanup(request, callable function, data=None)</b>
	    Registers a cleanup. Very similar to <code>req.register_cleanup()</code>,
	    except this cleanup will be executed at child termination time. This
	    function requires one extra argument - the request object. 
      </blockquote>
      <h4>Other Members</h4>
      <blockquote>
	  <dt><b>defn_name</b> <em>string, RO</em>
	    The name of the configuration file where the server definition was found.
	  <dt><br><b>defn_line_number</b> <em>int, RO</em>
	    Line number in the config file where the server definition is found.
	  <dt><br><b>srm_confname</b> <em>string, RO</em>
	    Location of the srm config file.
	  <dt><br><b>server_admin</b> <em>string, RO</em>
	    Value of the <code>ServerAdmin</code> directive.
	  <dt><br><b>server_hostname</b> <em>string, RO</em>
	    Value of the <code>ServerName</code> directive.
	  <dt><br><b>port</b> <em>int, RO</em>
	    TCP/IP port number.
	  <dt><br><b>error_fname</b> <em>string, RO</em>
	    The name of the error log file for this server, if any.
	  <dt><br><b>loglevel</b> <em>int, RO</em>
	    Logging level.
	  <dt><br><b>is_virtual</b> <em>int, RO</em>
	    1 if this is a virtual server.
	  <dt><br><b>timeout</b> <em>int, RO</em>
	    Timeout before we give up.
	  <dt><br><b>keep_alive_timeout</b> <em>int, RO</em>
	    Keep-Alive timeout.
	  <dt><br><b>keep_alive_max</b> <em>int, RO</em>
	    Maximum number of requests per Keep-Alive.
	  <dt><br><b>keep_alive</b> <em>int, RO</em>
	    1 if keep-alive is on.
	  <dt><br><b>send_buffer_size</b> <em>int, RO</em>
	    Size of the TCP send buffer.
	  <dt><br><b>path</b> <em>string, RO</em>
	    Path for <code>ServerPath</code>.
	  <dt><br><b>pathlen</b> <em>int, RO</em>
	    Path length.
	  <dt><br><b>server_uid</b> <em>int, RO</em>
	    UID under which the server is running.
	  <dt><br><b>server_gid</b> <em>int, RO</em>
	    GID under which the server is running.
      </blockquote>
      <a name="debugging"><h3>Debugging</h3></a>
      <blockquote>
	Mod_python supports the ability to execute handlers within the Python
	debugger (pdb) via the 
	<a href="#???">PythonEnablePdb</a> Apache directive. Since the 
	debugger is an interactive tool, <code>httpd</code> must be invoked with 
	the -X option. (NB: When pdb starts, you will not see the usual
	&quot;&gt;&gt;&gt;&quot; prompt. Just type in the pdb commands like you
	would if there was one.)
      </blockquote>
      <h3>Internal Callback Object</h3>
    <blockquote>
      The Apache server interfaces with the Python interpreter via a callback
      object <code>obCallBack</code>. When a subinterpreter is created, an instance of
      <code>obCallBack</code> is created in this subinterpreter. Interestingly, 
      <code>obCallBack</code> is not written in C, it is written in Python and the code
      for it is in the <code>apache</code> module. Mod_python only uses the C API to 
      import <code>apache</code> and then instantiate <code>obCallBack</code>,
      storing a reference to the instance in the interpreter dictionary described above.
      Thus, the values in the interpreter dictionary are callback object instances.
	When a request handler is invoked by Apache, mod_python uses the
	<code>obCallBack</code> reference to call its method <code>Dispatch</code>, 
	passing it the name of the handler being invoked as a string. 
	The <code>Dispatch</code> method then does the rest of the work of importing
	the user module, resolving the callable object in it and calling it passing it
	a <code>request</code> object.
    </blockquote>
<!-- Created: Tue May  9 08:24:45 EDT 2000 -->
<!-- hhmts start -->
Last modified: Wed Oct 18 11:34:43 EDT 2000
<!-- hhmts end -->
Sunbelt Computer Software

PL/B Language Development and Support

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sunbelt Computer Software

PL/B Language Development and Support

FilesExpand file tree

pythonapi.html

Latest commit

History

pythonapi.html

File metadata and controls
