Posts on how WSGI applications and the servers which host them actually behave, as opposed to what the specification appears to say at first reading, are as follows.
Please note older posts may not reflect what I now regard as best practice, or may describe software which has since changed or been superseded.
This batch of posts deals with writing the application or middleware itself, and the obligations that come with the parts of the specification people skip over:
- Implementing WSGI application objects.
- Decorating WSGI applications.
- Obligations for calling close() on the iterable returned by a WSGI application.
- WSGI middleware and the hidden write() callable.
- Returning a string as the iterable from a WSGI application.
- Effects of yielding multiple blocks in a WSGI application response.
- WSGI issues with HTTP HEAD requests.
- WSGI and printing to standard output.
This batch of posts works through wsgi.file_wrapper, the optional server extension for serving a file efficiently, and what it takes to implement one correctly:
- Solving some of the problems with wsgi.file_wrapper.
- Content length and wsgi.file_wrapper.
- Testing a wsgi.file_wrapper implementation.
This batch of posts is about measuring what a real application is doing, from a wrapper around the application through to monitoring built into the server itself:
- Measuring response time for web requests in a WSGI application.
- Monitoring the response content from a WSGI application.
- Performance monitoring of real WSGI application traffic.
- Implementing request monitoring within the WSGI server.
And on how the servers themselves differ, and why benchmarks of them mislead: