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:
https://stackoverflow.com/questions/28124461/how-do-i-solve-nonetype-object-is-not-callable-with-beautifulsoup-and-bottle
https://stackoverflow.com/questions/27518844/error-when-serving-html-with-wsgi
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 <rep...@bugs.python.org>
<http://bugs.python.org/issue29183>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
