[RFC] Allow compressed requests

[John Arbash Meinel]

Aaron Bentley wrote:
> 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?

Actually, it is more that the data we are reading is already compressed.
So there isn't any benefit to asking it to be requested again. Not that
we couldn't place the request.

> 
>>> 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?
> 
> Aaron

It's worth a thought.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20061206/d6f2eb52/attachment.pgp