[UGLY HACK] Proof of concept multipart/byteranges support and connection sharing

Michael Ellerman michael at ellerman.id.au
Tue May 23 14:20:03 BST 2006


On 5/22/06, Robert Collins <robertc at robertcollins.net> wrote:
> On Mon, 2006-05-22 at 11:15 +1000, Michael Ellerman wrote:
> > On Sat, 2006-05-20 at 20:57 +1000, Robert Collins wrote:
>
>
> > Yeah, the Curl() stuff is purely to do connection sharing. I don't know
> > how the transport code works, but from a quick glance, if we create a
> > new HttpClient() for each get_transport(..) isn't that equivalent to
> > having one Curl() per PyCurlTransport() ? If so, that doesn't get us as
> > big a win, because we create lots of transports.
>
> not at all - we typically use 'clone()' to 'chdir' around on a server.
> get_transport is only called when we go from URL to Transport.

Ah ok. The catch being that HttpTransportBase(), and in fact it seems
all the transports, implement clone() by creating a new object. So to
share the connection meaningfully will require a bit more work, or a
global shared connecton like sftp. But you don't like that idea, and I
admit it irks me a little too.

> > Yeah, there's lots of corner cases. I think I already handle the full
> > result case, as long as we get code 200 back, not 206. Reordering would
> > break that code in a jiffie. Before writing a proper version I'd like to
> > check what twisted do, and/or any other implementations.
>
> I have only seen one complete client implementation of ranges in source,
> and thats in squid. My advice - go with the rfc :).

Mmm, shite. I had a look at twisted, it has "TODO implement HTTP/1.1"
which was a little discouraging. It doesn't even do ranges properly in
the server it seems, so it's not the silver bullet I thought it might
be. Back to the RFC ...

cheers




More information about the bazaar mailing list