为什么有时我的自定义标头不显示? [英] Why is my custom header not present sometimes?
问题描述
在nginx和Phusion Passenger后面运行时，如何将自定义标头一直带到Rails应用程序中?有可能，请参阅下面的详细信息，但是当我仅使用Paw中的标题窗格时，它不会通过.
How do I get my custom header all the way to my Rails application when running behind nginx and Phusion Passenger? It is possible, please see details below, but when I just use the headers pane in Paw it is not passed through.
我正在使用Paw在Rails应用程序中测试和开发一些API端点.一切都能在我的开发环境中正常运行，这是一个使用Puma在macOS上运行的Rails 6应用程序.为了安全起见，我使用了包含个人身份验证令牌的自定义标头.当我检查Rails请求对象，特别是request.headers时，我可以看到包括我的自定义标头在内的所有标头，并且可以根据其值进行身份验证.
I am using Paw to test and develop some API endpoints in a Rails application. Everything works as expected in my development environment, which is a Rails 6 application running on macOS using Puma. For security, I use a custom header that contains a personal auth token. When I examine the Rails request object, specifically request.headers, I am able to see all the headers including my custom header and I can authenticate based on its value.
问题是在我对环境几乎没有控制的登台系统上运行时出现的.在这里，同一个Rails应用程序在nginx后面的Phusion Passenger下运行.当我用相同的请求命中相同的端点时，只要更改请求中的主机，就不会出现自定义标头.我通过将登台中每个请求的所有标头写入文件来验证这一点.
The problem comes when running on my staging system, where I have very little control of the environment. Here, the same Rails application is running under Phusion Passenger behind nginx. When I hit the same endpoint with the same request, just changing the host in the request, the custom header is not present. I verified this by writing all headers to a file for every request in staging.
标题到哪里去了?由于分阶段的环境不同，我怀疑nginx或Fusion Passenger正在接收标头，但没有将其传递给我的Rails应用程序.我无法验证这一点，因为除了Rails应用程序的日志之外，我无法访问其他日志.该应用程序旨在从外部服务获取请求，因此我通过该服务发送了一些请求，并且出现了标头.这很奇怪，因此一些标头正在传递，而有些则没有.
Where has the header gone? Because the environment is different in staging, I suspect that nginx or Fusion Passenger is receiving the header but not passing it through to my Rails application. I can't verify this since I have no access to the logs other than my Rails application's logs. The application is designed to get requests from an external service, so I send some requests through that service and the header is present. That is very strange, so some headers are being passed through and some are not.
-
爪子(在标题窗格下定义的标题).
Paw (header defined under headers pane).
我使用以下方法检查了cURL:
I checked with cURL using:
curl -X 'https://example.com/ivr/main_menu' -H 'X_JSW_AUTH_TOKEN':'my_tkn'
使用Ruby's Net :: HTTP:
With Ruby's Net::HTTP:
uri = URI('https://example.com/ivr/main_menu')
http = Net::HTTP.new(uri.host, uri.port)
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_PEER
req = Net::HTTP::Post.new(uri)
req.add_field "X_JSW_AUTH_TOKEN", "my_tkn"
res = http.request(req)
使用HTTPie:
With HTTPie:
http POST 'https://example.com/ivr/main_menu' 'X_JSW_AUTH_TOKEN':'my_tkn'
使用来自httprb的http gem:
With the http gem from httprb:
resp = HTTP.headers(X_JSW_AUTH_TOKEN: "my_tkn").post("https://example.com/ivr/main_menu")
推荐答案
似乎答案与Paw无关.当cURL，HTTPie和Net :: HTTP都具有与Paw相同的结果时，有充分的证据证明这一点.
It seems the answer has nothing to do with Paw. There's pretty solid evidence of this when cURL, HTTPie, and Net::HTTP all have the same results as Paw.
问题在于，默认情况下，nginx如何通过忽略下划线来处理带有下划线的标头.请参阅"为什么HTTP服务器禁止HTTP标头名称中的下划线"以获取更多信息.
The problem is how nginx treats headers with underscores by default by ignoring them. See "Why do HTTP servers forbid underscores in HTTP header names" for more information.
Ruby的HTTP之所以能够为我的应用程序提供标头，是因为它用标头名称中的连字符(-")替换了下划线("_")，因此这些标头使其进入了Rails应用程序.然后，Rails用下划线替换请求标头名称中的连字符.因此，发送方(HTTP)和接收方(Rails)都在后台进行替换.这使得解决问题变得更加困难.
Ruby's HTTP, which was able to provide the header to my application, did so because it replaces underscores ("_") with hyphens ("-") in header names, so these headers made it through to the Rails application. Rails then replaces hyphens in the header names of requests with underscores. So, both the sender (HTTP) and receiver (Rails) were making substitutions behind the scenes. This made it way harder to troubleshoot.
非常感谢克里斯·奥利弗的回答.
这篇关于为什么有时我的自定义标头不显示?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
