I found this bug while trying to understand why a 404 Not Found error was reported as a 200 Not Found. Turns out the HTTPError's self.code is overwritten with 200 after the 404 was correctly assigned. The attached patch fixes the problem.
Logged In: YES user_id=764593 Barry -- Are you sure that the original status code wasn't 204? If so, then this patch makes more sense. Georg -- any unrecognized response status NXX should be treated as N00. Since 204 (and 298, for that matter) aren't recognized by the urllib opener, they should be treated as 200, which the patch does. Whether the patch makes it harder to treat 204 separately when it is recognized is another issue.
Logged In: YES user_id=28665 There are two problems. 1) 200-299 are all good, not just 200 2) Setting the code in addinfourl needs to use the 2xx code that came from the server I have a complex http app that broken without this fix. I'm doing partial transfers that return 206 that was being overwritten. This is clearly a bug. The only issue is does the patch fix the bug and not cause other problems? In nearly a year of running with this patch on 700 systems I've not seen a problem.
The bug (interpreting non-200 2xx codes as error) has already been fixed. I've finished and committed the other part (adding getcode() to addinfourl) in r60133.
History
Date
User
Action
Args
2022-04-11 14:56:10
admin
set
github: 41818
2008-01-20 11:43:16
georg.brandl
set
status: open -> closedresolution: acceptedmessages: +