HTTP 标头操作

HTTP 连接管理器在解码（接收请求时）和编码（发送响应时）都会操作多个 HTTP 标头。

:scheme

Envoy 在处理请求时始终会设置 :scheme 标头。它始终应该可供过滤器使用，并且应该向上游转发以用于 HTTP/2 和 HTTP/3，在这些协议中，x-forwarded-proto 将为 HTTP/1.1 发送。

对于 HTTP/2 和 HTTP/3，传入的 :scheme 标头是可信的，并会通过上游传播。对于 HTTP/1，:scheme 标头将设置为 1) 如果存在并且有效，则来自绝对 URL。无效（不是“http”或“https”）方案，或者在未加密连接上的 https 方案将导致 Envoy 拒绝请求。这是 Envoy 执行的唯一方案验证，因为它避免了对边缘 Envoy 的 HTTP/1.1 特定特权升级攻击 [1]，而 HTTP/2 及更高版本没有类似的向量 [2]。2) 来自 x-forwarded-proto 标头的值，经过清理后（对来自可信下游的有效 x-forwarded-proto，否则基于下游加密级别）。

可以通过 scheme_header_transformation 配置选项覆盖此默认行为。

当需要 URI 方案时，Envoy 会在 x-forwarded-proto 上使用 :scheme 标头，例如根据 :scheme 标头而不是 X-Forwarded-Proto 从缓存中提供内容，或者根据原始 URI 的方案设置重定向的方案。有关更多详细信息，请参阅 为什么 Envoy 在 X-Forwarded-Proto 而不是 :scheme 或反之操作？。

:path

:path 标头是一个伪标头，由 Envoy 使用 HTTP 请求路径的值进行填充。例如，形式为 GET /docs/thing HTTP/1.1 的 HTTP 请求将具有 :path 值为 /docs/thing。

:method

:method 标头是一个伪标头，由 Envoy 使用 HTTP 请求方法的值进行填充。例如，形式为 GET /docs/thing HTTP/1.1 的 HTTP 请求将具有 :method 值为 GET。值以大写形式表示，例如 GET、PUT、POST 和 DELETE。其他可能的值在 HTTP 方法 <https://mdn.org.cn/en-US/docs/Web/HTTP/Methods> 中描述。

user-agent

如果启用了 add_user_agent 选项，连接管理器可能会在解码期间设置 user-agent 标头。只有在未设置标头时才会修改该标头。如果连接管理器确实设置了该标头，则其值由 --service-cluster 命令行选项确定。

server

server 标头将在编码期间设置为 server_name 选项中的值。

referer

referer 标头将在解码期间进行清理。将删除多个 URL、包含片段组件的无效相对 URL 以及包含用户信息或片段组件的有效绝对 URL。

x-client-trace-id

如果外部客户端设置了此标头，Envoy 将使用内部生成的 x-request-id 将提供的跟踪 ID 加入。x-client-trace-id 需要全局唯一，建议生成 uuid4。如果设置了此标头，它与 x-envoy-force-trace 的效果类似。请参阅 tracing.client_enabled 运行时配置设置。

x-envoy-downstream-service-cluster

内部服务通常希望知道哪些服务正在调用它们。此标头从外部请求中清理，但对于内部请求，它将包含调用者的服务集群。请注意，在当前实现中，这应该被视为一个提示，因为它由调用者设置，并且可以被任何内部实体轻松伪造。将来，Envoy 将支持相互认证的 TLS 网状网络，这将使此标头完全安全。与 user-agent 一样，其值由 --service-cluster 命令行选项确定。为了启用此功能，您需要将 user_agent 选项设置为 true。

x-envoy-downstream-service-node

内部服务可能希望知道下游节点请求来自何处。此标头与 x-envoy-downstream-service-cluster 非常相似，只是其值取自 --service-node 选项。

x-envoy-external-address

服务希望根据原始客户端的 IP 地址执行分析是一个常见情况。根据关于 XFF 的冗长讨论，这可能会变得非常复杂，因此 Envoy 通过将 x-envoy-external-address 设置为 可信客户端地址 （如果请求来自外部客户端）来简化此过程。对于内部请求，x-envoy-external-address 不会设置或覆盖。此标头可以在内部服务之间安全地转发以用于分析目的，而无需处理 XFF 的复杂性。

x-envoy-force-trace

如果内部请求设置了此标头，Envoy 将修改生成的 x-request-id，使其强制收集跟踪。这还强制 x-request-id 返回响应标头中。如果此请求 ID 随后传播到其他主机，则这些主机上也会收集跟踪，这将为整个请求流提供一致的跟踪。请参阅 tracing.global_enabled 和 tracing.random_sampling 运行时配置设置。

x-envoy-internal

一个常见的场景是服务需要知道请求是否来自内部。Envoy 使用 XFF 来判断，并将该头部值设置为 true。

这样做是为了方便，避免解析和理解 XFF。

x-envoy-original-dst-host

使用 原始目标 负载均衡策略时，用于覆盖目标地址的头部。

除非通过 use_http_header 启用，否则会被忽略。

x-forwarded-client-cert

x-forwarded-client-cert (XFCC) 是一个代理头部，它指示了从客户端到服务器的请求经过的全部或部分客户端或代理的证书信息。代理可以在转发请求之前对 XFCC 头部进行清理、追加或转发。

XFCC 头部值是一个用逗号 (",") 分隔的字符串。每个子字符串是一个 XFCC 元素，包含单个代理添加的信息。代理可以在逗号后将当前客户端证书信息作为 XFCC 元素追加到请求的 XFCC 头部末尾。

每个 XFCC 元素是一个用分号 (";") 分隔的字符串。每个子字符串是一个键值对，用等号 ("=") 分隔。键不区分大小写，值区分大小写。如果值中出现 ",", ";" 或 "=", 则该值应使用双引号括起来。值中的双引号应替换为反斜杠双引号 (")。

支持以下键

  1. By 当前代理证书的主题备用名称 (URI 类型)。当前代理证书可能包含多个 URI 类型主题备用名称，每个名称将是一个单独的键值对。

  2. Hash 当前客户端证书的 SHA 256 摘要。

  3. Cert 整个客户端证书，以 URL 编码的 PEM 格式呈现。

  4. Chain 整个客户端证书链 (包括叶证书)，以 URL 编码的 PEM 格式呈现。

  5. Subject 当前客户端证书的主题字段。该值始终用双引号括起来。

  6. URI 当前客户端证书的 URI 类型主题备用名称字段。客户端证书可能包含多个 URI 类型主题备用名称，每个名称将是一个单独的键值对。

  7. DNS 当前客户端证书的 DNS 类型主题备用名称字段。客户端证书可能包含多个 DNS 类型主题备用名称，每个名称将是一个单独的键值对。

客户端证书可能包含多种主题备用名称类型。有关不同主题备用名称类型的详细信息，请参阅 RFC 2459.

以下是 XFCC 头部的一些示例

  1. 对于只有一个 URI 类型主题备用名称的客户端证书：x-forwarded-client-cert: By=http://frontend.lyft.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de688;Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=Test Client";URI=http://testclient.lyft.com

  2. 对于有两个 URI 类型主题备用名称的客户端证书：x-forwarded-client-cert: By=http://frontend.lyft.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de688;URI=http://testclient.lyft.com,By=http://backend.lyft.com;Hash=9ba61d6425303443c0748a02dd8de688468ed33be74eee6556d90c0149c1309e;URI=http://frontend.lyft.com

  3. 对于同时具有 URI 类型和 DNS 类型主题备用名称的客户端证书：x-forwarded-client-cert: By=http://frontend.lyft.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de688;Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=Test Client";URI=http://testclient.lyft.com;DNS=lyft.com;DNS=www.lyft.com

Envoy 处理 XFCC 的方式由 forward_client_cert_details 和 set_current_client_cert_details HTTP 连接管理器选项决定。如果 forward_client_cert_details 未设置，则 XFCC 头部默认情况下会被清理。

x-forwarded-for

x-forwarded-for (XFF) 是一个标准的代理头部，它指示了从客户端到服务器的请求经过的 IP 地址。符合标准的代理会在转发请求之前将最近客户端的 IP 地址 追加 到 XFF 列表中。以下是一些 XFF 的示例

  1. x-forwarded-for: 50.0.0.1 (单个客户端)

  2. x-forwarded-for: 50.0.0.1, 40.0.0.1 (外部代理跳跃)

  3. x-forwarded-for: 50.0.0.1, 10.0.0.1 (内部代理跳跃)

Envoy 只有在 use_remote_address HTTP 连接管理器选项设置为 true 并且 skip_xff_append 设置为 false 时才会追加到 XFF。这意味着，如果 use_remote_address 为 false (默认值) 或 skip_xff_append 为 true，连接管理器将在透明模式下运行，不会修改 XFF。

注意

通常，当 Envoy 作为边缘节点 (也称为前端代理) 部署时，use_remote_address 应设置为 true，而在 Envoy 用作网格部署中的内部服务节点时，则可能需要将其设置为 false。

use_remote_address 的值控制 Envoy 如何确定可信客户端地址。假设一个 HTTP 请求经过一系列零个或多个代理到达 Envoy，可信客户端地址是已知准确的第一个源 IP 地址。Envoy 与直接下游节点之间的连接的源 IP 地址是可信的。XFF有时是可以信任的。恶意客户端可以伪造 XFF，但如果可信代理添加了 XFF 中的最后一个地址，那么该地址是可以信任的。

或者，Envoy 支持 扩展 来确定可信客户端地址或原始 IP 地址。

注意

这些扩展的使用不能与 use_remote_address 或 xff_num_trusted_hops 混合使用。

Envoy 确定可信客户端地址的默认规则 (在追加任何内容到 XFF 之前) 是

  • 如果 use_remote_address 为 false 且请求中存在至少包含一个 IP 地址的 XFF，则可信客户端地址是 XFF 中的最后一个 (最右侧) IP 地址。

  • 否则，可信客户端地址是直接下游节点与 Envoy 之间连接的源 IP 地址。

在边缘 Envoy 实例前面有一个或多个可信代理的环境中，可以使用 xff_num_trusted_hops 配置选项来信任 XFF 中的额外地址。

  • 如果 use_remote_address 为 false 且 xff_num_trusted_hops 设置为大于零的值N，则可信客户端地址是 XFF 右端 (N+1) 个地址。 (如果 XFF 包含的地址少于 N+1 个，Envoy 会回退到使用直接下游连接的源地址作为可信客户端地址。)

  • 如果 use_remote_address 为 true 且 xff_num_trusted_hops 设置为大于零的值N，则可信客户端地址是 XFF 右端第 N 个地址。 (如果 XFF 包含的地址少于 N 个，Envoy 会回退到使用直接下游连接的源地址作为可信客户端地址。)

注意

如果可信客户端地址应从已知 CIDR 列表中确定，请改用 xff 原始 IP 检测选项。

  • 如果远程地址包含在 xff_trusted_cidrs 中的条目中，并且最后一个 (最右侧) 条目也包含在 xff_trusted_cidrs 中的条目中，则可信客户端地址是 XFF 中的倒数第二个 IP 地址。

  • 如果 XFF 中的所有条目都包含在 xff_trusted_cidrs 中的条目中，则可信客户端地址是 XFF 中的第一个 (最左侧) IP 地址。

Envoy 使用可信客户端地址的内容来确定请求是否来自外部或内部。这会影响是否设置 x-envoy-internal 头部。

示例 1：Envoy 作为边缘代理，前面没有可信代理
设置
use_remote_address = true
xff_num_trusted_hops = 0
请求详细信息
下游 IP 地址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1”
结果
可信客户端地址 = 192.0.2.5 (忽略 XFF)
X-Envoy-External-Address 设置为 192.0.2.5
XFF 更改为 “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
X-Envoy-Internal 被移除 (如果它存在于传入请求中)
示例 2：Envoy 作为内部代理，前面有示例 1 中的 Envoy 边缘代理
设置
use_remote_address = false
xff_num_trusted_hops = 0
请求详细信息
下游 IP 地址 = 10.11.12.13 (Envoy 边缘代理的地址)
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
结果
可信客户端地址 = 192.0.2.5 (XFF 中的最后一个地址是可信的)
X-Envoy-External-Address 未修改
X-Envoy-Internal 被移除 (如果它存在于传入请求中)
示例 3：Envoy 作为边缘代理，前面有两个可信外部代理
设置
use_remote_address = true
xff_num_trusted_hops = 2
请求详细信息
下游 IP 地址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1”
结果
可信客户端地址 = 203.0.113.10 （XFF 中倒数第二个地址为可信地址）
X-Envoy-External-Address 设置为 203.0.113.10
XFF 更改为 “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
X-Envoy-Internal 被移除 (如果它存在于传入请求中)
示例 4：Envoy 作为内部代理，在它前面是示例 3 中的边缘代理
设置
use_remote_address = false
xff_num_trusted_hops = 2
请求详细信息
下游 IP 地址 = 10.11.12.13 (Envoy 边缘代理的地址)
XFF = “203.0.113.128, 203.0.113.10, 203.0.113.1, 192.0.2.5”
结果
可信客户端地址 = 203.0.113.10
X-Envoy-External-Address 未修改
X-Envoy-Internal 被移除 (如果它存在于传入请求中)
示例 5：Envoy 作为内部代理，接收来自内部客户端的请求
设置
use_remote_address = false
xff_num_trusted_hops = 0
请求详细信息
下游 IP 地址 = 10.20.30.40 （内部客户端的地址）
XFF 不存在
结果
可信客户端地址 = 10.20.30.40
X-Envoy-External-Address 保持未设置
X-Envoy-Internal 设置为“false”
示例 6：示例 5 中的内部 Envoy，接收由另一个 Envoy 代理的请求
设置
use_remote_address = false
xff_num_trusted_hops = 0
请求详细信息
下游 IP 地址 = 10.20.30.50 （代理到此 Envoy 实例的 Envoy 实例的地址）
XFF = “10.20.30.40”
结果
可信客户端地址 = 10.20.30.40
X-Envoy-External-Address 保持未设置
X-Envoy-Internal 设置为“true”
示例 7：Envoy 作为边缘代理，具有一个可信 CIDR
设置
use_remote_address = false
xff_trusted_cidrs = 192.0.2.0/24
请求详细信息
下游 IP 地址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 192.0.2.1”
结果
可信客户端地址 = 192.0.2.1
X-Envoy-External-Address 设置为 192.0.2.1
XFF 更改为“203.0.113.128, 203.0.113.10, 192.0.2.1, 192.0.2.5”
X-Envoy-Internal 被移除 (如果它存在于传入请求中)
示例 8：Envoy 作为边缘代理，具有两个可信 CIDR
设置
use_remote_address = false
xff_trusted_cidrs = 192.0.2.0/24, 198.51.100.0/24
请求详细信息
下游 IP 地址 = 192.0.2.5
XFF = “203.0.113.128, 203.0.113.10, 198.51.100.1”
结果
可信客户端地址 = 203.0.113.10
X-Envoy-External-Address 设置为 203.0.113.10
XFF 更改为“203.0.113.128, 203.0.113.10, 198.51.100.1, 192.0.2.5”
X-Envoy-Internal 被移除 (如果它存在于传入请求中)

关于 XFF 的一些非常重要的注意事项

  1. 如果将 use_remote_address 设置为 true，Envoy 会将 x-envoy-external-address 标头设置为可信客户端地址。

  1. Envoy 使用 XFF 来确定请求是内部来源还是外部来源。如果将 use_remote_address 设置为 true，当且仅当请求不包含 XFF 且直接下游节点到 Envoy 的连接具有内部（RFC1918 或 RFC4193）源地址时，请求才是内部的。如果 use_remote_address 为 false，当且仅当 XFF 包含单个 RFC1918 或 RFC4193 地址时，请求才是内部的。

    • 注意：如果内部服务将外部请求代理到另一个内部服务，并包含原始 XFF 标头，如果 use_remote_address 设置为 true，Envoy 会在出站时对其进行追加。这会导致另一端认为请求是外部的。通常，如果 XFF 被转发，这就是预期的行为。如果这不是预期的行为，请不要转发 XFF，而是转发 x-envoy-internal。

    • 注意：如果内部服务调用被转发到另一个内部服务（保留 XFF），Envoy 不会将其视为内部服务。这是由于 XFF 解析方式的简化导致的已知“错误”，以便确定请求是否为内部请求。在这种情况下，请不要转发 XFF，并允许 Envoy 使用单个内部源 IP 生成新的 XFF。

x-forwarded-host

标头 x-forwarded-host 是一个事实上的标准代理标头，它指示客户端在标头 :authority（在 HTTP1 中为 host）中请求的原始主机。符合标准的代理仅在修改标头 :authority 时才将标头 :authority 的原始值附加到 x-forwarded-host。

如果使用主机重写选项（host_rewrite_literal、auto_host_rewrite、host_rewrite_header 或 host_rewrite_path_regex 之一），Envoy 会更新标头 :authority，如果设置了 append_x_forwarded_host，Envoy 会将原始值附加到 x-forwarded-host。

x-forwarded-port

通常，标头 x-forwarded-port 与标头 x-forwarded-proto 一起使用，以便服务知道连接的原始目标端口，该端口是 Envoy 侧的监听器端口。

如果将 append_x_forwarded_port 设置为 true 且标头尚未设置，Envoy 会追加标头 x-forwarded-port。

仅当 xff_num_trusted_hops 不为零时，才会信任下游 x-forwarded-port 标头。如果 xff_num_trusted_hops 为零，则会覆盖下游 x-forwarded-port 标头。

x-forwarded-proto

在服务想要了解由前端/边缘 Envoy 终止的连接的原始协议（HTTP 或 HTTPS）的情况下，这很常见。 x-forwarded-proto 包含此信息。它将被设置为 http 或 https 之一。

仅当 xff_num_trusted_hops 不为零时，才会信任下游 x-forwarded-proto 标头。如果 xff_num_trusted_hops 为零，则会将下游 x-forwarded-proto 标头和 :scheme 标头设置为 http 或 https，具体取决于下游连接是否为 TLS。

如果通过 scheme_header_transformation 配置选项更改了方案，则也会更新 x-forwarded-proto。

Envoy 将在底层加密所需的 :scheme 之上使用 x-forwarded-proto 标头，例如根据 x-forwarded-proto 清除默认端口。有关更多详细信息，请参阅 Envoy 为什么在 X-Forwarded-Proto 而不是 :scheme 上运行，反之亦然？。

x-envoy-local-overloaded

如果请求因 过载管理器 而被丢弃，并且 配置选项 设置为 true，Envoy 会在下游响应中设置此标头。

x-request-id

标头 x-request-id 用于 Envoy 唯一地标识请求，以及执行稳定的访问日志记录和跟踪。Envoy 会为所有外部来源请求生成 x-request-id 标头（标头已消毒）。它还会为没有 x-request-id 标头的内部请求生成 x-request-id 标头。这意味着 x-request-id 可以在客户端应用程序之间传播，并且应该在客户端应用程序之间传播，以便在整个网格中拥有稳定的 ID。由于 Envoy 的进程外架构，标头不能由 Envoy 本身自动转发。这是少数需要使用精简的客户端库来执行此任务的领域之一。具体怎么做超出了本文档的范围。如果 x-request-id 在所有主机之间传播，则可以使用以下功能

有关更多信息，请参阅 上下文传播 上的架构概述。

x-ot-span-context

标头 x-ot-span-context HTTP 标头用于 Envoy 在与 LightStep 跟踪器一起使用时在跟踪跨度之间建立正确的父子关系。例如，出站跨度是入站跨度的子跨度（如果存在入站跨度）。Envoy 在入站请求上注入 x-ot-span-context 标头，并将其转发到本地服务。Envoy 依赖应用程序在出站调用到上游时传播 x-ot-span-context。有关跟踪的更多信息，请参阅 此处。

x-b3-traceid

标头 x-b3-traceid HTTP 标头用于 Envoy 中的 Zipkin 跟踪器。TraceId 的长度为 64 位，表示跟踪的总体 ID。跟踪中的每个跨度都共享此 ID。有关 zipkin 跟踪的更多信息，请参阅 此处。

x-b3-spanid

标头 x-b3-spanid HTTP 标头用于 Envoy 中的 Zipkin 跟踪器。SpanId 的长度为 64 位，表示跟踪树中当前操作的位置。该值不应被解释：它可能也可能不源自 TraceId 的值。有关 zipkin 跟踪的更多信息，请参阅 此处。

x-b3-parentspanid

Envoy 中的 Zipkin 跟踪器使用 x-b3-parentspanid HTTP 标头。ParentSpanId 的长度为 64 位，表示跟踪树中父操作的位置。当跨度是跟踪树的根时，ParentSpanId 缺失。有关 zipkin 跟踪的更多信息，请 点击此处。

x-b3-sampled

Envoy 中的 Zipkin 跟踪器使用 x-b3-sampled HTTP 标头。当 Sampled 标志未指定或设置为 1 时，跨度将被报告给跟踪系统。一旦 Sampled 设置为 0 或 1，则应将相同的值一致地发送到下游。有关 zipkin 跟踪的更多信息，请 点击此处。

x-b3-flags

Envoy 中的 Zipkin 跟踪器使用 x-b3-flags HTTP 标头。该标头用于对一个或多个选项进行编码。例如，Debug 编码为 X-B3-Flags: 1。有关 zipkin 跟踪的更多信息，请 点击此处。

b3

Envoy 中的 Zipkin 跟踪器使用 b3 HTTP 标头。这是一种更压缩的标头格式。有关 zipkin 跟踪的更多信息，请 点击此处。

x-datadog-trace-id

Envoy 中的 Datadog 跟踪器使用 x-datadog-trace-id HTTP 标头。64 位值表示整个跟踪的 ID，用于关联跨度。

x-datadog-parent-id

Envoy 中的 Datadog 跟踪器使用 x-datadog-parent-id HTTP 标头。64 位值唯一标识跟踪中的跨度，用于创建跨度之间的父子关系。

x-datadog-sampling-priority

Envoy 中的 Datadog 跟踪器使用 x-datadog-sampling-priority HTTP 标头。整数值表示已为该跟踪做出的采样决策。值为 0 表示不应收集跟踪，值为 1 表示请求对跨度进行采样并报告。

sw8

Envoy 中的 SkyWalking 跟踪器使用 sw8 HTTP 标头。它包含 SkyWalking 跟踪器的关键跟踪上下文，用于建立下游和 Envoy 跟踪跨度之间的关系。有关 SkyWalking 跟踪的更多信息，请 点击此处。

x-amzn-trace-id

Envoy 中的 AWS X-Ray 跟踪器使用 x-amzn-trace-id HTTP 标头。跟踪 ID、父 ID 和采样决策将添加到跟踪标头中的 HTTP 请求中。有关 AWS X-Ray 跟踪的更多信息，请 点击此处。

自定义请求/响应标头

自定义请求/响应标头可以在加权集群、路由、虚拟主机和/或全局路由配置级别添加到请求/响应中。请参阅 v3 API 文档。

通过此机制不能修改 : 前缀伪标头或 Host: 标头。 :path 和 :authority 标头可以通过 prefix_rewrite、regex_rewrite 和 host_rewrite 等机制进行修改。

标头按以下顺序追加到请求/响应中：加权集群级别标头、路由级别标头、虚拟主机级别标头，最后是全局级别标头。

Envoy 支持向请求和响应标头添加动态值。百分号 (%) 用于分隔变量名。

注意

如果请求/响应标头中需要字面百分号 (%)，则必须通过将其加倍来转义。例如，要发出值为 100% 的标头，Envoy 配置中的自定义标头值必须为 100%%。

所有用于访问日志记录的 HTTP 命令运算符 都可以在自定义请求/响应标头中指定。但是，根据特定命令运算符的用途，可能无法获得运算符所需的上下文，并且生成的输出为空字符串。例如，以下配置使用 %RESPONSE_CODE% 运算符来使用响应代码修改请求标头。输出为空字符串，因为请求标头在请求发送到上游之前就被修改，并且响应尚未收到。

header_formatters.yaml
1          route_config:
2            name: local_route
3            request_headers_to_add:
4            - header:
5                key: "response-code"
6                value: "%RESPONSE_CODE%"

注意

以下旧版标头格式化程序仍然受支持，但将在将来弃用。可以使用指示的替代方法访问等效的信息。

%DYNAMIC_METADATA(["namespace", "key", ...])%

使用请求中可用的动态元数据填充标头（例如：由标头到元数据过滤器之类的过滤器添加）。

这适用于请求和响应标头。

使用 %DYNAMIC_METADATA(namespace:key:…):Z% 代替。

%UPSTREAM_METADATA(["namespace", "key", ...])%

使用 EDS 端点元数据 填充标头，该元数据来自路由器选择的上传输主机。可以从任何命名空间选择元数据。通常，元数据值可以是字符串、数字、布尔值、列表、嵌套结构或空值。可以从嵌套结构中选择上游元数据值，方法是指定多个键。否则，仅支持字符串、布尔值和数值。如果未找到命名空间或键，或者选定的值不是支持的类型，则不会发出任何标头。命名空间和键将作为字符串的 JSON 数组指定。最后，参数中的百分号 **不需要** 通过将其加倍来转义。

上游元数据无法添加到请求标头中，因为在生成自定义请求标头时尚未选择上游主机。

使用 %UPSTREAM_METADATA(namespace:key:…):Z% 代替。

%PER_REQUEST_STATE(reverse.dns.data.name)%

使用在流信息 filterState() 对象上设置的值填充标头。要使用自定义请求/响应标头，这些值必须为 Envoy::Router::StringAccessor 类型。这些值应该以标准的逆向 DNS 样式命名，标识创建值的组织，并在唯一名称之后以数据结尾。

使用 %FILTER_STATE(reverse.dns.data.name:PLAIN):Z% 代替。