支持 HTTP 响应标头

本页面适用于 Apigee 和 Apigee Hybrid。

查看 Apigee Edge 文档。

本主题介绍 Apigee 如何在使用 ResponseCache 政策时处理 HTTP/1.1 缓存标头。Apigee 目前支持 HTTP/1.1 缓存标头和从后端目标（源服务器）收到的指令（不受支持的功能列于此主题）的子集。

此外，使用某些标头时，Apigee 会根据其指令执行操作。在某些情况下，这些 HTTP/1.1 缓存标头会覆盖 ResponseCache 政策中指定的任何行为。例如，如果从后端服务器返回 Cache-Control 标头，则可以让标头的 s-maxage 指令替换政策中的其他有效期设置。

注意：HTTP/1.1 规范介绍了支持 HTTP 请求/响应链缓存的标准缓存标头和控制机制。这些标头和机制提供有关缓存资源的信息。它们也有助于服务器确定如何管理缓存数据。规范本身包含有关 HTTP 缓存的详细信息。此外，网络上还有许多博客、文章和其他资源来介绍 HTTP 缓存。

注意：使用标头影响缓存键和缓存条目 TTL：在构建响应缓存键并设置缓存时，Apigee 可以使用响应标头 TTL。为此，您将使用 ResponseCache 政策的这些标记元素：

• <UseResponseCacheHeaders> - 如果此属性设置为 true，则 Apigee 会考虑在缓存中设置响应的“存留时间”(TTL) 时使用的 HTTP 响应标头。如需了解详情，请参阅响应缓存政策中的“设置缓存条目有效期”和 <UseResponseCacheHeaders>。
• <UseAcceptHeader> - 如果将此标志设置为 true，Apigee 将使用响应 Accept 标头来增加缓存键。如需了解详情，请参阅响应缓存政策中的 <UseAcceptHeader>。

标题	支持
Cache-Control	支持从后端源服务器返回的响应，但不支持客户端请求。Apigee 支持部分指令。
到期	支持。可被替换。
实体标记 (ETag)	If-Match 和 If-None-Match 的特定行为。
If-Modified-Since	在 GET 请求中，即使存在有效的缓存条目，标头也会传递到源服务器。
Accept-Encoding	Apigee 会根据收到的标头发送经过压缩或未压缩的响应。

Cache-Control

Apigee 仅支持对从后端源服务器返回的响应执行 Cache-Control 标头（HTTP/1.1 规范允许客户端请求和源服务器响应中的 Cache-Control 标头）。源服务器可以包括 Apigee API 代理中定义的目标端点，以及使用 TargetServer API 调用创建的目标端点。

Cache-Control 支持限制

Apigee 支持 HTTP/1.1 规范中定义的 Cache-Control 响应标头功能子集。请注意以下事项：

• Apigee 不支持传入客户端请求的 Cache-Control 标头。
• Apigee 仅支持公开缓存的概念。（根据 HTTP 规范，Cache-Control 可以是公开（共享）或专用（单个用户）。）
• Apigee 仅支持 HTTP/1.1 规范中的 Cache-Control 响应指令的子集。如需了解详情，请参阅支持 Cache-Control 响应标头指令。

支持 Cache-Control 响应标头指令

Apigee 支持 HTTP/1.1 规范中的对源服务器响应的指令。下表说明了 Apigee 对 HTTP Cache-Control 响应标头指令的支持。

如需详细了解此处列出的指令，请参阅 HTTP/1.1 规范中的 Cache-Control。

Cache-Control 指令	Apigee 如何处理指令
cache-extension	不受支持。
max-age	如果您的 ResponseCache 政策将 <UseResponseCacheHeaders> 元素设置为 true，则可缓存此指令指定的秒数。 此指令会被 s-maxage 指令替换，并替换 Expires 标头。它也可以被政策的 <ExpirySettings> 元素替换。如需了解详情，请参阅响应缓存政策中的“设置缓存条目有效期”和 <UseResponseCacheHeaders>。 注意：使用 ResponseCache 政策缓存的内容将保留其来源设置的 max-age 值。这意味着，从缓存中检索内容时，内容可能超过建议的 max-age 值（超过客户端知道的时间）。
must-revalidate	不受支持。缓存条目过期后，Apigee 会立即删除所有缓存条目。
no-cache	Apigee 会缓存源响应，但在用于满足任何后续客户端请求之前，必须先使用源服务器重新验证它。此规则允许源返回 304 Not Modified 响应，以指明响应应该从缓存返回，从而保存返回整个响应所需的处理。如果源服务器返回完整响应，则它会替换现有的缓存条目。使用此指令指定的任何字段名称均会被忽略。 注意：HTTP/1.0 标头 Pragma: no-cache 被视为 Cache-Control: no-cache。
no-store	不受支持。
no-transform	不受支持。
private	不受支持。如果收到此指令，则不会缓存源响应。所有字段名称均会被忽略。
proxy-revalidate	不受支持。缓存条目过期后，Apigee 会立即删除所有缓存条目。
public	即使其他指令另有说明，Apigee 也会缓存源响应。根据 HTTP/1.1 规范，此规则的唯一例外情况是如果响应中包含授权标头。
s-maxage	如果您的 ResponseCache 政策将 <UseResponseCacheHeaders> 元素设置为 true，则可缓存此指令指定的秒数。 此指令将替换 max-age 指令和 Expires 标头。此属性可被政策的 <ExpirySettings> 元素替换。如需了解详情，请参阅响应缓存政策中的“设置缓存条目有效期”和 <UseResponseCacheHeaders>。 注意：使用 ResponseCache 政策缓存的内容将保留其来源设置的 s-maxage 值。这意味着，从缓存中检索内容时，内容可能超过建议的 s-maxage 值（超过客户端知道的时间）。

有效期

当 ResponseCache 政策中的 UseResponseCacheHeaders 标志设置为 true 时，Apigee 可以使用 Expires 标头来确定缓存条目的存留时间 (TTL)。此标头指定响应的缓存条目被视为过期的日期/时间。此标头允许服务器在根据时间戳返回缓存值时发出信号。

注意：Cache-Control 标头指令 max-age 和 s-maxage 优先于 Expires 标头。如需了解详情，请参阅响应缓存政策中的“设置缓存条目有效期”和 <UseResponseCacheHeaders>。

HTTP/1.1 规范中介绍了 Expires 标头的可接受日期格式。例如：

有效期：1994 年 12 月 1 日星期四 16:00:00 GMT

如需详细了解 HTTP 日期/时间格式，请参阅 HTTP/1.1 规范中的日期/时间格式。

注意：虽然规范的第 14.21 部分表示，一年之后的 Expires 值表示缓存条目永不过期，但 Apigee 解释如下：这样的值表示条目应在指定的日期和时间之前缓存。

如需详细了解 Expires 标头，请参阅 HTTP/1.1 规范中的标头字段定义。

ETag

实体标记 (ETag) 是与所请求的资源关联的标识符。服务器可以使用 ETag，确定所请求的资源和关联的缓存资源是否匹配。例如，如果服务器与当前缓存的内容不匹配，服务器可能会重新缓存响应。如果 ETag 匹配，则系统可能会返回缓存的资源。

当目标端点使用 ETag 将响应发回 Apigee 时，Apigee 会缓存 ETag 以及响应。

如需详细了解实体标记，请参阅 HTTP/1.1 规范中的协议参数。

If-Match

使用 If-Match 请求标头时，如果标头中的 ETag 与缓存的 ETag 匹配，则缓存实体为当前状态。任何指定了 If-Match 标头的 GET 请求之外的所有请求都会传递到源服务器，以确保任何源缓存工具有机会处理请求。

如需详细了解 If-Match，请参阅 HTTP/1.1 规范中的标头字段定义。

如果 Apigee 收到来自包含 If-Match 标头的客户端的传入 GET 请求，那么：

如果	那么
If-Match 标头指定一个或多个 ETag	Apigee 会检索指定资源的所有未过期的缓存条目，并将这些缓存条目中的任何强 ETag 与 If-Match 标头中指定的条目进行比较。 如果找到匹配项，则会返回缓存条目。 否则，请求会传递到源服务器。
If-Match 标头指定“*”	请求会传递到源服务器，以确保任何源缓存工具有机会处理请求
已找到具有相同请求 URI 的缓存条目，但它只包含弱 ETag	该条目必须经过源服务器重新验证，然后才会返回客户端
ETag 来自源服务器。	将 ETag 返回给客户端

If-None-Match

使用 If-None-Match 标头时，如果标头中的 ETag 与缓存的 ETag 不匹配，则缓存实体为当前对象。包含此标头的 GET 以外的请求会传递到源服务器。

如果 Apigee 收到以下标头的传入 GET 请求：

如果	那么
If-None-Match 标头指定一个或多个 ETag	Apigee 会检索指定 URI 中所有未过期的缓存条目，并将这些缓存条目中的任何强 ETag 与 If-None-Match 标头中指定的那些条目进行比较。 如果找到匹配项，Apigee 将返回 304 Not Modified 状态。如果未找到匹配项，Apigee 会将该请求传递到源服务器。
If-None-Match 标头为请求的 URI 指定“*”和未过期的缓存条目	Apigee 返回 304 Not Modified 状态
包含相同请求 URI 的缓存条目，但只包含弱 ETag	必须经过源服务器重新验证条目，然后 Apigee 才会将其返回给客户端
Apigee 从源服务器接收 ETag	将 ETag 返回给客户端

If-Modified-Since

如果 Apigee 在 GET 请求中收到 If-Modified-Since 标头，即使存在有效的缓存条目，系统也会将其传递给源服务器。

这确保所有未通过 Apigee 的资源更新都计算在内。如果源服务器返回新实体，则 Apigee 会将现有缓存条目替换为新值。如果服务器返回 304 Not Modified 状态，并且如果缓存的响应的 Last-Modified 标头指示未更改，则 Apigee 会返回响应值。

Accept-Encoding

如果传入请求包含标头 Accept-Encoding、值为 gzip、deflate 或 compress，则源服务器会以压缩数据做出响应。如果后续请求没有 Accept-Encoding 标头，则它们希望未经压缩的响应。Apigee 的响应缓存机制能够根据传入的标头发送压缩和未压缩的响应，而无需返回源服务器。

您可以为缓存键附加 Accept 标头值，以使每个缓存项的键更加有意义。如需了解详情，请参阅响应缓存政策中的“配置缓存键”。