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:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
