On Mon, 24 APR 2006, Daniel Stenberg wrote:

>On Mon, 24 Apr 2006, David McCreedy wrote:
>
>>The curl_easy_getinfo processing for CURLINFO_LASTSOCKET returns the last
>>socket without regard to its current status. This small enhancement to
>>lib/getinfo.c would determine if the server sent a shutdown on the socket
>>and if so, return a -1 to indicate that the socket is no longer valid.
>
>That's indeed a good thought!
>
>A pretty big nit on your approach though:
>
>Using SSL_peek() like that is a big no-no. First, it won't build if you
>build libcurl without SSL support. Then, it won't build if you build with
>GnuTLS instead of OpenSSL.
>
>SSL-related functions need to be offered by the generic (SSL-library
>agnostic) interface (Curl_ssl_ prefixed) provided by sslgen.c, to allow us
>to support it in an independent manner.

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:

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.

If someone writes Curl_gtls_peek for gtls.c, Curl_ssl_peek could call it
when USE_GNUTLS is true.
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.

Is that right?

-David McCreedy
Received on 2006-04-25