[New-bugs-announce] [issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Jerome Leclanche report at bugs.python.org
Fri Jan 6 14:41:41 EST 2017

New submission from Jerome Leclanche:

TLDR: When an error happens in the wsgiref's write() or close(), stack traces get inundated with irrelevant yet legitimate errors which make it hard to track down the real issue.

Couple of examples of this happening in practice:



How to reproduce: The file I've attached reproduces the error on python 3.4, 3.5 and 3.6. The handler returns a string instead of bytes, which fails an early assert in handlers.py: write(data).

BaseHandler.run() triggers, gets as far as finish_response(), which triggers the above AssertionError. It falls into the except: block which attempts to handle_error(). But before doing that, it triggers self.close(), which sets result/headers/status/environ to None, bytes_sent to 0 and headers_sent to False.

Now when handle_error() triggers, `self.headers_sent` is False because of that, which attempts to trigger finish_response() *again*. This triggers a write() which attempts sending the headers, which checks client_is_modern(), subscripting `self.environ` which at that point has already been set to None. New error, which is caught in run()'s except block and re-raised after closing the connection (again).

I probably skipped some steps because the traceback is truly a mess. I think this could be improved, if only so that it doesn't get so confusing anymore.

files: test_server.py
messages: 284844
nosy: jleclanche
priority: normal
severity: normal
status: open
title: Unintuitive error handling in wsgiref when a crash happens in write() or close()
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file46179/test_server.py

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list