Daniel Stenberg wrote:
> On Thu, 20 Aug 2009, koettermarkus_at_gmx.de wrote:
>
>> Same args means same buffer, same len. curl fails here,
> Surely you can test this by making a HTTPS server that reads one byte
> per second and then have libcurl upload to it?

I was wrong, SSL_write reuses the same buffers, but as each protocol
implements this strategy itself, I was looking into the wrong place,
ftp.c:3653 CURLcode Curl_nbftpsendf
http.c:994 CURLcode add_buffer_send

>> SSL_ERROR_WANT_READ is not respected
>
> libcurl doesn't respect SSL_ERROR_WANT_* at all, no, but the impact of
> not respecting that is a short burst of too-much-looping and I've not
> yet seen anyone badly damaged by that. This flaw has existed since
> forever in libcurl.

Recycling ssl connections without proper shutdown works?

> We need to store the direction for the WANT and then we need to have a
> _getsock() implementation for the SSL lib so that the poll/select code
> can ask the SSL layer what to wait for on the socket.
>
> I thought this was mentioned in the TODO, but I'm mistaking. I'll add it
> there.
>
>> Openssl is sometimes not really intuitive
>
> Haha, now that's a nice understatement. Even for the functions where
> there exist docs, the docs leave out a lot of details or are so hard to
> decipher sometimes you end up using them wrong anyway. It's a stable and
> fine lib, but with a really wild and crazy API.

Current openssl documentation is pretty complete to do all required
actions, but it is a large, and easy to misunderstand.

>> but -for my experience- the only ssl layer you *can* use nonblocking
>
> Really? NSS and gnutls also provide fine non-blocking functionality. We
> don't take full advantage of that in libcurl yet, but that's more
> because of lack of someone doing the libcurl code for it than problems
> in the underlying libs.

I've never seen gnutls nonblocking code working, did not touch NSS yet,
as openssl works for me, licensing issues besides.

Markus
Received on 2009-08-20