V.92 -- Is it worth it ?

noone <(E-Mail Removed)> wrote:
> Clifford Kite wrote:

>> It makes sense to have compressed HTML pages at the server and uncompress
>> them with the browser since it reduces Internet traffic. It's transparent
>> to the browser user so I never noticed it - and know next to nothing
>> about HTTP.

> It should be supported at both ends ... Thus, when Mozilla sends an HTTP
> request, it sent the following:

> Accept-Encoding: gzip,deflate

> The webserver then knows that it can send an HTTP response with a
> "Content-Encoding: gzip" or "Content-Encoding: deflate" HTTP header and
> therefore instead of just serving the static / dynamic HTML file, the
> webserver compresses it.

> Now I just wonder if all that extra compression takes up a lot of CPU
> cycles on the webserver vs. just simply reading the file and writing it
> to the socket. Maybe there are PCI compression cards out there that
> allows you to off-load gzip and deflate compression onto the chip on the
> card ?

Let me reply with another question instead of me having to plow through
RFC 2616.

Does the HTTP specification say that the web server MUST compress
an uncompressed HTML page when the browser indicates it can do the
decompression, or can it store both a compressed and an uncompressed one,
and simply select the appropriate one to send? If that is left as an
"implementation detail" then I would choose to store both and select
whichever was appropriate.

My answer to your question about PCI cards is that I don't know whether
such cards exist or not.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The generation of random numbers is too important to be left
to chance. */

In article <(E-Mail Removed)>, Clifford Kite wrote:
>
> Does the HTTP specification say that the web server MUST compress
> an uncompressed HTML page when the browser indicates it can do the
> decompression, or can it store both a compressed and an uncompressed one,
> and simply select the appropriate one to send? If that is left as an
> "implementation detail" then I would choose to store both and select
> whichever was appropriate.

Just because a browser says that it can handle compressed transfer encodings,
doesn't mean the web server has to use them. It shouldn't be using
compressed transfer encodings when the browser hasn't told it that it
can handle them.

With apache 2 (I don't know about 1) it is possible to serve up different
files using content negotiation depending on whether or not the browser
can accept compressed content encodings. This allows you to trade disk
space for cpu time on the server.

I tried this out for someone who wanted to do this with speakeasy who
weren't using mod_deflate.
I put the following in my .htaccess file:
Options +Multiviews
addencoding x-gzip gzip
addhandler type-map var
directoryindex index.var

Then I named the compressed versions of whatever as whatever.gzip.

For the index file used automatically I used a .var file to provide both
compressed and uncompressed versions of the directory listing:
URI: index.html
Content-Type: text/html

URI: index.html.gzip
Content-Type: text/html
Content-Encoding: x-gzip

Bruno Wolff III <(E-Mail Removed)> wrote:

> Just because a browser says that it can handle compressed transfer encodings,
> doesn't mean the web server has to use them. It shouldn't be using
> compressed transfer encodings when the browser hasn't told it that it
> can handle them.

> With apache 2 (I don't know about 1) it is possible to serve up different
> files using content negotiation depending on whether or not the browser
> can accept compressed content encodings. This allows you to trade disk
> space for cpu time on the server.

Thanks. That, along with the example Apache configuration, answers
my question.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Speak softly and carry a +6 two-handed sword. */