How do you run and conformance-check a WSGI application with only the standard library?

### Why a reference implementation ships in the stdlib A specification that nobody implements drifts. `wsgiref` exists so PEP 3333 has an executable definition inside CPython itself: a server that drives applications, handlers that implement the protocol's rules, and a validator that asserts them. It is not a deployment target, and the documentation says so plainly — it is a teaching, testing and conformance tool. ### The pieces **`wsgiref.simple_server`** builds on the standard-library HTTP server machinery. `make_server(host, port, app)` returns a server object; `serve_forever()` loops, and `handle_request()` serves exactly one request, which is handy in a test. It is single-threaded and processes requests strictly in order, so a slow handler blocks everything behind it; there is no request-size limit, no keep-alive tuning and no timeout policy. `demo_app` is a tiny built-in application that prints the environ, useful when you want to see what a server actually passes. **`wsgiref.validate`** is the interesting one. `validator(app)` returns an application with the same signature that asserts the contract as data flows through it. On the way in it checks that `environ` is a dict, that its keys are strings, that the mandatory CGI keys are present, and that the request-body and error streams have the methods the specification requires. On the way out it checks the status string's shape, that headers are a list of two-tuples of strings, that `start_response` was called before the first chunk, and — the one that catches the most bugs — that every item yielded by the returned iterable is `bytes`. Violations raise `AssertionError` with a message naming the rule, which is exactly what you want in CI around a hand-written application or a piece of middleware. **`wsgiref.util`** carries small helpers, of which `setup_testing_defaults(environ)` is the one worth remembering: it fills in the mandatory keys so an application can be called directly in a unit test, with no socket and no server. It also has helpers for reconstructing the request URL and for handling the file-wrapper optimisation. **`wsgiref.headers`** provides `Headers`, a case-insensitive mapping view over the list of header tuples an application is about to return — convenient for middleware that adds or replaces a header without caring how the underlying list is ordered. **`wsgiref.handlers`** holds the base classes that actually implement the server side of the protocol, including a CGI handler. You reach for these only when writing a server or embedding one. ### Where it fits in practice Most applications never import `wsgiref`, because a framework and a production server sit in between. It earns its place in two situations. First, when you write **middleware** by hand — middleware is the easiest part of the ecosystem to get subtly wrong, and wrapping the stack in the validator during tests turns a vague downstream failure into a precise assertion. Second, when you need a **zero-dependency HTTP endpoint** inside a tool or a test fixture: a handful of lines gives you a real server that speaks HTTP without adding a package. ### The caveat to say out loud Interviewers ask this to see whether a candidate knows the difference between a reference implementation and a production one. The right answer names `wsgiref`, uses it for development, tests and conformance, and states the limitation without being prompted: one request at a time, no hardening, no timeouts, so it belongs behind nothing and in front of nobody.