Author martin.panter
Recipients chris.jerdonek, jleclanche, martin.panter
Date 2018-11-14.08:03:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1542182596.72.0.788709270274.issue29183@psf.upfronthosting.co.za>
In-reply-to
Content
There are actually two “close” methods in the WSGI package: ServerHandler’s implementation extends the BaseHandler implementation. Making the “close” methods do nothing if called a second time would avoid the error about “self.status” being None, but won’t help very much with other problems, such as:

* If no response has been sent when the exception happens, the first call to “ServerHandler.close” still won’t have a HTTP status code or response size to log. It is more useful in this case to log the 500 code in the second “close” call after the error page is generated, which is what happens in 2.6.

* If the response was started when the exception happens, the first call to “BaseHandler.close” will still reset “self.headers_sent”, which fools “handle_error” into trying to generate a 500 response despite already having started the application response.

To be clear, what I had in mind last week was to adjust “finish_response” to look something like:

class BaseHandler:
    ...
    def finish_response(self):
        try:
            ...
        except:
            # Limited version of “close” method on exception
            if hasattr(self.result, 'close'):
                self.result.close()
            raise
        self.close()  # Full “close” method when no exception

For the record: This is related to Issue 27682, specifically about handling ConnectionAbortedError and other network errors.
History
Date User Action Args
2018-11-14 08:03:16martin.pantersetrecipients: + martin.panter, chris.jerdonek, jleclanche
2018-11-14 08:03:16martin.pantersetmessageid: <1542182596.72.0.788709270274.issue29183@psf.upfronthosting.co.za>
2018-11-14 08:03:16martin.panterlinkissue29183 messages
2018-11-14 08:03:16martin.pantercreate