Custom Query (24003 matches)

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.

In the most recent release of the Tor Browser Bundle, the help documentation bundled with Vidalia (accessed by selecting Help) is out of date. A search of GeoIP will confirm this, as the documentation still lists the GeoIP lookup server at geoip.vidalia-project.net, which has not been maintained since 2010.