Strange status returns from perl_handler
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. I am not sure what interactions are going on here, as at first sight, this doesn't appear to happen with Linux running the same combination (dynamically linked, though). Any ideas, anyone? 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/
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)
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 :(
Re: BUG & PATCH (was: Strange status returns from perl_handler)
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)
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/