You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by David Dick <da...@iprimus.com.au> on 2003/02/01 23:35:52 UTC
Possible bug with a 206 Partial Response
G'day all,
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
HISTORY:
I've been using MD5 digests of the html sent from my scripts as ETags,
hence saving an important bit of bandwidth. Got a little bit carried
away with the success of this project and attempted to handle range
requests as well. Worked fine when running as a CGI script, but blew a
fuse when running as an Apache::Registry script. Stripped the script
down to the basics and the error continued.
I have a script called test.pl which has the following content.
#! /usr/bin/perl -wT
MAIN: {
print <<_OUT_;
Status: 206 Partial Content
Content-Type: text/html; charset=UTF-8
Content-Length: 11
Content-Range: bytes 0-10/1336
Date: Fri, 31 Jan 2003 09:39:01 GMT
ETag: "xxxx"
_OUT_
print '<?xml versi';
}
When the script is run, the following output appears.
[dave@localhost]$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.pl HTTP/1.1
Host: localhost
HTTP/1.1 206 Partial Content
Date: Sat, 01 Feb 2003 22:12:47 GMT
Server: Apache
Content-Range: bytes 0-10/1336
ETag: "xxxx"
Content-Length: 11
Content-Type: text/html; charset=UTF-8
<?xml versi<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>206 Partial Content</TITLE>
</HEAD><BODY>
<H1>Partial Content</H1>
The server encountered an internal error or
misconfiguration and was unable to complete
your request.<P>
Please contact the server administrator,
david_dick@iprimus.com.au and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.<P>
More information about this error may be available
in the server error log.<P>
</BODY></HTML>
Fairly obviously, not what is desired. However, if you change the '206'
in the script to a '200', the script works fine. I've searched through
the mod_perl code in a brief fashion for a condition that would cause
this, but couldn't find anything. Anyone got any ideas?
CONFIGURATION
apache 1.3.27
mod_perl 1.27
mod_ssl 2.8.11-1.3.27
httpd.conf
ServerType standalone
ServerTokens ProductOnly
Timeout 300
KeepAlive On
KeepAliveTimeout 100
MaxKeepAliveRequests 10
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 20
MaxRequestsPerChild 10
BindAddress 127.0.0.1
Port 80
User nobody
Group nobody
UseCanonicalName On
DefaultType text/plain
HostnameLookups Off
ServerSignature Off
ServerAdmin david_dick@iprimus.com.au
DocumentRoot /path/to/script/parent
<VirtualHost *>
ErrorLog /var/log/httpd/error_log
<Directory />
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
</Directory>
</VirtualHost>
Re: Registry return codes handling (was Re: Possible bug with a 206
Partial Response)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The only thing that puzzles me about this thread is that it seems to be
> leaning towards the position that says;
> If the developer just does straight out weird stuff and messes with
> $r->status in a cgi-script and expects it to work with Apache::Registry
> (which as far as I understand is a cgi emulation layer), we will
> accommodate them. However, if the s/he just expects Apache::Registry to
> behave like it mod_cgi (except faster, more brilliant, etc :)) then they
> will be disappointed. I am probably just fixated over my current work
> and can't see the proverbial forest. Can somebody explain this for me?
well, Apache::Registry started out as a mod_cgi emulation layer, trying to
speed up legacy mod_cgi scripts without alteration. personally, I think
that concept is flawed because we all know that many legacy CGI scripts are
poorly written, so you need take special measure to not fall into the
numerous documented Registry traps. not to mention that Registry doesn't
handle HEAD requests properly (in 1.0), if you read POST data elsewhere
you're SOL in your CGI script, etc. but, ok, say you have your CGI
emulation layer - that's one facet of Registry.
however, Registry also acts as a dispatch mechansim for people wanting to
use the mod_perl API without writing separate handlers for each bit of
functionality - since you get $r passed in automatically, or can retrieve it
via Apache->request on your own, you are fully free to use Registry this way
and many people do. fiddling with $r->status is _only_ possible when
Registry is used in this way - there is no mod_cgi equivalent way to set
that part of the request record (that I know about, anyway :) for people
who want to use the mod_perl API to, say, return REDIRECT, there needs to be
some mechanism to allow them to do so, and the $r->status hack has
traditionally served this purpose.
(one of) my points before was that with 2.0 and the Cooker idea, we really
can (and ought to) have two versions of Registry to accomodate these two
needs - people who just want faster mod_cgi (and Registry returns OK or
SERVER_ERROR) and people who want the mod_perl API (and Registry returns the
script return code). separating out the two classes of users will probably
make the Registry logic much easier and cleaner.
just my $0.02.
--Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206
Partial Response)
Posted by Stas Bekman <st...@stason.org>.
David Dick wrote:
[...]
> The only thing that messed me up was when running a script with mod_cgi,
> you can return your own status codes and apache will happily go along
> with it. However, when you run the same script under mod_perl's
> Apache::Registry, you suddenly get Apache::Registry second guessing the
> script and adding to the script, something that for (especially)
> USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just
> ended up writing my own version of Apache::Registry that always returns
> OK, which works for my purposes and therefore I'm content.
> The only thing that puzzles me about this thread is that it seems to be
> leaning towards the position that says;
> If the developer just does straight out weird stuff and messes with
> $r->status in a cgi-script and expects it to work with Apache::Registry
> (which as far as I understand is a cgi emulation layer), we will
> accommodate them. However, if the s/he just expects Apache::Registry to
> behave like it mod_cgi (except faster, more brilliant, etc :)) then they
> will be disappointed. I am probably just fixated over my current work
> and can't see the proverbial forest. Can somebody explain this for me?
Personally I don't see how is it possible to accomodate everybody in the same
handler. Because the requirements are conficting and second guessing is
working in 99% but breaks for 1%, causing torn out hairs.
Perhaps having two different sub-classes which do things differently is the
right way to go. The default should follow the course of the least surprise
and accomplish what it was designed for in first place: emulate mod_cgi, while
giving the speed benefits. The other sub-class should pitch towards developers
that use registry, for scripts which are expected to behave differently from
mod_cgi.
Looks like that's what we have under mod_perl 1.0. Apache::Registry and
Apache::PerlRun/RegistryNG behave differently and one should choose between
the two according to their needs. Even though the overall implementation is
different for a different reason (make a sub-classable registry).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Registry return codes handling (was Re: Possible bug with a 206
Partial Response)
Posted by David Dick <da...@iprimus.com.au>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>
>>> The logic here is simpler:
>>>
>>> 1. store the new status code (just in case the script has changed it)
>>> 2. reset the status code to the one before the script execution
>>> 3. if the script has attempted to change the status by itself and
>>> the execution status is Apache::OK return that new status. Otherwise
>>> return the execution status (which will be either Apache::OK or
>>> Apache::SERVER_ERROR)
>>>
>>
>> this is different that how Apache::Registry in 1.0 handles it,
>> specifically under circumstances like redirects, where people
>> typically do
>>
>> $r->headers_out(Location => '/foo');
>> $r->status(REDIRECT);
>> return REDIRECT;
>>
>> what you're saying now is that the status is only propagated if you
>> return OK. (at least that's what I _think_ you're saying - I'm still
>> trying to get back after a week off :)
>>
>> the logic should probably be something like respect the execution
>> status if it is OK or it matches the new status, making
>>
>> $r->status(REDIRECT);
>> return OK;
>>
>> and
>>
>> $r->status(REDIRECT);
>> return REDIRECT;
>>
>> both valid ways to effectively redirect the request from Registry.
>>
>> the $r->status() bit was always a hack - nobody is supposed to fiddle
>> with $r->status, which is why mod_perl saves and restores it. we
>> could do with a better way that saved us from all this logic for
>> people who want to use Registry with the mod_perl API. perhaps a
>> version of the Cooker that simply respected (and expected) the script
>> to return a meaningful status code. thus, the script would return
>> SERVER_ERROR if $@ is true, and the return status of the subroutine
>> otherwise. of course, we can't do this in CGI-portable mode, but for
>> folks that want to use Registry as a dispatch mechanism, this is
>> really the preferred way.
>
>
> OK, so we are not done with it.
>
> The first thing I'd like to see is to have Apache::Registry and
> Apache::PerlRun agree on how they handle return codes, because they
> aren't the same. Once this happens, the Cooker will do the same.
>
> As you have mentioned we have a problem with relying on return status.
> Because if the script doesn't use the mod_perl API, it normally may
> return absolutely anything, which may mess things up. So the safest
> approach, is to run the script, ignore its return value (not status!)
> and return OK or SERVER_ERROR based on whether the execution was
> error-free or not. Plus add the hack of returning of the new status if
> it was changed by the script. That's the approach that is taken by
> Apache::Registry and it seems that most people are happy with it.
> PerlRun does return the execution status, but when I first made the
> Cooker use this approach we immediately received a bug report, where
> the script wasn't doing the right thing.
The only thing that messed me up was when running a script with mod_cgi,
you can return your own status codes and apache will happily go along
with it. However, when you run the same script under mod_perl's
Apache::Registry, you suddenly get Apache::Registry second guessing the
script and adding to the script, something that for (especially)
USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just
ended up writing my own version of Apache::Registry that always returns
OK, which works for my purposes and therefore I'm content.
The only thing that puzzles me about this thread is that it seems to be
leaning towards the position that says;
If the developer just does straight out weird stuff and messes with
$r->status in a cgi-script and expects it to work with Apache::Registry
(which as far as I understand is a cgi emulation layer), we will
accommodate them. However, if the s/he just expects Apache::Registry to
behave like it mod_cgi (except faster, more brilliant, etc :)) then they
will be disappointed. I am probably just fixated over my current work
and can't see the proverbial forest. Can somebody explain this for me?
Re: Registry return codes handling (was Re: Possible bug with a 206
Partial Response)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> OK, so we are not done with it.
>>
>> The first thing I'd like to see is to have Apache::Registry and
>> Apache::PerlRun agree on how they handle return codes, because they
>> aren't the same. Once this happens, the Cooker will do the same.
>>
>> As you have mentioned we have a problem with relying on return status.
>> Because if the script doesn't use the mod_perl API, it normally may
>> return absolutely anything, which may mess things up. So the safest
>> approach, is to run the script, ignore its return value (not status!)
>> and return OK or SERVER_ERROR based on whether the execution was
>> error-free or not. Plus add the hack of returning of the new status if
>> it was changed by the script. That's the approach that is taken by
>> Apache::Registry and it seems that most people are happy with it.
>> PerlRun does return the execution status, but when I first made the
>> Cooker use this approach we immediately received a bug report, where
>> the script wasn't doing the right thing.
>
>
> I can't remember whether you modeled Cooker after PerlRun or RegistryNG.
> the current logic in RegistryNG represents a recent change and is my fault
>
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=101240123609773&w=2
>
> basically, I was trying to fix pretty much what we're talking about but
> might have gotten it wrong.
>
> we probably ought to just follow the 1.0 Registry formula, since I can't
> remember anybody complaining about it in recent memory. that is, if
> we're going to have one version - see my other email for thoughts on
> having two versions of Registry :)
I don't see what's wrong with your change, it brings things to be more
consistent with Registry.pm. I've modeled the RegistryCooker after
PerlRun.pm/RegistryNG.pm, but referring to Registry.pm when unsure.
In any case, let's leave 1.0 alone (those who need it changed, can subclass
RegistryNG) and work out a good 2.0.
Re: ModPerl::RegistryCooker and its subclasses, you have to come forward and
send tests that don't work as expected and we will act accordingly. My goal is
to have an exhaustive test suite for registry scripts, because I'm sick of
running my in-head built-in mod_perl ;) That includes lots of edge cases, for
various error cases and such. Currently we have 34 tests, but more are needed.
206................ok
404................ok
500................ok
basic..............ok
closure............ok
perlrun_require....ok
redirect...........ok
special_blocks.....ok
All tests successful.
Files=8, Tests=34, 11 wallclock secs ( 6.80 cusr + 0.80 csys = 7.60 CPU)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Registry return codes handling (was Re: Possible bug with a 206
Partial Response)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> OK, so we are not done with it.
>
> The first thing I'd like to see is to have Apache::Registry and
> Apache::PerlRun agree on how they handle return codes, because they
> aren't the same. Once this happens, the Cooker will do the same.
>
> As you have mentioned we have a problem with relying on return status.
> Because if the script doesn't use the mod_perl API, it normally may
> return absolutely anything, which may mess things up. So the safest
> approach, is to run the script, ignore its return value (not status!)
> and return OK or SERVER_ERROR based on whether the execution was
> error-free or not. Plus add the hack of returning of the new status if
> it was changed by the script. That's the approach that is taken by
> Apache::Registry and it seems that most people are happy with it.
> PerlRun does return the execution status, but when I first made the
> Cooker use this approach we immediately received a bug report, where the
> script wasn't doing the right thing.
I can't remember whether you modeled Cooker after PerlRun or RegistryNG.
the current logic in RegistryNG represents a recent change and is my fault
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=101240123609773&w=2
basically, I was trying to fix pretty much what we're talking about but
might have gotten it wrong.
we probably ought to just follow the 1.0 Registry formula, since I can't
remember anybody complaining about it in recent memory. that is, if we're
going to have one version - see my other email for thoughts on having two
versions of Registry :)
--Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206
Partial Response)
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> The logic here is simpler:
>>
>> 1. store the new status code (just in case the script has changed it)
>> 2. reset the status code to the one before the script execution
>> 3. if the script has attempted to change the status by itself and the
>> execution status is Apache::OK return that new status. Otherwise
>> return the execution status (which will be either Apache::OK or
>> Apache::SERVER_ERROR)
>>
>
> this is different that how Apache::Registry in 1.0 handles it,
> specifically under circumstances like redirects, where people typically do
>
> $r->headers_out(Location => '/foo');
> $r->status(REDIRECT);
> return REDIRECT;
>
> what you're saying now is that the status is only propagated if you
> return OK. (at least that's what I _think_ you're saying - I'm still
> trying to get back after a week off :)
>
> the logic should probably be something like respect the execution status
> if it is OK or it matches the new status, making
>
> $r->status(REDIRECT);
> return OK;
>
> and
>
> $r->status(REDIRECT);
> return REDIRECT;
>
> both valid ways to effectively redirect the request from Registry.
>
> the $r->status() bit was always a hack - nobody is supposed to fiddle
> with $r->status, which is why mod_perl saves and restores it. we could
> do with a better way that saved us from all this logic for people who
> want to use Registry with the mod_perl API. perhaps a version of the
> Cooker that simply respected (and expected) the script to return a
> meaningful status code. thus, the script would return SERVER_ERROR if $@
> is true, and the return status of the subroutine otherwise. of course,
> we can't do this in CGI-portable mode, but for folks that want to use
> Registry as a dispatch mechanism, this is really the preferred way.
OK, so we are not done with it.
The first thing I'd like to see is to have Apache::Registry and
Apache::PerlRun agree on how they handle return codes, because they aren't the
same. Once this happens, the Cooker will do the same.
As you have mentioned we have a problem with relying on return status. Because
if the script doesn't use the mod_perl API, it normally may return absolutely
anything, which may mess things up. So the safest approach, is to run the
script, ignore its return value (not status!) and return OK or SERVER_ERROR
based on whether the execution was error-free or not. Plus add the hack of
returning of the new status if it was changed by the script. That's the
approach that is taken by Apache::Registry and it seems that most people are
happy with it. PerlRun does return the execution status, but when I first made
the Cooker use this approach we immediately received a bug report, where the
script wasn't doing the right thing.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Registry return codes handling (was Re: Possible bug with a 206
Partial Response)
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The logic here is simpler:
>
> 1. store the new status code (just in case the script has changed it)
> 2. reset the status code to the one before the script execution
> 3. if the script has attempted to change the status by itself and the
> execution status is Apache::OK return that new status. Otherwise return
> the execution status (which will be either Apache::OK or
> Apache::SERVER_ERROR)
>
this is different that how Apache::Registry in 1.0 handles it, specifically
under circumstances like redirects, where people typically do
$r->headers_out(Location => '/foo');
$r->status(REDIRECT);
return REDIRECT;
what you're saying now is that the status is only propagated if you return
OK. (at least that's what I _think_ you're saying - I'm still trying to get
back after a week off :)
the logic should probably be something like respect the execution status if
it is OK or it matches the new status, making
$r->status(REDIRECT);
return OK;
and
$r->status(REDIRECT);
return REDIRECT;
both valid ways to effectively redirect the request from Registry.
the $r->status() bit was always a hack - nobody is supposed to fiddle with
$r->status, which is why mod_perl saves and restores it. we could do with a
better way that saved us from all this logic for people who want to use
Registry with the mod_perl API. perhaps a version of the Cooker that simply
respected (and expected) the script to return a meaningful status code.
thus, the script would return SERVER_ERROR if $@ is true, and the return
status of the subroutine otherwise. of course, we can't do this in
CGI-portable mode, but for folks that want to use Registry as a dispatch
mechanism, this is really the preferred way.
--Geoff
Registry return codes handling (was Re: Possible bug with a 206 Partial
Response)
Posted by Stas Bekman <st...@stason.org>.
I did some more tweaking to ModPerl::RegistryCooker. I think my previous
implementation would have problems when the script has changed the status and
then failed (the failure would be ignored then). Please verify that this is
still good (the test suite passes, but it's not exhaustive).
# handlers shouldn't set $r->status but return it, so we reset the
# status after running it
my $old_status = $self->[REQ]->status;
my $rc = $self->run;
my $new_status = $self->[REQ]->status($old_status);
return ($old_status != $new_status && $rc == Apache::OK)
? $new_status
: $rc;
The logic here is simpler:
1. store the new status code (just in case the script has changed it)
2. reset the status code to the one before the script execution
3. if the script has attempted to change the status by itself and the
execution status is Apache::OK return that new status. Otherwise return the
execution status (which will be either Apache::OK or Apache::SERVER_ERROR)
So if that's valid, here are the suggested patches to bring all 3
implementations in sync (David, please check that both Registry and PerlRun
work for you):
Index: lib/Apache/Registry.pm
===================================================================
RCS file: /home/cvs/modperl/lib/Apache/Registry.pm,v
retrieving revision 1.34
diff -u -r1.34 Registry.pm
--- lib/Apache/Registry.pm 23 May 2002 04:21:07 -0000 1.34
+++ lib/Apache/Registry.pm 5 Feb 2003 06:14:00 -0000
@@ -169,7 +169,8 @@
# return REDIRECT;
# }
# }
- return $r->status($old_status);
+ my $new_status = $r->status($old_status);
+ return $old_status != $new_status ? $new_status : OK;
} else {
xlog_error($r, "$filename not found or unable to stat");
return NOT_FOUND unless $Debug && $Debug & 2;
Index: lib/Apache/RegistryNG.pm
===================================================================
RCS file: /home/cvs/modperl/lib/Apache/RegistryNG.pm,v
retrieving revision 1.8
diff -u -r1.8 RegistryNG.pm
--- lib/Apache/RegistryNG.pm 24 Mar 2002 22:06:39 -0000 1.8
+++ lib/Apache/RegistryNG.pm 5 Feb 2003 06:14:00 -0000
@@ -56,7 +56,7 @@
my $pr_status = $pr->status;
$r->status($old_status);
- return ($rc != OK) ? $rc : $pr_status;
+ return ($rc == OK && $old_status != $new_status) ? $pr_status : $rc;
}
1;
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Possible bug with a 206 Partial Response
Posted by Stas Bekman <st...@stason.org>.
David Dick wrote:
>>
>> If I'm correct both Apache::PerlRun and Apache::Registry will have
>> problems in certain situations if we agree that ModPerl::Registry has
>> the correct logic for handling the execution status. If you can tell
>> otherwise please give me a test script that doesn't work under
>> ModPerl::Registry.
>>
>> But in your particular example, Dick, if you configure the
>
>
> I'm presuming that you simply mixed up which is my first name and
> surname? :) Usually dave is fine. :)
Oops, sorry Dave ;)
>> script to run under Apache::RegistryNG, does it work?
>
>
> No.
So that confirms my suspicion that the problem in 1.0 implementation is that
it unconditionally resets the status.
>> If not, that's where the difference between 1.0 and 2.0 lays:
>> ModPerl::Registry doesn't reset status if it wasn't changed by the
>> script.
>
> well the ModPerl::Registry behaviour certainly suits my program. :)
Good, though I'm not sure how to proceed from here. 1.0's registry doesn't
have a test suite and I'm afraid to break other people's code on the next
release. So perhaps someone will take a good look at it, before we move on
with this change.
In any case, you can subclass Apache::RegistryNG and override the handler()
method to get things working for you now. or give a try to mp2.0.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Possible bug with a 206 Partial Response
Posted by David Dick <da...@iprimus.com.au>.
>
> If I'm correct both Apache::PerlRun and Apache::Registry will have
> problems in certain situations if we agree that ModPerl::Registry has
> the correct logic for handling the execution status. If you can tell
> otherwise please give me a test script that doesn't work under
> ModPerl::Registry.
>
> But in your particular example, Dick, if you configure the
I'm presuming that you simply mixed up which is my first name and
surname? :) Usually dave is fine. :)
>
> script to run under Apache::RegistryNG, does it work?
No.
> If not, that's where the difference between 1.0 and 2.0 lays:
> ModPerl::Registry doesn't reset status if it wasn't changed by the
> script.
well the ModPerl::Registry behaviour certainly suits my program. :)
Uru
-dave
Re: Possible bug with a 206 Partial Response
Posted by Stas Bekman <st...@stason.org>.
David Dick wrote:
> alrightly, back again. The problem is that Apache::Registry will return
> a 206, which will trigger the error message. In case there is anyone
> out there as daft as me :), the crude delegation-type module below can
> solve this problem. Maniacs who see a need to return 204's, etc can
> probably extend this to a more general solution. :)
>
> package MyPrefix::Apache::Registry;
> use strict;
>
> BEGIN {
> use Apache::Registry();
> use Apache::Constants qw(:common);
> use constant PARTIAL_CONTENT => 206;
> }
>
> sub handler {
> my ($return) = Apache::Registry::handler(@_);
> if ($return == PARTIAL_CONTENT) {
> return OK;
> } else {
> return ($return);
> }
> }
>
> END { }
>
> 1;
When I've tried to run your test script under ModPerl::Registry
(mp2.0) I was surprised to learn that it worked just fine. So far I
was fixing the porting bugs ;) I've added your test script to the
ModPerl::Registry test suite.
We better fix it in the 1.0 core. But before that we need to be clear of how
the return codes should be handled, because the currect three implementations
all diverge when it comes to handling the return codes/execution status.
In order to simplify the logic, assuming that the script was
successfully executed and inlining some code, the 3 different registry
implementations resemble the following:
Apache::Registry does:
my $old_status = $r->status;
eval { &{$cv}($r, @_) };
return $r->status($old_status);
Apache::PerlRun/RegistryNG do:
my $old_status = $r->status;
eval { &{$cv}($r, @_) };
$r->status($old_status);
return OK;
ModPerl::RegistryCooker does:
# handlers shouldn't set $r->status but return it
my $old_status = $self->[REQ]->status;
eval { &{$cv}($r, @_) };
my $new_status = $self->[REQ]->status;
# only if the script has changed the status, reset to the old
# status and return the new status
return $old_status != $new_status
? $self->[REQ]->status($old_status)
: OK;
If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.
But in your particular example, Dick, if you configure the
script to run under Apache::RegistryNG, does it work? If not, that's where the
difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if
it wasn't changed by the script.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Possible bug with a 206 Partial Response
Posted by David Dick <da...@iprimus.com.au>.
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT => 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
Uru
-Dave
Ged Haywood wrote:
>Hi again,
>
>On Mon, 3 Feb 2003, David Dick wrote:
>
>
>
>>not even getting a broken connection. So somehow mod_perl doesn't
>>_really_ think it's an error.
>>
>>
>
>Check out DEBUGGING in 'perldoc Apache::Registry'.
>
>Apache::Registry won't always return what you'd think it should.
>This has snookered more than one in the past...
>
>73,
>Ged.
>
>
>
>
Re: Possible bug with a 206 Partial Response
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi again,
On Mon, 3 Feb 2003, David Dick wrote:
> not even getting a broken connection. So somehow mod_perl doesn't
> _really_ think it's an error.
Check out DEBUGGING in 'perldoc Apache::Registry'.
Apache::Registry won't always return what you'd think it should.
This has snookered more than one in the past...
73,
Ged.
Re: Possible bug with a 206 Partial Response
Posted by David Dick <da...@iprimus.com.au>.
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Ged Haywood wrote:
>Hi there,
>
>On Sun, 2 Feb 2003, David Dick wrote:
>
>
>
>>Forgot to mention that the error log is completely empty. :)
>>
>>
>
>Are you getting core dumps?
>
>73,
>Ged.
>
>
>
>
Re: Possible bug with a 206 Partial Response
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
> Forgot to mention that the error log is completely empty. :)
Are you getting core dumps?
73,
Ged.
Re: Possible bug with a 206 Partial Response
Posted by David Dick <da...@iprimus.com.au>.
Good Point. Forgot to mention that the error log is completely empty. :)
Ged Haywood wrote:
>Hi there,
>
>On Sun, 2 Feb 2003, David Dick wrote:
>
>
>
>>Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
>>type script.
>>
>>
>[snip]
>
>
>>More information about this error may be available
>>in the server error log.<P>
>>
>>
>[snip]
>
>
>>Anyone got any ideas?
>>
>>
>
>What does it say in the error_log?
>
>73,
>Ged.
>
>
>
>
Re: Possible bug with a 206 Partial Response
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Sun, 2 Feb 2003, David Dick wrote:
> Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
> type script.
[snip]
> More information about this error may be available
> in the server error log.<P>
[snip]
> Anyone got any ideas?
What does it say in the error_log?
73,
Ged.