[Mod_gzip] A glimpse into the crystal ball ...

[mod_gzip@lists.over.net]

Hi Todd,


> Also, the note above says nothing at all about matching on
> MIME types. Testing indicates that
>    mod_gzip_item_exclude mime ^^image/
>    mod_gzip_item_exclude mime ^^application/
> does not, in fact, turn off the Vary: headers.

You are right.

As of 1.3.26.1a, we were not yet absolutely sure about
which "Vary:" header this might require to be sent in
this case, so we chose to rather incrementally improve
the procedure than implement something we would have to
remove in the next release.
I believe that the confidence of the mod_gzip users
should no be shattered by us releasing things that we
ourselves are not yet confident about. I think we all
can live better with more and incremental releases than
with having to publish warnings like "oops, we rather
shouldn't have released this yet, please go back to the
previous version". ;-)

> So there's still some work to be done on making the Vary:
> generation smarter.  8-)

Yes. But on the other hand, it might be a solution for the
future to teach people how to use <Files> and <Location>
and all this stuff, and think about which directives
mod_gzip might possibly no longer need in future versions.

A large part of the set of configuration directives like
the "handler" and "file" filters and the header parsing is
no more than a kludge to handle broken instances of other
players in the game. These may not vanish completely from
the Web, but their importance will be lower in some years,
especially as now Netscape 7.0 final is available and many
office installations now finally have the _option_ to up-
grade to anything other than M$IE.
Other things, like the dechunking feature for SSI and CGI,
might work differently in Apache 2.0 because of its new
architecture. Maybe adding mod_gzip as a CONTENT_SET-Filter
will give it a better chance to seamlessly cooperate with
other modules like mod_ssl, mod_proxy, PHP, Java Servlets
that all need sophisticated configuration in mod_gzip 1.3.

One of the goals with a long-time perspective is to re-open
the door for mod_gzip to one day become a module maintained
by the Apache Group itself.
There are several issues to be solved before thinking about
such a move, one of which seems to be getting rid of direc-
tives than mod_gzip would no longer need in Apache 2.0.
Currently, Christian is concentrating on the Apache 1.3
module API and on functionality, but although Apache 1.3.27
has been released these days the future may rather belong
to the Apache 2.0 kernel.
So maybe in one or two years, if Apache 2.0 would then have
stable APIs, and a market share that would demand for a
mod_gzip port with the current functionality of the 1.3
branch, this port might be done in a way that the result
would be much more integrated into the Apache 2.0 concept.
And having much less broken browsers and proxies around,
thus requiring less directives but then some more knowledge
about general Apache configuration. Maybe in Apache 2.0
disabling the compression module based upon <Files> and
<LocationMatch> containers can solve many more configura-
tion cases than in Apache 1.3, and thus make the architec-
ture of mod_gzip 2.0 very much simpler.
And if so, this would be a much more likely candidate for
being taken over by the Apache Group, as they do have a
valid point about not wanting to have things being imple-
mented several times in redundant ways.
Maybe the way to get a 'good' mod_gzip for Apache 2.0 would
rather be a complete rewrite than a port. And maybe this
would even require some things to be implemented into the
Apache core to seamlessly integrate this future mod_gzip
(and its HTTP/1.1 requirements) into the server.
This would then require some communication with the Apache
Group, just like we currently have this successful communi-
cation with the Squid developers about the Vary: issues
during the last months.
But even so, mod_gzip might still live on as a separate
product, if the Apache Group would not accept specific
features of mod_gzip inside their core, like the refreshing
of precompressed files that Christian just implemented for
mod_gzip 1.3.26.1a. If 'the Apache' must not write to docu-
ment directories as a conditio sine qua non, then mod_gzip
would either lose this feature when being taken over by the
Apache Group or remain a separate product if the users need
this feature.

Another possible development might be some knowledge transfer
between the Apache Group and the mod_gzip maintainers to get
a better mod_deflate implementation.
After all, there is compression module already being shipped
together with Apache 2.0, and although this can do a lot less
than mod_gzip and is classified experimental by the Apache
Group, in principle they might just learn from mod_gzip and
implement the features that would need to be added as to make
mod_deflate be a usable replacement for mod_gzip.
After all, we want the _Apache_ server to be able to compress
pages - we don't necessarily need this to be done by some
separate 3rd party module that isn't being shipped together
with the standard Apache and thus will be installed only on
servers of admins that show the initiative to care about per-
formance.
Just remember that mod_gzip already _had_ been donated to the
Apache Group, and while the attempt has failed to work the
last time, I wouldn't rule out that some day some retry, with
a better point to start from, might be more successful.



Regards, Michael