PUMA失败了，因为请求标题为“ nil”，但它们存在于n env中。
两个应用程序，一种使用PUMA 4.3.4和一个使用PUMA 5.6.4的应用程序，两者都开始失败，而同样的错误：
Read error: #<NoMethodError: undefined method `each' for nil:NilClass>
PUMA 5.6.4不给出backtrace，但4.3.4表示问题出在/usr/local中/bundle/gems/puma-4.3.4/lib/puma/server.rb:759它是puma调用headers.eave的地方。
我已经在这里求和，确实标题是nil，但是我不知道原因。今天所有这些都非常快乐！
如果我检查env我可以按预期查看请求标头，http_host，http_cookie等等。那么，为什么PUMA无法执行通常在准备handle_request的过程中进行的任何操作？
这些应用程序是包括代理的Docker-Compose设置的一部分，但直接从其自己的容器内拨打应用程序会出现相同的问题，因此这不是代理剥离标头的问题（无论如何，无论如何，他们会从
升级PUMA 4.3.4到5.6.4没有修复事物，这也有意义，因为5.6.4应用程序也被打破了，我认为这是同一问题，尽管没有回溯，我不确定如何验证这一点。
这些是Sinatra应用程序，但我不确定这是相关的 - 当错误发生时，该请求似乎并没有达到堆栈中的那一点。
Two applications, one using Puma 4.3.4 and one using Puma 5.6.4, have both started failing with the same error:
Read error: #<NoMethodError: undefined method `each' for nil:NilClass>
Puma 5.6.4 gives no backtrace, but 4.3.4 indicates the problem is in /usr/local/bundle/gems/puma-4.3.4/lib/puma/server.rb:759 which is where Puma calls headers.each.
I’ve dropped into Pry here, and indeed headers is nil, but I can’t figure out why. This was all working quite happily earlier today!
If I inspect env I can see the request headers as expected, HTTP_HOST, HTTP_COOKIE and so on. So why is Puma failing to do whatever manipulation it normally does in preparation for handle_request?
These apps are part of a docker-compose setup which includes a proxy, but calling directly to the applications from within their own container gives the same problem, so it’s not the proxy stripping the headers (and anyway, they would be missing from env if so).
Upgrading Puma 4.3.4 to 5.6.4 doesn’t fix things, which also makes sense because the 5.6.4 app is broken too, and I assume it’s the same problem although without a backtrace I’m not sure how to verify that.
These are Sinatra apps, but I’m not sure that’s relevant – the request doesn’t seem to have reached that point in the stack when the error happens.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因此，这实际上是自定义中间件中的一个错误：当它在某些情况下失败时，它返回
nil而不是提出例外。这意味着没有触发通常的Sinatra或Sentry错误处理，进而将空的结果返回到Puma，然后像上面一样被cho住了。
关键是要确保在所有情况下都无法做出回应的情况下，中间件引起了例外！
So this was in fact a bug in a custom middleware: when it failed under certain circumstances it returned
nilrather than raising an exception.This meant that none of the usual Sinatra or Sentry error-handling was triggered, and in turn they passed the empty result back up to Puma, which then choked as above.
The key thing was to make sure the middleware raised an exception under all circumstances where it cannot give a response!