Repository navigation
Consistenty - IOError vs EBADF? #798
Description
SSLSocket error conditions are not consistent with IO.
io.closefollowed byio.readcan result inEBADFrather thanIOError.- Without
sync_close,io.closefollowed byio.readwill hang. Even if the underlying IO is not closed, I don't think theSSLSocketinstance should continue to work after being closed?
Reproduction:
#!/usr/bin/env ruby
require 'bundler/inline'
gemfile do
source 'https://rubygems.org'
gem 'localhost'
end
require 'socket'
require 'openssl'
require 'localhost'
def read_after_close(io)
io.close
io.read
end
begin
client, server = Socket.pair(:UNIX, :STREAM)
read_after_close(client)
rescue => error
$stderr.puts error.full_message
end
begin
authority = Localhost::Authority.fetch
client, server = Socket.pair(:UNIX, :STREAM)
ssl_server = OpenSSL::SSL::SSLSocket.new(server, authority.server_context)
ssl_server.sync_close = true
ssl_client = OpenSSL::SSL::SSLSocket.new(client, authority.client_context)
ssl_client.sync_close = true # If this is not set, `io.read` above will hang which is also a bit odd.
Thread.new{ssl_server.accept}
ssl_client.connect
read_after_close(ssl_client)
rescue => error
$stderr.puts error.full_message
endIs this something we can improve?
Activity
[-]Consistenty - IOError vs EBADF?[/-][+]Consistenty - `IOError` vs `EBADF`?[/+]Add a compatibility fix for `SSLSocket` raising `EBADF`.
rhenium commentedon Oct 31, 2024
Calling read/write on a closed socket is a user error, but hanging indefinitely doesn't seem ideal. I think we can manage a flag in
SSLSocketso we can raiseIOError.What should happen if a thread closes
SSLSocketwithoutsync_closewhile another thread is waiting forrb_io_maybe_wait_readable()on the underlying socket?ioquatix commentedon Oct 31, 2024
I'm on the fence about how this should work.
On the one hand, I understand someone might call
io.close. What happens to other users blockingio.read?There are two options:
io.closeis able to cause other operations to abortio.readetc. However, there are many such operations, and so this implementation is extremely complex. It's current behaviour (does it have race conditions? not sure).io.closewith pending operations fails as a runtime error. In other words,io.closecan fail if you don't cause all other usage to exit first. The implementation of this is more trivial as it's just a reference count.io.closeshould simply wait for all operations to finish. In other words, it blocks indefinitely if the io is in use elsewhere.As we see in my example here, and your response about how should
sync_closebe handled - it becomes extremely tricky.@ko1 do you have any thoughts about it? I know you believe that
File.open{...}should be able to close the file in all situations, but I'm not so sure if it's good. If the user writes thisI also believe this is a problem with the program.
ioquatix commentedon Jun 19, 2025
For consistency's sake, I think we should fix this.
IO#read_nonblock(raisesIOError) andSSLSocket#read_nonblock(raisesErrno::EBADF) seem inconsistent in this regard.ioquatix commentedon Jun 19, 2025
See socketry/io-stream#6 for a related PR that is working around this issue.
rhenium commentedon Sep 2, 2026
I've submitted #1106 for this.