Antwort: [Mod_gzip] Q: DECLINED:HAS_CE

[mod_gzip@lists.over.net]

Hallo Rolf,


> - win2k apache / 2.0.45
> - mod_gzip / mod_gzip-2.0.45

be aware of the fact that most of the mod_gzip 1.3
documentation, especially about module interactions,
doesn't apply any more for mod_gzip 2.0 because of
the totally different Apache 2.0 architecture (fil-
ter model).

> - cfmx with updater 3.0
> - i load mod_gzip before the mod_jrun20 is loaded
> (although i checked it in both ways :))

I don't think this is of any importance in Apache 2.0.

> what i've already checked:
> =========================
> 'has_ce' meens that there already is a content
> encoding in the page and mod_gzip doesn't compress
> pages that are already encoded. (i would expect
> to receive an 'SEND_AS_IS:HAS_CE' - but anyway:))

Actually, mod_gzip 1.3.19+ would exactly do what you
expect, but mod_gzip 2.0 is _much_older_ (its archi-
tecture is more like mod_gzip 1.3.14, from then on
only the Apache 2.0 APIs have been adapted, I think)
and may well have a behaviour of its own.

> what i suppose:
> ==============
> @ http://www.iem.pw.edu.pl/ftp/FreeBSD/distfiles/mod_gzip.c
> i found the following function included in mod_gzip's source:
>
> if ( strstr( has_encoding, "gzip" ) ) {
> [...]
 ap_table_setn(r->notes,"mod_gzip_result",ap_pstrdup(r-
>pool,"DECLINED:HAS_CE:GZIP"));
> }
> does that meen, that my cfm-pages are compressed twice?

The exact opposite is the case. ;-)

Some lines above the "has_encoding" is set by
     has_encoding = ap_table_get( r->headers_out, "Content-encoding" );
- so at this moment at least mod_gzip claims to
have _seen_ a content-encoding which contained
the substring "gzip" and decides to keep its hands
away from this response.
(mod_gzip 1.3 would decline to compress the response
when it detects _any_ content_encoding, not only the
"gzip" type; Kevin Kiley claims to have experienced
browser problems when applying more than one content
encoding, which otherwise would be perfectly legal
according to RFC2616.)

mod_gzip is just setting a "note" (which will later
be evaluated by the Apache log file handler).
This is the step where mod_gzip "gives up" and tells
others why it did so.

> this is the html-header:
> ========================
> [ 15] HTTP/1.0 200 OK
> [ 48] Cache-Control: no-cache="set-cookie,set-cookie2"
> [ 17] Connection: close
> [ 35] Date: Tue, 15 Apr 2003 18:05:24 GMT
> [ 29] Server: Apache/2.0.45 (Win32)
> [ 23] Content-Language: de-DE
> [ 43] Content-Type: text/html; charset=ISO-8859-1
> [ 38] Expires: Thu, 01 Dec 1994 16:00:00 GMT
> [ 62] Set-Cookie: CFID=;expires=Mon, 15-Apr-2002 17:54:45 GMT;path=/
> [ 65] Set-Cookie: CFTOKEN=;expires=Mon, 15-Apr-2002 17:54:45 GMT;path=/
> [ 53] Set-Cookie: JSESSIONID=80301124321050429924375;path=/
> Client-Date: Tue, 15 Apr 2003 18:06:06 GMT
> Client-Response-Num: 1

The problem is that in Apache 2 everything is different.

Especially, the filter concept would allow you to send
the output of mod_gzip to any other filter layer which
might then do whatever it thinks reasonable, maybe even
remove some Content-Encoding.
We don't know what it looked like when mod_gzip saw the
header ...

Viele Grüße

      Michael