Comment 30 for bug 198646

>>>>> Miriup writes:

    > 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:

This means the culprit is your proxy no ?

<snip/>

    > 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.

Well, wrong for the proxy ;)

This is also bad for the client and in the end for the user as it means
the connection will have to be re-established incurring latency penalty.

<snip/>

    > As the bigger chunk of the "developing world" enforces proxy
    > servers on a national level, this breakage will be widespread.

:-/

<snip/>

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

You're welcome to work on this !

I suggest you look at the bzr http client implementations which already
implement a fallback mechanism when encountering servers which doesn't
implement multiple range requests.

I'm even surprised it didn't trigger in this case.

Ideally, this should be turned into a config option that could be
activated upfront on a server basis (so you can explicitly turn it on
without waiting for the first error)

Thinking about it, the fallback turn multiple ranges into single
requests merging all ranges into the single encompassing one (which
means we transfer more data than needed). But in your case, it may be
better to issue one request by range instead, while still delivering the
same result on the callers.

I'd be happy to help you work on this so feel free to create a merge
proposal as soon as you have questions or are blocked in any way.

The bzr client implementations are under bzrlib/transport/http and the
corresponding tests in bzrlib/tests/test_http*.