Comment 28 for bug 198646

I did some more investigation. What made this transfer special weren't the ranges. It were the multiple ranges. The transfer above is complete. My bzr client has requested the byte ranges 0-41 and 448-790 from the file 131ce2d0f2883b17b081d43af081770d.pack, but got only 0-41. Obviously it expects another boundary with the range 448-790 and missing that it dies.

I did the transfer once through my proxy and once through a SSH tunnel and filtering out some headers such as 'Host' that are different due to the method I get the following difference at the failing transfer:

-----8<-----
@@ -1498,18 +1436,1967 @@
 Cache-Control: max-age=0^M
 Range: bytes=0-41,448-790^M
 ^M
-HTTP/1.1 206 Partial content^M
-Content-Type: multipart/byteranges; boundary="Q(f9?SXuX1RnXykU6w)h"^M
+HTTP/1.1 206 Partial Content^M
 Server: Apache/2.2.14 (Ubuntu)^M
 Last-Modified: Tue, 22 Dec 2009 20:57:07 GMT^M
 ETag: "154623e-477-47b5772e7aec0"^M
 Accept-Ranges: bytes^M
+Content-Length: 579^M
+Content-Type: multipart/byteranges; boundary=4a29fa408f5635eed^M
 Via: 1.1 bazaar.launchpad.net^M
-Connection: close^M
-Age: 0^M
+Connection: Keep-Alive^M
 ^M
---Q(f9?SXuX1RnXykU6w)h^M
-Content-Type: text/plain^M
-Content-Range: bytes 0-41/1143^M
+^M
+--4a29fa408f5635eed^M
+Content-type: text/plain^M
+Content-range: bytes 0-41/1143^M
+^M
+Bazaar pack format 1 (introduced in 0.18)
+^M
+--4a29fa408f5635eed^M
+Content-type: text/plain^M
+Content-range: bytes 448-790/1143^M
+^M
+B337
+
# Additional binary + lines cut out.
-----8<-----

Notice also that the proxy server actually changes "Connection: Keep-Alive" to "Connection: close", which it didn't do for the earlier transfers, so it obviously has also noticed that there's something wrong with this transfer. The former means to keep the TCP channel (which we use for the HTTP) open and the latter means to close it after this transfer. So it's very apparent the fault lies at whatever is inbetween me and launchpad.

As the bigger chunk of the "developing world" enforces proxy servers on a national level, this breakage will be widespread. Though the fault lies actually at the man in the middle, in most cases it will be next to impossible to get it fixed there. My suggested workaround-fix would be to detect the above circumstances and to reissue the request for the second range again. Maybe optionally some internal flag could be set as well that for all remaining requests ranges are not pooled.

I'd even implement this modification if the regulars here consider my suggestion useful. I definitely have a good testing ground. ;)