source: vendor/python/2.5/Doc/lib/libbasehttp.tex

Last change on this file was 3225, checked in by bird, 18 years ago

Python 2.5

File size: 9.0 KB
Line 
1\section{\module{BaseHTTPServer} ---
2 Basic HTTP server}
3
4\declaremodule{standard}{BaseHTTPServer}
5\modulesynopsis{Basic HTTP server (base class for
6 \class{SimpleHTTPServer} and \class{CGIHTTPServer}).}
7
8
9\indexii{WWW}{server}
10\indexii{HTTP}{protocol}
11\index{URL}
12\index{httpd}
13
14This module defines two classes for implementing HTTP servers
15(Web servers). Usually, this module isn't used directly, but is used
16as a basis for building functioning Web servers. See the
17\refmodule{SimpleHTTPServer}\refstmodindex{SimpleHTTPServer} and
18\refmodule{CGIHTTPServer}\refstmodindex{CGIHTTPServer} modules.
19
20The first class, \class{HTTPServer}, is a
21\class{SocketServer.TCPServer} subclass. It creates and listens at the
22HTTP socket, dispatching the requests to a handler. Code to create and
23run the server looks like this:
24
25\begin{verbatim}
26def run(server_class=BaseHTTPServer.HTTPServer,
27 handler_class=BaseHTTPServer.BaseHTTPRequestHandler):
28 server_address = ('', 8000)
29 httpd = server_class(server_address, handler_class)
30 httpd.serve_forever()
31\end{verbatim}
32
33\begin{classdesc}{HTTPServer}{server_address, RequestHandlerClass}
34This class builds on the \class{TCPServer} class by
35storing the server address as instance
36variables named \member{server_name} and \member{server_port}. The
37server is accessible by the handler, typically through the handler's
38\member{server} instance variable.
39\end{classdesc}
40
41\begin{classdesc}{BaseHTTPRequestHandler}{request, client_address, server}
42This class is used
43to handle the HTTP requests that arrive at the server. By itself,
44it cannot respond to any actual HTTP requests; it must be subclassed
45to handle each request method (e.g. GET or POST).
46\class{BaseHTTPRequestHandler} provides a number of class and instance
47variables, and methods for use by subclasses.
48
49The handler will parse the request and the headers, then call a
50method specific to the request type. The method name is constructed
51from the request. For example, for the request method \samp{SPAM}, the
52\method{do_SPAM()} method will be called with no arguments. All of
53the relevant information is stored in instance variables of the
54handler. Subclasses should not need to override or extend the
55\method{__init__()} method.
56\end{classdesc}
57
58
59\class{BaseHTTPRequestHandler} has the following instance variables:
60
61\begin{memberdesc}{client_address}
62Contains a tuple of the form \code{(\var{host}, \var{port})} referring
63to the client's address.
64\end{memberdesc}
65
66\begin{memberdesc}{command}
67Contains the command (request type). For example, \code{'GET'}.
68\end{memberdesc}
69
70\begin{memberdesc}{path}
71Contains the request path.
72\end{memberdesc}
73
74\begin{memberdesc}{request_version}
75Contains the version string from the request. For example,
76\code{'HTTP/1.0'}.
77\end{memberdesc}
78
79\begin{memberdesc}{headers}
80Holds an instance of the class specified by the \member{MessageClass}
81class variable. This instance parses and manages the headers in
82the HTTP request.
83\end{memberdesc}
84
85\begin{memberdesc}{rfile}
86Contains an input stream, positioned at the start of the optional
87input data.
88\end{memberdesc}
89
90\begin{memberdesc}{wfile}
91Contains the output stream for writing a response back to the client.
92Proper adherence to the HTTP protocol must be used when writing
93to this stream.
94\end{memberdesc}
95
96
97\class{BaseHTTPRequestHandler} has the following class variables:
98
99\begin{memberdesc}{server_version}
100Specifies the server software version. You may want to override
101this.
102The format is multiple whitespace-separated strings,
103where each string is of the form name[/version].
104For example, \code{'BaseHTTP/0.2'}.
105\end{memberdesc}
106
107\begin{memberdesc}{sys_version}
108Contains the Python system version, in a form usable by the
109\member{version_string} method and the \member{server_version} class
110variable. For example, \code{'Python/1.4'}.
111\end{memberdesc}
112
113\begin{memberdesc}{error_message_format}
114Specifies a format string for building an error response to the
115client. It uses parenthesized, keyed format specifiers, so the
116format operand must be a dictionary. The \var{code} key should
117be an integer, specifying the numeric HTTP error code value.
118\var{message} should be a string containing a (detailed) error
119message of what occurred, and \var{explain} should be an
120explanation of the error code number. Default \var{message}
121and \var{explain} values can found in the \var{responses}
122class variable.
123\end{memberdesc}
124
125\begin{memberdesc}{protocol_version}
126This specifies the HTTP protocol version used in responses. If set
127to \code{'HTTP/1.1'}, the server will permit HTTP persistent
128connections; however, your server \emph{must} then include an
129accurate \code{Content-Length} header (using \method{send_header()})
130in all of its responses to clients. For backwards compatibility,
131the setting defaults to \code{'HTTP/1.0'}.
132\end{memberdesc}
133
134\begin{memberdesc}{MessageClass}
135Specifies a \class{rfc822.Message}-like class to parse HTTP
136headers. Typically, this is not overridden, and it defaults to
137\class{mimetools.Message}.
138\withsubitem{(in module mimetools)}{\ttindex{Message}}
139\end{memberdesc}
140
141\begin{memberdesc}{responses}
142This variable contains a mapping of error code integers to two-element
143tuples containing a short and long message. For example,
144\code{\{\var{code}: (\var{shortmessage}, \var{longmessage})\}}. The
145\var{shortmessage} is usually used as the \var{message} key in an
146error response, and \var{longmessage} as the \var{explain} key
147(see the \member{error_message_format} class variable).
148\end{memberdesc}
149
150
151A \class{BaseHTTPRequestHandler} instance has the following methods:
152
153\begin{methoddesc}{handle}{}
154Calls \method{handle_one_request()} once (or, if persistent connections
155are enabled, multiple times) to handle incoming HTTP requests.
156You should never need to override it; instead, implement appropriate
157\method{do_*()} methods.
158\end{methoddesc}
159
160\begin{methoddesc}{handle_one_request}{}
161This method will parse and dispatch
162the request to the appropriate \method{do_*()} method. You should
163never need to override it.
164\end{methoddesc}
165
166\begin{methoddesc}{send_error}{code\optional{, message}}
167Sends and logs a complete error reply to the client. The numeric
168\var{code} specifies the HTTP error code, with \var{message} as
169optional, more specific text. A complete set of headers is sent,
170followed by text composed using the \member{error_message_format}
171class variable.
172\end{methoddesc}
173
174\begin{methoddesc}{send_response}{code\optional{, message}}
175Sends a response header and logs the accepted request. The HTTP
176response line is sent, followed by \emph{Server} and \emph{Date}
177headers. The values for these two headers are picked up from the
178\method{version_string()} and \method{date_time_string()} methods,
179respectively.
180\end{methoddesc}
181
182\begin{methoddesc}{send_header}{keyword, value}
183Writes a specific HTTP header to the output stream. \var{keyword}
184should specify the header keyword, with \var{value} specifying
185its value.
186\end{methoddesc}
187
188\begin{methoddesc}{end_headers}{}
189Sends a blank line, indicating the end of the HTTP headers in
190the response.
191\end{methoddesc}
192
193\begin{methoddesc}{log_request}{\optional{code\optional{, size}}}
194Logs an accepted (successful) request. \var{code} should specify
195the numeric HTTP code associated with the response. If a size of
196the response is available, then it should be passed as the
197\var{size} parameter.
198\end{methoddesc}
199
200\begin{methoddesc}{log_error}{...}
201Logs an error when a request cannot be fulfilled. By default,
202it passes the message to \method{log_message()}, so it takes the
203same arguments (\var{format} and additional values).
204\end{methoddesc}
205
206\begin{methoddesc}{log_message}{format, ...}
207Logs an arbitrary message to \code{sys.stderr}. This is typically
208overridden to create custom error logging mechanisms. The
209\var{format} argument is a standard printf-style format string,
210where the additional arguments to \method{log_message()} are applied
211as inputs to the formatting. The client address and current date
212and time are prefixed to every message logged.
213\end{methoddesc}
214
215\begin{methoddesc}{version_string}{}
216Returns the server software's version string. This is a combination
217of the \member{server_version} and \member{sys_version} class variables.
218\end{methoddesc}
219
220\begin{methoddesc}{date_time_string}{\optional{timestamp}}
221Returns the date and time given by \var{timestamp} (which must be in the
222format returned by \function{time.time()}), formatted for a message header.
223If \var{timestamp} is omitted, it uses the current date and time.
224
225The result looks like \code{'Sun, 06 Nov 1994 08:49:37 GMT'}.
226\versionadded[The \var{timestamp} parameter]{2.5}
227\end{methoddesc}
228
229\begin{methoddesc}{log_date_time_string}{}
230Returns the current date and time, formatted for logging.
231\end{methoddesc}
232
233\begin{methoddesc}{address_string}{}
234Returns the client address, formatted for logging. A name lookup
235is performed on the client's IP address.
236\end{methoddesc}
237
238
239\begin{seealso}
240 \seemodule{CGIHTTPServer}{Extended request handler that supports CGI
241 scripts.}
242
243 \seemodule{SimpleHTTPServer}{Basic request handler that limits response
244 to files actually under the document root.}
245\end{seealso}
Note: See TracBrowser for help on using the repository browser.