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
> patch:

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