[ruby-core:83351] Re: [Ruby trunk Bug#14013] [PATCH] Webrick 60172 fix

[e-mail] 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: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>