httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Malo>
Subject Re: [Review] mod_deflate.xml (Revision)
Date Wed, 20 Nov 2002 06:04:11 GMT
* wrote:

>>  put the whole revision online again at
>> <>

at first: Joshua revised the document already some time ago, so some of 
your comments are outdated, see online version for the current variant.

(According to this fact, I'm skipping some of your comments, feel free to 
repeat them)

>> Some popular browsers cannot handle compression of all content
> you might want to claim safe some browser here, like there are
> browser lists in the mod_auth_digest documentation:

don't know, whether it makes much sense. Most browsers that handle 
requested compressed content correctly. There are only few exceptions,...

> Or you could explicitly blame Netscape 4 for doing what it does,

..mainly Netscape 4. And we *do* blame it (see example).

>> If you want to restrict the compression to particular MIME types in
> general,
>> you may use the AddOutputFilterByType directive.
> You might add a note about this being a valid alternative to
> excluding Netscape 4.


> (before I decided to let all those
> CSS and JS files rather be included server-sided, as my pages
> are mostly dynamic anyway and this did even save lots of HTTP
> headers, which aren't compressed after all).

btw: you know <>? ;-)

> And did you ever try to send compressed PDF to a MSIE5 Acrobat
> plugin? Now this depends ... ;-(

ehm, no. I don't use the MSIE for normal browsing ;-)
What happens?
However, it's easy to exclude pdf files... should we include that in the 
example? Other opinions?

>> Now if a request contains a Content-Encoding: gzip  header
> I am rather indecisive about some appropriate location but I
> think about somewhere telling the reader how and why this ac-
> tually does happen, especially for the IE.

Just a note, the quote is from the section about *input* 

> Surely, this is none of Apache's core business, but one might
> be disappointed not to serve compressed content to a lot of
> browsers just because these Internet Explorers ship with a
> default setting that will decline them to send the proper HTTP
> header when effectively using a proxy server, which can be as-
> sumed to be the case for most installations on office systems.

hmm, what can a server admin actually do?

(possible variant:
  BrowserMatch \bMSIE MSIE
  SetEnvIf http_version HTTP/1.0 waah
  <!--#if expr="$MSIE && $waah" -->
    Enable HTTP/1.1 for compression
  <!--#endif -->

No, I think, mod_deflate.xml is not a good place for that.
If someone writes a compression howto, that would be appropriate.
Hmm... seriously: Are you interested in writing such a document?

> Or maybe just a note how to check whether this header actually
> arrived from the browser ... I remember the log definitions
> provide for HTTP request headers being accessible like
> "%{Accept-Encoding}i", at least this worked for Apache 1.3. ;-)

That's documented in mod_log_config.xml.

> compiliant -> compliant.
>     ^^
> (There is a second occurrence of this, somewhere later in the file.)

oops ;-) I should use a dictionary more often...
However, Joshua corrected that already.

> Actually, using the UserAgent as a negotiation parameter is a
> thing that I discourage doing (in the mod_gzip docs) because of
> this effect. You are faced with the trade-off whom to let suffer:
> Either serve the Netscape 4 users broken content or serve every-
> one correct but slow content.

+1 for slow ;-)
We cannot recommed to serve broken content. (resp. *I* cannot...)

> One should be aware of this situ-
> ation when using "UserAgent" as a negotiation dimension - there
> will be one day when the Netscape 4 users will be only a marginal
> minority (now that Netscape 7 is finally available even for office
> installations that won't dare to install Mozilla). So plan ahead
> for the future.

The example is "recommended". That means, "it's correct, but nevertheless 
the user has to decide, what he does". If I have to setup an intranet 
webserver, there are clear conditions and I know, what browsers are in use.

> Squid 2.0 to 2.4 will take _any_ "Vary:" header to simply turn
> off caching for this response - this is correct but quite a pity
> in case of performance. As long as there are not many Squid 2.5
> around, the main requirement is sending any "Vary:" at all; the
> more widely used Squid 2.5 will be, the more important the
> "Vary:" content will become.

Hmm, a Vary header that doesn't reflect the parameters, that *vary*, is 
worthless, isn't it?

> But as there are other, broken proxies out there, causing a lot
> of trouble when dealing with gzipped content, you might hint at
> the "Via:" header to be another potential negotiation parameter
> that is worth being taken into consideration, once you identified
> the "broken guy". (Does Apache provide an easy means for that?)

ehm... SetEnvIf?
But I guess, it's similar to the User-Agent stuff (much to match...)

>> The DeflateBufferSize directive specifies the size in bytes of the
>> fragments that zlib should compress at one time.
> Seems to be a performance tuning issue, not changing the effective
> content output, right? You might tell this explicitly, possibly.

hmm, perhaps.

> (Any reasonable interval for values? How often will a buffer of
> this size reside in memory, given some average Apache configura-
> tion? Once per child process? Depends on MPM?)

every time the filter is invoked (i.e. per actually compressed response).

>> DeflateFilterNote Directive
> <feature_request>

should be easy to build in. Perhaps you should post this on the dev list 
again ;-)

>> DeflateMemLevel Directive
>> Description: How much memory should be used by zlib for compression
> Is this the comandline parameter that is available for the UNIX
> 'gzip' command ("gzip -9 filename")?

I think so.

> If so, the gains of using more than 6 seem to be _very_ small
> (below the 1% rate in many cases), thus you might suggest to use
> something in the 3 (reasonable minimum) to 6 range for installa-
> tions that would like to save CPU power - they won't lose a lot
> of the effect by doing so.

is there some more mathematical stuff somewhere? (or statistics?) Actually 
I don't know enough about the compression algorithm to verify that...

> If you had the ability to cache the compressed content (like
> gzip_cnc does, or when combining an Apache and some front-end
> proxy Squid 2.5), _then_ 9 would be the perfect choice, but not
> if each and every content has to be compressed again. Run bench-
> marks on this, it may turn out quite expensive for high-traffic
> servers.

hmm. I someone would ask me, I would *always* recommend to use statically 
compressed content. compressed CGI output (like a webforum) should be 
tested on compression vs. performance. But I guess most CGI programs or PHP 
scripts actually waste more time and load than the compression ever would 

> Viele Grüße


> [...] weiß jemand zufällig, was der Tag DIV ausgeschrieben bedeutet?
DIVerses. Benannt nach all dem unstrukturierten Zeug, was die Leute da
so reinpacken und dann absolut positionieren ...
                           -- Florian Hartig und Lars Kasper in dciwam

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message