AMP
EN
Deutsch Français العربية Español Italiano Indonesia 日本語 한국어 Português Русский Türkçe 中文 Polski Tiếng việt

AMP 缓存 URL 格式和请求处理

本文档将介绍 AMP 缓存 URL 格式以及如何处理请求。

URL 格式

在可能的情况下，Google AMP 缓存将为每个 AMP 文档的域创建一个子域，方法是先将其从 IDN（Punycode） 转换为 UTF-8。缓存会将每个 -（破折号）替换为 --（两个破折号），并将每个 .（点号）替换为 -（破折号）。例如，pub.com 将映射到 pub-com.cdn.ampproject.org。

您可以使用此 URL 计算器将 URL 转换为 AMP 缓存版本

使用 AMP-Toolbox 缓存 URL Node.js 模块将 URL 从原始格式转换为 AMP 缓存 URL 格式。

本文档介绍了

  • AMP 缓存上的 URL 结构。
  • 如何预测您的 URL 在 AMP 缓存上的显示方式。
  • 如何反转 AMP 缓存来源标头以确定其发布者域。

域名协议

所有文档在 AMP 缓存上都使用 https 协议。

域名后缀

所有 AMP 缓存都在一个 JSON 文件中注册，该文件可以在 AMPHTML 存储库 上找到。此文件中的缓存记录示例将如下所示

{
  "id": "google",
  "name": "Google AMP Cache",
  "docs": "https://developers.google.com/amp/cache/",
  "cacheDomain": "cdn.ampproject.org",
  "updateCacheApiDomainSuffix": "cdn.ampproject.org",
  "thirdPartyFrameDomainSuffix": "ampproject.net"
},

AMP 缓存在 cacheDomain 指定的域上提供记录。在这种情况下，域是 cdn.ampproject.org。

本文档使用以 cdn.ampproject.org 为例的 URL，但其他缓存通常使用类似的 URL 结构。

域名前缀

AMP 缓存在修改后的 URL 上提供文档，例如 example-com.cdn.ampproject.org。示例中原始域名 example.com 的第一个带点的组件变为 example-com。本文档将此不带点的字符串 example-com 称为“域名前缀”。有关执行此转换的算法，请参见下文。

此前缀不使用多个带点的组件，例如 example.com.cdn.ampproject.org，这是由于 https (TLS) 证书的限制，RFC 2818

Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com.

发布者域的长度最多可以为 255 个字符，而根据 RFC 2181 的规定，每个域名前缀的长度限制为 63 个字符

The length of any one label is limited to between 1 and 63 octets.  A full domain name is limited to 255 octets (including the separators).

所有发布者域都映射到唯一的域名前缀。执行此操作的算法会尝试使映射具有可读性。但是，如果发布者域太长，并且在以下描述的情况下，映射会恢复为使用安全哈希

基本算法

将发布者域转换为域名前缀的基本算法如下

  1. 对发布者域进行 Punycode 解码。请参见 RFC 3492
  2. 将步骤 1 输出中的任何 "-"（连字符）字符替换为 "--"（两个连字符）。
  3. 将步骤 2 输出中的任何 "."（点号）字符替换为 "-"（连字符）。
  4. 如果步骤 3 的输出在第 3 个和第 4 个位置都有 "-"（连字符），则在步骤 3 的输出中添加 "0-" 前缀，并添加 "-0" 后缀。有关背景信息，请参见 #26205。
  5. 对步骤 3 的输出进行 Punycode 编码。请参见 RFC 3492

基本算法的一些示例

发布者域 域名前缀
example.com example-com
foo.example.com foo-example-com
foo-example.com foo--example-com
xn--57hw060o.com (⚡😊.com) xn---com-p33b41770a (⚡😊-com)
en-us.example.com 0-en--us-example-com-0

仅当域名前缀不是有效的 DNS 标签时，在运行基本算法后，我们才运行下面描述的备用算法。

如果域名前缀的长度超过 63 个字符，则不是有效的 DNS 标签

备用算法

将发布者域转换为域名前缀的备用算法如下

  1. 使用 SHA256 对发布者的域进行哈希处理。
  2. 对步骤 1 的输出进行 Base32 转义。
  3. 删除步骤 2 输出的最后 4 个字符，它们始终是 =（等于）字符。

备用算法将生成一个 52 个字符的字符串，如下所示，没有 -（连字符）：v2c4ucasgcskftbjt4c7phpkbqedcdcqo23tkamleapoa5o6fygq。

组合算法

组合算法为

  1. 运行基本算法。如果输出是有效的 DNS 标签，则附加缓存域名后缀并返回，例如 example-com.cdn.ampproject.org。否则，继续执行步骤 2。
  2. 运行备用算法。附加缓存域名后缀并返回，例如：v2c4ucasgcskftbjt4c7phpkbqedcdcqo23tkamleapoa5o6fygq.cdn.ampproject.org

URL 路径

AMP 缓存上 URL 的“路径”始终由一个或多个前缀目录组成，例如 /c，如果发布者 URL 为 http s，则仅后跟一个 /s 中缀，后跟不带协议的发布者文档的 URL。

前缀目录（例如 /c）对应于 AMP 缓存可能执行的不同类型的服务。不同的 AMP 缓存可能支持不同的服务类型，这不是一个详尽的列表

  • /c - Content：这是一个 AMP 文档，作为独立页面提供，可以在某些界面中直接链接到该页面。
  • /v - Viewer：这也是一个 AMP 文档，但在 AMP Viewer 中提供，该查看器是一个框架环境，可在搜索结果页面或其他界面的上下文中显示 AMP 文档。
  • /wp - Web Package：这是一个 AMP 文档，作为 Signed Exchange（一种 Web Package 技术）提供。这些 URL 用作重定向到发布者自己的来源。
  • /cert - Certificate：这是一个公用证书，用于 Signed Exchange。
  • /i - Image：这是由 AMP 缓存提供的图像，通常作为文档子资源。
  • /ii - Image：这也是 AMP 缓存提供的图像，但通常可以与其他缓存配置参数（例如 /ii/w800）结合使用，后者指示文档请求的最大宽度。缓存可以在此处生成具有不同比例的图像，以节省浏览器的带宽。

此外，AMP 缓存可以选择将特殊的查询参数附加到文档 URL，这些参数不是发布者文档查询的一部分。例如，<amp-live-list> 通过使用参数 amp_latest_update_time< 获取文档来发出刷新请求。这些参数不会在爬取文档时传递到原始地址，而严格用于配置对 AMP 缓存的请求。

CORS 来源

许多发布者使用其 AMP 文档的 CORS 请求来检索额外数据。CORS 请求的工作方式是在请求中发送一个 Origin: HTTP 标头，指定发出请求的文档的来源。如上所示，文档的来源在 AMP 缓存上与原始文档上的来源不同。在上面的域名部分中，您可以找到根据发布者 URL 确定 AMP 缓存 URL 的来源的算法。下面我们指定反向算法，用于将 CORS Origin: 请求标头解码回原始发布者域。

AMP 缓存来源到发布者域

AMP 缓存来源标头值将类似于以下示例之一

  • https://www-example-com.cdn.ampproject.org
  • https://v2c4ucasgcskftbjt4c7phpkbqedcdcqo23tkamleapoa5o6fygq.cdn.ampproject.org

首先，删除协议前缀 (https://) 和 AMP 缓存域名后缀，例如 .cdn.ampproject.org。后缀可以来自 caches.json 中列出的任何一个缓存。剩余的字符串将是“域名前缀”。对于以上两个示例，“域名前缀”为

  • www-example-com
  • v2c4ucasgcskftbjt4c7phpkbqedcdcqo23tkamleapoa5o6fygq

接下来，检查“域名前缀”是否包含至少一个 ‘-’（连字符）。包含一个或多个连字符是最常见的情况。如果“域名前缀”不包含至少一个 ‘-’（连字符），则无法直接反转 AMP 缓存来源。相反，如果您知道可能的发布者域集，则可以使用本文档前面介绍的域名算法创建 AMP 缓存来源集。然后，您可以根据固定集进行验证。

算法的其余部分假定“域名前缀”包含至少一个 ‘-’（连字符）。

  1. 如果域名前缀以 xn-- 开头，请对“域名前缀”进行 punycode 解码。例如 xn---com-p33b41770a 变为 ⚡😊-com。有关 punycode，请参见 RFC 3492。
  2. 如果域名前缀以 "0-" 开头并以 "-0" 结尾，则去除 "0-" 前缀和 "-0" 后缀。
  3. 按顺序迭代步骤 2 输出的字符，并按遇到顺序发出它们。当遇到 "-" (连字符) 时，查看下一个字符。如果下一个字符也是 "-" (连字符)，则跳过输入中的这两个字符，并发出一个 "-" (连字符)。如果下一个字符是任何其他字符，则仅跳过当前单个 "-" (连字符)，并发出一个 "." (点)。例如，a--b-example-com 变为 a-b.example.com。
  4. 对步骤 3 的结果进行 Punycode 编码。有关 Punycode，请参阅 RFC 3492。

步骤 4 的结果将是发布者域名。协议本身无法从域中获取，但为 http 或 https。端口始终是协议的默认端口。

重定向 & 错误处理

以下是一些关于 AMP Cache 如何处理重定向和错误的示例

重定向

AMP Cache 在解析 AMP URL 时会遵循重定向。例如，如果 URL 重定向到另一个 AMP URL

$ curl -I https://amp.org.cn/documentation/examples/api/redirect?url=https://amp.org.cn/index.amp.html
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://amp.org.cn/index.amp.html
...

那么 AMP Cache 将返回原始 URL 的已解析重定向的内容。

示例：https://amp-dev.cdn.ampproject.org/amp.dev/documentation/examples/api/redirect?url=https://amp.org.cn/index.amp.html。

如果您移动服务器上 AMP 文件的位置，请确保设置从旧位置到新位置的重定向。

未找到

当在 AMP Cache 中找不到页面时，它将显示一个错误页面并返回 404 状态。

示例：https://amp-dev.cdn.ampproject.org/amp.dev/documentation/examples/api/not-found

无效 AMP

当页面是无效的 AMP 时，AMP Cache 将重定向到规范页面。

示例：https://amp-dev.cdn.ampproject.org/amp.dev/documentation/examples/api/invalid-amp

服务器错误

如果 URL 返回 5XX 服务器错误，AMP Cache 将返回 404 状态。

示例：https://amp-dev.cdn.ampproject.org/amp.dev/documentation/examples/api/server-error