What's the status on this fix? Currently, an IPv6-only client using an IPv6-only DNS resolver will fail to reach wikimedia services. If their DNS resolver is capable of using a NAT64 translator, that might be a reasonable workaround (as suggested by https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/), but a workaround shouldn't be necessary for foundational websites like wikipedia.

hm, it might be nice to have access to that space in /srv, but i don't think it's necessary right now. it looks like some extra space was already freed up earlier, and i've freed up more just now, so we're at 14G free on /dev/md0. I think we can close this ticket.

In the IETF's TLS working group, we're aiming to add a padding mechanism at the TLS layer, so that should give you a place to do the padding that won't be interfered with by gzip (or whatever other HTTP weirdness pops up) at the application layer.