I'm struggling with the very vexing problem of having a snippet of code that works fine when invoked in a stand-alone process but does not work within the context of a mod_perl handler. Said snippet invokes an https request with LWP::UserAgent (using an HTTP::Request), and has $ENV{HTTPS_CA_FILE} set to a CA bundle file to trigger server certificate validation. In the stand-alone program I get back a response code from LWP::UserAgent of 200 if the cert was validated and 500 if it was not. In the mod_perl handler the code always returns 200, apparently never bothering with the CA bundle at all. I verified this by using strace. The stand-alone program opens the bundle but the mod_perl handler does not. Additionally strace shows the mod_perl handler successfully opening SSLeay.pm and SSLeay.so.
Even more interesting is that if I invoke the program version of the code via backticks from the mod_perl handler it works, so it can't possibly be a permissions issue within the web server. The only thing I can fathom is that somehow the Perl I'm getting for a stand-alone process is in some subtle way different from the Perl for which mod_perl was built, but both report 5.8.0 as their version. I've tried every sanity check and comparison my poor brain can muster, but I'm totally stumped and ready to surrender.
What could possibly be causing an identical code snippet to behave differently in these two contexts? I've printed out %ENV and it is as I expect. Could there be a binary incompabibility somewhere? A different library path configuration? I have never been more perplexed.
In reply to A tale of LWP::UserAgent, Crypt::SSLeay and mod_perl by skyknight
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |