[RFC] Allow compressed requests

Aaron Bentley aaron.bentley at utoronto.ca
Wed Dec 6 17:50:28 GMT 2006

Hash: SHA1

John Arbash Meinel wrote:
> For implementation, either we could add a hint parameter to get() which
> we discussed in the past. But actually, I was thinking that we don't
> really need it. Instead we can use get_uncompressed() or maybe
> _get_uncompressed() which is what readv() would use, and just switch the
> default to compressing if the transport supports it.

Yes, I would use _get_uncompressed, and see if we ever needed the other.
 I should think not.

The readv fallback-to-get behaviour could also use compression.  That
would mean there would be cases where it would be cheaper to do a full
get than a proper readv.

Are we certain that HTTP range requests don't work with compression?

> The only concern I have, is that sometimes asking for a transfer
> encoding of compressed would get confused whether or not the actual
> content was compressed. I guess that was a content encoding versus
> transfer encoding, or something like that.

Well, the more HTTP features we use, the more vulnerable we are to
quirky HTTP servers.  Still, I don't see the harm in trying.  If it's a
win, we just have to test it widely.

Hmm.  Should we also have a "safe mode" for http?  http+safe would be a
dog-slow implementation that used the bare minimum of HTTP features, so
that if we encounter a server that does the wrong thing (especially
likely with end-to-end compression, I suspect), we can still interact
with it?

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the bazaar mailing list