谷歌云负载均衡器自定义 http 标头丢失答案

【问题标题】：Google cloud load balancer custom http header is missing谷歌云负载均衡器自定义 http 标头丢失
【发布时间】：2017-01-25 10:49:55
【问题描述】：

在使用 Google Cloud HTTPS 负载平衡器时，我们遇到了以下错误。找不到任何相关信息。

我们的请求中有一个自定义的 http 标头： X-<Company name>-abcde。如果我们直接在服务器上工作，一切都很好，但是一旦我们通过负载均衡器工作，我们的自定义标头就会丢失。我们在文档中没有找到任何需要将我们的标头列入白名单或类似内容的参考。

为什么我的自定义标头在通过 Google Cloud Load Balancer 工作时没有传输到我的后端服务器？以及如何让它发挥作用？

谢谢

【问题讨论】：

标签： load-balancing google-cloud-platform

【解决方案1】：

数据

经过大量测试，我得出以下结果：

Google Cloud HTTPS 负载平衡器确实将自定义 HTTP 标头传输到后端服务。
但是，它将它们更改为小写。

因此，在您的情况下，X-Custom-Header 转换为 x-custom-header。

解决方案

只需更改代码即可读取自定义 HTTP 标头的小写版本。这是一个简单的修复方法，但 Google 可能不会长期提供支持（Google 的文档中没有对此进行了说明，因此如有更改，恕不另行通知）。
请求 Google 改变这种特殊行为，或者至少在他们的文档中明确提及。

一点额外的

据我所知，RFC 2047 为自定义 HTTP 标头指定 X- 前缀并为每个单词传播大写字母的伪标准已被弃用并替换为 RFC 6648 建议反对X- 前缀一般，并没有提及自定义 HTTP 标头键名称中的其余单词。如果我是 Google，我会更改此行为以按原样传递自定义 HTTP 标头，并让开发人员按照他们设置的字符串处理它们。

【讨论】：

HTTP 标头名称不区分大小写 (RFC 7230)，因此 Google 的行为符合标准。通过以区分大小写的方式查找标头，应用程序未遵循标准。
嗯..检查。似乎。小写不再起作用了。

【解决方案2】：

HTTP/1.1 消息语法和路由的 RFC (RFC 7230) 指出标头字段具有不区分大小写的字段名称。如果您依赖大小写来匹配与 RFC 不一致的标头。

回到过去，我查看了 Tomcat 的 Jetty 源代码，他们使用 .toLower() 处理所有内容。

Go 有一个 CanonicalMIMEHeaderKey，它会以一种通用方式格式化标题，以确保所有内容都在同一页面上。

Python 仍然可以追溯到 RFC822 (hg.python.org/cpython/file/2.7/Lib/rfc822.py#l211) 时代，但它强制标头上的 .lower() 标准化。

虽然 GCP HTTP(S) 负载均衡器所做的工作基本上就 RFC 而言是可以接受的。

【讨论】：

好发现！但是，在我看来：HTTP 标头主要用于 HTTP 环境，即 Web 服务器。大多数 Web 服务器都是基于 Linux 的。 Linux 环境区分大小写，除非您花费额外的计算能力来操作字符串并进行检查。既然如此，看来7230 并没有真正起飞。特别是因为 Google Cloud HTTP(S) 负载平衡器产品添加自己的自定义 HTTP 标头，并维护“已弃用”的 X-Capital-Letter 命名约定。我的观点是，除非有好的、标准的采用，否则 RFC 不值得写在上面的 .txt。
@SimpleAnecdote 我见过的绝大多数 HTTP 实现都以不区分大小写的方式使用标头名称。不属于例外情况的应用程序应予以修复。顺便说一句，不区分大小写！= 小写：“X-Capital-Letter”不是“弃用”，它只是与“x-capital-letter”相同的标题。

【解决方案3】：

这很可能是应用程序错误。

正如其他答案所述，HTTP 标头名称区分大小写。 Ime，每次标头似乎都区分大小写时，这是因为应用程序调用堆栈中的某处有一个请求包装器。

像这样的请求包装器在 Java servlet 过滤器中很常见（通常是必需的）。对包装器中的标头名称使用区分大小写的匹配（例如常规 Java HashMap<String, T>()）是一个常见的新手错误。

这就是我开始寻找你的错误的地方。

创建不区分大小写且不修改键的 Java Map<String, T> 的合理方法是使用 new TreeMap<String, T>( String.CASE_INSENSITIVE_ORDER )。

【讨论】：