On Thu, 22 Dec 2005, vadim_at_mbdsys.com wrote:

>> o This code can also easily fail. Like if you first get a URL that leaves a
>> connection alive, then you get a second using the same curl handle but
>> from a server that makes a "Connection: close" as then your request to
>> extract the socket will return the one from the first request and not the
>> most recent one that I bet the user would expect.

> I thik this situation can't areise in our use case

While I can understand that in your current situation this won't happen, I
would require a biiiig note about this known flaw in the (still missing) docs
for this option. And even then I would hesitate to incorporate code with such
an obvious risk of malfunctioning. It isn't like it would be impossible to
rectify.

The described situation might not hit you, but you can be sure there will be
other users and one of them is bound to get hit by this sooner or later.

Surely you agree?

>> o Why is this function limited to "HTTP sockets"?

You didn't answer to this. libcurl handles protocols in a fairly transparent
way that makes the app-side pretty similar and independent of protocol. I
can't see any reason for this option to not work for other protocols as well.
Can you?

>> o Are you aware that the HTTP bit is also set for HTTPS connections?
>>
> I was not aware of this but it really does not matter in our case

No, but then we don't add code in libcurl for your case alone. We add code to
be used by hundreds of thousands of users in hundeds of apps.

Also, I miss the description of what an app can and should do with this socket
and what it should not.

While this seems like a quick and simple patch for your case, it is a lot more
work to make it solid, working and reliable for use by the masses.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html