Jeff Pohlmeyer wrote:
>> All these values are set with "curl_easy_setopt(CURLOPT_FOO)".
>> Why can't they be retrieved with "curl_easy_getopt(CURLOPT_FOO).
>> No new constants need be invented.
>
> Not all of the setopt's make sense as getopt's.
> For instance, if I do a simple http download without
> explicitly setting the port number, what would you
> expect curl_easy_getinfo(CURLOPT_PORT) to return?
> Some people might think 80, because that's the port
> libcurl used, others might think 0, because the
> port wasn't specified. Of course, you could argue
> to only return values for (potentially) dynamic data,
> but that sounds a bit tricky to document. If
> I don't set USER_AGENT, but I pass a header list
> that contains a "User-Agent: foo" field, what
> does curl_easy_getinfo(CURLOPT_USERAGENT) return?
> If it's NULL, does that mean the header was ignored?
> If it's non-null, should it be free'd?
>
> Sounds like a real can of worms to me...

That's a reasonable point and one Daniel has made as well in the past.
But to me it seems not particularly confusing to document that
curl_easy_getopt returns exactly what (if anything) was set with
curl_easy_setopt, and that for any "implied" values you're on your own,
just as you are now. I agree that going down the "implied/default" road
would open up a can of worms.

To put it differently, the getopt function would query the state of the
handle, not the state of a (potential or recent) request.

MB
Received on 2006-10-14