> This is actually by design and not a bug. CURLOPT_COOKIE adds the cookie
> header in the outgoing request, and with CURLOPT_FOLLOWLOCATION enabled
> there may be more than one request performed and they all get that cookie
> header.
>
> (I've now clarified this a bit in the docs.)
>
> If you'd rather want a cookie added to the "engine" and thus sent only to
> the proper host etc you probably should rather add the cookie with
> CURLOPT_COOKIELIST.

I'm querying another source for cookies based on the URLs I'm
fetching, so I don't have a full list available for setting before my
query.

If I call curl_easy_setop(CURLOPT_COOKIE) with my new cookie while
processing the Location header, will that new cookie value be used for
the redirected connection? I see the code in Curl_http that uses the
cookie value, and as long as the set.newurl handling is done outside
of this call resulting in a new call to it for the redirected
connection, it seems like it would work.

However, when I looked in the code, it looked like the Location:
header parsing was a more complicated than grabbing the value after
Location and chopping off leading/trailing whitespace because of hacks
to deal with non-absolute URLs there. I didn't see any way to access
that redirected URL value stored in req.newurl until after the new
transfer has started when you can query it via CURLINFO_EFFECTIVE_URL,
and at that time, it's too late to add or change cookies.

What I'd love to see would be a curl_easy_getinfo option that let me
query the req.newurl value, something like CURLINFO_REDIRECTED_URL,
and for that to be set even if I have "alwaysfollow" turned off, so I
could manually do the re-request using the right value when I get a
3xx series result code.
Received on 2008-04-10