您正在查看的是 Apigee Edge 文档。
转到 Apigee X 文档。 信息
本主题介绍了在使用 ResponseCache 政策时,Edge 如何处理 HTTP/1.1 缓存标头。Apigee Edge 目前支持从后端目标(源)服务器接收的一部分 HTTP/1.1 缓存标头和指令(本主题中列出了不受支持的功能)。
此外,对于某些标头,Edge 会根据其指令执行操作。在某些情况下,这些 HTTP/1.1 缓存标头会覆盖 ResponseCache 政策中指定的任何行为。例如,如果从后端服务器返回 Cache-Control
标头,则可以让标头的 s-maxage
指令替换政策中的其他有效期设置。
标题 | 支持 |
---|---|
Cache-Control | 支持从后端源服务器返回的响应,但不支持客户端请求。Edge 支持部分指令。 |
到期 | 受支持。 可被替换。 |
实体标记 (ETag) | If-Match 和 If-None-Match 的特定行为。 |
If-Modified-Since | 在 GET 请求中,即使存在有效的缓存条目,标头也会传递到源服务器。 |
Accept-Encoding | 边缘会发送压缩或未压缩的响应,具体取决于传入标头。 |
Cache-Control
Apigee Edge 仅针对从后端源服务器返回的响应支持 Cache-Control
标头(HTTP/1.1 规范允许在客户端请求和源服务器响应中使用 Cache-Control
标头)。源服务器可以包括 Apigee Edge API 代理中定义的目标端点以及使用 TargetServer API 调用创建的目标端点。
Cache-Control 支持限制
Apigee Edge 支持 HTTP/1.1 规范中定义的 Cache-Control
响应标头功能子集。请注意以下事项:
- Apigee Edge 不支持随入站客户端请求到达的
Cache-Control
标头。 - Apigee Edge 仅支持公共缓存的概念。(根据 HTTP 规范,
Cache-Control
可以是公开(共享)或专用(单个用户)。) - Apigee Edge 仅支持 HTTP/1.1 规范中的一部分
Cache-Control
响应指令。如需了解详情,请参阅支持 Cache-Control 响应标头指令。
支持 Cache-Control 响应标头指令
Apigee 支持 HTTP/1.1 规范中的对源服务器响应的指令。下表介绍了 Apigee Edge 对 HTTP Cache-Control 响应标头指令的支持。
如需详细了解此处列出的指令,请参阅 HTTP/1.1 规范中的 Cache-Control。
Cache-Control 指令 | Apigee Edge 如何处理指令 |
cache-extension |
不受支持。 |
max-age |
如果您的 ResponseCache 政策将 此指令会被 |
must-revalidate |
不支持。 所有缓存条目过期后,Apigee Edge 都会立即将其删除。 |
no-cache |
边缘会缓存源站响应,但必须先通过源服务器重新验证该响应,然后才能用于满足任何后续客户端请求。此规则允许源返回 304 Not Modified 响应,以指明响应应该从缓存返回,从而保存返回整个响应所需的处理。如果源服务器返回完整响应,则它会替换现有的缓存条目。使用此指令指定的任何字段名称均会被忽略。 |
no-store |
不受支持。 |
no-transform |
不受支持。 |
private |
不受支持。如果收到此指令,则不会缓存源响应。所有字段名称均会被忽略。 |
proxy-revalidate |
不支持。 所有缓存条目过期后,Apigee Edge 都会立即将其删除。 |
public |
即使其他指令另有指示,边缘也会缓存来源响应。根据 HTTP/1.1 规范,此规则的唯一例外情况是如果响应中包含授权标头。 |
s-maxage |
如果您的 ResponseCache 政策将 此指令将替换 |
有效期至:
当 ResponseCache 政策中的 UseResponseCacheHeaders
标志设置为 true
时,Edge 可以使用 Expires
标头确定缓存条目的存留时间 (TTL)。此标头指定响应的缓存条目被视为过期的日期/时间。此标头允许服务器在根据时间戳返回缓存值时发出信号。
HTTP/1.1 规范中介绍了 Expires
标头的可接受日期格式。例如:
有效期:1994 年 12 月 1 日星期四 16:00:00 GMT
如需详细了解 HTTP 日期/时间格式,请参阅 HTTP/1.1 规范中的日期/时间格式。
如需详细了解 Expires
标头,请参阅 HTTP/1.1 规范中的标头字段定义。
ETag
实体标记 (ETag) 是与所请求的资源关联的标识符。服务器可以使用 ETag,确定所请求的资源和关联的缓存资源是否匹配。例如,如果服务器与当前缓存的内容不匹配,服务器可能会重新缓存响应。如果 ETag 匹配,则系统可能会返回缓存的资源。
当目标端点将带有 ETag 的响应发回给 Edge 时,Edge 会将 ETag 随响应一同缓存。
如需详细了解实体标记,请参阅 HTTP/1.1 规范中的协议参数。
If-Match
使用 If-Match
请求标头时,如果标头中的 ETag 与缓存的 ETag 匹配,则缓存实体为当前状态。任何指定了 If-Match
标头的 GET 请求之外的所有请求都会传递到源服务器,以确保任何源缓存工具有机会处理请求。
如需详细了解 If-Match
,请参阅 HTTP/1.1 规范中的标头字段定义。
如果 Edge 收到来自包含 If-Match
标头的客户端的入站 GET 请求:
如果 | Then |
---|---|
If-Match 标头指定一个或多个 ETag |
|
If-Match 标头指定“*” |
请求会传递到源服务器,以确保任何源缓存工具有机会处理请求 |
已找到具有相同请求 URI 的缓存条目,但它只包含弱 ETag | 该条目必须经过源服务器重新验证,然后才会返回客户端 |
ETag 来自源服务器。 | 将 ETag 返回给客户端 |
If-None-Match
使用 If-None-Match
标头时,如果标头中的 ETag 与缓存的 ETag 不匹配,则缓存实体为当前对象。包含此标头的 GET 以外的请求会传递到源服务器。
如果 Edge 收到包含以下标头的入站 GET 请求:
如果 | Then |
---|---|
If-None-Match 标头指定一个或多个 ETag |
|
|
Edge 会返回“304 Not Modified”状态 |
包含相同请求 URI 的缓存条目,但只包含弱 ETag | 条目必须由源服务器重新验证,然后 Edge 才能将其返回给客户端 |
Edge 从源服务器接收 ETag | 将 ETag 返回给客户端 |
If-Modified-Since
如果 Apigee Edge 在 GET 请求中收到 If-Modified-Since
标头,即使存在有效的缓存条目,该标头也会被传递给源服务器。
这可确保所有未通过 Apigee Edge 的资源更新都得到统计。如果源服务器返回新实体,则 Edge 会使用新值替换现有的缓存条目。如果服务器返回 304 Not Modified 状态,并且已缓存响应的 Last-Modified
标头指示未更改,Edge 会返回响应值。
Accept-Encoding
如果传入请求包含标头 Accept-Encoding
、值为 gzip
、deflate
或 compress
,则源服务器会以压缩数据做出响应。如果后续请求没有 Accept-Encoding
标头,则它们希望未经压缩的响应。Apigee 的响应缓存机制能够根据传入的标头发送压缩和未压缩的响应,而无需返回源服务器。
您可以为缓存键附加 Accept 标头值,以使每个缓存项的键更加有意义。如需了解详情,请参阅响应缓存政策中的“配置缓存键”。