You might want to just keep the new curl under /usr/local and leave
the old version where it is. Rebuild anything else you want new
versions of, such as openssl, and drop them into /usr/local as well.

I believe the change from .2 to .3 reflects a fairly major alteration
in the library, so all those dependancies you don't want to update may
break. As it is, those things obviously are working properly at the
moment, so why not leave them alone??

I have a working Redhat 7.2 system with multiple versions of curl,
openssl & apache, each in their own subdirectory under /usr/local. It
grew up too fast to test all the older scripts with newer versions, so
I just kept the old versions available. I think the oldest curl I'm
using is 7.9.3, and it still works fine in the scripts that were
written for it. I'm gradually dragging that system out of the dark
ages, though... :) I have no idea what the actual system version of
curl is, but it could probably legally buy alcohol.

Ralph

On 5/2/05, man_at_tfhs.net <man_at_tfhs.net> wrote:
> yes, i have just compiled 7.13.2 into /usr/local, and linked my app
> against it. Multi-part post now works thru default squid proxy, thanks! I
> have yet to test proxyauth stuff, however.
>
> i was using the version that came with FC2 before, So now i think i will
> try to make an rpm of 7.13.2 that will drop-in replace the old one, since
> the rpms listed on the downloads page require too many dependency upgrades
> for me...
>
> i notice that the 7.11.1 was libcurl.so.2, and 7.13.2 is libcurl.so.3.
> will it be ok to symlink the .2 to the new libcurl, or should i attempt to
> maintain the old lib for compatability?
>
> thanks!
>
> allan
>
> On Mon, May 2, 2005, Ralph Mitchell <ralphmitchell_at_gmail.com> said:
>
> > First off, would it be possible for you to update to the latest
> > version, which is 7.13.2?? The one you're using dates back to March
> > 2004. Source is here:
> >
> > http://curl.haxx.se/download.html
> >
> > The ChangeLog (linked in the Related box, top right of the above page)
> > shows a lot of changes. You may be tripping a bug that's already been
> > fixed.
> >
> > Ralph Mitchell
> >
> >
> > On 5/2/05, man_at_tfhs.net <man_at_tfhs.net> wrote:
> >> first, thanks for libcurl. i had been beating my head against libwww for a
> >> couple weeks, when i found libcurl. much easier to use, and it actually
> >> seems to work :)
> >>
> >> now, my problem:
> >>
> >> C app that multipart posts a memory buffer as if it were a file upload,
> >> along with a couple short (<20 chars) textual variables. i have installed
> >> a call-back for libcurl to write to, and i can post and receive the
> >> response into memory just fine. all is well, until i try to pass thru a
> >> squid proxy.
> >>
> >> the setup: the posting app (using libcurl 7.11.1) and the http server
> >> (apache 2.0.x/modperl 1.99.x) are both on my desktop machine. the squid
> >> proxy is another machine on the same subnet. if i use mozilla from the
> >> app/server machine to post the same data to the same url as my app, it
> >> works. if i use libcurl in my app, it times out.
> >>
> >> i take tcpdump on the proxy, for all packets from the app/server machine.
> >> what i see is:
> >>
> >> ******* working mozilla **************
> >> mozilla sends http headers and post contents to proxy in 4 sequential
> >> packets. (squid ACK after each). the http headers are split across the
> >> first two packets. it does not use the Expect: header. it is an http 1.1
> >> post.
> >>
> >> then, squid opens a connection back to port 80, and sends the request in
> >> three packets quickly, the 3 ACKs appear to come back from apache after
> >> the last. the headers are all in the first packet, the post body is in
> >> two, larger segments, but is otherwise the same. it is an http 1.0 post.
> >>
> >> apache returns 200 to squid, the connection is torn down. this is http 1.1
> >>
> >> squid returns 200 to the app, the connection is torn down. this is http
> >> 1.0
> >>
> >> ********** non-working my app **************
> >> app sends http headers in a single packet, gets an ACK. the post body is
> >> never sent. I do not use the Expect: header.
> >>
> >> squid opens a connection to post 80, sends the headers, gets an ack.
> >>
> >> then we wait. app times out, and tears down connection to squid.
> >>
> >> squid tears down connection to httpd. httpd returns 200 OK during the
> >> teardown, and squid sends RST.
> >>
> >> *********************
> >>
> >> ok, so i am sure this is something i am doing, but it looks like even
> >> though i have Expect: turned off, libcurl is still waiting instead of
> >> sending the post body. i have searched around quite a bit, but did not see
> >> any answers.
> >>
> >> things to try? suggestions?
> >>
> >> thanks for any help you can give.
> >>
> >> allan
> >>
> >
> >
>
> --
>
>
Received on 2005-05-02