twisted.web.client.HTTPClient should expose the HTTP status as an integer

[nejucomo]

The twisted.web.http.Request.setResponseCode() method requires an int argument to represent the HTTP status code to send to a client.

On the other hand, the twisted.web.client.HTTPClientFactory.deferred errback fires with a Failure whose .value.status contains a string representing the HTTP status code in the response from a server. (The errback fires when this status is an error status, such as a 404.)

I assumed I could pass the contents of a Failure to a Request (server-side response) but this raised a type error. A simplified example of the code would look like this:

def errback(reason):
    assert the_reason_represents_a_404_error_response(reason)
    myRequest.setResponseCode(reason.value.status)


cfac = HTTPClientFactory('http://www.google.com/nonexistent_path_wombat')
cfac.deferred.addCallbacks(normalHandler, errback)
reactor.connectTCP(cfac.host, cfac.port, cfac)

[exarkun]

Aiming for this kind of symmetry is a great idea. For one thing, if a particular type makes sense on one side of the connection, it almost certainly makes sense on the other side. In this case, it certainly makes sense to represent the HTTP status as an integer; the server gets it right, the client gets it wrong. Fortunately, the new HTTP client gets it right and represents it as an integer.

I don't think this is something to fix in the older HTTP client though. Simply changing status to an integer is an incompatible change, so we should avoid that. We can add a new attribute and make that an integer... But that's a bit confusing and redundant, and considering all that's necessary to get the status as an integer is to use int on the existing attribute, may not be worthwhile.

If someone wants to implement this, or has another idea about how this might be improved, go for it. However, since it's so easy to "work around", and since there's a replacement for this API anyway, I don't think it's a big deal.

[glyph]

Actually, even in the new client, integer status codes are problematic;  IIS apparently has some status codes with dots in them, although that's not spec-compliant.

We should probably have some kind of specific type used for HTTP status codes.

[jknight]

I don't believe you. I think they only put those extended statuses in freetext parts of the response.