Thanks for analyzing this. We'd be happy to mentor you to put in a
workaround for the problem.

Getting one range at a time may be somewhat slower so we probably don't want
to do it unless it's necessary.

I would be inclined to start by adding a config option to not send multiple
range requests, and then later see about automatically detecting the need to
use it. Just ask if you want help or a review.
On May 6, 2011 9:11 PM, "Miriup" <email address hidden> wrote:
> 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. ;)
>
> --
> You received this bug notification because you are a member of bzr-core,
> which is subscribed to Bazaar.
> https://bugs.launchpad.net/bugs/198646
>
> Title:
> Invalid http response ... Expected a boundary