Delete the LaTeX doc tree.

1 files changed, 0 insertions, 782 deletions

diff --git a/Doc/lib/libwsgiref.tex b/Doc/lib/libwsgiref.tex
deleted file mode 100755
index 37ded9f..0000000
--- a/Doc/lib/libwsgiref.tex
+++ /dev/null
@@ -1,782 +0,0 @@
-\section{\module{wsgiref} --- WSGI Utilities and Reference
-Implementation}
-\declaremodule{}{wsgiref}
-\moduleauthor{Phillip J. Eby}{pje@telecommunity.com}
-\sectionauthor{Phillip J. Eby}{pje@telecommunity.com}
-\modulesynopsis{WSGI Utilities and Reference Implementation}
-
-\versionadded{2.5}
-
-The Web Server Gateway Interface (WSGI) is a standard interface
-between web server software and web applications written in Python.
-Having a standard interface makes it easy to use an application
-that supports WSGI with a number of different web servers.
-
-Only authors of web servers and programming frameworks need to know
-every detail and corner case of the WSGI design.  You don't need to
-understand every detail of WSGI just to install a WSGI application or
-to write a web application using an existing framework.
-
-\module{wsgiref} is a reference implementation of the WSGI specification
-that can be used to add WSGI support to a web server or framework.  It
-provides utilities for manipulating WSGI environment variables and
-response headers, base classes for implementing WSGI servers, a demo
-HTTP server that serves WSGI applications, and a validation tool that
-checks WSGI servers and applications for conformance to the
-WSGI specification (\pep{333}).
-
-% XXX If you're just trying to write a web application...
-
-See \url{http://www.wsgi.org} for more information about WSGI,
-and links to tutorials and other resources.
-
-
-
-
-
-
-
-
-
-
-
-
-
-\subsection{\module{wsgiref.util} -- WSGI environment utilities}
-\declaremodule{}{wsgiref.util}
-
-This module provides a variety of utility functions for working with
-WSGI environments.  A WSGI environment is a dictionary containing
-HTTP request variables as described in \pep{333}.  All of the functions
-taking an \var{environ} parameter expect a WSGI-compliant dictionary to
-be supplied; please see \pep{333} for a detailed specification.
-
-\begin{funcdesc}{guess_scheme}{environ}
-Return a guess for whether \code{wsgi.url_scheme} should be ``http'' or
-``https'', by checking for a \code{HTTPS} environment variable in the
-\var{environ} dictionary.  The return value is a string.
-
-This function is useful when creating a gateway that wraps CGI or a
-CGI-like protocol such as FastCGI.  Typically, servers providing such
-protocols will include a \code{HTTPS} variable with a value of ``1''
-``yes'', or ``on'' when a request is received via SSL.  So, this
-function returns ``https'' if such a value is found, and ``http''
-otherwise.
-\end{funcdesc}
-
-\begin{funcdesc}{request_uri}{environ \optional{, include_query=1}}
-Return the full request URI, optionally including the query string,
-using the algorithm found in the ``URL Reconstruction'' section of
-\pep{333}.  If \var{include_query} is false, the query string is
-not included in the resulting URI.
-\end{funcdesc}
-
-\begin{funcdesc}{application_uri}{environ}
-Similar to \function{request_uri}, except that the \code{PATH_INFO} and
-\code{QUERY_STRING} variables are ignored.  The result is the base URI
-of the application object addressed by the request.
-\end{funcdesc}
-
-\begin{funcdesc}{shift_path_info}{environ}
-Shift a single name from \code{PATH_INFO} to \code{SCRIPT_NAME} and
-return the name.  The \var{environ} dictionary is \emph{modified}
-in-place; use a copy if you need to keep the original \code{PATH_INFO}
-or \code{SCRIPT_NAME} intact.
-
-If there are no remaining path segments in \code{PATH_INFO}, \code{None}
-is returned.
-
-Typically, this routine is used to process each portion of a request
-URI path, for example to treat the path as a series of dictionary keys.
-This routine modifies the passed-in environment to make it suitable for
-invoking another WSGI application that is located at the target URI.
-For example, if there is a WSGI application at \code{/foo}, and the
-request URI path is \code{/foo/bar/baz}, and the WSGI application at
-\code{/foo} calls \function{shift_path_info}, it will receive the string
-``bar'', and the environment will be updated to be suitable for passing
-to a WSGI application at \code{/foo/bar}.  That is, \code{SCRIPT_NAME}
-will change from \code{/foo} to \code{/foo/bar}, and \code{PATH_INFO}
-will change from \code{/bar/baz} to \code{/baz}.
-
-When \code{PATH_INFO} is just a ``/'', this routine returns an empty
-string and appends a trailing slash to \code{SCRIPT_NAME}, even though
-empty path segments are normally ignored, and \code{SCRIPT_NAME} doesn't
-normally end in a slash.  This is intentional behavior, to ensure that
-an application can tell the difference between URIs ending in \code{/x}
-from ones ending in \code{/x/} when using this routine to do object
-traversal.
-
-\end{funcdesc}
-
-\begin{funcdesc}{setup_testing_defaults}{environ}
-Update \var{environ} with trivial defaults for testing purposes.
-
-This routine adds various parameters required for WSGI, including
-\code{HTTP_HOST}, \code{SERVER_NAME}, \code{SERVER_PORT},
-\code{REQUEST_METHOD}, \code{SCRIPT_NAME}, \code{PATH_INFO}, and all of
-the \pep{333}-defined \code{wsgi.*} variables.  It only supplies default
-values, and does not replace any existing settings for these variables.
-
-This routine is intended to make it easier for unit tests of WSGI
-servers and applications to set up dummy environments.  It should NOT
-be used by actual WSGI servers or applications, since the data is fake!
-\end{funcdesc}
-
-
-
-In addition to the environment functions above, the
-\module{wsgiref.util} module also provides these miscellaneous
-utilities:
-
-\begin{funcdesc}{is_hop_by_hop}{header_name}
-Return true if 'header_name' is an HTTP/1.1 ``Hop-by-Hop'' header, as
-defined by \rfc{2616}.
-\end{funcdesc}
-
-\begin{classdesc}{FileWrapper}{filelike \optional{, blksize=8192}}
-A wrapper to convert a file-like object to an iterator.  The resulting
-objects support both \method{__getitem__} and \method{__iter__}
-iteration styles, for compatibility with Python 2.1 and Jython.
-As the object is iterated over, the optional \var{blksize} parameter
-will be repeatedly passed to the \var{filelike} object's \method{read()}
-method to obtain strings to yield.  When \method{read()} returns an
-empty string, iteration is ended and is not resumable.
-
-If \var{filelike} has a \method{close()} method, the returned object
-will also have a \method{close()} method, and it will invoke the
-\var{filelike} object's \method{close()} method when called.
-\end{classdesc}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-\subsection{\module{wsgiref.headers} -- WSGI response header tools}
-\declaremodule{}{wsgiref.headers}
-
-This module provides a single class, \class{Headers}, for convenient
-manipulation of WSGI response headers using a mapping-like interface.
-
-\begin{classdesc}{Headers}{headers}
-Create a mapping-like object wrapping \var{headers}, which must be a
-list of header name/value tuples as described in \pep{333}.  Any changes
-made to the new \class{Headers} object will directly update the
-\var{headers} list it was created with.
-
-\class{Headers} objects support typical mapping operations including
-\method{__getitem__}, \method{get}, \method{__setitem__},
-\method{setdefault}, \method{__delitem__}, \method{__contains__} and
-\method{has_key}.  For each of these methods, the key is the header name
-(treated case-insensitively), and the value is the first value
-associated with that header name.  Setting a header deletes any existing
-values for that header, then adds a new value at the end of the wrapped
-header list.  Headers' existing order is generally maintained, with new
-headers added to the end of the wrapped list.
-
-Unlike a dictionary, \class{Headers} objects do not raise an error when
-you try to get or delete a key that isn't in the wrapped header list.
-Getting a nonexistent header just returns \code{None}, and deleting
-a nonexistent header does nothing.
-
-\class{Headers} objects also support \method{keys()}, \method{values()},
-and \method{items()} methods.  The lists returned by \method{keys()}
-and \method{items()} can include the same key more than once if there
-is a multi-valued header.  The \code{len()} of a \class{Headers} object
-is the same as the length of its \method{items()}, which is the same
-as the length of the wrapped header list.  In fact, the \method{items()}
-method just returns a copy of the wrapped header list.
-
-Calling \code{str()} on a \class{Headers} object returns a formatted
-string suitable for transmission as HTTP response headers.  Each header
-is placed on a line with its value, separated by a colon and a space.
-Each line is terminated by a carriage return and line feed, and the
-string is terminated with a blank line.
-
-In addition to their mapping interface and formatting features,
-\class{Headers} objects also have the following methods for querying
-and adding multi-valued headers, and for adding headers with MIME
-parameters:
-
-\begin{methoddesc}{get_all}{name}
-Return a list of all the values for the named header.
-
-The returned list will be sorted in the order they appeared in the
-original header list or were added to this instance, and may contain
-duplicates.  Any fields deleted and re-inserted are always appended to
-the header list.  If no fields exist with the given name, returns an
-empty list.
-\end{methoddesc}
-
-
-\begin{methoddesc}{add_header}{name, value, **_params}
-Add a (possibly multi-valued) header, with optional MIME parameters
-specified via keyword arguments.
-
-\var{name} is the header field to add.  Keyword arguments can be used to
-set MIME parameters for the header field.  Each parameter must be a
-string or \code{None}.  Underscores in parameter names are converted to
-dashes, since dashes are illegal in Python identifiers, but many MIME
-parameter names include dashes.  If the parameter value is a string, it
-is added to the header value parameters in the form \code{name="value"}.
-If it is \code{None}, only the parameter name is added.  (This is used
-for MIME parameters without a value.)  Example usage:
-
-\begin{verbatim}
-h.add_header('content-disposition', 'attachment', filename='bud.gif')
-\end{verbatim}
-
-The above will add a header that looks like this:
-
-\begin{verbatim}
-Content-Disposition: attachment; filename="bud.gif"
-\end{verbatim}
-\end{methoddesc}
-\end{classdesc}
-
-\subsection{\module{wsgiref.simple_server} -- a simple WSGI HTTP server}
-\declaremodule[wsgiref.simpleserver]{}{wsgiref.simple_server}
-
-This module implements a simple HTTP server (based on
-\module{BaseHTTPServer}) that serves WSGI applications.  Each server
-instance serves a single WSGI application on a given host and port.  If
-you want to serve multiple applications on a single host and port, you
-should create a WSGI application that parses \code{PATH_INFO} to select
-which application to invoke for each request.  (E.g., using the
-\function{shift_path_info()} function from \module{wsgiref.util}.)
-
-
-\begin{funcdesc}{make_server}{host, port, app
-\optional{, server_class=\class{WSGIServer} \optional{,
-handler_class=\class{WSGIRequestHandler}}}}
-Create a new WSGI server listening on \var{host} and \var{port},
-accepting connections for \var{app}.  The return value is an instance of
-the supplied \var{server_class}, and will process requests using the
-specified \var{handler_class}.  \var{app} must be a WSGI application
-object, as defined by \pep{333}.
-
-Example usage:
-\begin{verbatim}from wsgiref.simple_server import make_server, demo_app
-
-httpd = make_server('', 8000, demo_app)
-print "Serving HTTP on port 8000..."
-
-# Respond to requests until process is killed
-httpd.serve_forever()
-
-# Alternative: serve one request, then exit
-##httpd.handle_request()
-\end{verbatim}
-
-\end{funcdesc}
-
-
-
-
-
-
-\begin{funcdesc}{demo_app}{environ, start_response}
-This function is a small but complete WSGI application that
-returns a text page containing the message ``Hello world!''
-and a list of the key/value pairs provided in the
-\var{environ} parameter.  It's useful for verifying that a WSGI server
-(such as \module{wsgiref.simple_server}) is able to run a simple WSGI
-application correctly.
-\end{funcdesc}
-
-
-\begin{classdesc}{WSGIServer}{server_address, RequestHandlerClass}
-Create a \class{WSGIServer} instance.  \var{server_address} should be
-a \code{(host,port)} tuple, and \var{RequestHandlerClass} should be
-the subclass of \class{BaseHTTPServer.BaseHTTPRequestHandler} that will
-be used to process requests.
-
-You do not normally need to call this constructor, as the
-\function{make_server()} function can handle all the details for you.
-
-\class{WSGIServer} is a subclass
-of \class{BaseHTTPServer.HTTPServer}, so all of its methods (such as
-\method{serve_forever()} and \method{handle_request()}) are available.
-\class{WSGIServer} also provides these WSGI-specific methods:
-
-\begin{methoddesc}{set_app}{application}
-Sets the callable \var{application} as the WSGI application that will
-receive requests.
-\end{methoddesc}
-
-\begin{methoddesc}{get_app}{}
-Returns the currently-set application callable.
-\end{methoddesc}
-
-Normally, however, you do not need to use these additional methods, as
-\method{set_app()} is normally called by \function{make_server()}, and
-the \method{get_app()} exists mainly for the benefit of request handler
-instances.
-\end{classdesc}
-
-
-
-\begin{classdesc}{WSGIRequestHandler}{request, client_address, server}
-Create an HTTP handler for the given \var{request} (i.e. a socket),
-\var{client_address} (a \code{(\var{host},\var{port})} tuple), and
-\var{server} (\class{WSGIServer} instance).
-
-You do not need to create instances of this class directly; they are
-automatically created as needed by \class{WSGIServer} objects.  You
-can, however, subclass this class and supply it as a \var{handler_class}
-to the \function{make_server()} function.  Some possibly relevant
-methods for overriding in subclasses:
-
-\begin{methoddesc}{get_environ}{}
-Returns a dictionary containing the WSGI environment for a request.  The
-default implementation copies the contents of the \class{WSGIServer}
-object's \member{base_environ} dictionary attribute and then adds
-various headers derived from the HTTP request.  Each call to this method
-should return a new dictionary containing all of the relevant CGI
-environment variables as specified in \pep{333}.
-\end{methoddesc}
-
-\begin{methoddesc}{get_stderr}{}
-Return the object that should be used as the \code{wsgi.errors} stream.
-The default implementation just returns \code{sys.stderr}.
-\end{methoddesc}
-
-\begin{methoddesc}{handle}{}
-Process the HTTP request.  The default implementation creates a handler
-instance using a \module{wsgiref.handlers} class to implement the actual
-WSGI application interface.
-\end{methoddesc}
-
-\end{classdesc}
-
-
-
-
-
-
-
-
-
-\subsection{\module{wsgiref.validate} -- WSGI conformance checker}
-\declaremodule{}{wsgiref.validate}
-When creating new WSGI application objects, frameworks, servers, or
-middleware, it can be useful to validate the new code's conformance
-using \module{wsgiref.validate}.  This module provides a function that
-creates WSGI application objects that validate communications between
-a WSGI server or gateway and a WSGI application object, to check both
-sides for protocol conformance.
-
-Note that this utility does not guarantee complete \pep{333} compliance;
-an absence of errors from this module does not necessarily mean that
-errors do not exist.  However, if this module does produce an error,
-then it is virtually certain that either the server or application is
-not 100\% compliant.
-
-This module is based on the \module{paste.lint} module from Ian
-Bicking's ``Python Paste'' library.
-
-\begin{funcdesc}{validator}{application}
-Wrap \var{application} and return a new WSGI application object.  The
-returned application will forward all requests to the original
-\var{application}, and will check that both the \var{application} and
-the server invoking it are conforming to the WSGI specification and to
-RFC 2616.
-
-Any detected nonconformance results in an \exception{AssertionError}
-being raised; note, however, that how these errors are handled is
-server-dependent.  For example, \module{wsgiref.simple_server} and other
-servers based on \module{wsgiref.handlers} (that don't override the
-error handling methods to do something else) will simply output a
-message that an error has occurred, and dump the traceback to
-\code{sys.stderr} or some other error stream.
-
-This wrapper may also generate output using the \module{warnings} module
-to indicate behaviors that are questionable but which may not actually
-be prohibited by \pep{333}.  Unless they are suppressed using Python
-command-line options or the \module{warnings} API, any such warnings
-will be written to \code{sys.stderr} (\emph{not} \code{wsgi.errors},
-unless they happen to be the same object).
-\end{funcdesc}
-
-\subsection{\module{wsgiref.handlers} -- server/gateway base classes}
-\declaremodule{}{wsgiref.handlers}
-
-This module provides base handler classes for implementing WSGI servers
-and gateways.  These base classes handle most of the work of
-communicating with a WSGI application, as long as they are given a
-CGI-like environment, along with input, output, and error streams.
-
-
-\begin{classdesc}{CGIHandler}{}
-CGI-based invocation via \code{sys.stdin}, \code{sys.stdout},
-\code{sys.stderr} and \code{os.environ}.  This is useful when you have
-a WSGI application and want to run it as a CGI script.  Simply invoke
-\code{CGIHandler().run(app)}, where \code{app} is the WSGI application
-object you wish to invoke.
-
-This class is a subclass of \class{BaseCGIHandler} that sets
-\code{wsgi.run_once} to true, \code{wsgi.multithread} to false, and
-\code{wsgi.multiprocess} to true, and always uses \module{sys} and
-\module{os} to obtain the necessary CGI streams and environment.
-\end{classdesc}
-
-
-\begin{classdesc}{BaseCGIHandler}{stdin, stdout, stderr, environ
-\optional{, multithread=True \optional{, multiprocess=False}}}
-
-Similar to \class{CGIHandler}, but instead of using the \module{sys} and
-\module{os} modules, the CGI environment and I/O streams are specified
-explicitly.  The \var{multithread} and \var{multiprocess} values are
-used to set the \code{wsgi.multithread} and \code{wsgi.multiprocess}
-flags for any applications run by the handler instance.
-
-This class is a subclass of \class{SimpleHandler} intended for use with
-software other than HTTP ``origin servers''.  If you are writing a
-gateway protocol implementation (such as CGI, FastCGI, SCGI, etc.) that
-uses a \code{Status:} header to send an HTTP status, you probably want
-to subclass this instead of \class{SimpleHandler}.
-\end{classdesc}
-
-
-
-\begin{classdesc}{SimpleHandler}{stdin, stdout, stderr, environ
-\optional{,multithread=True \optional{, multiprocess=False}}}
-
-Similar to \class{BaseCGIHandler}, but designed for use with HTTP origin
-servers.  If you are writing an HTTP server implementation, you will
-probably want to subclass this instead of \class{BaseCGIHandler}
-
-This class is a subclass of \class{BaseHandler}.  It overrides the
-\method{__init__()}, \method{get_stdin()}, \method{get_stderr()},
-\method{add_cgi_vars()}, \method{_write()}, and \method{_flush()}
-methods to support explicitly setting the environment and streams via
-the constructor.  The supplied environment and streams are stored in
-the \member{stdin}, \member{stdout}, \member{stderr}, and
-\member{environ} attributes.
-\end{classdesc}
-
-\begin{classdesc}{BaseHandler}{}
-This is an abstract base class for running WSGI applications.  Each
-instance will handle a single HTTP request, although in principle you
-could create a subclass that was reusable for multiple requests.
-
-\class{BaseHandler} instances have only one method intended for external
-use:
-
-\begin{methoddesc}{run}{app}
-Run the specified WSGI application, \var{app}.
-\end{methoddesc}
-
-All of the other \class{BaseHandler} methods are invoked by this method
-in the process of running the application, and thus exist primarily to
-allow customizing the process.
-
-The following methods MUST be overridden in a subclass:
-
-\begin{methoddesc}{_write}{data}
-Buffer the string \var{data} for transmission to the client.  It's okay
-if this method actually transmits the data; \class{BaseHandler}
-just separates write and flush operations for greater efficiency
-when the underlying system actually has such a distinction.
-\end{methoddesc}
-
-\begin{methoddesc}{_flush}{}
-Force buffered data to be transmitted to the client.  It's okay if this
-method is a no-op (i.e., if \method{_write()} actually sends the data).
-\end{methoddesc}
-
-\begin{methoddesc}{get_stdin}{}
-Return an input stream object suitable for use as the \code{wsgi.input}
-of the request currently being processed.
-\end{methoddesc}
-
-\begin{methoddesc}{get_stderr}{}
-Return an output stream object suitable for use as the
-\code{wsgi.errors} of the request currently being processed.
-\end{methoddesc}
-
-\begin{methoddesc}{add_cgi_vars}{}
-Insert CGI variables for the current request into the \member{environ}
-attribute.
-\end{methoddesc}
-
-Here are some other methods and attributes you may wish to override.
-This list is only a summary, however, and does not include every method
-that can be overridden.  You should consult the docstrings and source
-code for additional information before attempting to create a customized
-\class{BaseHandler} subclass.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Attributes and methods for customizing the WSGI environment:
-
-\begin{memberdesc}{wsgi_multithread}
-The value to be used for the \code{wsgi.multithread} environment
-variable.  It defaults to true in \class{BaseHandler}, but may have
-a different default (or be set by the constructor) in the other
-subclasses.
-\end{memberdesc}
-
-\begin{memberdesc}{wsgi_multiprocess}
-The value to be used for the \code{wsgi.multiprocess} environment
-variable.  It defaults to true in \class{BaseHandler}, but may have
-a different default (or be set by the constructor) in the other
-subclasses.
-\end{memberdesc}
-
-\begin{memberdesc}{wsgi_run_once}
-The value to be used for the \code{wsgi.run_once} environment
-variable.  It defaults to false in \class{BaseHandler}, but
-\class{CGIHandler} sets it to true by default.
-\end{memberdesc}
-
-\begin{memberdesc}{os_environ}
-The default environment variables to be included in every request's
-WSGI environment.  By default, this is a copy of \code{os.environ} at
-the time that \module{wsgiref.handlers} was imported, but subclasses can
-either create their own at the class or instance level.  Note that the
-dictionary should be considered read-only, since the default value is
-shared between multiple classes and instances.
-\end{memberdesc}
-
-\begin{memberdesc}{server_software}
-If the \member{origin_server} attribute is set, this attribute's value
-is used to set the default \code{SERVER_SOFTWARE} WSGI environment
-variable, and also to set a default \code{Server:} header in HTTP
-responses.  It is ignored for handlers (such as \class{BaseCGIHandler}
-and \class{CGIHandler}) that are not HTTP origin servers.
-\end{memberdesc}
-
-
-
-\begin{methoddesc}{get_scheme}{}
-Return the URL scheme being used for the current request.  The default
-implementation uses the \function{guess_scheme()} function from
-\module{wsgiref.util} to guess whether the scheme should be ``http'' or
-``https'', based on the current request's \member{environ} variables.
-\end{methoddesc}
-
-\begin{methoddesc}{setup_environ}{}
-Set the \member{environ} attribute to a fully-populated WSGI
-environment.  The default implementation uses all of the above methods
-and attributes, plus the \method{get_stdin()}, \method{get_stderr()},
-and \method{add_cgi_vars()} methods and the \member{wsgi_file_wrapper}
-attribute.  It also inserts a \code{SERVER_SOFTWARE} key if not present,
-as long as the \member{origin_server} attribute is a true value and the
-\member{server_software} attribute is set.
-\end{methoddesc}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Methods and attributes for customizing exception handling:
-
-\begin{methoddesc}{log_exception}{exc_info}
-Log the \var{exc_info} tuple in the server log.  \var{exc_info} is a
-\code{(\var{type}, \var{value}, \var{traceback})} tuple.  The default
-implementation simply writes the traceback to the request's
-\code{wsgi.errors} stream and flushes it.  Subclasses can override this
-method to change the format or retarget the output, mail the traceback
-to an administrator, or whatever other action may be deemed suitable.
-\end{methoddesc}
-
-\begin{memberdesc}{traceback_limit}
-The maximum number of frames to include in tracebacks output by the
-default \method{log_exception()} method.  If \code{None}, all frames
-are included.
-\end{memberdesc}
-
-\begin{methoddesc}{error_output}{environ, start_response}
-This method is a WSGI application to generate an error page for the
-user.  It is only invoked if an error occurs before headers are sent
-to the client.
-
-This method can access the current error information using
-\code{sys.exc_info()}, and should pass that information to
-\var{start_response} when calling it (as described in the ``Error
-Handling'' section of \pep{333}).
-
-The default implementation just uses the \member{error_status},
-\member{error_headers}, and \member{error_body} attributes to generate
-an output page.  Subclasses can override this to produce more dynamic
-error output.
-
-Note, however, that it's not recommended from a security perspective to
-spit out diagnostics to any old user; ideally, you should have to do
-something special to enable diagnostic output, which is why the default
-implementation doesn't include any.
-\end{methoddesc}
-
-
-
-
-\begin{memberdesc}{error_status}
-The HTTP status used for error responses.  This should be a status
-string as defined in \pep{333}; it defaults to a 500 code and message.
-\end{memberdesc}
-
-\begin{memberdesc}{error_headers}
-The HTTP headers used for error responses.  This should be a list of
-WSGI response headers (\code{(\var{name}, \var{value})} tuples), as
-described in \pep{333}.  The default list just sets the content type
-to \code{text/plain}.
-\end{memberdesc}
-
-\begin{memberdesc}{error_body}
-The error response body.  This should be an HTTP response body string.
-It defaults to the plain text, ``A server error occurred.  Please
-contact the administrator.''
-\end{memberdesc}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Methods and attributes for \pep{333}'s ``Optional Platform-Specific File
-Handling'' feature:
-
-\begin{memberdesc}{wsgi_file_wrapper}
-A \code{wsgi.file_wrapper} factory, or \code{None}.  The default value
-of this attribute is the \class{FileWrapper} class from
-\module{wsgiref.util}.
-\end{memberdesc}
-
-\begin{methoddesc}{sendfile}{}
-Override to implement platform-specific file transmission.  This method
-is called only if the application's return value is an instance of
-the class specified by the \member{wsgi_file_wrapper} attribute.  It
-should return a true value if it was able to successfully transmit the
-file, so that the default transmission code will not be executed.
-The default implementation of this method just returns a false value.
-\end{methoddesc}
-
-
-Miscellaneous methods and attributes:
-
-\begin{memberdesc}{origin_server}
-This attribute should be set to a true value if the handler's
-\method{_write()} and \method{_flush()} are being used to communicate
-directly to the client, rather than via a CGI-like gateway protocol that
-wants the HTTP status in a special \code{Status:} header.
-
-This attribute's default value is true in \class{BaseHandler}, but
-false in \class{BaseCGIHandler} and \class{CGIHandler}.
-\end{memberdesc}
-
-\begin{memberdesc}{http_version}
-If \member{origin_server} is true, this string attribute is used to
-set the HTTP version of the response set to the client.  It defaults to
-\code{"1.0"}.
-\end{memberdesc}
-
-
-
-
-
-\end{classdesc}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-