[RFC] Allow compressed requests
aaron.bentley at utoronto.ca
Wed Dec 6 17:50:28 GMT 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar