On Fri, 25 Apr 2008, tetetest tetetest wrote:

> I am afraid it isn't. After SSL connection is established, you must use the
> SSL session. You cannot re-establish sessions on the fly (that's what SSL is
> basically for; otherwise an intruder could hijack an existing session
> without any trouble).

Well, it's not "an intruder" and all that is required for this to actually
work is for the app to use the proper callback to pick up the context struct
pointer, at least if OpenSSL is used.

I'm however not saying this is good enough from a usability stand-point.

> 'Send' for sending, 'recv' for receiving, and something like 'poll' (or
> 'select') to check if data is available for reading or sendable. That should
> be pretty enough for everyone. Other functionality (like reading strings in
> string-oriented protocols) could easily be implemented using these three
> basic functions.

I would think that poll() and select() are already perfectly fine to use as
they are, and I'd rather avoid introducing our own versions as long as we
don't have to. Remember that we do provide an API for the app to extract the
raw socket and that could be used fine with select()/poll()/epoll()/whatever
even if libcurl-specific recv and send functions are then invoked to actually
perform.

> And those geeks who send OOB data over non-blocking sockets should resort to
> good old CURLINFO_LASTSOCKET.

I don't understand this remark. The socket will be non-blocking and thus
send() and recv() will only send and receive as much as they can without
blocking. Or are you also suggesting we should support a blocking mode?

Mixing actual real socket-access with accesses using "curl_socket_*" (or
whatever the name would be) will be a very error-prone business and will most
likely be an unrecommended practise.

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