Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

HTTPError creation raises an exception when connection is severed by the remote server during a long HTTPRequest #691

nisanharamati opened this Issue Mar 6, 2013 · 2 comments


None yet
2 participants

When the remote server is shutdown before an HTTPRequest completes, the HTTPError exception fails to instantiate due to a TypeError in the string formatting of the error message. This prevents the real exception from being rethrown and passed in to the HTTPResponse object.

A non-integer code argument is passed at the exception instance creation. This prevents HTTPClient from creating the appropriate 5xx HTTPError to pass to the client for handling, as the compiler raises its own exception at trying to format a non-integer into an integer format place holder.

Apart from fixing the offending code that tries to create the HTTPError instance with non-integer code parameter (I couldn't actually track that one down to the source), I suggest to change the format string to use non-type specific formatting as per the mini string formatting language spec. This will at least prevent the runtime from choking at Exception creation.

Suggested fix:

In httpclient.py

class HTTPError(Exception):
    def __init__(self, code, message=None, response=None):
        self.code = code
        message = message or httputil.responses.get(code, "Unknown")
        self.response = response
        Exception.__init__(self, "HTTP %d: %s" % (self.code, message))


Exception.__init__(self, "HTTP %d: %s" % (self.code, message))


Exception.__init__(self, "HTTP {}: {}" % (self.code, message))

letting Python manage the types.


bdarnell commented Apr 14, 2013

Can't you see where the non-integer value comes from in the stack trace of the TypeError? I'd rather fix that and guarantee that HTTPError.code is always an int than cover up the problem here.

I think it wasn't actually in the stack trace. I'm not sure if this is because of the way the event loop handles rethrowing exceptions or something else... I'll try to write the code to reproduce this sometime this week and see if I can find the actual error that generates the non-integer value (and post it here, either way.)

@bdarnell bdarnell added the web label Jul 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment