Slashdot Mirror

Exactly right. Something like this is the solution.

Mail attachments are usually transfered base64-encoded, thus having an overhead of about 33%. If the server decodes the attachments and lets the user download them using HTTP(S), there is only a very small, nearly constant overhead of the HTTP protocol headers, as HTTP itself is "8-bit clean". So if you download already-decoded large attachments using HTTP, you save about 25% compared to POP3. If browser and HTTP server can agree to using gzip transfer encoding (see gzip_cnc project; most browsers support it), you can save even more.

Nevertheless, I don't want my provider to mess around with my emails, especially I want the attachments within the emails, not a "click here within the next three days" link. It would make archiving emails much harder if I had to download each attachment separately.

Tux2000

One step most of these proxies is doing is compressing HTML files. HTML is highly redundant, so compression can save alot of space. However, it's silly for the proxy to do the compressing. Instead web site owners can do the compressing! Transferring pages gzip compressed is part of the standard. No special software is needed by end users. A 3:1 reduction in bytes transferred for your web pages (the HTML itself) is a reasonable minimum. The result is that you use less bandwidth and end users get a faster web site! Every mainstream browser supports this, and those browsers that don't support it will automatically get the uncompressed version. If you're using Apache, you'll want mod_gzip to automatically compress transfers. (You can fake the effect with MultiViews, but it's a hassle to maintain two copies of every HTML file.)

(Yes, I know I don't practice what I preach. I'm working on it.)

And for those of you who have broadband that you use to run an HTTP server on---have you considered using mod_gzip? It will let you serve more with less, which is a very good thing if you ever get linked to from slashdot.

What? Have you never heard of mod_gzip? Do you have any idea how http works?

You are using mod_gzip, aren't you? Depending on content, you may be able to reduce your bandwidth usage by 50%, at the expense of some CPU time.

The article mentions that this will be of particular interest for web servers.

Why? Gzip already uses minimal processor time...and many sites already use Mod_Gzip...

So, as far as I'm concerned, unless the Mod_Gzip project supports this hardware,it's not gonna float...

Most all current browsers will automatically uncompress gzipped files sent to it, allowing things such as the mod_gzip module to compress web pages and have them rendered on the browser transparently. The bandwith savings ccan be huge, with all the associated benefits (less bandwith for the server, less for the clients and less congestion on the net). Without bzip2 support built into the browser, the hardware compression isn't useful for general web traffic, as it can't be used for the pages being sent.

It'd be nice if I could convince my boss to get some of these for us, but our CPU usage is pretty low right now with the mod_gzip module installed, so it'd be an unnecessary luxury at this point for us.