`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 Application and RequestHandler classes are designed for use with the Tornado HTTPServer and cannot be used in a generic WSGI container.

classtornado.wsgi.WSGIContainer(wsgi_application:WSGIAppType, executor:Executor|None =None)[source] ¶

Makes a WSGI-compatible application runnable on Tornado’s HTTP server.

Warning

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 WSGIContainer is to support both WSGI applications and native Tornado RequestHandlers in a single process. WSGI-only applications are likely to be better off with a dedicated WSGI server such as gunicorn or uwsgi.

Wrap a WSGI application in a WSGIContainer to make it implement the Tornado HTTPServer request_callback interface. The WSGIContainer object can then be passed to classes from the tornado.routing module, tornado.web.FallbackHandler, or to HTTPServer directly.

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 HTTPServer:

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.routing module to set up routing rules between your WSGI application and, typically, a tornado.web.Application. Alternatively, tornado.web.Application can be used as the top-level router and tornado.web.FallbackHandler can embed a WSGIContainer within it.

If the executor argument is provided, the WSGI application will be executed on that executor. This must be an instance of concurrent.futures.Executor, typically a ThreadPoolExecutor (ProcessPoolExecutor is not supported). If no executor is 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.

Warning

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 ThreadPoolExecutor when constructing the WSGIContainer, after verifying that your application is thread-safe. The default will change to use a ThreadPoolExecutor in Tornado 7.0.

Added in version 6.3: The executor parameter.

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] ¶: Converts a tornado.httputil.HTTPServerRequest to a WSGI environment.

Changed in version 6.3: No longer a static method.

tornado.wsgi — Interoperability with other Python frameworks and servers¶

`tornado.wsgi` — Interoperability with other Python frameworks and servers¶