On Thu, 22 Dec 2005, Vadim Lebedev wrote:

>>>> 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.

> What would be your suggestion to prevent this situation...? Checking the
> validity of socket handle before timestamp comparaison?

I would suggest that the UrlState struct for example stores an index to the
previously used entry in the connection cache. Then your function can
instantly check if the connection is still present or not.

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

> The main idea of this extension is to allow application to use curl proxy
> traversing capabilities
>
> Well, obviously this operation may have some sense in case of telnet sockets
> too, but do ypu really think it is useful in case of FTP?

Well, the same way you use it for HTTP someone _can_ use it for FTP. *I* don't
find a use for either case! ;-) (but then I don't use lots of options and
features, as I suspect goes for most people, everyone uses just a subset...)

> Or/And in case of SSLified protocols (where we need to invent a way to pass
> to the application SSL or TLS context too)...

Yes, but now you're out on thin ice, if I may say so. You want a feature that
extracts a rather low-level socket from the transfer lib to the application
layer. I say that is a weird idea to begin with. Now you're trying to explain
how this is hard or bad in all other cases but the way you use it...

I say if you really want a function that extracts the socket from the lib and
you want to play rough and fiddle with things you REALLY need to know what
you're doing before you even consider doing, then why add artificial limits
just because those situations don't apply to your use case?

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

> Where (which file) this descritpion would go?

You add an option to curl_easy_getinfo() so I think the new option would need
to be documented there: docs/libcurl/curl_easy_getinfo.3 is the file.

> Actually i think that curl could greatly benefit if one would implement
> 'Generic transport layer' which would abstract all socket opeartions and
> which can be hookable by application for example by registering URI scheme
> handlers, in this way one will be able to do HTTP transfers over UDP or
> maybe even serial lines for example

Most features that people seriously want done are often implemented. The
things that aren't really and truly useful will seldom see the light of day.

People have suggested "plugins" and "hooks" for libcurl on and off for as long
as I can remember, but still no one has ever produced a concept that would
work or even come up with protocols/ideas that anyone would use that would
take advantage of it.

I'm not saying it won't ever happen, just that it doesn't actually solve an
existing problem.

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