'Antwort: [Mod_gzip] mod_gzip and ssi does not work... need help!'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modgzip
Subject:    Antwort: [Mod_gzip] mod_gzip and ssi does not work... need help!
From:       Michael.Schroepl () telekurs ! com
Date:       2002-04-23 14:35:25
[Download RAW message or body]

Hi Andre,

> i use mod_gzip Version 1.3.19.1a and Apache/1.3.24 (Unix)
> if i enable mod_gzip all the virtual hosts that using
> mod_gzip and ssi going crazy.
> the informations from file ssi/meta.inc seems to be compressed
> two times.

can you please give us some information about why you think
this would happen?
Because I doubt this could ever be possible, given the ar-
chitecture of the current mod_gzip implementation.

> one time on the include and the second time with the fully
> page. so if the browser extract it, there are fragments
> that will not be extracted...

mod_gzip clearly distincts between 'normal requests' and
'internal redirections'.
As to my scope of understanding, it will only ever compress
'normal requests', in your case the SSI file after having
included all referenced parts.

<!--#include virtual="ssi/meta.inc" -->

The parts themselves would not be compressed, even if *.inc
would qualify for compression when you access it directly.

I am using mod_gzip with Apache (1.3.20 & 1.3.22) in combi-
nation with SSI and don't experience any problems.
So I guess the cause of your problems must be elsewhere.

If anyone other than mod_gzip would compress a page's content,
then the SSI handler would need to understand Content-Encoding
to correctly understand what is happening. Which means that
the SSI handler would have to uncompress the content, then in-
clude it into the main file, then deliver the result so that
mod_gzip again would be able to compress the whole content ...
and if this content then again would be included into some
other SSI file of higher inclusion hierarchy, the SSI handler
invoked one level higher would again have to uncompress the
content and ... you see, it is not a bad idea of mod_gzip to
not compress internal subrequests.

> here is my configuration, maybe there is an error with it?

I don't see one. You even excluded *.inc from compression,
there seems to be nothing more you can do.
_But_ I don't think mod_gzip is compressing your file.

On the other hand, _if_ there were any handler producing com-
pressed output and not caring about being a subrequest, then
the SSI handler would have to do additional work.
I have checked about this one, as I have some application that
can deliver gzipped content. So I wrote some SSI file including
some output of my application - and it worked.

This is the request for the file compressed by my application
(some CGI script as Apache handler for the ".layout" extension):

     finxs-dhtml 153.46.90.209 - - [23/Apr/2002:13:47:07 +0200]
     "GET /checkit.layout HTTP/1.1" 200 2660
     SEND_AS_IS:HAS_CE 0 -> 0 = 0 Prozent

mod_gzip did detect the compression, and declines to further
compress the content.

And this is the access for a file with the content
"":

     finxs-dhtml 153.46.90.209 - - [23/Apr/2002:13:49:36 +0200]
     "GET /ssitest.shtml HTTP/1.1" 200 2578
     DECHUNK:OK 11816 -> 2378 = 80 Prozent
In this case mod_gzip de-chunked the SSI output, and then com-
pressed it.

You can see that the original uncompressed content was 11816
bytes, the compression by the application itself reduced it
to 2660 bytes, but mod_gzip even did the better job and used
only 2378 bytes.

I have saved both files from Mozilla 1.0RC1, and compared the
content with my editor: Both resulting files were identical.

As this application is simply a CGI script that cannot know
(I think) whether it has been invoked explicitly or implici-
tly I don't expect this application to conditionally compress
its output, thus I think the SSI handler indeed can correctly
uncompress it and include it.

Greetings,

      Michael

_______________________________________________
mod_gzip mailing list
mod_gzip@lists.over.net
http://lists.over.net/mailman/listinfo/mod_gzip
[prev in list] [next in list] [prev in thread] [next in thread] 