cURL / Mailing Lists / curl-users / Single Mail

curl-users

cURL PHP/SSL Weirdness?

From: Aaron Greenspan <aarong_at_thinkcomputer.com>
Date: Wed, 15 Oct 2003 17:07:54 -0400

Hi,

I've been using cURL 7.10.3 for awhile with my homemade shopping cart,
and it's worked relatively well with one notable exception: PHP crashes
on a fairly frequent basis (i.e. "segmentation fault (11)" in the Apache
error log). My thinking was that it could be my code, or it could be
cURL, so I wanted to find out.

My shopping cart verifys credit cards through Authorize.Net using an
HTTPS POST request. I built cURL 7.10.3 from source using the plain
"./configure" command with no options, and it seemed to worked fine, if
you ignored the crashing. When I tried upgrading to cURL 7.10.7, I
realized it wouldn't work with an HTTPS POST request unless I downloaded
and compiled OpenSSL, which I did. I used the latest stable version
available, which right now I believe to be 0.9.7c. When I used the
"./configure" command or "./configure --with-ssl," I would always get
errors about two missing symbols, both starting with RAND. When I used
"./configure --with-ssl=/usr/local/ssl," even though I thought
/usr/local/ssl was the default, the symbol errors finally went away.
After running "make" and "make install," I restarted Apache and tested
my shopping cart.

The end result was that every time I would try an HTTPS POST request,
PHP would run until it timed out. I upped the timeout setting to 90
seconds from 30, to no avail. When I set the CURLOPT_VERBOSE option, I
would see cURL making the secure connection to port 443 in the Apache
error log, but it would just sit there until I hit reload in my web
browser, or until its own connection timeout kicked in. I tried going
through the whole installation process with an earlier version of cURL,
7.10.5, and ran into the exact same problem. I tried compiling 7.10.7
again using the "./configure --without-ssl" command, but then it
wouldn't even try to use HTTPS POST at all.

It appears that the latest builds of cURL are now incompatible with
Authorize.Net at the very least. I'm using a Cobalt RaQ 3i as my
platform, so I'm not sure how much that makes a difference, but I know
for a fact that it worked before... Based on mailing list threads I
searched on Google, it appears that others might be having this problem,
but may have been brushed aside.

If you have any suggestions, I'd be interested to hear them. Aside from
this, cURL has been great.

Thanks,

Aaron

Aaron Greenspan
President & CEO
Think Computer Corporation

http://www.thinkcomputer.com

--------------040103070307010003030001--

--h9FLAPB05670.1066252225/us20.unix.fas.harvard.edu--

--------------060009030802080401050206--
ReSent-Date: Thu, 16 Oct 2003 08:05:14 +0200 (CEST)
ReSent-From: Daniel Stenberg <dast_at_contactor.se>
ReSent-To: Curl Mailinglist <curl-users_at_lists.sourceforge.net>
ReSent-Subject: cURL PHP/SSL Weirdness?
ReSent-Message-ID: <Pine.LNX.4.58.0310160805140.26459_at_linux3.contactor.se>

Hi,

I've been using cURL 7.10.3 for awhile with my homemade shopping cart,
and it's worked relatively well with one notable exception: PHP crashes
on a fairly frequent basis (i.e. "segmentation fault (11)" in the Apache
error log). My thinking was that it could be my code, or it could be
cURL, so I wanted to find out.

My shopping cart verifys credit cards through Authorize.Net using an
HTTPS POST request. I built cURL 7.10.3 from source using the plain
"./configure" command with no options, and it seemed to worked fine, if
you ignored the crashing. When I tried upgrading to cURL 7.10.7, I
realized it wouldn't work with an HTTPS POST request unless I downloaded
and compiled OpenSSL, which I did. I used the latest stable version
available, which right now I believe to be 0.9.7c. When I used the
"./configure" command or "./configure --with-ssl," I would always get
errors about two missing symbols, both starting with RAND. When I used
"./configure --with-ssl=/usr/local/ssl," even though I thought
/usr/local/ssl was the default, the symbol errors finally went away.
After running "make" and "make install," I restarted Apache and tested
my shopping cart.

The end result was that every time I would try an HTTPS POST request,
PHP would run until it timed out. I upped the timeout setting to 90
seconds from 30, to no avail. When I set the CURLOPT_VERBOSE option, I
would see cURL making the secure connection to port 443 in the Apache
error log, but it would just sit there until I hit reload in my web
browser, or until its own connection timeout kicked in. I tried going
through the whole installation process with an earlier version of cURL,
7.10.5, and ran into the exact same problem. I tried compiling 7.10.7
again using the "./configure --without-ssl" command, but then it
wouldn't even try to use HTTPS POST at all.

It appears that the latest builds of cURL are now incompatible with
Authorize.Net at the very least. I'm using a Cobalt RaQ 3i as my
platform, so I'm not sure how much that makes a difference, but I know
for a fact that it worked before... Based on mailing list threads I
searched on Google, it appears that others might be having this problem,
but may have been brushed aside.

If you have any suggestions, I'd be interested to hear them. Aside from
this, cURL has been great.

Thanks,

Aaron

Aaron Greenspan
President & CEO
Think Computer Corporation

http://www.thinkcomputer.com

--------------040103070307010003030001--

--h9FLAPB05670.1066252225/us20.unix.fas.harvard.edu--

--------------060009030802080401050206--

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
Received on 2003-10-16