You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Richard Chen <ri...@doubleprime.com> on 2004/04/05 18:29:28 UTC
A bug in Apache::Dynazip?
Hi,
I am trying out Apache::Dynazip. All is well
using the IE browser. However, when I use curl (a nice
commandline web client), there are no contents coming back.
I have traced the cause of the problem to
the fact that I did not specify Accept-Encoding header
in curl which invoked a part of code in Apache::Dynazip
that skips compression. But that part seems buggy.
The bug seems to come from the part of the code:
my $headers = retrieve_all_cgi_headers_via ($fh);
$r->send_cgi_header($headers); # just for the case...
(line 862 of Apache::Dynagzip version 0.11). On line 44 we have:
sub retrieve_all_cgi_headers_via { # call model: my $hdrs = retrieve_all_cgi_headers_via ($fh);
my $fh = shift;
my $headers;
{
local $/ = "\n\n";
$headers = <$fh>;
}
return $headers;
}
The problem is that my content generation module does not contain a
header section. 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.
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.
I think most people will not encounter this if they use IE/netscape
because these browsers set Accept-Encoding header by default.
But a well-behaved web site should be able to handle as many clients
as possible. So this problem is worth fixing.
Thanks for any info.
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
Re: A bug in Apache::Dynazip?
Posted by Slava Bizyayev <sb...@outlook.net>.
Hi Richard,
On Mon, 2004-04-05 at 16:43, Richard Chen wrote:
> [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.
Yes, this seems like a bug. Thank you for the hint. I'll release a fix
shortly.
Thanks,
Slava
--
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
Re: A bug in Apache::Dynazip?
Posted by Richard Chen <ri...@doubleprime.com>.
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
Re: A bug in Apache::Dynazip?
Posted by Slava Bizyayev <sb...@outlook.net>.
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?
> 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?
>
> 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
--
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