Antwort: RE: Antwort: RE: [Mod_gzip] Request Handling

[mod_gzip@lists.over.net]

Hi Etienne,




> The application server is WebSphere 5.0 and it does have a
> module that gets loaded in the configuration file.

and this module is loaded before mod_gzip, so that
mod_gzip resides on top of the module stack and thus
has the first access to this request, so that it can
gaurantee to be invoked later to compress the output.

> When I specify a log file for mod_gzip I can see that the
> application server requests are being compressed (if chunks
> are enabled), does this mean that it is actually working?

If the logfile "notes" are set by mod_gzip (and noone
would care about them) you at least know that mod_gzip
did care about this request.
If you want to see the gzipped content with your own
eyes, then request one of your URLs via
     http://www.schroepl.net/cgi-bin/http_trace.pl

> I have not specified "mod_gzip_item_include handler xxxxx"
> but it seems to be working, how can this be?
> (From your response it seemed like the handler directive
> would be required fro it to work)

Not "required", but "likely to be required".

mod_gzip is "satisfied" if you tell it to care about
URLs, files, handlers and/or request headers what to
compress and what not to compress (Phase 1) and then
confirm this by including via response headers and/or
MIME types (Phase 2). So including file (or URI) and
MIME _might_ actually suffice.

It is just that some handlers don't "play fair" and
internally rewrite URIs, file names and whatnot!
If so, then your include rules will fail to match,
and the handler name would then be your "last resort"
to still "catch" this request.

> Why does it only work when chunks are enabled?

Chunks are meant to be sent separately and have the
browser collect and re-join them before extracting
the HTTP content. (You do this when you don't have
the "Content-Lenght" beforehand, i. e. in most cases
of dynamic output, like CGI and SSI.)
This would then collide with the idea of compressing
the whole content, as you must not compress individual
chunks (the order of the communication layers is not
so to allow that - Content Encoding is for contents,
not for chunks).

So if your Websphere application generates chunks then
mod_gzip has to collect all these chunks, then compress
the content and send it to the browser as if no chunks
had been there at all.
In this case mod_gzip acts like a "buffer" for your
output, and it may even delay the output in some cases
(but still save a lot of bandwidth).

This is the reason why "de-chunking" is not enabled au-
tomatically but requires your decision to activate it.
Normally you will have this delay for dynamic output
whose computation costs some delay anyway, so you are
likely willing to pay this price, but ... after all,
you are the user, and it is your choice.

Regards, Michael