tornado.wsgi — Interoperability with other Python frameworks and servers¶
WSGI support for the Tornado web framework.
WSGI is the Python standard for web servers, and allows for interoperability between Tornado and other Python web frameworks and servers.
This module provides WSGI support via the
WSGIContainer class, which
makes it possible to run applications using other WSGI frameworks on
the Tornado HTTP server. The reverse is not supported; the Tornado
RequestHandler classes are designed for use with
HTTPServer and cannot be used in a generic WSGI
- class tornado.wsgi.WSGIContainer(wsgi_application: WSGIAppType, executor: Optional[Executor] = None)[source]¶
Makes a WSGI-compatible application runnable on Tornado’s HTTP server.
WSGI is a synchronous interface, while Tornado’s concurrency model is based on single-threaded asynchronous execution. Many of Tornado’s distinguishing features are not available in WSGI mode, including efficient long-polling and websockets. The primary purpose of
WSGIContaineris to support both WSGI applications and native Tornado
RequestHandlersin a single process. WSGI-only applications are likely to be better off with a dedicated WSGI server such as
Wrap a WSGI application in a
WSGIContainerto make it implement the Tornado
WSGIContainerobject can then be passed to classes from the
tornado.web.FallbackHandler, or to
This class is intended to let other frameworks (Django, Flask, etc) run on the Tornado HTTP server and I/O loop.
Realistic usage will be more complicated, but the simplest possible example uses a hand-written WSGI application with
def simple_app(environ, start_response): status = "200 OK" response_headers = [("Content-type", "text/plain")] start_response(status, response_headers) return [b"Hello world!\n"] async def main(): container = tornado.wsgi.WSGIContainer(simple_app) http_server = tornado.httpserver.HTTPServer(container) http_server.listen(8888) await asyncio.Event().wait() asyncio.run(main())
The recommended pattern is to use the
tornado.routingmodule to set up routing rules between your WSGI application and, typically, a
tornado.web.Applicationcan be used as the top-level router and
tornado.web.FallbackHandlercan embed a
executorargument is provided, the WSGI application will be executed on that executor. This must be an instance of
concurrent.futures.Executor, typically a
ProcessPoolExecutoris not supported). If no
executoris given, the application will run on the event loop thread in Tornado 6.3; this will change to use an internal thread pool by default in Tornado 7.0.
By default, the WSGI application is executed on the event loop’s thread. This limits the server to one request at a time (per process), making it less scalable than most other WSGI servers. It is therefore highly recommended that you pass a
ThreadPoolExecutorwhen constructing the
WSGIContainer, after verifying that your application is thread-safe. The default will change to use a
ThreadPoolExecutorin Tornado 7.0.
New in version 6.3: The
Deprecated since version 6.3: The default behavior of running the WSGI application on the event loop thread is deprecated and will change in Tornado 7.0 to use a thread pool by default.
- environ(request: HTTPServerRequest) Dict[str, Any] [source]¶
tornado.httputil.HTTPServerRequestto a WSGI environment.
Changed in version 6.3: No longer a static method.