On Thu, 11 Apr 2002, Mandar Wadekar wrote:

> The First URL was like this :
> http://servername/appserver/isapi.dll?application?mn_mainmenu.havbmainme
> nuclass&HASW&ANI123&DNIS123d&CALLERID123&undefined
> The Second URL would be something like
> http://servername/appserver/isapi.dll?RespondToApp?XYZ=abc&TYP=def

But what did the headers you received look like? What did the cookijar
contain afterwards?

We need to take this step by step to see what curl receives, what it saves,
what it loads, and why it doesn't send the proper cookies in the second
request.

> To use CURLOPT_COOKIE, I read the cookie.ck file which was generated by
> first request, stripped off the name,value pair from the cookie file and
> the code looks like following :

> curl_easy_setopt(curl,CURLOPT_COOKIEFILE, cookieFileName );
>
> #ifdef _FORCE_COOKIE_
> _ReadCookie(); //this strips the cookie
> value from cookie.ck file generated in first request.
> strcpy(szCookie,"AppServerSyncFile=");
> strcat(szCookie,szCookieValue);
> strcat(szCookie,";");
> res = curl_easy_setopt(curl,
> CURLOPT_COOKIE, szCookie);
>
> #endif
> res = curl_easy_perform(curl);
>

... and what did the header look like when you issued this request?

> I have tried the same code on Unix (ofcourse with Unix version of library)
> and it works perfect (without _FORCE_COOKIE). It gives me a feeling that
> windows library behaves in different manner.

Ah, this makes the matter more complicated of course. The fact that it works
on "unix" but not on windows indeed make it sound like a bug somewhere.

Since you obviously have done this on two platforms, can you see where the
two versions first differ?

Do the cookiejars end up the same when saved?

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/