自从 ruby 容器升级以来，我们遇到了很多：`OpenSSL::SSL::SSLError``SSL_read：读取时出现意外的 eof` 问题

Question

因此，当我们升级 ruby alpine 基础容器镜像时，我们看到了很多

OpenSSL::SSL::SSLError

SSL_read: unexpected eof while reading

。据我了解，我们问题背后的主要原因是 openssl 从 1.1 升级到 3。有一段时间我们降级到 1.1。我不太确定我们是如何做到的，因为它工作了一段时间 - 然后就不再工作了。最有可能在某个时候我们也升级了 openssl gem 本身。我没有深入研究“为什么降级工作了一段时间后突然不再起作用”（但这无论如何都不应该与此相关，因为我通常会因为一个糟糕的选择而选择降级，而我们只是在我们之后才选择了降级）最初的研究没有足够快地给我们任何结果）。

在深入研究如何使用 openssl 3（gem 和 libs）修复它之后，我终于想通了，我可以通过设置恢复到旧的行为

OpenSSL::SSL::SSLContext::DEFAULT_PARAMS = OpenSSL::SSL::SSLContext::DEFAULT_PARAMS.merge( 
  options: OpenSSL::SSL::SSLContext::DEFAULT_PARAMS[:options] + OpenSSL::SSL::OP_IGNORE_UNEXPECTED_EOF 
).freeze

（是的，我不应该为覆盖该常量而感到自豪。我尝试以我能想象到的侵入性最小的方式来做到这一点）

我们现在就忍受这个。但对我来说感觉不对。 所以我深入研究了一些具体问题。其中一个是关于旧的自定义社交媒体验证器，它检查某些给定社交媒体标识符的 url - 如果没有 oauth 授权，将无法再访问它。因此，由于授权问题，会发生意外的 eof。无论如何，这是我用谷歌搜索的可能根本原因之一。

但是对于我们的主要问题之一，我无法找到根本原因。因此，我们使用谷歌存储提供商的主动存储来上传图像。我在我们的错误跟踪器中看到只有 5 步深的回溯，从中间件直接跳转到 openssl/buffering.rb 第 80 行。但问题似乎发生在

ActiveStorage::Representations::RedirectController#show

之间的某个地方。我无法想象，谷歌仍然以错误的 ssl 处理进行响应（因为这就是 openssl 必须支持忽略意外 EOF 这么长时间的原因）。但我没有预感，我们可能在这里做错了什么。

那么：有没有人在主动存储+谷歌存储方面遇到过这个问题，并且知道一些可能的根本原因以及如何正确修复它（而不是覆盖

SSLContext

的默认参数）？

到目前为止谢谢

Answer 1

您可以添加到配置/初始化程序中，例如 ssl_patch.rb

if OpenSSL::SSL.const_defined?(:OP_IGNORE_UNEXPECTED_EOF)
  OpenSSL::SSL::SSLContext::DEFAULT_PARAMS[:options] |= OpenSSL::SSL::OP_IGNORE_UNEXPECTED_EOF
end