From: Eric Wong Date: 2017-10-18T20:54:57+00:00 Subject: [ruby-core:83351] Re: [Ruby trunk Bug#14013] [PATCH] Webrick 60172 fix Greg.mpls@gmail.com wrote: > Issue #14013 has been updated by MSP-Greg (Greg L). > > File webrick_ssl.patch added > > I posted [GitHub PR #1718](https://github.com/ruby/ruby/pull/1718), which passed both Travis & Appveyor. It also passes on my local MinGW trunk build > > Rather than an OS check, it checks to see if the `#wait_*` methods return `nil`. > Below is patch, attached also. Thanks. I'm somewhat inclined to accept it because it solves your problem; but the troubling thing is I don't understand why it is necessary.... > WEBrick::Utils.timeout(@config[:RequestTimeout]) do > + # it stop returning wait_* symbols or wait_* methods return !nil: > + begin > + ret = sock.accept_nonblock(exception: false) > + if ret == :wait_readable || ret == :wait_writable > + break unless sock.to_io.__send__(ret).nil? IO#wait_readable and IO#wait_writable only return nil if a timeout is specified, so I'm not sure how it could ever return nil. In other words, we might as well not be looping at all. And reading the implementation of ossl_start_ssl (in ext/openss/ossl_ssl.c) more carefully, it seems my initial use of SSLSocket#accept was entirely sufficient to handle blocking sockets. I'm actually suspecting there's a bug in the openssl extension around error handling for Windows, since there is a win32-specific errno path for ssl_get_error in ext/openssl/ossl_ssl.c > + end > + end until ret == sock SSLSocket#accept_nonblock clearly documents ret == sock is the expected and eventual outcome of a successful negotiation, so that is fine. > end > end > call_callback(:AcceptCallback, sock) > > ``` > > Thanks for all your help & suggestions. > Greg Unsubscribe: