Tested on:
$Net::SSL::VERSION: 2.77 ($Crypt::SSLeay::VERSION: 0.51)
Test case:
################################################################
#!perl
use Net::SSL;
$hash_ref = { 'foo' => 'bar' };
mysub($hash_ref);
sub mysub {
my $hr = shift;
$ENV{'HTTPS_PROXY'} = 'localhost:8080';
$sock = Net::SSL->new(
PeerAddr => 'www.microsoft.com',
PeerPort => 443,
Timeout => 10
);
}
################################################################
This dies with error:
proxy connect failed: Can't call method "isa" on unblessed reference at
...\Net\SSL.pm line 320.
The problem stems from get_lwp_object() running isa() on the first
parameter of every function call on the stack. In this case, it is
running isa() on the parameter to mysub(). Since that parameter is an
unblessed hash reference, isa() dies with the above error.
I can think of a few ways to fix this. The easiest is probably to wrap
the isa() in an eval{}. Another is to check to see if the parameter is
an unblessed reference (HASH, ARRAY, SCALAR, etc.) and shortcut out
before running isa() (you'd have to know the full list of possible
unblessed reference types and hard-code them in for this to work, and it
might not be future-proof if a new native type is added to Perl). Also,
I haven't traced the use of Net::SSL in relation to LWP, but if the
execution path always has LWP calling Net::SSL (and Net::SSL is then
trying to backtrack up the stack and find the LWP object), then perhaps
you can limit the checks in get_lwp_object() to only happen if the
package namespace for the caller is 'LWP'.
Also, the currently implemented behavior could lead to problems, if for
some reason the calling application happens to pass an unrelated LWP
object somewhere up the call stack. The current get_lwp_object() will
traverse up the entire stack and grab any LWP object encountered,
whether or not it has any context or bearing to the actual call to
Net::SSL down the road. Imagine someone implementing a conversion
function which converts/extracts an LWP object to a set of data values,
changes some of the values, and then calls Net::SSL with those new
values. Net::SSL will traverse up through the call stack, past the
conversion function, and slurp values out of the original LWP object
prior to conversion.
And of all this is merely to be able to send a User-Agent string to the
*proxy* server (not the web server itself), which is a very minor
functional benefit. The potential and actual ramifications seem to
outweigh the minimal benefit, IMHO.
Thanks,
- J
David Landgren via RT wrote:
Show quoted text> <URL:
http://rt.cpan.org/Ticket/Display.html?id=4759 >
>
> On Fri Dec 26 19:35:14 2003, guest wrote:
>> When Net::SSL is used with a proxy, proxy_connect_helper() calls
>> get_lwp_object(). Get_lwp_object() traverses up the call stack and
>> runs isa() on every 1st function argument reference. It is
>> traversing very far up into my program, which passes unblessed
>> anonymous hashes in some places as function parameters...and isa()
>> causes an immediate abort since the anonymous hashes are unblessed.
>>
>> So either the isa() needs to be wrapped in an eval{}, or the program
>> has to be a little more courteous as to how far it's going to trace
>> back in order to not puke on perfectly-acceptable function
>> parameters used within the calling app.
>
> Hello,
>
> I am the new maintainer for Crypt-SSLeay. Is this problem still an
> issue? Can you produce a small test case? Ideally something I can add to
> the test suite to make sure the module is behaving according to spec?
>
> Thanks,
> David
>
