Sat, 08 Sep 2018 21:58:51 +0800 httppeer: use util.readexactly() to abort on incomplete responses
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Sep 2018 21:58:51 +0800] rev 39501
httppeer: use util.readexactly() to abort on incomplete responses Plain resp.read(n) may not return exactly n bytes when we need, and to detect such cases before trying to interpret whatever has been read, we can use util.readexactly(), which raises an Abort when stream ends unexpectedly. In the first case here, readexactly() prevents a traceback with struct.error, in the second it avoids looking for invalid compression engines. In this test case, _wraphttpresponse doesn't catch the problem (presumably because it doesn't know transfer encoding), and the code continues reading the response until it gets to compression engine data. Maybe there should be checks before the execution gets there, but I'm not sure where (httplib?)
Sat, 08 Sep 2018 23:57:07 +0800 httppeer: calculate total expected bytes correctly
Anton Shestakov <av6@dwimlabs.net> [Sat, 08 Sep 2018 23:57:07 +0800] rev 39500
httppeer: calculate total expected bytes correctly User-facing error messages that handled httplib.IncompleteRead errors in Mercurial used to look like this: abort: HTTP request error (incomplete response; expected 3 bytes got 1) But the errors that are being handled underneath the UI look like this: IncompleteRead(1 bytes read, 3 more expected) I.e. the error actually counts total number of expected bytes minus bytes already received. Before, users could see weird messages like "expected 10 bytes got 10", while in reality httplib expected 10 _more_ bytes (20 in total).
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -2 +2 +10 +30 +100 +300 +1000 +3000 +10000 tip