You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Julian Gilbey <J....@qmw.ac.uk> on 2001/05/23 18:58:47 UTC
BUG & PATCH (was: Strange status returns from perl_handler)
On Mon, May 21, 2001 at 06:36:54PM +0100, Julian Gilbey wrote:
> We've just upgraded a SunOS machine from Apache 1.3.9 + mod_perl 1.21
> (dynamically linked) to Apache 1.3.19 + mod_perl 1.25 (statically
> linked). I have a CGI/Perl script, handled as normal by perl-script
> and Apache::Registry. Now, this CGI script sometimes returns a page
> with status something like '403 Forbidden', including full content and
> full headers. With the old version, the perl_handler function
> returned with status=0 (OK), even if the HTTP status was going to be
> 403, and then Apache was quite happy with this. However, in the
> current combination, the perl_handler function returns with the HTTP
> status, so that the Apache core adds on its own content.
Right, here's a patch. This line of code was erroneously removed some
time between version 1.21 and 1.25 of mod_perl.
--- Apache.xs~ Tue May 15 14:20:51 2001
+++ Apache.xs Wed May 23 17:18:45 2001
@@ -937,6 +937,7 @@
r->content_type = pstrdup(r->pool, type);
send_http_header(r);
mod_perl_sent_header(r, 1);
+ r->status = 200; /* XXX, why??? */
#ifndef PERL_OBJECT
An improved comment might help here. The r->status variable is used
for two distinct purposes:
(1) Once the Perl script has correctly executed (or something like
that; the details are really confusing), and until the HTTP header
is correctly sent, it is used to indicate the HTTP status code
(200 = HTTP_OK, for example).
(2) After this, it is used to record the status of the Perl script.
The perl_call_handler function in mod_perl.c takes a status value
of 200 to mean that everything has gone OK.
(3) The HTTP procedures don't need the HTTP status code again after
the header has been sent.
Therefore, this line of code is necessary to keep the rest of the
system correctly functioning.
So I'd recommend a comment like:
/* mod_perl needs this to say the code has executed correctly */
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: BUG & PATCH (was: Strange status returns from perl_handler)
Posted by Julian Gilbey <J....@qmw.ac.uk>.
On Fri, Jul 06, 2001 at 01:50:57PM -0700, Doug MacEachern wrote:
> On Wed, 23 May 2001, Julian Gilbey wrote:
>
> > On Mon, May 21, 2001 at 06:36:54PM +0100, Julian Gilbey wrote:
> > > We've just upgraded a SunOS machine from Apache 1.3.9 + mod_perl 1.21
> > > (dynamically linked) to Apache 1.3.19 + mod_perl 1.25 (statically
> > > linked). I have a CGI/Perl script, handled as normal by perl-script
> > > and Apache::Registry. Now, this CGI script sometimes returns a page
> > > with status something like '403 Forbidden', including full content and
> > > full headers. With the old version, the perl_handler function
> > > returned with status=0 (OK), even if the HTTP status was going to be
> > > 403, and then Apache was quite happy with this. However, in the
> > > current combination, the perl_handler function returns with the HTTP
> > > status, so that the Apache core adds on its own content.
>
> can you post an example script? i think the current sources do the right
> thing. re-reading your message, it sounds like you should be using a
> CustomResponse (or $r->custom_response) if you want to generate a 403
> response yourself. i realize what you're doing 'worked' in older
> mod_perls, but that was a bug, not a feature.
I'm using CGI.pm, version 2.56, with the
print header(-status => '403 Forbidden');
function. So perhaps it's a CGI.pm bug?
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: BUG & PATCH (was: Strange status returns from perl_handler)
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 23 May 2001, Julian Gilbey wrote:
> On Mon, May 21, 2001 at 06:36:54PM +0100, Julian Gilbey wrote:
> > We've just upgraded a SunOS machine from Apache 1.3.9 + mod_perl 1.21
> > (dynamically linked) to Apache 1.3.19 + mod_perl 1.25 (statically
> > linked). I have a CGI/Perl script, handled as normal by perl-script
> > and Apache::Registry. Now, this CGI script sometimes returns a page
> > with status something like '403 Forbidden', including full content and
> > full headers. With the old version, the perl_handler function
> > returned with status=0 (OK), even if the HTTP status was going to be
> > 403, and then Apache was quite happy with this. However, in the
> > current combination, the perl_handler function returns with the HTTP
> > status, so that the Apache core adds on its own content.
can you post an example script? i think the current sources do the right
thing. re-reading your message, it sounds like you should be using a
CustomResponse (or $r->custom_response) if you want to generate a 403
response yourself. i realize what you're doing 'worked' in older
mod_perls, but that was a bug, not a feature.
Re: BUG & PATCH (was: Strange status returns from perl_handler)
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 23 May 2001, Julian Gilbey wrote:
> Right, here's a patch. This line of code was erroneously removed some
> time between version 1.21 and 1.25 of mod_perl.
see Changes:
"fix bug where Apache::send_http_header was resetting r->status = 200
thanks to brian d foy for the spot"
the problem is that setting r->status = 200 makes for bogus access_log
entries.
> (2) After this, it is used to record the status of the Perl script.
> The perl_call_handler function in mod_perl.c takes a status value
> of 200 to mean that everything has gone OK.
perl_call_handler doesn't check r->status, it checks the return value of
the subroutine. using r->status is hack for Apache::Registry, which i
guess has not quite been untangled. i will revisit the problem before
1.26 and see if we can fix both the response problem and maintain proper
access_log entries. thanks for the patch, i know this particular problem
is painful, been there a couple of times already :(