From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Thu, 14 May 2015 15:32:37 +0200
From: Steffen Nurpmeso <sdaoden@yandex.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-ID: <20150514133237.bKzVgyACWBpdGosFpyEqGg==@yandex.com>
References: <05640016b2f7b677b54134d515e69f0f@felloff.net>
In-Reply-To: <05640016b2f7b677b54134d515e69f0f@felloff.net>
User-Agent: s-nail v14.8.0-16-gb218d6a
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] Ports tree for Plan 9
Topicbox-Message-UUID: 52fcb8c0-ead9-11e9-9d60-3106f5b1d025

cinap_lenrek@felloff.net wrote:
 |found it. the server sends Content-Encoding header which causes hget
 |to add a decompression filter, so you get as output a tarball.
 |
 |<- Content-Type: application/x-gzip
 |<- Content-Encoding: gzip

 |

 |this is clearly silly, as the file is already compressed, \
 |and decompressing it
 |will not yield the indicated content-type: application/x-gzip, \
 |but a tarball.
 |
 |maybe the w3c is wrong, or is ignored in practice or we need to handle gz=
ip
 |specially. the problem is that some webservers compress the \

The problem is that IANA doesn't support a tar-gz MIME type, so
that mime.types(5) (tika [1]=C2=A0for Apache) will return "silly"
values, as in

  application/gzip              tgz gz emz
  application/x-bzip2           bz2 tbz2 boz
  # EXTENSION .tbz
  application/x-xz              xz tbz
  application/x-tar             tar

  [1] http://svn.apache.org/viewvc/tika/trunk/tika-core/src/main/resources/=
org/apache/tika/mime/tika-mimetypes.xml

 |data, like you request
 |a html file and it gives you gzip back, thats why hget uncompresses.

mime.types(5) (re-)evaluating expanded content seems what IANA has
in mind with its decision (it would be all too simple if it would
just work (tm)).

--steffen