bzr + cherokee

to elaborate a little bit further:

When doing a request for ranges:
  [[49218, 51215], [56564, 58178]]
We would get back a single-range response of 49218 - 51214

So:
1) I believe HTTP ranges are supposed to be inclusive. So it should include byte 51215 in the response.

2) It should either collapse the two ranges into 1 big range, or send multiple ranges back, raise an invalid range request, or switch back to a full 200 GET response. But cherokee seems to be just returning something invalid.

(To verify, I did a similar request to Apache, and it does include the start and end bytes)

I can't connect to the cherokee server, down at this time ?

What should bzr do in case of bogus servers like this ?

Adjust ranges (+1 for last byte) and issue several GET requests ?

Switch to one big range (adjusted too) ?

Download the whole file and process ranges locally ?

I smell the need for a test-server command in bzr that will allows users to "certify" their server for use with bzr.

Of course we should support as many servers as possible, but there will always be some unknowns.

1) Convince the project developers that they need to conform properly to the http spec. I believe this has already been done in the case of Cherokee.

2) We probably want to be able to degrade to single ranges. In case we get an InvalidRangeRequest, or whatever code the server should send in that case. I don't know if we want to, but we could have a flag that makes us request ranges + 1. And then we just monitor the returned bytes, if it comes back short, we set the flag, and re-issue a bigger request.

On 9/25/06, vila <email address hidden> wrote:
> I can't connect to the cherokee server, down at this time ?
>
> What should bzr do in case of bogus servers like this ?
>
> Adjust ranges (+1 for last byte) and issue several GET requests ?
>
> Switch to one big range (adjusted too) ?
>
> Download the whole file and process ranges locally ?

Fix the broken web server software :)

cheers

The problem is now solved with the latest cherokee svn release (420).

This bug can be closed.

This was a bug in cherokee, not in bzr. This might be backported to release 0.5.5.

This really was a more important bug, considering it make cherokee unusable.

I'd like to keep this bug under scrutiny as old versions of cherokee may still be in use and we need to support them as other semi-bogus servers.

It can be achieved, as John's idea, by the transport detecting this kind of error, trying single range request and then (if still failing) a whole download of the file with ranges processed locally. The transport should remember the lowest conforming level for the rest of it's life.

So I reopen the bug, even if we may consider it fixed for that particular use case/user.

If i'm wrong, we may want to open another one.

A fix is available in the associated bzr.urllib.keepalive branch.

New target 0.13