a space case for transparent gemtext compression
mbays at sdf.org
Sat Jun 19 14:23:06 BST 2021
* Saturday, 2021-06-19 at 11:34 +0200 - Francis Siefken <fsiefken at gmail.com>:
>TLS 1.3 has compression on board, it's a security
>risk in HTTP session hijacking and all HTTP browsers have turned it off.
>But this security risk doesn't apply to Gemini or with SMTP or IMAP. This
>would be another way to making this compressed gemtext vision work.
If I understand correctly, TLS 1.3 actually *removed* compression.
> legacy_compression_methods: Versions of TLS before 1.3 supported
> compression with the list of supported compression methods being
> sent in this field. For every TLS 1.3 ClientHello, this vector
> MUST contain exactly one byte, set to zero, which corresponds to
> the "null" compression method in prior versions of TLS. If a
> TLS 1.3 ClientHello is received with any other value in this
> field, the server MUST abort the handshake with an
> "illegal_parameter" alert. Note that TLS 1.3 servers might
> receive TLS 1.2 or prior ClientHellos which contain other
> compression methods and (if negotiating such a prior version) MUST
> follow the procedures for the appropriate prior version of TLS.
So TLS compression does not seem to be a viable option (we don't want to
downgrade to 1.2, for various reasons).
P.S. here's how one could handle gzipped gemtext in diohsc, causing it
to be presented as if it were uncompressed text/gemini:
set geminator text/gemini+gzip gzip -dc -
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 195 bytes
Desc: not available
More information about the Gemini