perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <>
Subject Re: cvs commit: modperl-2.0/src/modules/perl modperl_callback.c
Date Tue, 07 Oct 2003 19:39:41 GMT

Stas Bekman wrote:
> Geoffrey Young wrote:
>> 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.

ok, I'll take it out.

> 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.

I'd rather not do any guessing.  if it comes up, we can examine the issue 
and decide who is at fault (the EU or the codebase).

> 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.

the issue here isn't related to the new hook, but rather my use of setting 
the return status based on $r->args - I think $port was getting assigned the 
PV value and mod_perl isn't getting the associated IV.  int() was just my 

but yes, it's somewhat of a real issue (though apparently not, if nobody has 
reported it yet).

I'll do some investigation and see it I can't fix it for everyone.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message