Antwort: AW: Antwort: [Mod_gzip] SEND_AS_IS:RESPONSE_CONTENT_TYPE _EXCLUDED

[mod_gzip@lists.over.net]

Hallo Markus,


>> You either explicitly excluded this Content-Type, or you
>> didn't exclude it. At least, mod_gzip didn't find an include
>> rule firing in rule evaluation phase 2.
> Why does not the next config-lines work?:
> mod_gzip_item_include         file       \.jsp$
> mod_gzip_item_include         file       \.jsp
> mod_gzip_item_include         uri        \.jsp$
> mod_gzip_item_include         uri        \.jsp

one of these rules _does_ work - but they apply to rule evaluation
phase 1. And mod_gzip requires the request to be included in both
phases to compress the content.

Suggested reading:
     http://www.schroepl.net/projekte/mod_gzip/config.htm#filters

> mod_gzip_item_include         mime       ^^text/*$

This rule doesn't seem to be what you want.
You instruct mod_gzip to check whether the MIME type starts
("^^") with the string "text", followed by any number (even
zero) of "/" characters, and then terminating without any
further content.
This would _not_ match to "text/html", for example (but would
match to "text" and "text///").
Welcome in the wonderful world of the regular expression 4GL.

Maybe you mean "^^text/.*$"?
This would mean "any number of the single character wildcard".

But then, you would get the same semantics by simply writing
"^^text/", which does a prefix match with the named string but
then doesn't care which text subtype it actually was.

> mod_gzip_item_include         mime       ^^text/jsp
> mod_gzip_item_include         mime       ^^text/jsp$

The second of these two rules is redundant, as the first one
will check this as well.
(The exact match is a subset of the prefix match.)

> What is the correct configuration to compress JSP output?

Speaking of phase 2, this doesn't depend on the origin of the
page but only on the MIME content type.
Both the status codes you posted are created in phase 2 only.

>> > Can't mod_gzip compress output from the web-to-go handler?
>> This depends on how this output works and how you configure mod_gzip.
> The JSP application is connected to Apache with the web-to-go handler.
> I think, it may be similar to mod_jk to connect Apache to Tomcat.
> Does the handler need a special configuration in the include/exclude
> list?

This depends upon how the handler works.
Some handlers rewrite the request URI within handling the request
and the like ... so you can hardly ever be sure which rule will
actually fire unless you have tried it out.
But this effect area applies to phase 1 only, which doesn't seem
to be your problem.

>>  > mod_gzip_item_include         handler    !cgi-script$
>>  > mod_gzip_item_include         handler    !cgi-script
>>  > mod_gzip_item_include         handler    !web-to-go$
>>  > mod_gzip_item_include         handler    !web-to-go
>>  What is this exclamation mark going to mean?
> I have read from another posting that '!' means dynamic content output.

All you are doing there is specifying a regular expression. Whether
the content is dynamic or not is of no importance at this point.

> Is this right or is '!' not defined??
I would say it makes your rules matching to a string starting with
the exclamation mark.
But again, this is rule evaluation phase 1, so the fact that in
your case the problem is in phase 2 tells me that some other rule
("file", possibly) takes care of the phase 1 matching.
And having one "include" firing per checking phase is sufficient.

>>   > mod_gzip_item_include         file       ^^text/jsp$
>>   > mod_gzip_item_include         handler    !text/jsp$
>>   These two rules don't make any sense to me.
> Deleted! No positve changes.

I didn't expect positive changes. You need a "include_item mime"
rule that fires for your Content-Type - which means that you need
to know which Content-Type your JSP application is generating and
write an appropriate regular expression for it.

Viele Grüße

      Michael