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，从而为每个 AMP 文档的域名创建一个子域名。缓存将每个 ` - `（破折号）替换为`--`（两个破折号），并将每个`.`（点）替换为`-`（破折号）。例如，`pub.com` 将映射到 `pub-com.cdn.ampproject.org`。

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

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

本文档描述了

  • AMP 缓存上的 URL 结构。
  • 如何预测您的 URL 在 AMP 缓存上的显示方式。
  • 如何反向解析 AMP 缓存 Origin 标头以确定其发布商域名是什么。

域名协议

所有文档在 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` 称为“域名前缀”。有关执行此转换的算法，请参见下文。

由于 https（TLS）证书的约束，RFC 2818，在此前缀中不使用多个点分量，例如 `example.com.cdn.ampproject.org`

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 个字符，该 RFC 规定

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. Punycode 编码步骤 3 的输出。请参阅 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. Base32 转义步骤 1 的输出。
  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` 中缀，后跟不带协议的发布商文档的 URL。

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

  • `/c` - **C**ontent（内容）：这是一个作为独立页面提供的 AMP 文档，可以在某些界面中直接链接到该页面。
  • `/v` - **V**iewer（查看器）：这也是一个 AMP 文档，但是它在 AMP 查看器中提供，后者是一个框架环境，可在搜索结果页面或其他界面的上下文中显示 AMP 文档。
  • `/wp` - **W**eb **P**ackage（Web 包）：这是一个作为 Signed Exchange（一种 Web 包技术）提供的 AMP 文档。这些 URL 用作重定向到发布商自己的原始位置。
  • `/cert` - **Cert**ificate（证书）：这是一个公共证书，用于 Signed Exchange。
  • `/i` - **I**mage（图像）：这是由 AMP 缓存提供的图像，通常作为文档子资源。
  • `/ii` - **I**mage（图像）：这也是由 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 缓存 Origin 标头值将如下所示

  • 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 缓存如何处理重定向和错误的示例

重定向

AMP 缓存在解析 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 缓存将返回原始 URL 解析后的重定向内容。

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

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

未找到

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

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

无效的 AMP

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

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

服务器错误

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

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