This is similar to the questions I was asking about getting to a
'known' state for a CURL* handle. Because you get a performance boost
from keeping the same handle around, it is good to do so. But once
you've made several setopt() calls, you've made it hard on yourself to
get the handle back to normal.

My guess (it's a guess, based off my experience with other calls
having similar issues):

curl_easy_setopt(pCURL, CURLOPT_POST, FALSE);
curl_easy_setopt(pCURL, CURLOPT_POSTFIELDS, NULL);
curl_easy_setopt(pCURL, CURLOPT_POSTFIELDSIZE, 0);

curl_easy_setopt(pCURL, CULROPT_NOBODY, TRUE);

That would be a guess. Don't know if I'm right. I have not looked at
the underlying structure of the CURL* handle, but would it be possible
to have a function that allows us to re-init the CURL* handle without
cleaning it up? This would make performing multiple heterogeneous
calls much simpler.

Just an idea...then again, perhaps I could look into it.

curl_easy_reset(CURL* pCURL);

Cheers.
Casey

> I have a question about libcurl. I use version 7.10.8.
> In the implementation of libcurl the same CURL handle
> is used for multiple requests. A weird situation occurs
> when request 1 is a POST request and the request 2 is a
> HEAD request. For the POST request we set the
> CURLOPT_POSTFIELDS, CURLOPT_POSTFIELDSIZE and
> CURLOPT_POST options. For the HEAD request we set the
> CURLOPT_NOBODY option to '1'. However, the
> data->set.httpreq variable keeps the value HTTPREQ_POST
> (because of the previous POST request). Because of this
> the 'switch (data->set.httpreq)' in the Curl_http
> function checks if there is post data, which is there.
> It then tries to add the post data to the HEAD request.
>
> Is this an known issue?
Received on 2004-06-29