Peter,

The situation may not be as grim as it looks. You can leave the existing
RedHat 7.3 curl in place and simply compile up the latest and greatest curl,
and place it under /usr/local (or somewhere):

    ./configure --prefix=/usr/local/curl-7.10.4
    make
    make install

then recompile PHP in a similar fashion, pointing to the updated curl:

    cd ../php4.3.1
    ./configure --with-curl=/usr/local/curl-7.10.4 ...[other options]...

I have a server running two different versions of Apache, each with their own
copies of php, curl, openssl, mysql, etc. This allows me to leave a
"production" system alone while checking out new versions of various things.

If you're using curl in scripts or off the command line, you'd need to make
sure your $PATH contains the new curl directory *before* the regular system
directories. I just have /usr/local/curl in my PATH and symbolic-link that
to the latest version of curl.

Presumably you're upgrading PHP & MySQL as well, to avoid the recent
exploits?

Ralph Mitchell

curl-users wrote:

> I know, this is an older release, but it comes bundled with the Redhat 7.3
> release, and upgrading it seems rather dangerous, considering all the
> dependencies involved. It's just to early for me to upgrade to Redhat 8
> with Apache 2.0 and all, I want to have a stable server.
>
> In my setup, curl is used in a PHP application that acts as a "connector"
> between outside HTTP GET and POST requests, it links them through to the
> databases behind the firewall (and does some other stuff not relevant
> here).
> The project is almost ready, and I'm doing some test runs with different
> site setups. The problem I'm bumping into:
>
> A bigger POST request is received only partially at the receiver side.
> Only approx. 320 bytes of the POSTed data arrive. Here's part of my code:
> $postData = ArrayToPostString($_POST); // urlencoding the POSTed data
> curl_setopt ($ch, CURLOPT_POSTFIELDS, $postData); // this part is
> truncated to some 320 bytes when received on the other end
>
> I did a test setup with a Redhat 8 server with the latest and greatest
> curl available in that distribution, and the same code runs fine.
> Therefore I presume this could be a bug in the curl 7.9.5 release.
>
> My question: can somebody help here? Curl 7.9.5 is available as a source
> RPM release, so it is probable that a curl guru can pinpoint the problem.
> If I could simply re-compile the fixed source code, it would save me from
> a complete upgrade of the server. I'd rather program a socket based
> work-around in PHP to get the bigger POSTs right, than to upgrade my
> server.
>
> Thanks for any help offered!
> -- Peter

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
Received on 2003-04-08