You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2003/11/22 17:55:47 UTC
[mp2] Apache::OK vs 200
I've noticed the following with the current cvs build of
mod_perl 2, under Win32 ActivePerl 807 and Apache/2.0.48,
and was wondering if I'm not understanding something. I
first noticed it with Apache::ASP, but the following handler
also illustrates it:
===========================================================
package Apache::Hello;
use strict;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile => ':common';
sub handler {
my $r = shift;
my $time = scalar localtime();
my $package = __PACKAGE__;
$r->content_type('text/html');
$r->print(<<"END");
<HTML><BODY>
<H3>Hello</H3>
Hello from <B>$package</B>! The time is $time.
</BODY></HTML>
END
return 200;
}
1;
==============================================================
configured with
==============================================================
PerlModule Apache::Hello
<Location /hello>
SetHandler modperl
PerlResponseHandler Apache::Hello
</Location>
==============================================================
With this, a request for http://localhost/hello results in
the browser
=============================================================
Hello
Hello from Apache::Hello! The time is ....
OK
The server encountered an internal error ....
=================================================================
although nothing is reported in the error log, and the
status in the access log is reported as 200. The problem
arises from returning '200' from Apache::Hello; changing
return 200;
to
return Apache::OK;
fixes things.
Is there something wrong in principle with returning an
explicit status of, eg, 200, rather than using the Apache::*
constants?
--
best regards,
randy kobes
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Stas Bekman <st...@stason.org>.
I've documented the mod_perl 2.0 handler return value "protocol" here:
http://perl.apache.org/docs/2.0/user/handlers/intro.html#Handler_Return_Values
Please read and submit patches if something is wrong/unclear. Muchas Gracias.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Apache::OK vs 200
Posted by Stas Bekman <st...@stason.org>.
I've documented the mod_perl 2.0 handler return value "protocol" here:
http://perl.apache.org/docs/2.0/user/handlers/intro.html#Handler_Return_Values
Please read and submit patches if something is wrong/unclear. Muchas Gracias.
__________________________________________________________________
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
>> And if you return Apache::HTTP_OK, in response handler it's
>> essentially an error too. If people feel really strong about it, we
>> can put back the special case for Apache::HTTP_OK. Though if you think
>> about it, it makes your life much simpler is you remember that all you
>> have to return in OK or DECLINED to continue and anything else will
>> abort the normal loop. I hope you will agree with me.
>
>
> for the record, this is exactly how apache behaves for people writing C
> modules - it expects a handler to return OK, DECLINED, DONE, or
> _some_http_status_all_of_which_mean_"error"
>
> so, I'd rather not go back to 200 == OK.
+1
> not only does this make
> writing handlers in perl different than C, but is also creates a problem
> for people who use mod_perl to drive protocols other than HTTP, where
> 200 might well mean something entirely different.
Not really. If you implement a different protocol it's a totally different
story. Apache won't make sense of anything that you return from
PerlConnectionHandler, but OK/DECLINED. Here is the whole protocol driving
function from httpd-2.0/server/connection.c
AP_CORE_DECLARE(void) ap_process_connection(conn_rec *c, void *csd)
{
int rc;
ap_update_vhost_given_ip(c);
rc = ap_run_pre_connection(c, csd);
if (rc != OK && rc != DONE) {
c->aborted = 1;
}
if (!c->aborted) {
ap_run_process_connection(c);
}
}
So as you can see Apache simply ignores any return codes besides OK/DECLINED,
which are hidden in ap_run_process_connection(c);
__________________________________________________________________
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
>> And if you return Apache::HTTP_OK, in response handler it's
>> essentially an error too. If people feel really strong about it, we
>> can put back the special case for Apache::HTTP_OK. Though if you think
>> about it, it makes your life much simpler is you remember that all you
>> have to return in OK or DECLINED to continue and anything else will
>> abort the normal loop. I hope you will agree with me.
>
>
> for the record, this is exactly how apache behaves for people writing C
> modules - it expects a handler to return OK, DECLINED, DONE, or
> _some_http_status_all_of_which_mean_"error"
>
> so, I'd rather not go back to 200 == OK.
+1
> not only does this make
> writing handlers in perl different than C, but is also creates a problem
> for people who use mod_perl to drive protocols other than HTTP, where
> 200 might well mean something entirely different.
Not really. If you implement a different protocol it's a totally different
story. Apache won't make sense of anything that you return from
PerlConnectionHandler, but OK/DECLINED. Here is the whole protocol driving
function from httpd-2.0/server/connection.c
AP_CORE_DECLARE(void) ap_process_connection(conn_rec *c, void *csd)
{
int rc;
ap_update_vhost_given_ip(c);
rc = ap_run_pre_connection(c, csd);
if (rc != OK && rc != DONE) {
c->aborted = 1;
}
if (!c->aborted) {
ap_run_process_connection(c);
}
}
So as you can see Apache simply ignores any return codes besides OK/DECLINED,
which are hidden in ap_run_process_connection(c);
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Apache::OK vs 200
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> for the record, this is exactly how apache behaves for people writing
> C modules
> - it expects a handler to return OK, DECLINED, DONE, or
> _some_http_status_all_of_which_mean_"error"
>
> so, I'd rather not go back to 200 == OK. not only does this make writing
> handlers in perl different than C, but is also creates a problem for
> people who use mod_perl to drive protocols other than HTTP, where 200
> might well mean something entirely different.
+1.
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> And if you return Apache::HTTP_OK, in response handler it's essentially
> an error too. If people feel really strong about it, we can put back the
> special case for Apache::HTTP_OK. Though if you think about it, it makes
> your life much simpler is you remember that all you have to return in OK
> or DECLINED to continue and anything else will abort the normal loop. I
> hope you will agree with me.
for the record, this is exactly how apache behaves for people writing C
modules - it expects a handler to return OK, DECLINED, DONE, or
_some_http_status_all_of_which_mean_"error"
so, I'd rather not go back to 200 == OK. not only does this make writing
handlers in perl different than C, but is also creates a problem for people
who use mod_perl to drive protocols other than HTTP, where 200 might well
mean something entirely different.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> And if you return Apache::HTTP_OK, in response handler it's essentially
> an error too. If people feel really strong about it, we can put back the
> special case for Apache::HTTP_OK. Though if you think about it, it makes
> your life much simpler is you remember that all you have to return in OK
> or DECLINED to continue and anything else will abort the normal loop. I
> hope you will agree with me.
for the record, this is exactly how apache behaves for people writing C
modules - it expects a handler to return OK, DECLINED, DONE, or
_some_http_status_all_of_which_mean_"error"
so, I'd rather not go back to 200 == OK. not only does this make writing
handlers in perl different than C, but is also creates a problem for people
who use mod_perl to drive protocols other than HTTP, where 200 might well
mean something entirely different.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Apache::OK vs 200
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi Stas,
On Sat, 22 Nov 2003, Stas Bekman wrote:
> [snip]
> so only when a handler returns OK or DECLINED will the request loop continue
> [snip]
> if you think about it, it makes your life much simpler is you remember
> that all you have to return in OK or DECLINED to continue and anything
> else will abort the normal loop. I hope you will agree with me.
I agree strongly with that.
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi Stas,
On Sat, 22 Nov 2003, Stas Bekman wrote:
> [snip]
> so only when a handler returns OK or DECLINED will the request loop continue
> [snip]
> if you think about it, it makes your life much simpler is you remember
> that all you have to return in OK or DECLINED to continue and anything
> else will abort the normal loop. I hope you will agree with me.
I agree strongly with that.
73,
Ged.
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Apache::OK vs 200
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Sat, 2003-11-22 at 11:55, Randy Kobes wrote:
>
>>Is there something wrong in principle with returning an
>>explicit status of, eg, 200, rather than using the Apache::*
>>constants?
>
>
> As I understand it, they are two different things. The Apache constants
> are for telling apache what's going on and do not necessarily correspond
> to values in HTTP.
Not so much about the constants (since you can use just numbers), but about
the values expected to be returned from the handler.
In order to support stacked handlers Apache expects a handler to return one of
the special Apache::OK, Apache::DECLINED, Apache::DONE or an HTTP_ code (or
its alias, e.g SERVER_ERROR instead of HTTP_INTERNAL_SERVER_ERROR). The first
two codes ensure the continuation of the request loop, all the rest abort it.
http://perl.apache.org/docs/2.0/user/handlers/http.html#HTTP_Request_Cycle_Phases
We used to have special handling of return codes to guess what the user may
have meant, but recently decided to drop any second guessing and always return
to Apache whatever the handler has returned. Therefore earlier we were always
doing status =~ s/200/0/, now we don't.
Handlers should always return one of the above three codes when everything is
OK, returning any other code is an error to Apache, because it'll break the
request loop. The internal Apache logic goes as:
if (status = phase1()) { // e.g. header_parser
return status;
}
if (status = phase2()) { // e.g. trans
return status;
}
...
if (status = phaseN()) { // e.g. fixup
return status;
}
so only when a handler returns OK or DECLINED will the request loop continue
(see the URL above). Any other return code will break the flow at the current
phase and no other phase will be executed (besides logging and cleanup phases
which always get executed). So for example if you return Apache::DONE at the
header_parser phase, no other phases will be executed.
And if you return Apache::HTTP_OK, in response handler it's essentially an
error too. If people feel really strong about it, we can put back the special
case for Apache::HTTP_OK. Though if you think about it, it makes your life
much simpler is you remember that all you have to return in OK or DECLINED to
continue and anything else will abort the normal loop. I hope you will agree
with me.
__________________________________________________________________
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
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Apache::OK vs 200
Posted by Stas Bekman <st...@stason.org>.
Perrin Harkins wrote:
> On Sat, 2003-11-22 at 11:55, Randy Kobes wrote:
>
>>Is there something wrong in principle with returning an
>>explicit status of, eg, 200, rather than using the Apache::*
>>constants?
>
>
> As I understand it, they are two different things. The Apache constants
> are for telling apache what's going on and do not necessarily correspond
> to values in HTTP.
Not so much about the constants (since you can use just numbers), but about
the values expected to be returned from the handler.
In order to support stacked handlers Apache expects a handler to return one of
the special Apache::OK, Apache::DECLINED, Apache::DONE or an HTTP_ code (or
its alias, e.g SERVER_ERROR instead of HTTP_INTERNAL_SERVER_ERROR). The first
two codes ensure the continuation of the request loop, all the rest abort it.
http://perl.apache.org/docs/2.0/user/handlers/http.html#HTTP_Request_Cycle_Phases
We used to have special handling of return codes to guess what the user may
have meant, but recently decided to drop any second guessing and always return
to Apache whatever the handler has returned. Therefore earlier we were always
doing status =~ s/200/0/, now we don't.
Handlers should always return one of the above three codes when everything is
OK, returning any other code is an error to Apache, because it'll break the
request loop. The internal Apache logic goes as:
if (status = phase1()) { // e.g. header_parser
return status;
}
if (status = phase2()) { // e.g. trans
return status;
}
...
if (status = phaseN()) { // e.g. fixup
return status;
}
so only when a handler returns OK or DECLINED will the request loop continue
(see the URL above). Any other return code will break the flow at the current
phase and no other phase will be executed (besides logging and cleanup phases
which always get executed). So for example if you return Apache::DONE at the
header_parser phase, no other phases will be executed.
And if you return Apache::HTTP_OK, in response handler it's essentially an
error too. If people feel really strong about it, we can put back the special
case for Apache::HTTP_OK. Though if you think about it, it makes your life
much simpler is you remember that all you have to return in OK or DECLINED to
continue and anything else will abort the normal loop. I hope you will agree
with me.
__________________________________________________________________
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Perrin Harkins <pe...@elem.com>.
On Sat, 2003-11-22 at 11:55, Randy Kobes wrote:
> Is there something wrong in principle with returning an
> explicit status of, eg, 200, rather than using the Apache::*
> constants?
As I understand it, they are two different things. The Apache constants
are for telling apache what's going on and do not necessarily correspond
to values in HTTP.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> It seemed that early in mod_perl use,
> the return codes would be the literal status codes, like 500 for
> server error, 302 for redirect and 200 for success. This is
> then very different in mod_perl 2, and hopefully I can implement
> this is some rational way so that Apache::ASP can still do something
> correct with $Response->{Status} across mod_perl 1 + 2.
302, 500, and all the other HTTP_* error codes still behave the same way.
what is different is that HTTP_OK (200) is no longer treated as OK (0).
other values that were altered to read as OK were returns < 100 and > 600,
but those probably don't matter. 200 is probably the only value you need to
worry about intercepting.
the bottom line is that request-time handlers need to return OK, DECLINED,
or DONE. all other responses (including 200) are treated as "errors" by
apache. this behavior, while new to mod_perl, is exactly the same as apache
itself, in both 1.3 and 2.0 - the change is that where mod_perl used to
second guess a handler's intent (by changing odd return codes to OK) it no
longer does so.
HTH
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Josh Chamas <jo...@chamas.com>.
> although nothing is reported in the error log, and the
> status in the access log is reported as 200. The problem
> arises from returning '200' from Apache::Hello; changing
> return 200;
> to
> return Apache::OK;
> fixes things.
>
> Is there something wrong in principle with returning an
> explicit status of, eg, 200, rather than using the Apache::*
> constants?
>
Thanks for starting this thread Randy & figuring out what the
problem was. I have been swamped this past month, and have been
unable to look into this much, but as I understand it, using the
standard Apache constants is a fix here.
Having looked into this some already, it seems that the Apache handler
model in mod_perl has changed some with respect to the return codes
that a handler provides. It seemed that early in mod_perl use,
the return codes would be the literal status codes, like 500 for
server error, 302 for redirect and 200 for success. This is
then very different in mod_perl 2, and hopefully I can implement
this is some rational way so that Apache::ASP can still do something
correct with $Response->{Status} across mod_perl 1 + 2.
Thanks again, and I expect to have this problem resolved in the
next release of Apache::ASP, release date TBD. Unfortunately, this
"fix" seems rather involved, so I am not sure when this release date
will be.
Regards,
Josh
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] Apache::OK vs 200
Posted by Perrin Harkins <pe...@elem.com>.
On Sat, 2003-11-22 at 11:55, Randy Kobes wrote:
> Is there something wrong in principle with returning an
> explicit status of, eg, 200, rather than using the Apache::*
> constants?
As I understand it, they are two different things. The Apache constants
are for telling apache what's going on and do not necessarily correspond
to values in HTTP.
- Perrin
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [mp2] Apache::OK vs 200
Posted by Josh Chamas <jo...@chamas.com>.
> although nothing is reported in the error log, and the
> status in the access log is reported as 200. The problem
> arises from returning '200' from Apache::Hello; changing
> return 200;
> to
> return Apache::OK;
> fixes things.
>
> Is there something wrong in principle with returning an
> explicit status of, eg, 200, rather than using the Apache::*
> constants?
>
Thanks for starting this thread Randy & figuring out what the
problem was. I have been swamped this past month, and have been
unable to look into this much, but as I understand it, using the
standard Apache constants is a fix here.
Having looked into this some already, it seems that the Apache handler
model in mod_perl has changed some with respect to the return codes
that a handler provides. It seemed that early in mod_perl use,
the return codes would be the literal status codes, like 500 for
server error, 302 for redirect and 200 for success. This is
then very different in mod_perl 2, and hopefully I can implement
this is some rational way so that Apache::ASP can still do something
correct with $Response->{Status} across mod_perl 1 + 2.
Thanks again, and I expect to have this problem resolved in the
next release of Apache::ASP, release date TBD. Unfortunately, this
"fix" seems rather involved, so I am not sure when this release date
will be.
Regards,
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org