Opened 11 years ago

Last modified 7 years ago

#947 closed enhancement (Deferred)

Compress html pages with gzip

Reported by: tortor Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version: 0.2.0.31
Severity: Keywords:
Cc: tortor, nickm, arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Here is another idea to speed up tor.
Compress html/css/javascript (basically any text/* mime types) pages at the exit node with gzip, even if the website itself does not support it.

Most browsers support gzip, even if they dont, they wont request a gzip page anyway.
But must websites do not do gzip compression so waste bandwidth.

gzip can make html code upto 8 times smaller.
It would help with tor bandwidth and gzip is very fast.

I know html is probably the lowest bandwidth consumer tor has to worry about, but when your downloading at 2kb/sec it really does makes a difference if the page is 40kb or 8kb.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (6)

comment:1 Changed 10 years ago by phobos

This would require Tor to look at the content it's transporting. We don't want to inspect the content for a number of

reasons for legal liability. Acting as an ISP affords Tor strong protections,

see https://www.torproject.org/eff/tor-dmca-response.html.en for more information.

comment:2 Changed 10 years ago by arma

There are two ways we could do this. One is for Tor to compress stuff at the exit
relay, and then uncompress it for you at the client side. Then the browser never
needs to know it's happening. We dabbled at doing that a few years ago, but it was
a mess to integrate zlib in the right places. Patches happily accepted. :)

Another place is for Polipo to automatically turn on "I would like compression if
available", and know how to decompress things. It might be easier to set up in
Polipo -- or it might not be, if it doesn't already have a zlib dependency.

comment:3 Changed 10 years ago by phobos

For the same reason ISPs don't compress your traffic, we shouldn't either. Once we can tell the mime type of the
content you're passing through Tor, we should start blocking all bad mimetypes, and heck, all bad content. Where
bad is defined by someone else. Most webservers on the live internet already support gzip of html on delivery, I don't
see this feature in Tor shrinking bandwidth consumption all that much.

comment:4 Changed 10 years ago by arma

My thought about polipo turns out to be useless. It isn't that the browser (or
proxy) aren't asking for compression. It's that most websites don't actually
volunteer it. So there isn't anything polipo can do to help here.

I'm going to close the bug; we've been pondering doing compression on streams
between the exit node and the client for a while. We wouldn't do it for html --
we'd do it for everything, in an application-data-independent way.

But we tried it a while ago and it turned into a real mess well before we actually
got it working. So, I think it will remain on the distant-future-wishlist for now.

comment:5 Changed 10 years ago by phobos

flyspray2trac: bug closed.

comment:6 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.