Antwort: Re: Antwort: [Mod_gzip] mod_gzip without apache..?

[mod_gzip@lists.over.net]

Hi Eyck,


> based on that description:
> "mod_gzip adds HTTP compression to web server.
> Although it may be used with any webserver (well, its authors
> say that ;-)), its Debian version was prepared for using with Apache."

Very interesting statement ... ;-)

> Would you just gzip everything that goes through?

No.

You have to check whether the User-Agent allows you to serve
compressed content.
You would content-negotiate for the "Accept-Encoding" header.

> ( what should you do to inform browser that what is coming is
> compressed? add header? change mime-type or sth? )

Add "Content-Encoding", if Content-Encoding is the way you
want to do it.
(In theory, HTTP allows you to use Transfer-Encoding as well,
but I am not sure whether any browser would support this.)

>> And why should this "proxy" not be an Apache with mod_proxy
>> and mod_gzip?
> Hmm, because i'm short on memory, and don't want to bring whole
> apache for such simple task.

A "whole" Apache can well be a rather tiny thing if you
compile nothing but the modules you need. "configure" is a
great tool to make customized Apaches ... just read the docs.

> Also, seems like mod_gzip uses files for it's operation.

Yes - this is because the mechanism how mod_gzip interacts
with other modules works this way.
mod_gzip tries to compress content of as many modules of any
type as possible, especially dynamic content; if you want to
only compress static content then you might have other options.

> I'd like something working using some kind of streaming...
> ( like you can do tar -c | lzop | do something )

But you are aware that a pipe has to be stored somewhere as
well, which might easily be a disk file?
And that you are able to put the "files" of mod_gzip on a
RAM disk that is mounted into the file system?

> Hmm, is this issue really that complicated?

It depends upon how detailled you know what you actually want.

> I thought I'd find answers quickly by looking at the source,
> but I found the source to be way bigger then I expected,

mod_gzip ships with its own compression code, which is not
a simple thing. mod_deflate would use the zlib interface -
and your own solution might do the same (as gzip_cnc does).

> and handling way more possible options etc than I thought is needed.

Yep - this is a great discovery, isn't it? ;-)

> Maybe there's some technical document that describes it's workings
> that I've been missing?

If you are trying to write a totally new solution then I
think the gzip_cnc documentation would come closer to what
you want than everything that mod_gzip provides as of now.

Regards, Michael