WSGI, the Web Server Gateway Interface, is the standard interface that sits between web servers and Python web applications or frameworks. It was proposed by Phillip J. Eby in PEP 333 in 2003 to solve a recurring problem in Python’s web ecosystem: applications written for one server were often incompatible with another, locking developers into a particular deployment stack. WSGI’s stated aim is “to promote web application portability across a variety of web servers” by decoupling framework selection from server choice.
The specification defines a deliberately simple two-sided contract. On the server or gateway side, the server invokes a callable application object once per HTTP request and is responsible for managing HTTP headers and transmission. On the application or framework side, the application provides a callable that accepts two positional arguments: environ, a dictionary of CGI-style environment variables describing the request, and start_response, a callable used to begin the HTTP response. PEP 3333 emphasizes that “simplicity of implementation on both the server and framework sides of the interface is absolutely critical to the utility of the WSGI interface.”
PEP 3333 is the version most implementations target today. Created on 26 September 2010, it “replaces” the original PEP 333 with changes “to improve usability under Python 3, and to incorporate several long-standing de facto amendments.” The update was careful not to break the existing ecosystem: “no changes were made that invalidate previously-compliant servers or applications under Python 2.x,” so the transition was largely a clarification of byte-versus-text handling for the Python 3 string model rather than a redesign.
Because the contract is so minimal, WSGI made possible a healthy separation of concerns in Python web development. Servers and gateways such as Gunicorn, uWSGI, and mod_wsgi implement the server side, while frameworks such as Django and Flask implement the application side, and the two interoperate freely. Middleware components can also sit in the chain, since a piece of WSGI middleware is simultaneously an application to the server above it and a server to the application below it.
WSGI’s design reflects the broader value of small, well-specified interfaces: by standardizing a single callable shape, it let a whole marketplace of independently developed servers, frameworks, and middleware compose without coordination. Its synchronous, request-per-callable model later motivated a successor, ASGI, for async and WebSocket workloads, but WSGI remains the foundational standard underpinning most production Python web deployments.