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.