Tor shouldn't set Content-Type: application/octet-stream when compressing results

arma complained on IRC about his browser trying to download descriptor files instead of displaying them in the browser.

I tracked this to tor replacing the Content-Type with application/octet-stream when compression is done.

At least in modern HTTP, the Content-Type should not change with compression. You can see this by using curl --compressed -v or -I on any modern web server. Example:

$ curl --compressed -I https://www.torproject.org
HTTP/1.1 200 OK
Date: Thu, 18 Oct 2018 01:48:00 GMT
Server: Apache
Content-Location: index.html.en
Vary: negotiate,Accept-Encoding
TCN: choice
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-Xss-Protection: 1
Referrer-Policy: no-referrer
Strict-Transport-Security: max-age=15768000; preload
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';
Last-Modified: Wed, 17 Oct 2018 18:48:13 GMT
ETag: "3ca6-578711cc71540-gzip"
Accept-Ranges: bytes
Content-Encoding: gzip
Cache-Control: max-age=3600
Expires: Thu, 18 Oct 2018 02:48:00 GMT
Content-Length: 4049
Content-Type: text/html
Content-Language: en

I didn't really look hard for any specs. It's probably somewhere in some RFC, but as a practical matter, 100% of web servers do this and 100% of web clients expect this.

I'm pretty sure this won't break Tor, since I searched the code for "content-type" and didn't find any results actually checking the type, only setting it.