this was committed separately, as it's not really part of the PerlDefaultPortHandler implementation.
open for discussion, though, is whether we want to keep or remove this kind of logic from modperl_callback.
as I think about it more, I'm kinda against second-guessing handlers here - we ought to assume they return what they mean to return. this will be especially true in protocol handlers, where in order to return status codes over 600 (which the protocol may very well have) we would need to duplicate Perl callback logic.
as the test suite passes, and I can't think of a good reason why returning 2 or 914 from a handler ought to really mean OK, I think it is safe to remove it without causing too much trouble. if somebody complains, we can evaluate whether what they are doing is legitimate, or whether the EU needs to change their approach.
in fact, I'm actually in favor of removing HTTP_OK logic too in order to make things completely protocol-independent (and reusable for all Perl callbacks) - people shouldn't be returning HTTP_OK from their handler and thinking it is equivalent to OK.
+1 on removing second guessing for the generic callback.
However we could have special handling for return codes based on the callback type, so if it's one of the HTTP callbacks we may want to do some special handling. Granted any guessing proves to bite us somewhere in the long run, the only reason for not removing it would be breaking someone's mp1 code. But I guess that's fine as we move to mp2, as long as it's easy to fix for them.
As I pointed out in private email, this is definitely not something we want to leave exposed:
+sub handler {
+ my $r = shift;
+
+ my $port = $r->args || Apache::OK;
+
+ return int $port;
+}so the callback mechanism could do the fixing of the return value knowing that it's a default port callback, without introducing potential errors and confusion in user's code.
__________________________________________________________________ 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]
