diff options
Diffstat (limited to 'Doc/lib/libwsgiref.tex')
| -rwxr-xr-x | Doc/lib/libwsgiref.tex | 782 |
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} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |