On Wed, 15 Oct 2003, Aaron Greenspan wrote:

[since this mail concerns PHP/CURL, I'm also CC'ing my reply to the
curl-and-php mailing list, perhaps someone there recognizes the problem or
have other clues to offer]

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

If you wrote PHP code, you shouldn't be able to crash Apache. I'd say it
indicates a bug in one of these products: PHP, PHP/CURL (the binding, which is
a part of PHP) or libcurl.

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

Perhaps you have two installed OpenSSL versions now? It sure sounds as if
configure found some kind of mix until you used --with-ssl=/usr/local/ssl...

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

This is of course not acceptable, and there's nothing in libcurl that can
sensibly explain any such timeouts. What if you use the command line tool
curl, does the same timeouts occur?

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

Did you try to check the network with a network analyzer/snooper to see what's
going on on the wire then this idling is going on?

> 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've not seen any (other) recent reports on problems like this or even
remotely similar to this...

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

Right, since SSL is required for curl to be able to do HTTPS.

> It appears that the latest builds of cURL are now incompatible with
> Authorize.Net at the very least.

I tried this little command line:

        curl https://secure.authorize.net/gateway/transact.dll

... with a very recent curl, and it sure returned contents fine.

-- 
 Daniel Stenberg -- curl: been grokking URLs since 1998
-------------------------------------------------------
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