tornado.httpserver — Non-blocking HTTP server

A non-blocking, single-threaded HTTP server.

Typical applications have little direct interaction with the HTTPServer class except to start a server at the beginning of the process (and even that is often done indirectly via tornado.web.Application.listen).

This module also defines the HTTPRequest class which is exposed via tornado.web.RequestHandler.request.

HTTPRequest objects

class tornado.httpserver.HTTPRequest(method, uri, version='HTTP/1.0', headers=None, body=None, remote_ip=None, protocol=None, host=None, files=None, connection=None)[source]

A single HTTP request.

All attributes are type str unless otherwise noted.


HTTP request method, e.g. “GET” or “POST”


The requested uri.


The path portion of uri


The query portion of uri


HTTP version specified in request, e.g. “HTTP/1.1”


HTTPHeader dictionary-like object for request headers. Acts like a case-insensitive dictionary with additional methods for repeated headers.


Request body, if present, as a byte string.


Client’s IP address as a string. If HTTPServer.xheaders is set, will pass along the real IP address provided by a load balancer in the X-Real-Ip header


The protocol used, either “http” or “https”. If HTTPServer.xheaders is seet, will pass along the protocol used by a load balancer if reported via an X-Scheme header.


The requested hostname, usually taken from the Host header.


GET/POST arguments are available in the arguments property, which maps arguments names to lists of values (to support multiple values for individual names). Names are of type str, while arguments are byte strings. Note that this is different from RequestHandler.get_argument, which returns argument values as unicode strings.


File uploads are available in the files property, which maps file names to list of files. Each file is a dictionary of the form {“filename”:..., “content_type”:..., “body”:...}. The content_type comes from the provided HTTP header and should not be trusted outright given that it can be easily forged.


An HTTP request is attached to a single HTTP connection, which can be accessed through the “connection” attribute. Since connections are typically kept open in HTTP/1.1, multiple requests can be handled sequentially on a single connection.


Returns True if this request supports HTTP/1.1 semantics


Writes the given chunk to the response stream.


Finishes this HTTP request on the open connection.


Reconstructs the full URL for this request.


Returns the amount of time it took for this request to execute.


Returns the client’s SSL certificate, if any.

To use client certificates, the HTTPServer must have been constructed with cert_reqs set in ssl_options, e.g.:

server = HTTPServer(app,

The return value is a dictionary, see SSLSocket.getpeercert() in the standard library for more details.

HTTP Server

class tornado.httpserver.HTTPServer(request_callback, no_keep_alive=False, io_loop=None, xheaders=False, ssl_options=None)[source]

A non-blocking, single-threaded HTTP server.

A server is defined by a request callback that takes an HTTPRequest instance as an argument and writes a valid HTTP response with request.write(). request.finish() finishes the request (but does not necessarily close the connection in the case of HTTP/1.1 keep-alive requests). A simple example server that echoes back the URI you requested:

import httpserver
import ioloop

def handle_request(request):
   message = "You requested %s\n" % request.uri
   request.write("HTTP/1.1 200 OK\r\nContent-Length: %d\r\n\r\n%s" % (
                 len(message), message))

http_server = httpserver.HTTPServer(handle_request)

HTTPServer is a very basic connection handler. Beyond parsing the HTTP request body and headers, the only HTTP semantics implemented in HTTPServer is HTTP/1.1 keep-alive connections. We do not, however, implement chunked encoding, so the request callback must provide a Content-Length header or implement chunked encoding for HTTP/1.1 requests for the server to run correctly for HTTP/1.1 clients. If the request handler is unable to do this, you can provide the no_keep_alive argument to the HTTPServer constructor, which will ensure the connection is closed on every request no matter what HTTP version the client is using.

If xheaders is True, we support the X-Real-Ip and X-Scheme headers, which override the remote IP and HTTP scheme for all requests. These headers are useful when running Tornado behind a reverse proxy or load balancer.

HTTPServer can serve HTTPS (SSL) traffic with Python 2.6+ and OpenSSL. To make this server serve SSL traffic, send the ssl_options dictionary argument with the arguments required for the ssl.wrap_socket() method, including “certfile” and “keyfile”:

HTTPServer(applicaton, ssl_options={
    "certfile": os.path.join(data_dir, "mydomain.crt"),
    "keyfile": os.path.join(data_dir, "mydomain.key"),

By default, listen() runs in a single thread in a single process. You can utilize all available CPUs on this machine by calling bind() and start() instead of listen():

http_server = httpserver.HTTPServer(handle_request)
http_server.start(0) # Forks multiple sub-processes

start(0) detects the number of CPUs on this machine and “pre-forks” that number of child processes so that we have one Tornado process per CPU, all with their own IOLoop. You can also pass in the specific number of child processes you want to run with if you want to override this auto-detection.

Initializes the server with the given request callback.

If you use pre-forking/start() instead of the listen() method to start your server, you should not pass an IOLoop instance to this constructor. Each pre-forked child process will create its own IOLoop instance after the forking process.

listen(port, address='')[source]

Binds to the given port and starts the server in a single process.

This method is a shortcut for:

server.bind(port, address) server.start(1)
bind(port, address=None, family=0)[source]

Binds this server to the given port on the given address.

To start the server, call start(). If you want to run this server in a single process, you can call listen() as a shortcut to the sequence of bind() and start() calls.

Address may be either an IP address or hostname. If it’s a hostname, the server will listen on all IP addresses associated with the name. Address may be an empty string or None to listen on all available interfaces. Family may be set to either socket.AF_INET or socket.AF_INET6 to restrict to ipv4 or ipv6 addresses, otherwise both will be used if available.

This method may be called multiple times prior to start() to listen on multiple ports or interfaces.


Starts this server in the IOLoop.

By default, we run the server in this process and do not fork any additional child process.

If num_processes is None or <= 0, we detect the number of cores available on this machine and fork that number of child processes. If num_processes is given and > 1, we fork that specific number of sub-processes.

Since we use processes and not threads, there is no shared memory between any server code.

Note that multiple processes are not compatible with the autoreload module (or the debug=True option to tornado.web.Application). When using multiple processes, no IOLoops can be created or referenced until after the call to HTTPServer.start(n).


Stops listening for new connections.

Requests currently in progress may still continue after the server is stopped.

class tornado.httpserver.HTTPConnection(stream, address, request_callback, no_keep_alive=False, xheaders=False)[source]

Handles a connection to an HTTP client, executing HTTP requests.

We parse HTTP headers and bodies, and execute the request callback until the HTTP conection is closed.


Writes a chunk of output to the stream.


Finishes the request.

Table Of Contents

Previous topic

tornado.webRequestHandler and Application classes

Next topic

tornado.template — Flexible output generation

This Page