On Fri, 6 Nov 2009, L S wrote:

> if((k->keepon & KEEP_RECV) &&
> ((select_res & CURL_CSELECT_IN) || conn->bits.stream_was_rewound)) {
>
> result = readwrite_data(data, conn, k, &didwhat, done);
> if(result || *done)
> return result;
>
> The upper if statement isn't fulfilled after a SSL_ERROR_WANT_WRITE

Why isn't it fulfilled anymore? I mean, what exactly makes this condition no
longer match after a SSL_ERROR_WANT_WRITE? I can't see any particular
treatment of SSL_ERROR_WANT_WRITE in the code so I don't see how your
described problem happens.

> If this is considered to be an bug and not a feature ( there might be some
> reason for this that isn't libcurls fault. There are winsock calls involved
> that I don't know what they do )

Your described problem certainly sounds like a bug, and the fact that you can
make it work again even more suggests that this is a libcurl bug. To me the
question is mostly how the fix should be made.

> then this little fix seems to work out for me. In file Transfer.c line 449:

> conn->cselect_bits |= CURL_CSELECT_IN; //Remember that connection is of type
> CURL_CSELECT_IN

That's unfortunately too naive. In fact, when OpenSSL has returned
SSL_ERROR_WANT_WRITE we shouldn't in fact wait for input anymore but we should
rather wait for the socket to become writable since OpenSSL wants to _write_
data at that point. We have however never addressed that problem and yet we've
done quite well, so I'm not sure we really need to care about that detail
right now.

This extra fiddling with those bits was added in 7.19.7 to allow protocols to
actually set the bits for writing while it is in fact downloading and vice
versa, so we can't unconditionally set downloading to use the CURL_CSELECT_IN
bit.

> If you want to reproduce the bug i suggest that you sent a couple of
> thousand https messages to a server running on a VMWare running on the same
> computer. I believe that SSL_ERROR_WANT_WRITE only occur from SSL_read when
> using a very fast connection.

I'm seriously backlogged with libcurl stuff, but I'll see if I can work on
repeating this problem soonish.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html