Remko Tronçon wrote:
>> Compressing a TLS layer makes no sense at all. So if I want compression
>> (and not using TLS compression itself), I would first start TLS and
>> after that zlib. In that order zlib compresses XML data, the other way
>> around it compresses encrypted data which is much less effective.
>
> That's what I said, yes :-)
Sorry, I missed that :)
>> But IMHO TLS should be mandatory which raises the question if we need
>> zlib compression at all.
>
> IMO, The current state of TLS compression is pretty obscure, at least
> in OpenSSL (where there's no documentation on this whatsoever). And
> it's not only the API incantations that are obscure, I find the
> negotiation and prerequisites of it pretty untransparant as well. As I
> said, I don't think there are many clients out there actually using
> TLS compression.
I did not know that. I only knew that TLS provides compression, not how
good it is and how many clients use it.
> Maybe it will eventually be widely adopted, and ZLib won't be used
> that much, but for now, ZLib stream compression over TLS is the only
> transparent way to get stream compression AFAICT.
In that case ignore me comment about not using zlib at all. But the fact
remains: zlib should be available _after_ the TLS feature to not
compress the TLS data stream.
Dirk
--
printk("autofs: Out of inode numbers -- what the heck did you do??\n");
2.0.38 /usr/src/linux/fs/autofs/root.c
