\chapter{Python API\label{pythonapi}}

\section{Multiple Interpreters\label{pyapi-interps}}

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 and can only be accessed through

the \citetitle[http://www.python.org/doc/current/api/api.html]{C

language API}.

Python C API provides the ability to create \dfn{subinterpreters}. A

more detailed description of a subinterpreter is given in the

documentation for the

\citetitle[http://www.python.org/doc/current/api/initialization.html]{\cfunction{Py_NewInterpreter()}}

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

interfere with one another.

At server start-up or mod_python initialization time, mod_python

initializes an interpreter called \dfn{main} interpreter. The main

interpreter contains a dictionary of subinterpreters. Initially, this

dictionary is empty. With every request, as needed, subinterpreters

are created, and references to them are stored in this dictionary. The

dictionary is keyed on a string, also known as \emph{interpreter

name}. This name can be any string. The main interpreter is named

\samp{main_interpreter}. The way all other interpreters are named can

be controlled by \code{PythonInterp*} directives. Default behaviour is

to name interpreters using the Apache virtual server name

(\code{ServerName} directive). This means that all scripts in the same

virtual server execute in the same subinterpreter, but scripts in

different virtual servers execute in different subinterpreters with

completely separate namespaces.

\citetitle[dir-other-ipd.html]{\code{PythonInterpPerDirectory}} and

\citetitle[dir-other-ipdv.html]{\code{PythonInterpPerDirective}}

directives alter the naming convention to use the absolute path of the

directory being accessed, or the directory in which the

\code{Python*Handler} was encountered, respectively.

\citetitle[dir-other-pi.html]{\code{PythonInterpreter}} can be used to

force the interpreter name to a specific string overriding any naming

conventions.

Once created, a subinterpreter will be reused for subsequent requests.

It is never destroyed and exists until the Apache process dies.

You can find out the name of the interpreter under which you're

running by peeking at \member{req.interpreter}.

Note that if any third party module is being used which has a C code

component that uses the simplified API for access to the Global

Interpreter Lock (GIL) for Python extension modules, then the interpreter

name must be forcibly set to be \samp{main_interpreter}. This is necessary

as such a module will only work correctly if run within the context of

the first Python interpreter created by the process. If not forced to

run under the \samp{main_interpreter}, a range of Python errors can arise,

each typically referring to code being run in \emph{restricted mode}.

\begin{seealso}

\seetitle[http://www.python.org/doc/current/api/api.html]

{Python C Language API}{Python C Language API}

\seetitle[http://www.python.org/peps/pep-0311.html]

{PEP 0311 - Simplified Global Interpreter Lock Acquisition for Extensions}{PEP 0311 - Simplified Global Interpreter Lock Acquisition for Extensions}

\end{seealso}

\section{Overview of a Request Handler\label{pyapi-handler}}

\indexii{request}{handler}

A \dfn{handler} 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 by the

user and written in Python. A handler written in Python is not any

different from a handler written in C, and follows these rules:

\index{req} \indexii{request}{object} A handler function will always

be passed a reference to a request object. (Throughout this manual,

the request object is often referred to by the \code{req} variable.)

Every handler can return:

\begin{itemize}

\constant{apache.OK}, meaning this phase of the request was handled by this

handler and no errors occurred.

\constant{apache.DECLINED}, meaning this handler has not handled this

phase of the request to completion and Apache needs to look for

another handler in subsequent modules.

\constant{apache.\emph{HTTP_ERROR}}, meaning an HTTP error occurred.

\var{HTTP_ERROR} can be any of the following:

\begin{verbatim}

\end{verbatim}

\end{itemize}

As an alternative to \emph{returning} an HTTP error code, handlers can

signal an error by \emph{raising} the \constant{apache.SERVER_RETURN}

exception, and providing an HTTP error code as the exception value,

e.g.

\begin{verbatim}

\end{verbatim}

Handlers can send content to the client using the \method{req.write()}

method.

Client data, such as POST requests, can be read by using the

\method{req.read()} function.

\begin{notice}

The directory of the Apache \code{Python*Handler}

directive in effect is prepended to the \code{sys.path}. If the

directive was specified in a server config file outside any

\code{<Directory>}, then the directory is unknown and not prepended.

\end{notice}

An example of a minimalistic handler might be:

\begin{verbatim}

\end{verbatim}

\section{Overview of a Filter Handler\label{pyapi-filter}}

\indexii{filter}{handler}

A \dfn{filter handler} is a function that can alter the input or the

output of the server. There are two kinds of filters - \dfn{input} and

\dfn{output} that apply to input from the client and output to the

client respectively.

At this time mod_python supports only request-level filters, meaning

that only the body of HTTP request or response can be filtered. Apache

provides support for connection-level filters, which will be supported

in the future.

A filter handler receives a \emph{filter} object as its argument. The

request object is available as well via \code{filter.req}, but all

writing and reading should be done via the filter's object read and

write methods.

Filters need to be closed when a read operation returns None

(indicating End-Of-Stream).

The return value of a filter is ignored. Filters cannot decline

processing like handlers, but the same effect can be achieved

by using the \method{filter.pass_on()} method.

Filters must first be registered using \code{PythonInputFilter} or

\code{PythonOutputFilter}, then added using the Apache

\code{Add/SetInputFilter} or \code{Add/SetOutputFilter} directives.

Here is an example of how to specify an output filter, it tells the

server that all .py files should processed by CAPITALIZE filter:

\begin{verbatim}

\end{verbatim}

And here is what the code for the \file{capitalize.py} might look

like:

\begin{verbatim}

\end{verbatim}

When writing filters, keep in mind that a filter will be called any

time anything upstream requests an IO operation, and the filter has no

control over the amount of data passed through it and no notion of

where in the request processing it is called. For example, within a

single request, a filter may be called once or five times, and there

is no way for the filter to know beforehand that the request is over

and which of calls is last or first for this request, thought

encounter of an EOS (None returned from a read operation) is a fairly

strong indication of an end of a request.

Also note that filters may end up being called recursively in

subrequests. To avoid the data being altered more than once, always

make sure you are not in a subrequest by examining the \code{req.main}

value.

For more information on filters, see

\citetitle[http://httpd.apache.org/docs-2.0/developer/filters.html]{http://httpd.apache.org/docs-2.0/developer/filters.html}.

\section{Overview of a Connection Handler\label{pyapi-conn}}

\indexii{connection}{handler}

A \dfn{connection handler} handles the connection, starting almost

immediately from the point the TCP connection to the server was

made.

Unlike HTTP handlers, connection handlers receive a \emph{connection}

object as an argument.

Connection handlers can be used to implement protocols. Here is an

example of a simple echo server:

Apache configuration:

\begin{verbatim}

\end{verbatim}

Contents of \filenq{echo.py} file:

\begin{verbatim}

\end{verbatim}

\section{\module{apache} -- Access to Apache Internals.}

\declaremodule[apache]{extension}{apache}

\modulesynopsis{Access to Apache Internals}

\moduleauthor{Gregory Trubetskoy}{[email protected]}

The Python interface to Apache internals is contained in a module

appropriately named \module{apache}, located inside the

\module{mod_python} package. This module provides some important

objects that map to Apache internal structures, as well as some useful

functions, all documented below. (The request object also provides an

interface to Apache internals, it is covered in its own section of

this manual.)

\indexii{_apache}{module} The \module{apache} module can only be

imported by a script running under mod_python. This is because it

depends on a built-in module \module{_apache} provided by

mod_python.

It is best imported like this:

\begin{verbatim}

\end{verbatim}

\module{mod_python.apache} module defines the following functions and

objects. For a more in-depth look at Apache internals, see the

\citetitle[http://httpd.apache.org/dev/]{Apache Developer page}

\subsection{Functions\label{pyapi-apmeth}}

\begin{funcdesc}{log_error}{message\optional{, level, server}}

An interface to the Apache \code{ap_log_error()}

function. \var{message} is a string with the error message,

\var{level} is one of the following flags constants:

\begin{verbatim}

\end{verbatim}

\var{server} is a reference to a \member{req.server} object. If

\var{server} 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. When \var{server} is not specified,

the setting of LogLevel does not apply, the LogLevel is dictated by

an httpd compile-time default, usually \code{warn}.

If you have a reference to a request object available, consider using

\method{req.log_error} instead, it will prepend request-specific

information such as the source IP of the request to the log entry.

\end{funcdesc}

\begin{funcdesc}{import_module}{module_name\optional{, autoreload=1, log=0, path=None}}

This function can be used to import modules taking advantage of

mod_python's internal mechanism which reloads modules automatically

if they have changed since last import.

\var{module_name} is a string containing the module name (it can

contain dots, e.g. \code{mypackage.mymodule}); \var{autoreload}

indicates whether the module should be reloaded if it has changed since

last import; when \var{log} is true, a message will be written to

the logs when a module is reloaded; \var{path} allows restricting

modules to specific paths.

Example:

\begin{verbatim}

\end{verbatim}

\end{funcdesc}

\begin{funcdesc}{allow_methods}{\optional{*args}}

A convenience function to set values in \member{req.allowed}.

\member{req.allowed} is a bitmask that is used to construct the

\samp{Allow:} header. It should be set before returning a

\code{HTTP_NOT_IMPLEMENTED} error.

Arguments can be one or more of the following:

\begin{verbatim}

\end{verbatim}

\end{funcdesc}

\begin{funcdesc}{exists_config_define}{name}

This function returns True if the Apache server was launched

with the definition with the given \var{name}. This means

that you can test whether Apache was launched with the \code{-DFOOBAR}

parameter by calling \code{apache.exists_config_define('FOOBAR')}.

\end{funcdesc}

\begin{methoddesc}[server]{register_cleanup}{handler\optional{, data}}

Registers a cleanup. Equivalent to \function{req.register_cleanup()}

or \function{req.server.register_cleanup()}, except that a server or request

object is not required.

\end{methoddesc}

\begin{funcdesc}{config_tree}{}

Returns the server-level configuration tree. This tree does not

include directives from .htaccess files. This is a \emph{copy} of

the tree, modifying it has no effect on the actual configuration.

\end{funcdesc}

\begin{funcdesc}{server_root}{}

Returns the value of ServerRoot.

\end{funcdesc}

\begin{funcdesc}{make_table}{}

This function is obsolete and is an alias to \class{table} (see below).

\end{funcdesc}

\begin{funcdesc}{mpm_query}{code}

Allows querying of the MPM for various parameters such as numbers of

processes and threads. The return value is one of three constants:

\begin{verbatim}

\end{verbatim}

The \var{code} argument must be one of the following:

\begin{verbatim}

\end{verbatim}

Example:

\begin{verbatim}

\end{verbatim}

\end{funcdesc}

\subsection{Table Object (mp_table)\obindex{table}\label{pyapi-mptable}}

\index{table}

\begin{classdesc}{table}{\optional{mapping-or-sequence}}

Returns a new empty object of type \code{mp_table}. See Section

\ref{pyapi-mptable} for description of the table object. The

\var{mapping-or-sequence} will be used to provide initial values for

the table.

The table object is a wrapper around the Apache APR table. The table

object behaves very much like a dictionary (including the Python 2.2

features such as support of the \code{in} operator, etc.), with the

following differences:

\begin{itemize}

\item

Both keys and values must be strings.

\item

Key lookups are case-insensitive.

\item

Duplicate keys are allowed (see \method{add()} below). When there is

more than one value for a key, a subscript operation returns a list.

\end{itemize}

Much of the information that Apache uses is stored in tables. For

example, \member{req.headers_in} and \member{req.headers_out}.

All the tables that mod_python provides inside the request

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 the following method:

\begin{methoddesc}[table]{add}{key, val}

\function{add()} allows for creating duplicate keys, which is useful

when multiple headers, such as \code{Set-Cookie:} are required.

\end{methoddesc}

\versionadded{3.0}

\end{classdesc}

\subsection{Request Object\index{request}\label{pyapi-mprequest}}

The request object is a Python mapping to the Apache

\code{request_rec} structure. When a handler is invoked, it is always

passed a single argument - the request object.

You can dynamically assign attributes to it as a way to communicate

between handlers.

\subsubsection{Request Methods\label{pyapi-mprequest-meth}}

\begin{methoddesc}[request]{add_common_vars}{}

Calls the Apache \cfunction{ap_add_common_vars()} function. After a

call to this method, \member{req.subprocess_env} will contain a

lot of CGI information.

\end{methoddesc}

\begin{methoddesc}[request]{add_handler}{htype, handler\optional{, dir}}

Allows dynamic handler registration. \var{htype} is a string

containing the name of any of the apache request (but not filter or

connection) handler directives,

e.g. \samp{PythonHandler}. \var{handler} is a string containing the

name of the module and the handler function. Optional \var{dir} is

a string containing the name of the directory to be added to the

pythonpath. 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. If there is a \code{PythonPath} directive in effect, then

\code{sys.path} will be set exactly according to it (no directories

added, the \var{dir} argument is ignored).

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 dynamically decide what will happen next. A typical example

might be a \code{PythonAuthenHandler} that will assign different

\code{PythonHandlers} based on the authorization level, something

like:

\begin{verbatim}

\end{verbatim}

\begin{notice}

If you pass this function an invalid handler, an exception will be

generated at the time an attempt is made to find the handler.

\end{notice}

\end{methoddesc}

\begin{methoddesc}[request]{allow_methods}{methods\optional{, reset}}

Adds methods to the \member{req.allowed_methods} list. This list

will be passed in \code{Allowed:} header if

\constant{HTTP_METHOD_NOT_ALLOWED} or \constant{HTTP_NOT_IMPLEMENTED}

is returned to the client. Note that Apache doesn't do anything to

restrict the methods, this list is only used to construct the

header. The actual method-restricting logic has to be provided in the

handler code.

\var{methods} is a sequence of strings. If \var{reset} is 1, then

the list of methods is first cleared.

\end{methoddesc}

\begin{methoddesc}[request]{document_root}{}

Returns DocumentRoot setting.

\end{methoddesc}

\begin{methoddesc}[request]{get_basic_auth_pw}{}

Returns a string containing the password when Basic authentication is

used.

\end{methoddesc}

\begin{methoddesc}[request]{get_config}{}

Returns a reference to the table object containing the mod_python

configuration in effect for this request except for

\code{Python*Handler} and \code{PythonOption} (The latter can be

obtained via \method{req.get_options()}. The table has directives as

keys, and their values, if any, as values.

\end{methoddesc}

\begin{methoddesc}[request]{get_remote_host}{\optional{type, str_is_ip}}

This method is used to determine remote client's DNS name or IP

number. 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 \var{type} argument can specify the following:

\begin{itemize}

\item

\code{apache.REMOTE_HOST} Look up the DNS name. Return None if Apache

directive \code{HostNameLookups} is \code{off} or the hostname cannot

be determined.

\item

\code{apache.REMOTE_NAME} \emph{(Default)} Return the DNS name if

possible, or the IP (as a string in dotted decimal notation)

otherwise.

\item

\code{apache.REMOTE_NOLOOKUP} 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.

\item

\code{apache.REMOTE_DOUBLE_REV} Force a double-reverse lookup. On

failure, return None.

\end{itemize}

If \var{str_is_ip} is \code{None} or unspecified, then the return

value is a string representing the DNS name or IP address.

If the optional \var{str_is_ip} argument is not \code{None}, then the

return value is an \code{(address, str_is_ip)} tuple, where \var{str_is_ip}

is non-zero if \code{address} is an IP address string.

On failure, \code{None} is returned.

\end{methoddesc}

\begin{methoddesc}[request]{get_options}{}

Returns a reference to the table object containing the options set by

the \code{PythonOption} directives.

\end{methoddesc}

\begin{methoddesc}[request]{internal_redirect}{new_uri}

Internally redirects the request to the \var{new_uri}. \var{new_uri}

must be a string.

The httpd server handles internal redirection by creating a new

request object and processing all request phases. Within an internal

redirect, \code{req.prev} will contain a reference to a request

object from which it was redirected.

\end{methoddesc}

\begin{methoddesc}[request]{is_https}{}

Returns non-zero if the connection is using SSL/TLS. Will always return

zero if the mod_ssl Apache module is not loaded.

You can use this method during any request phase, unlike looking for

the \code{HTTPS} variable in the \code{subprocess_env} member dictionary.

This makes it possible to write an authentication or access handler

that makes decisions based upon whether SSL is being used.

Note that this method will not determine the quality of the

encryption being used. For that you should call the \code{ssl_var_lookup}

method to get one of the \code{SSL_CIPHER*} variables.

\end{methoddesc}

\begin{methoddesc}{log_error}{message\optional{, level}}

An interface to the Apache \code{ap_log_rerror}

function. \var{message} is a string with the error message,

\var{level} is one of the following flags constants:

\begin{verbatim}

\end{verbatim}

If you need to write to log and do not have a reference to a request object,

use the \function{apache.log_error} function.

\end{methoddesc}

\begin{methoddesc}[request]{meets_conditions}{}

Calls the Apache \cfunction{ap_meets_conditions()} function which

returns a status code. If \var{status} is \constant{apache.OK}, generate

the content of the response normally. If not, simply return \var{status}.

Note that \member{req.headers_out} should be set prior to calling this

function. The same goes for \member{req.status} if the status differs

from \constant{apache.OK}.

Example:

\begin{verbatim}

\end{verbatim}

\end{methoddesc}

\begin{methoddesc}[request]{requires}{}

Returns a tuple of strings of arguments to \code{require} directive.

For example, with the following apache configuration:

\begin{verbatim}

\end{verbatim}

\method{requires()} would return \code{('user joe', 'valid-user')}.

\end{methoddesc}

\begin{methoddesc}[request]{read}{\optional{len}}

Reads at most \var{len} bytes directly from the client, returning a

string with the data read. If the \var{len} argument is negative or

omitted, reads all data given by the client.

This function is affected by the \code{Timeout} Apache configuration

directive. The read will be aborted and an \exception{IOError}

raised if the \code{Timeout} is reached while reading client data.

This function relies on the client providing the \code{Content-length}

header. Absence of the \code{Content-length} header will be treated as

if \code{Content-length: 0} was supplied.

Incorrect \code{Content-length} may cause the function to try to read

more data than available, which will make the function block until a

\code{Timeout} is reached.

\end{methoddesc}

\begin{methoddesc}[request]{readline}{\optional{len}}

Like \function{read()} but reads until end of line.

\begin{notice}

In accordance with the HTTP specification, most clients will

be terminating lines with \samp{\e r\e n} rather

than simply \samp{\e n}.

\end{notice}

\end{methoddesc}

\begin{methoddesc}[request]{readlines}{\optional{sizehint}}

Reads all or up to \var{sizehint} bytes of lines using

\method{readline} and returns a list of the lines read.

\end{methoddesc}

\begin{methoddesc}[request]{register_cleanup}{callable\optional{, data}}

Registers a cleanup. Argument \var{callable} can be any callable

object, the optional argument \var{data} can be any object (default is

\code{None}). At the very end of the request, just before the actual

request record is destroyed by Apache, \var{callable} will be called

with one argument, \var{data}.

It is OK to pass the request object as data, but keep in mind that

when the cleanup is executed, the request processing is already

complete, so doing things like writing to the client is completely

pointless.

If errors are encountered during cleanup processing, they should be in

error log, but otherwise will not affect request processing in any

way, which makes cleanup bugs sometimes hard to spot.

If the server is shut down before the cleanup had a chance to run,

it's possible that it will not be executed.

\end{methoddesc}

\begin{methoddesc}[request]{sendfile}{path\optional{, offset, len}}

Sends \var{len} bytes of file \var{path} directly to the client,

starting at offset \var{offset} using the server's internal

API. \var{offset} defaults to 0, and \var{len} defaults to -1 (send

the entire file).

Returns the number of bytes sent, or raises an IOError exception

on failure.

This function provides the most efficient way to send a file to the

client.

\end{methoddesc}

\begin{methoddesc}[request]{ssl_var_lookup}{var_name}

Looks up the value of the named SSL variable. This method queries

the mod_ssl Apache module directly, and may therefore be used in

early request phases (unlike using the \code{subprocess_env} member.

If the mod_ssl Apache module is not loaded or the variable is not

found then \code{None} is returned.

If you just want to know if a SSL or TLS connection is being used,

you may consider calling the \code{is_https} method instead.

It is unfortunately not possible to get a list of all available

variables with the current mod_ssl implementation, so you must know

the name of the variable you want. Some of the potentially useful

ssl variables are listed below. For a complete list of variables

and a description of their values see the mod_ssl documentation.

\begin{verbatim}

\end{verbatim}

\begin{notice}

Not all SSL variables are defined or have useful values in every

request phase. Also use caution when relying on these values for

security purposes, as SSL or TLS protocol parameters can often be

renegotiated at any time during a request.

\end{notice}

\end{methoddesc}

\begin{methoddesc}[request]{write}{string\optional{, flush=1}}

Writes \var{string} directly to the client, then flushes the buffer,

unless flush is 0.

\end{methoddesc}

\begin{methoddesc}[request]{flush}{}

Flushes the output buffer.

\end{methoddesc}

\begin{methoddesc}[request]{set_content_length}{len}

Sets the value of \member{req.clength} and the \samp{Content-Length}

header to len. Note that after the headers have been sent out (which

happens just before the first byte of the body is written,

i.e. first call to \member{req.write()}), calling the method is

meaningless.

\end{methoddesc}

\subsubsection{Request Members\label{pyapi-mprequest-mem}}

\begin{memberdesc}[request]{connection}

A \code{connection} object associated with this request. See

Connection Object below for details.

\emph{(Read-Only)}

\end{memberdesc}

\begin{memberdesc}[request]{server}

A server object associate with this request. See Server Object below

for details.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{next}

If this is an internal redirect, the request object we redirect to.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{prev}

If this is an internal redirect, the request object we redirect from.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{main}

If this is a sub-request, pointer to the main request.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{the_request}

String containing the first line of the request.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{assbackwards}

Indicates an HTTP/0.9 ``simple'' request. This means that the

response will contain no headers, only the body. Although this

exists for backwards compatibility with obsolescent browsers, some

people have figred out that setting assbackwards to 1 can be a

useful technique when including part of the response from an

internal redirect to avoid headers being sent.

\end{memberdesc}

\begin{memberdesc}[request]{proxyreq}

A proxy request: one of \constant{apache.PROXYREQ_*} values.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{header_only}

A boolean value indicating HEAD request, as opposed to GET.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{protocol}

Protocol, as given by the client, or \samp{HTTP/0.9}. Same as CGI \envvar{SERVER_PROTOCOL}.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{proto_num}

Integer. Number version of protocol; 1.1 = 1001

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{hostname}

String. Host, as set by full URI or Host: header.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{request_time}

A long integer. When request started.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{status_line}

Status line. E.g. \samp{200 OK}.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{status}

Status. One of \constant{apache.HTTP_*} values.

\end{memberdesc}

\begin{memberdesc}[request]{method}

A string containing the method - 'GET', 'HEAD', 'POST', etc.

Same as CGI \envvar{REQUEST_METHOD}.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{method_number}

Integer containing the method number.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{allowed}

Integer. A bitvector of the allowed methods. Used to construct the

Allowed: header when responding with

\constant{HTTP_METHOD_NOT_ALLOWED} or

\constant{HTTP_NOT_IMPLEMENTED}. This field is for Apache's internal

use, to set the Allowed: methods use \method{req.allow_methods()}

method, described in section \ref{pyapi-mprequest-meth}.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{allowed_xmethods}

Tuple. Allowed extension methods.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{allowed_methods}

Tuple. List of allowed methods. Used in relation with

\constant{METHOD_NOT_ALLOWED}. This member can be modified via \method{req.allow_methods()}

described in section \ref{pyapi-mprequest-meth}.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{sent_bodyct}

Integer. Byte count in stream is for body. (?)

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{bytes_sent}

Long integer. Number of bytes sent.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{mtime}

Long integer. Time the resource was last modified.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{chunked}

Boolean value indicating when sending chunked transfer-coding.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{range}

String. The \code{Range:} header.

\emph{(Read-Only})

\end{memberdesc}

\begin{memberdesc}[request]{clength}

Long integer. The ``real'' content length.