>>(CC'ing the curl-library list)

Sorry for posting it to the wrong list and thanks for replying to all my
posts.

> Are there any plans to enhance cURL to provide more than just the last

> used URL when we call the "curl_easy_getinfo" API.

The "plans", as far as there are any, are summarized in the TODO and
KNOWN_BUGS document. But we generally tend to fix things we come to think of
is missing or not working when we fall over them.

I personally don't see the benefit of your suggested option.

> Ideally, an API which returns all the URL's (where number of URL's is

> specified by CURLOPT_MAXCONNECTS) will help applications using cURL in

> a multi threaded environment - where each thread has its own cURL

> handle in intelligently selecting the right thread there by selecting

> the right handle to do the work.

>>You mean you want to figure out if one of your existing CURL handles has a
connection open >>to a host you want to fetch a URL from?

That is correct - I want to intelligently select from a pool of CURL
handles. Even if the connection is closed - I get the benefit of the CURL
handle caching the SSL session ID's. So I can use the curl handle which has
the cached session ID rather than some other CURL handle which does not have
the SSL session ID in its cache.

>>EFFECTIVE_URL isn't gonna provide that answer, since the connection may
very well have been >>disconnected.

Yeah, from what I read EFFECTIVE_URL is just going to return the last URL
accessed by the CURL handle. Any suggestions on this issue ?

-k

 
Received on 2004-10-15