-------- Original Message -------- From: Stephen J. Turnbull [mailto:turnbull.stephen.fw@u.tsukuba.ac.jp] Sent: Wednesday, April 21, 2021, 18:28 UTC
In fact, most modern systems will negotiate compressed streams, so if you provide a .txt to your webserver, the client will tell the server "hey, I know how to gunzip", the server will automatically gzip, the client gunzip, and you know nothing about it except that you have text onscreen.
It's unclear what the system will do if offered a .txt.gz file. If the server is smart, it might say
Content-Type: text/plain; name=whatever.txt <-- note: no .gz Content-Transfer-Encoding: gzip
and the end result is as above. But it's not obviously a good idea for the server to second-guess the admin that way.
It's plausible that if the server just sends it as a binary, the client will say, "oh, they gzipped it on purpose, I should treat it as a file and save it", or it might say, "I know what a .txt is, and go ahead and transparently ungzip it. Clients are reliably unreliable as a class -- some users want Do What I Mean, some what Do What I Say, and different clients will cater to different users.
Bottom line: if you're sure you want your .txt files treated as plain text and displayed as conveniently as possible, ungzip them! Very likely you won't use any more bandwidth (and by the way, modern servers tend to cache that gzipped blob in case somebody asks for it again, so on-the-fly compression doesn't necessarily waste hours of CPU).
If for some reason you'd prefer that they be gzipped at both ends, that's probably more work to guarantee.
Thanks very much for this Steve. The learning from you guys never stops :-)
And "unzip" was the pick at of the day.
Best, Mark