On Fri, 1 May 2009, Pankaj Kumar Maharana wrote:

> Still it did not solve the issue.. I tried by setting CURLOPT_HTTPAUTH to
> CURLAUTH_BASIC. But I found a new use case. The new use case is that if I
> set CURLAUTH_BASIC with the initial request itself than I did not get any
> response at all.

I'd claim that's a flaw in the server end in that case. Or how is this
libcurl's fault?

> So I tried setting CURLAUTH_ANY with the initial request. But when I get 401
> error than set CURLAUTH_BASIC with the username and password from header
> callback. Here I observed that the issue of not sending second time is still
> there with this approach also.

It's not supposed to. The header callback just brings you the response
headers, it will not trigger another request even if you alter options. You
need to do that second request yourself.

> The issue is, with the same handle when i am setting a new username and
> password than CURL does not send that information to the server. Instead it
> gives back the response body through write_callback function.

Yes, that's what it is supposed to do. You can of course abort that by
returning the right code from the write callback.

> I understand that it is not the correct behaviour. If I am setting username
> and password with the same handle than CURL need to send the info to server
> and need to call header_callback with the response header.

libcurl doesn't work that way at any time really. It's basically:

  * create handle
  * set options
  * perform request
  * receive data / send data

...and if you then want to alter options, you can of course do this at any
time during the receiving/sending but they change in the handle and will only
be used when you (the app) do a subsequent request.

-- 
  / daniel.haxx.se