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

[Dariusz Pietrzak]

Hi, 

> > Although it may be used with any webserver (well, its authors
> Very interesting statement ... ;-)
 It comes from README.Debian in libapache-mod-gzip package.

> > Would you just gzip everything that goes through?
> You would content-negotiate for the "Accept-Encoding" header.
 In my situation all clients support gzip encoding. But still, this
 would be just compressing everything when Accept-Encoding says it
 supports deflate or gzip. Right?

> Add "Content-Encoding", if Content-Encoding is the way you
> want to do it.
 And where would I put original Content-Encoding?

> > Also, seems like mod_gzip uses files for it's operation.
> mod_gzip tries to compress content of as many modules of any
> type as possible, especially dynamic content; if you want to
Well.. that's one of the reasons i'd like to do it using proxy - 
i don't care what module created the content, whether it was dynamically
created or it's static.. I just want to compress everything text/*.

> only compress static content then you might have other options.
 pre-compressed files seem like a great and underutilized idea.

> But you are aware that a pipe has to be stored somewhere as
> well, which might easily be a disk file?
 Well... no. I'm not aware of that. I even know for a sure that pipe
 does NOT need to be stored anywhere ( ie, you don't need 10G of storage
 to push 10G of data through pipe , try 'cat /dev/zero | gzip -1 >
 /dev/null' ;) )

> And that you are able to put the "files" of mod_gzip on a
> RAM disk that is mounted into the file system?
 Hmm, that's not really an option  on memory starved system, especially
 when you expect large ( ie 20-150kB ) files to be pushed through your
 machine.

> > Hmm, is this issue really that complicated?
> It depends upon how detailled you know what you actually want.
 good point.


> > 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
and it's own string functions and it's own a lot of stuff I find
distracting.
> 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? ;-)
 It's a horrible discovery, and I thought that I've seen everything with
 mod_rewrite ...

> If you are trying to write a totally new solution then I
> think the gzip_cnc documentation would come closer to what
 great, thanx, I haven't heard of gzip_cnc, i'll take a peek.
 

regards, 
 Eyck