Nothing so complex...
I'm embarrassed to report that I somehow managed to delete the
Not one of my better days.
On Mon, April 30, 2012 11:15 am, Shanshui Liu wrote:
> Maybe the cookies are not set by HTTP headers at all (e.g. via
> Have you looked through the headers to see whether "Set-Cookie:" does
> exist? Also, modified versions of PHP (e.g. Suhosin) might prevent
> from writing to files not owned by the same user as the web server /
> CGI process, so you may want to try running a chown (change owner) on
> cookie file? (I'm not familiar with server adminstration stuff
> With regards,
> Liu Shan Shui
> "Life would be much easier if I had the source code." - Anonymous
> On Mon, Apr 30, 2012 at 10:12 PM, Richard Lynch <ceo_at_l-i-e.com> wrote:
>> I'm having trouble with CURLOPT_COOKIEFILE and CURLOPT_COOKIEJAR in
>> I have tried ./cookies.txt and /full/path/to/cookies.txt
>> I have them at 777 in sheer desperation.
>> Are there any checks in libcurl for keeping me from shooting myself
>> the foot with owner/group/permission?
>> I am using RETURNTRANSFER and FOLLOWLOCATION.
>> I seem to remember having issues with CURLOPT_HEADER in conjunction
>> with COOKIE* way back when. It felt like since I was getting the
>> headers, libcurl didn't feel the need to track cookies for me...
>> Are there any known incompatibilities among those three?
>> I need to make a second request in another HTTP transaction, so I'm
>> pretty sure I need those cookies, and I'd rather not parse the
>> for them... Especially as there might be one set by an interstitial
>> page, so I'd have to also follow the 30* redirects by hand as well.
>> brain cancer update:
brain cancer update:
Received on 2012-05-01