On Mon, Apr 05, 2004 at 01:21:18PM -0500, Slava Bizyayev wrote: > Hi Richard, > > On Mon, 2004-04-05 at 11:29, Richard Chen wrote: > > ...The problem is that my content generation module does not contain a > > header section. > > Do you mean that your CGI content generator fails to produce even an > empty line in the beginning of the content? >
That is correct. This is a pure mod_perl server. No cgi content. The content directly comes from a template system. However, mod_perl server will at the end insert the correct headers to the client anyways. > > In fact, I believe that in mod_perl, by default, there > > will be no headers sent out. So the above code will actually read > > the content as the value for $headers. Then when the time comes > > to fetch the body content, it will be empty. > > Supposed to work this way then... > > > > > My current solution is to simply comment out the lines > > > > my $headers = retrieve_all_cgi_headers_via ($fh); > > $r->send_cgi_header($headers); # just for the case... > > > > but I am wondering if this is a genuine bug in Apache::Dynazip > > when the content does not come from cgi but mod_perl handler, > > or I have used it inappropriately. > > Usually, Apache::Dynagzip expects CGI-compatible content generators in > CGI mode. Though, it's not quite clear for me at the moment, where is > your problem is originating from. Why won't you append a nice piece of > error_log relevant to your request? > > > The error log does not show anything abnormal because except that the body text is empty due to it being mistaken as headers, there is nothing wrong. Here is a sample entry: [Mon Apr 5 17:23:52 2004] [info] [client 123.123.123.123] Apache::Dynagzip default_content_handler is serving the main request for GET /path/to/file.tmpl?scheme=http HTTP/1.1 targeting /dev.myhost.com/path/to/file.tmpl via /path/to/file.tmpl Light Compression is Off. Source comes from Filter Chain. The client curl/7.10.7 (i586-pc-linux-gnu) libcurl/7.10.7 OpenSSL/0.9.7c zlib/1.1.4 does not accept GZIP. [Mon Apr 5 17:24:49 2004] [info] [client 123.123.123.123] Apache::Dynagzip default_content_handler no gzip for GET /path/to/file.tmpl?scheme=http HTTP/1.1 min_chunk_size=8192 [Mon Apr 5 17:24:49 2004] [info] [client 123.123.123.123] Apache::Dynagzip default_content_handler is done OK for /dev.myhost.com/path/to/file.tmpl > > I think most people will not encounter this if they use IE/netscape > > because these browsers set Accept-Encoding header by default. > > Not quite the truth. M$IE does not set Accept-Encoding header over > initial HTTP/1.0 request. > > > But a well-behaved web site should be able to handle as many clients > > as possible. So this problem is worth fixing. > > Definitely. > > Thanks, > Slava It is interesting that Apache::Dynagzip works correctly when the client specifies Accept-Encoding:gzip header, even if the template module does not supply any header lines at all. In this caes, there is no call to retrieve_all_cgi_headers_via and so my template content is not mistaken as headers. So for some reason, Apache::Dynagzip was not implemented consistently in the 2 cases. Thanks for your help. Richard -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
