Re: CURLINFO_LASTSOCKET change
Date: Tue, 25 Apr 2006 09:51:52 +0200 (CEST)
On Tue, 25 Apr 2006, David McCreedy wrote:
> We clearly didn't understand the Curl architecture for this. The patch
> obviously won't work. I think it makes sense now, but let me run through it
> so you can confirm I'm on the right track before we create and test a new
I have full understanding that not all details and quirks are obvious.
> The old patch to getinfo.c stays the same but SSL_peek becomes Curl_ssl_peek,
> which will go into sslgen.c.
> The new Curl_ssl_peek function calls a new Curl_ossl_peek in ssluse.c if
> USE_SSLEAY is true.
> Finally, Curl_ossl_peek issues the actual SSL_peek. Abstracting the
> platform/package specifics.
Yes, that's exactly how I propose it.
> If someone writes Curl_gtls_peek for gtls.c, Curl_ssl_peek could call it
> when USE_GNUTLS is true.
Yes. From some quick glancing in the GnuTLS docs it seems there's no easy
equivalent to the SSL_peek().
> Otherwise GNUTLS would follow the non-USE_OPENSSL path in the new
> Curl_ssl_peek function. That path will return a value that leaves the
> existing CURLINFO_LASTSOCKET processing (results) unchanged.
Yes, in a best-effort approach: if we can't do the check we don't, but we do
it for the SSL lib(s) where we can.
Thanks for your patience and efforts!
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2006-04-25