On Thu, 20 Aug 2009, koettermarkus_at_gmx.de wrote:

> Same args means same buffer, same len. curl fails here,

Are you sure about that? I know I got hit in the face with that problem in the
fast and I made an effort to make sure we send the same buffer again on
retries. Wouldn't we have a lot more problems with HTTPS if that didn't work
at least mostly?

Surely you can test this by making a HTTPS server that reads one byte per
second and then have libcurl upload to it?

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

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.

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

-- 
  / daniel.haxx.se