Hi,
> > We are using libwww-ssl to fetch pages from secure webservers on the
> > internet, but we find that there are some problems in the
> way this happens.
> > Since requests failed in strange ways, we conducted tests
> to see where the
> > connection attempts failed. After increasing the logging
> using in libwww, it
> > became obvious that it was the SSL connect stage that
> failed every time.
> > Further investigation revealed that this problem appears
> only when the
> > connect was done using a non-blocking socket.
> > Searching the mailing-lists, it seemed that we are not the
> only ones having
> > problems using OpenSSL/libwwwssl with non-blocking sockets.
> Did anybody
> > verify whether or not there is a bug in OpenSSL regarding
> SSL_connect on a
> > nonblocking socket?
> It is always dangerous to say that there is no bug because
> somebody may prove you wrong later.
> Having this said: are you aware of the fact that the
> programming interface
> changes when using non-blocking sockets? You may have to call
> SSL_connect
> several times in a row and check the error code, since
> SSL_connect will
> also lose its blocking behaviour.
> Details have been discussed on the openssl-* mailings lists
> in the recent
> past. Please check the mailing-list archives and search for
> "non-blocking"
> or e.g. SSL_ERROR_WANT_READ (a typical state that occurs
> during non-blocking
> I/O).
Of course, the interface changes. But as stated above, this code comes from
libwwwssl. It may very well be that the library isn't handling OpenSSL
correctly. That's why this mail was also sent to the libwww mailing-list.
[After checking]
But you seem to be right. The libwww-ssl code does not seem to check whether
or not the connect succeeded or if it returned an SSL_ERROR_WANT_READ. I
will try to get the opinion of the libwww-ssl people on this.
--
The woods are lovely, dark and deep,
But I have lines to code before I sleep, lines
to code before I sleep.
Sander Alberink.vcf
