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

AMP-кеш: формат URL-адресов и обработка запросов

В этом документе вы узнаете о формате URL-адресов кешированных AMP-документов и о том, как AMP-кеш обрабатывает запросы.

Формат URL-адресов

Поддомены для AMP-документов, размещенных в Google AMP Cache, генерируются на основе их исходного домена (когда это возможно). Вначале домен конвертируется из формата IDN (punycode) в UTF-8, затем все дефисы (-) заменяются на двойные дефисы (--), а точки (.) — на одиночные дефисы (-). Например, pub.com превращается в pub-com.cdn.ampproject.org.

Преобразовать URL-адрес в версию для AMP-кеша можно при помощи калькулятора URL-адресов:

Для преобразования URL-адреса источника в формат URL-адреса кешированного AMP-документа испольуйте модуль AMP-Toolbox Cache URL для Node.js.

Этот документ описывает:

  • Структуру URL-адресов в AMP-кеше.
  • Алгоритм преобразования URL-адреса AMP-страницы в адрес ее кешированной версии.
  • Алгоритм определения домена издателя по заголовку Origin, ссылающемуся на AMP-кеш.

Протокол

Все документы в AMP-кешах используют протокол https.

Суффикс доменного имени

Список существующих AMP-кешей доступен онлайн в репозитории AMPHTML в виде файла JSON. Вот пример записи в этом файле:

{
  "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).

В этом документе в качестве примеров используются URL-адреса с доменом cdn.ampproject.org, однако другие кеши обычно используют похожую структуру URL-адресов.

Префикс доменного имени

Для доступа к документам в AMP-кеше используются измененные URL-адреса (пример: example-com.cdn.ampproject.org). Первая часть, отделенная точкой, — это преобразованная версия исходного доменного имени (например, example.com превращается в example-com). В рамках данного документа не содержащая точек часть (например, example-com) называется доменным префиксом. Ниже приведен алгоритм для получения доменных префиксов.

Использование префиксов из нескольких частей, записанных через точку (например: example.com.cdn.ampproject.org), не допускается ввиду ограничения, накладываемого стандартом RFC 2818 на сертификаты https (TLS):

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 символов, в то время как длина доменного префикса ограничена 63 символами в соответствии с RFC 2181:

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 стоит дефис (-), добавьте к ней префикс 0- и суффикс -0. Разъяснение смотрите здесь: #26205.
  5. Получившуюся строку закодируйте в формат 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, то запускается резервный алгоритм, описанный ниже.

Доменный префикс не является допустимой меткой DNS, если его длина превышает 63 символа.

Резервный алгоритм

Резервный алгоритм преобразования домена издателя в доменный префикс выглядит так:

  1. Хешируйте домен издателя при помощи SHA256.
  2. Строку, получившуюся в результате шага 1, закодируйте при помощи Base32.
  3. Из строки, получившейся в результате шага 2, отбросьте 4 знака равенства (=), находящиеся в конце строки.

Резервный алгоритм генерирует строку из 52 символов, не содержащую дефисов (-), например: v2c4ucasgcskftbjt4c7phpkbqedcdcqo23tkamleapoa5o6fygq.

Комбинированный алгоритм

Комбинированный алгоритм выглядит так:

  1. Выполните основной алгоритм. Если в результате получится допустимая метка DNS, то добавьте к ней доменный суффикс кеша и верните ее в качестве результата (например: example-com.cdn.ampproject.org). В противном случае перейдите к шагу 2.
  2. Выполните резервный алгоритм. К сгенерированной строке добавьте доменный суффикс кеша, после чего верните ее в качестве результата (например: v2c4ucasgcskftbjt4c7phpkbqedcdcqo23tkamleapoa5o6fygq.cdn.ampproject.org).

Путь URL-адреса

«Путь» URL-адреса в AMP-кеше начинается с одного или нескольких директорий-префиксов, таких как /c. Далее, если URL-адрес издателя использует протокол https, следует инфикс /s. В конце идет URL-адрес документа издателя (без протокола).

Директории-префиксы, такие как /c, соответствуют различным типам ответов, которые может предоставлять AMP-кеш. AMP-кеши могут поддерживать различные типы ответов; вот некоторые из них:

  • /c — Content («контент»): AMP-документ, отображаемый в виде самостоятельной страницы; некоторые интерфейсы могут ссылаться на них напрямую.
  • /v — Viewer («средство просмотра»): это тоже AMP-документ, однако отображаемый с помощью средства просмотра AMP в специальном фрейме в контексте страницы результатов поиска или другого интерфейса.
  • /wp — Web Package («веб-пакет»): AMP-документ, выдаваемый в рамках подписанного обмена (разновидность веб-пакетов). Такие URL-адреса служат для перенаправления к собственному источнику издателя.
  • /cert — Certificate («сертификат»): открытый сертификат для использования в рамках подписанного обмена.
  • /i — Image («изображение»): изображение из AMP-кеша; обычно используется в качестве подресурса документа.
  • /ii — Image («изображение»): также изображение из AMP-кеша, но с возможностью дополнительной настройки результата — например, /ii/w800 для ограничения максимальной ширины, запрашиваемой документом. Кеш может генерировать изображения разных размеров, чтобы сократить объем данных, загружаемых браузером.

Кроме того, при обращении к AMP-кешу в URL-адресе документа могут использоваться специальные параметры запроса, не являющиеся частью исходного запроса к издателю. Например, когда компонент <amp-live-list> запрашивает обновления, то указывает при загрузке документа параметр amp_latest_update_time<. Эти параметры не передаются при индексировании документа его источнику и служат исключительно для уточнения запроса к AMP-кешу.

Источники CORS-запросов

Многие издатели используют CORS-запросы из AMP-документов для получения дополнительных данных. Функциональность CORS-запроса обеспечивается HTTP-заголовком Origin:, указывающим на источник документа. Как можно видеть выше, у документа в AMP-кеше адрес источника отличается от исходного документа. В разделах о доменных именах выше мы уже описывали алгоритм для определения домена URL-адреса кешированного AMP-документа по URL-адресу издателя. Ниже дается описание алгоритма, который выполняет обратное преобразование заголовка Origin: в CORS-запросе для получения исходного домена издателя.

Преобразование источника кешированного AMP-документа в домен издателя

Значение заголовка Origin в запросе, выполненном из кешированного AMP-документа, может выглядеть следующим образом:

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

Сначала следует отбросить префикс протокола (https://), а также доменный суффикс AMP-кеша (это может быть суффикс любого из кешей, указанных в файле caches.json, например .cdn.ampproject.org). Оставшаяся часть строки — это доменный префикс. В случае с двумя примерами, приведенными выше, доменные префиксы будут следующими:

  • 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-кеш следует перенаправлениям при разрешении URL-адресов AMP-страниц. Например, если при переходе по URL-адресу происходит перенаправление на другой URL-адрес AMP:

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

Тогда AMP-кеш вернет содержимое документа, на который происходит перенаправление с изначального URL-адреса.

Пример: https://amp-dev.cdn.ampproject.org/amp.dev/documentation/examples/api/redirect?url=https://amp.dev/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