背景

今天组内的一位同事找我协助解决一个问题。他在一个API中需要第三方传递一个名为access_token的头信息，但在将其发布到测试环境后，便无法获取到这个头信息。尽管在本地调试时一切正常，但在测试环境中却出现了问题。我希望能够帮助他找到解决方案。

排查

HTTP传递头信息出现问题，这本应是一个非常成熟的技术，很有可能是代码出现了问题。我建议先看一下代码，因为只有一行request.getHeader，理论上不应该出现问题。那么问题出在哪里呢？

“弄清楚请求链路，从外到内，从内到外逐个分析”。

冷静下来分析后，我认为可能是请求链路上的其他节点未能正确传递access_token，因此我与这位同事一起梳理了一下请求链路。大致情况如下（ 可能与实际情况有所不同，只是根据我了解到的情况 ）：

浏览器->外网nginx->k8s ingress->springboot服务。

接下来，我们开始逐个节点从内到外进行测试分析，以找出问题的根源。

1.首先进入springboot服务所属的容器内，使用curl 127.0.0.1进行测试，相当于自己访问自己，排除了其他节点的干扰。结果显示可以正常获取到access_token的值， 排除了代码问题 。

2.接着进入ingress的容器内，同样使用curl 127.0.0.1进行测试。这时的请求链路相当于curl->k8s ingress->springboot服务，目的是验证k8s ingress是否会影响请求头的传递。

3.按照此类推进行测试和分析。

实际上，在进行完第一步测试时，我突然想到了答案（ 很久之前遇到过，一开始没想起来 ）。因此，后续步骤并未进行。我在这里写下这些，只是希望能够与大家分享一下我排查此类问题时的思路。至于答案是什么，我先卖个关子，接下来我将先普及一个冷知识。

http请求头规范

https://www.rfc-editor.org/rfc/rfc9110.html#name-field-names

解读上述文字的意思：nginx会丢弃带有下划线的请求头，不会将其传递至后续节点。若不希望丢弃这些信息，可以修改underscores_in_headers的值为on，或者将ignore_invalid_headers修改为off。

最终处理

1.梳理链路上的nginx，修改underscores_in_headers或ignore_invalid_headers的值；

2.将access_token修改为access-token，使其符合规范；

最终采用了第二种方案解决问题。原因很简单，修改请求链路上的参数会带来较大的影响，而且不一定能够覆盖所有情况。已知的影响因素有nginx，可能还包括slb、iis、apache等，不可控因素太多。