когда Яндекс берет заголовок для сниппета не из тега Title — Сосновский.ру

🖖 Недавно я опубликовал пост о том, как бесплатно получать ссылки с главных страниц форумов в свой телеграм @sosnovskij. Туда я публикую посты, не попадающих под формат блога. Подключайся! 🔌.

Привет, друзья! Ровно полгода назад команда поиска Яндекса анонсировала новость о том, что заголовок сниппета сайта в поисковой выдаче может выбираться не только из тега title, но еще из заголовков на самой странице ресурса.

Обычно после подобных анонсов еще какое-то время тестируются функции и вносятся поправки. На данный момент прошло 6 месяцев, в течение которых данный механизм должен был устояться. В посте я разберу случаи, при которых в заголовок сниппета Яндекс берет фразы из контента страницы, а также интересные особенности.

Буквально вчера я создал экспериментальную страницу, которая стала плацдармом для получения актуальных данных по этому вопросу. Кстати, спасибо тем, кто поддержал ее в социальных сетях 

.

За час она попала в Яндекс и Google. Сразу можно было делать анализ.

В первую очередь, нужно было разобраться, зачем вообще нашему зеркалу рунета нужно было данное нововведение. Title не всегда качественно описывает страницу, либо этот тег вообще может быть не заполнен. Также в нем может не содержаться запрос или его часть. В этих случаях, как пишет Яндекс, заголовок может браться непосредственно из заголовков страницы, которые могут оказаться наиболее информативными для пользователя.

В принципе верное решение. Например, вы пишите статью «Как создать веб-ресурс в интернете» с одноименным тегом тайтл, и решили освятить в ней все популярные моменты:

— Создание сайта на Joomla.
— Создание сайта на WordPress.
— Бесплатные конструкторы веб-проектов.

Это были заголовки на странице. Пользователь задает запрос поисковой машине «создание сайтов на wordpress». Ваша страница оказывается ему релевантна. Какой заголовок в выдаче будет более привлекательнее «Создание сайта на WordPress» или «Как создать веб-ресурс в интернете».

Естественно, первый вариант 

.

Как правило, под заголовком довольно подробно раскрывается его суть. Поэтому Яндекс решил брать информацию для заголовка сниппета именно оттуда: на странице, в большинстве случаев, будет информация, которая интересует пользователя.

Как обычно формируются подзаголовки на странице? Верно, тегами h и жирным выделением: теги b и strong. Вот из текстов в этих тегах отечественный поисковик и может составлять заголовки в выдаче. Но не все так просто — у этого механизма есть свои особенности. О них как раз ниже 

.

Содержание:

• h2-h4
• b и strong
• Жирный маркированный список
• Яндекс.Каталог и DMOZ
• b, strong и <br>
• Выводы
• А что же в Google?

h2-h4

Текст в этих тегах может появляться в заголовках сниппета (может быть, в h5-h6 тоже, но я не проверял). Причем в качестве запроса может быть содержание всего тега, либо его часть, с точкой или без на конце.

Часть заголовка h2. Title страницы «Последствия возникновения внутренних дублей на сайте, их поиск и удаление».

Полностью h4. Title страницы «Продвижение сайта в разных регионах».

b и strong

Несмотря на то, что по значению эти 2 тега разделяются, Яндекс в данном случае ставит их в равенство. То есть неважно, что вы используете для выделения жирным b или strong. Механизм будет работать одинаково. Пример для стронга (из экспериментальной страницы).

Жирный маркированный список

Выделение жирным работает также и в маркированном списке.

Для сведения, стронгом я выделял каждый пункт в маркированном списке, а не сразу целый блок. А вот с нумерованным списком такое не прошло.

Почему не вышло? Есть идеи 

?

Если запрос пользователя совпадает полностью с подзаголовком на странице, то большая вероятность, что он будет в заголовке сниппета в Яндексе. Также он показывается, когда пользователем запрашивается только его часть. Но эти 2 случая не являются гарантом (это касается также h2-h4).

Яндекс.Каталог и DMOZ

Конечно, это частный случай, который не подходит под описываемый механизм, но который подходит под тему поста. Иногда заголовок в серпе формируется из названия сайта в Яндекс-каталоге. Еще реже из описания DMOZ’а.

b, strong и <br>

Буквально на днях при анализе клиентского сайта наткнулся на конструкцию, которая очень интересно себя ведет. Это выделение жирным (b или strong — без разницы), а также переход на новую строку <br>. Смотрите сами.

Чем привлекательна данная конструкция? Во-первых, она срабатывает с большой долей вероятности. Во-вторых, в заголовок попадает не только выделенная фраза, но еще и некоторый текст после. Этот момент можно использовать в своих целях 

.

Здесь я не использовал точку после жирного выделения. Возможно, с ней выдача будет вести себя по-другому. Есть «положительные» конструкции с запятой в стронге, но вот дефис повел себя иначе.

А вот запрос без дефиса.

Таким образом, в данном случае лучше не использовать дефисы, знаки препинания и так далее.

Что я еще проверял? На всякий случай я проверил следующие виды «выделений» текста:

• цитата;
• маркированный список;
• нумерованный список;
• зачеркнутый текст;
• подчеркнутый текст;
• курсив

Эксперимент подтвердил мою гипотезу, что все это не появляется в заголовке сниппета.

Выводы

1) Страница со структурированным заголовками может привлекать на себя больше внимания в поисковой выдаче благодаря новому механизму в Яндексе.

2) Вряд ли подзаголовки увеличили свой вес при ранжировании. Скорее всего, изменения коснулись только представления сайта в SERP. Другими словами, они улучшают вид ресурса в выдаче, но появляются только для релевантного контента.

3) В выдаче в качестве заголовков могут выступать фразы в тегах h, strong, b, а также текст после 2-х последних, разделенный переносом строки <br>.

4) Подзаголовки на сайте могут появляться как при полном совпадении, так и при частичном.

5) b=strong.

6) Текст, выделенный стронгом или b, но находящийся в середине абзаца, не должен появиться в качестве заголовка. Данный механизм, скорее всего, рассчитан только на отдельные конструкции подзаголовков.

7) Иногда знаки препинания и, например, дефисы ведут себя неоднозначно. В заголовках лучше воздержаться от них, если есть желание, чтобы они попали в сниппет.

8 ) Вряд ли, вы встретите подобные конструкции для высокочастотных или высококонкурентных запросов. Чаще они будут появляться для низкочастотников.

9) Это дополнительный «инструмент», благодаря которому можно частично влиять на SERP.

А что же в Google?

В Google подобные вещи не замечал, хотя встречаются мнения о том, что и в этом поисковике не всегда title «во главе». Нашел только такой пример.

Тайтл у страницы следующий — «Продвижение сайтов | Сосновский.ру — оптимизатор по жизни — Страница 6» (запрос «яндекс каталог»). Я так понимаю, цифра 6 была взята из анкора ссылки, которая находится в навигации 

. Она и в title находится, но там другой порядок.

Замечали ли вы подобные вещи на своих сайтах? Какие бы еще выделили моменты, при которых заголовок для сниппета сайта берется не из тега title? С нетерпением жду ваши отзывы и комментарии 

.

Создание писем с возможностью отписки через заголовок «List-Unsubscribe» в Яндекс и Gmail (Mail.ru — не рекомендуется) / Хабр

Сразу оговорюсь и скажу, что метод работает и с другими почтовыми сервисами. В данной статье были протестированы только Яндекс, Gmail и Mail.ru.

Современные почтовые сервисы поддерживают обработку заголовка List-Unsubscribe. Если этот заголовок есть, то сервис выведет кнопку для отписки от вашей рассылки.

Почему это нельзя использовать для писем mail.ru, описано в самом конце статьи.

Это полезно и удобно. Полезность кнопки «отписаться» заключается в следующем: те, кому ваша рассылка неинтересна, нажмут «Отписаться» вместо «Это спам» с большей долей вероятности, чем если бы этой кнопки не было. В итоге довольный подписчик и чистая карма вашей рассылки и домена рассылки в целом.

Опишу частый случай, приводящий к негативным последствиям и попаданию рассылок в спам.

Мы заходим в интернет-магазин и покупаем хорошую вещь по достаточно низкой цене. Мы же все знаем, что покупка в интернете часто на порядок дешевле, чем в компьютерных супермаркетах. Впрочем, и у самых известных компьютерных супермаркетов давно есть свои интернет-витрины с ценами ниже, чем в их розничных филиалах.

Итак, мы добавили товар в корзину, и нам предлагают зарегистрироваться. Мы довольны и хотим прийти сюда снова, конечно мы регистрируемся и заказываем свой товар. При регистрации, скорее всего, стоит галочка «Подписаться на новинки» или «Подписаться на скидки» и т.п.

(это конечно есть не у всех, но у подавляющего числа магазинов, потому что каждый продавец заинтересован сделать вас постоянным клиентам и напоминать о себе почаще).

В итоге мы получаем письма, которые со временем нам начинают надоедать.

Что клиент этого магазина предпримет?
1) Нажмет — Удалить
2) Нажмет — Спам
3) Нажмет — Отписаться (внизу письма или по специальной кнопке, если рассылка имеет заголовок «List-Unsubscribe»)

Скорее всего, наш покупатель сначала нажмет удалить. Потом еще раз удалить. И когда ему совсем надоест рассылка, он отпишется от нее или отправит в спам. И вот тут кнопка «отписаться» на панели почтового сервиса поможет ему принять верное решение.
В большинстве случаев кнопку «отписаться» все прячут в самом низу своей рассылки (и это правильно), поэтому ее могут и не увидеть те, кто вообще откажется читать вашу рассылку.

Добавление кнопки «отписаться» на панель инструментов почтового сервиса

Чтобы добавить кнопку «отписаться» на панель почтового сервиса для своих рассылок, нужно передать в заголовке письма следующую строчку:
List-Unsubscribe: <ссылка на отписку>
или
List-Unsubscribe: <email для отправки письма на отписку>

В Gmail кнопки сразу не появится. Однако сам сервис рекомендует использовать этот заголовок, но оговаривает: что помимо этого заголовка в самом письме должна быть видимая ссылка на отписку.
Скорее всего, это связано с тем, что Gmail отображает данную кнопку для сервисов, которые себя зарекомендовали как добропорядочные. Чтобы этой возможностью не пользовались сервисы спам рассылок.

В Яндекс почте вы сразу увидите новую кнопку:

Mail.ru также сразу отобразит эту кнопку:

Поведение этой кнопки следующее: при нажатии будет переход по этой ссылке, письмо будет удалено. Если ссылка верная, то пользователь увидит что-то подобное: «Здравствуйте! Вы успешно отписаны от нашей рассылки.» (конечно же, это зависит от того, что вы решите написать на этой странице)

И все довольны: и пользователь и почтовый сервис, и вы — так как ваша рассылка не была помечена как «спам».

Проблемы с отпиской через «List-Unsubscribe» в Mail.ru.

Но это не работает с Mail.ru. Я написал им письмо с просьбой изменить их алгоритм, получил ответ — «Мы рассмотрим ваше предложение».
Может быть, и правда рассмотрят, но пока это работает совсем не так, как хотелось бы.

Mail.ru Group написали статью в своем блоге, описывающую некоторые преимущества их сервиса и дополнительные возможности, подробнее можно прочитать тут: habrahabr.ru/company/mailru/blog/216535

Вот в чем подвох: при нажатии на кнопку отписки на панели инструментов mail.ru — вы никуда не будете перенаправлены. А значит, и результата своей подписки не увидите на экране. Mail.ru сам за вас откроет ссылку, указанную в заголовке List-Unsubscribe, а письмо отправит в спам.

• Для владельца рассылки это нежелательно, получается, что вы дали дополнительную возможность отписаться — но за это получили метку спама для своей рассылки (если пользователь отписался).
  
• Для вашего клиента это тоже не хорошо — теперь если он захочет снова подписаться на вас, ваши письма будут попадать в его почту с меткой «спам».

нагрузочное тестирование — Яндекс-танк добавляет заголовки cookie и Host в запросы из журнала доступа

Задать вопрос

спросил 7 лет, 1 месяц назад

Изменено 7 лет, 1 месяц назад

Просмотрено 1к раз

У меня есть access. log nginx с файлом cookie:

99.20.231.22 www.carite.com - [01/Dec/2015:03:00:10 -0600] "GET /?mode=_ajax&_imod[]=i159330&make= Mercedes-Benz&_=1448960297171 HTTP/1.1" 200 1182 "http://www.carite.com/" "Mozilla/5.0 (iPhone; процессор iPhone OS 9_1, например, Mac OS X) AppleWebKit/601.1.46 (KHTML, например, Gecko) Версия/9.0 Mobile/13B143 Safari/601.1" "PHPSESSID=ebg5n89m9pc1iamekii1qra5k0; ChooseStoreNotificationShown=1; dfa_visit=1448960180633603603; dfa_visitor=1448960180633796491; mod-compare-box=%7B%22vehicles%22%3A%7B%22v11279294%22%3A%7B%22vuid%22%3A%2211279294%22%2C%22isCompared%22%3Afalse%7D%7D%2C%22compareAll %22%3Atrue%2C%22cookieLifeTime%22%3A30%2C%22cookiePath%22%3A%22%5C%2F%22%7D; _ga=GA1.2.10339867.1448960182; _гали = сделать; _gat_a1=1; _gat_a2=1; _gat_a3=1; _gat_a4=1; usy46gabsosd=collserve__-2_1448960382693_8786" 80 0.295

Могу ли я указать Яндекс-танку получать cookie из журнала доступа и добавлять его в каждый запрос yandex-tank?

Также мне нужно получить заголовок «Host:» из журнала доступа вместо его указания в load. ini вроде: headers = [Host: www.carite.com]

• load-testing
• yandex
• yandex-tank

У вас есть два варианта:

. журнал (это должно быть сделано вокруг там https://github.com/yandex/yandex-tank/blob/master/yandextank/stepper/missile.py#L213)

1. создайте отдельный файл из access.log в формате https://yandextank.readthedocs.org/en/latest/tutorial.html#uri-style-uris-in-file. Заголовки переопределяются на ходу, поэтому вы можете переопределить заголовки в любом месте

   Например, это может быть так:

   [Хост: www.carite.com]
   [Файл cookie: PHPSESSID=ebg5n89m9pc1iamekii1qra5k0; выберитеStoreNotificationShown=1; dfa_visit=1448960180633603603; dfa_visitor=1448960180633796491; …]
   /?mode=_ajax& imod[]=i159330&make=Mercedes-Benz& =1448960297171
   …
   [Хост: example.com]
   [Cookie: myowncookie=1]
   /something
   …

Советую использовать 2-й способ как самый простой

6

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но никогда не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

ietf-httpapi-idempotency-key-header-02 — Поле заголовка HTTP Idempotency-Key

Javascript отключен? Как и другие современные веб-сайты, IETF Datatracker использует Javascript. Пожалуйста, включите Javascript для полной функциональности.

 Сетевая рабочая группа J. Jena
Интернет-Черновик
Предполагаемый статус: трек стандартов С. Далал
Истекает: 13 мая 2023 г. 9 ноября 2022 г.
 Поле заголовка HTTP с ключом идемпотентности
 черновик-ietf-httpapi-idempotency-key-header-02
Абстрактный
 Поле заголовка запроса HTTP Idempotency-Key может использоваться для переноса
 ключ идемпотентности, чтобы сделать неидемпотентные методы HTTP, такие как
 "POST" или "PATCH" отказоустойчивый.
Места для дискуссий
 Это примечание должно быть удалено перед публикацией в виде RFC.
 Обсуждение этого документа происходит в разделе Building Blocks for
 Список рассылки рабочей группы HTTP API ([email protected]), который
 заархивировано по адресу https://mailarchive.ietf.org/arch/browse/httpapi/.
 Исходный код этого черновика и средство отслеживания проблем можно найти по адресу
 https://github. com/mnot/idempotency.
Статус этого меморандума
 Настоящий Интернет-проект представлен в полном соответствии с
 положения BCP 78 и BCP 79.
 Интернет-Черновики являются рабочими документами Интернет-Инженерии.
 Целевая группа (IETF). Обратите внимание, что другие группы также могут распространять
 рабочие документы в виде Internet-Drafts. Список актуальных интернет-
 Черновики находятся по адресу https://datatracker.ietf.org/drafts/current/.
 Интернет-проекты – это проекты документов, действительные не более шести месяцев.
 и могут быть обновлены, заменены или устаревшими другими документами в любое время.
 время. Неуместно использовать Internet-Drafts в качестве справочного материала.
 материал или цитировать их, кроме как «в процессе».
 Срок действия настоящего интернет-драфта истекает 13 мая 2023 года.
Уведомление об авторских правах
 Copyright (c) 2022 IETF Trust и лица, указанные в качестве
 авторы документа. Все права защищены.
 Этот документ регулируется BCP 78 и юридическими документами IETF Trust. Положения, касающиеся документов IETF (https://trustee.ietf.org/
 лицензия-информация), действующая на дату публикации этого документа.
 Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права.
 и ограничения в отношении этого документа. Компоненты кода
 извлеченные из этого документа должны включать текст упрощенной лицензии BSD
 как описано в Разделе 4.e Правовых положений о трастах, и
 предоставляется без гарантии, как описано в упрощенной лицензии BSD.
Оглавление
 1. Введение
 1.1. Условные обозначения
 2. Поле заголовка HTTP-запроса Idempotency-Key
 2.1. Синтаксис
 2.2. Уникальность ключа идемпотентности
 2.3. Срок действия и срок действия ключа идемпотентности
 2.4. Отпечаток пальца идемпотентности
 2.5. Обязанности
 2.6. Сценарии применения идемпотентности
 2.7. Сценарии ошибок
 3. Соображения IANA
 3.1. Поле заголовка HTTP-запроса Idempotency-Key
 4. Статус реализации
 4.1. Реализация концепции
 5. Вопросы безопасности
 6. Примеры
 7. Ссылки
 7.1. Нормативные ссылки
 7.2. Информативные ссылки
 Приложение A. Импортированный ABNF
 Благодарности
 Адреса авторов
1. Введение
 Идемпотентность — это свойство некоторых операций в математике и
 информатики, благодаря чему их можно применять многократно без
 изменение результата за пределами первоначального приложения. Это не
 имеет значение, вызывается ли операция только один раз или 10 раз.
 Результат ДОЛЖЕН быть одинаковым.
 Идемпотентность важна для создания отказоустойчивого HTTP API. Ан
 Метод HTTP-запроса считается «идемпотентным», если ожидаемый эффект
 на сервере нескольких одинаковых запросов с этим методом является
 такой же, как эффект для одного такого запроса. Согласно с
 [RFC7231], HTTP-методы «OPTIONS», «HEAD», «GET», «PUT» и «DELETE».
 являются идемпотентными, а методы "POST" и "PATCH" - нет.
 Допустим, клиент HTTP API хочет создать (или обновить)
 ресурс с использованием метода «POST». Поскольку "POST" НЕ является идемпотентом
 метод, вызов которого несколько раз может привести к дублированию или неправильному
 обновления. Рассмотрим сценарий, в котором клиент отправил запрос «POST».
 на сервер, но он получил тайм-аут. Возникают следующие вопросы:
 ресурс фактически создан (или обновлен)? Произошел ли тайм-аут
 при отправке запроса или при получении ответа?
 Может ли клиент безопасно повторить запрос или ему нужно выяснить
 из того, что произошло в первую очередь? Если бы "POST" был
 идемпотентного метода таких вопросов может и не возникнуть. Клиент будет безопасно
 повторять запрос до тех пор, пока он действительно не получит действительный ответ от
 сервер.
 Во многих случаях использования HTTP API дублирование ресурсов является серьезной проблемой.
 проблема с точки зрения бизнеса. Например, повторяющиеся записи
 для запросов, связанных с любым видом денежных переводов, «НЕ ДОЛЖЕН» быть
 допустимый. В других случаях обработка повторной доставки веб-перехватчика
 неожиданно. 1.1. Условные обозначения
 {::шаблон bcp14-tagged}
 В этой спецификации используется расширенная форма Бэкуса-Наура (ABNF).
 обозначение [RFC5234] и включает, по ссылке, IMF-fixdate
 правило, как определено в Разделе 7.1.1.1 [RFC7231].
 Термин «ресурс» следует толковать в соответствии с определением, указанным в разделе 2
 [RFC7231], который идентифицируется URI. Термин «сервер ресурсов»
 следует интерпретировать как «исходный сервер», как определено в Разделе 3
 [RFC7231].
2. Поле заголовка HTTP-запроса Idempotency-Key
 Ключ идемпотентности — это уникальное значение, сгенерированное клиентом, которое
 сервер ресурсов использует для распознавания последующих попыток одного и того же
 запрос. Поле заголовка HTTP-запроса Idempotency-Key содержит
 этот ключ.
2.1. Синтаксис
 «Idempotency-Key» — это структурированный заголовок элемента [RFC8941]. Его значение
 ДОЛЖЕН быть строкой. Обратитесь к разделу 3.3.3 [RFC8941] для ABNF
 "sf-строка":
 Ключ идемпотентности = sf-строка
 Клиенты НЕ ДОЛЖНЫ включать более одного поля заголовка «Idempotency-Key». в том же запросе.
 В следующем примере показан ключ идемпотентности с использованием «UUID».
 [RFC4122]:
 Ключ идемпотентности: "8e03978e-40d5-43e8-bc93-6894a57f9324"
2.2. Уникальность ключа идемпотентности
 Ключ идемпотентности, который предоставляется как часть каждого запроса «POST».
 ДОЛЖЕН быть уникальным и НЕ ДОЛЖЕН повторно использоваться с другим запросом с
 различная полезная нагрузка запроса.
 Уникальность ключа ДОЛЖНА быть определена владельцем ресурса и ДОЛЖНА
 быть реализованы клиентами сервера ресурсов. это
 РЕКОМЕНДУЕТСЯ использовать "UUID" [RFC4122] или аналогичный случайный идентификатор.
 используется как ключ идемпотентности.
2.3. Срок действия и срок действия ключа идемпотентности
 Ресурс МОЖЕТ применять ключи идемпотентности на основе времени, таким образом, иметь возможность
 для очистки или удаления ключа по истечении срока его действия. Сервер ресурсов ДОЛЖЕН
 определить такую ​​политику истечения срока действия и опубликовать ее в документации. 2.4. Отпечаток пальца идемпотентности
 Отпечаток идемпотентности МОЖЕТ использоваться вместе с
 ключ идемпотентности для определения уникальности запроса. Такой
 отпечаток генерируется из данных полезной нагрузки запроса ресурсом
 сервер. Алгоритм генерации идемпотентного отпечатка МОЖЕТ использовать один
 из следующих или подобных подходов к созданию отпечатка пальца.
 * Контрольная сумма всей полезной нагрузки запроса.
 * Контрольная сумма выбранных элементов в полезной нагрузке запроса.
 * Значение поля соответствует каждому полю в полезной нагрузке запроса.
 * Значение поля соответствует выбранным элементам в полезной нагрузке запроса.
 * Запросить дайджест/подпись.
2.5. Обязанности
 Клиент
 Клиенты HTTP API, требующие идемпотентности, ДОЛЖНЫ понимать
 требования, связанные с идемпотентностью, опубликованные сервером, и использование
 соответствующий алгоритм для генерации ключей идемпотентности.
 Для каждого запроса клиент ДОЛЖЕН
 * Отправить уникальный ключ идемпотентности в HTTP "Idempotency-Key"
 поле заголовка запроса. Сервер ресурсов
 Сервер ресурсов ДОЛЖЕН опубликовать спецификацию, связанную с идемпотентностью. Этот
 спецификация ДОЛЖНА включать политику, связанную с истечением срока действия, если это применимо.
 Сервер отвечает за управление жизненным циклом идемпотентности.
 ключ.
 Для каждого запроса сервер ДОЛЖЕН
 * Определите ключ идемпотентности из HTTP-запроса «Idempotency-Key».
 поле заголовка.
 * При необходимости сгенерируйте отпечаток идемпотентности.
 * Проверка на идемпотентность с учетом различных сценариев, включая
 те, которые описаны в разделе ниже.
2.6. Сценарии применения идемпотентности
 * Первый запрос (ключ идемпотентности и отпечаток пальца не
 видимый)
 Сервер ресурсов ДОЛЖЕН нормально обрабатывать запрос и
 ответьте соответствующим ответом и кодом состояния.
 * Дублированный запрос (были замечены ключ идемпотентности и отпечаток пальца)
 Повторить попытку
 Запрос был повторен после завершения исходного запроса.
 ресурсный сервер ДОЛЖЕН ответить результатом предыдущего
 завершенная операция, успех или ошибка. См. Сценарии ошибок для
 подробности об ошибках.
 Параллельный запрос
 Запрос был повторен до завершения исходного запроса.
 Сервер ресурсов ДОЛЖЕН ответить ошибкой конфликта ресурсов.
 Дополнительные сведения см. в разделе Сценарии ошибок.
2.7. Сценарии ошибок
 Если заголовок запроса Idempotency-Key отсутствует для документированного
 идемпотентная операция, требующая этого заголовка, сервер ресурсов
 СЛЕДУЕТ ответить кодом состояния HTTP "400" с телом, содержащим
 ссылка, указывающая на соответствующую документацию. Следующие примеры показывают
 ответ об ошибке с описанием проблемы с использованием [RFC7807].
HTTP/1.1 400 Неверный запрос
Content-Type: приложение/проблема+json
Язык содержания: en
{
 "тип": "https://developer.example.com/idempotency",
 "title": "Ключ идемпотентности отсутствует",
 "detail": "Эта операция является идемпотентной и требует правильного использования ключа идемпотентности.",
}
 В качестве альтернативы, используя HTTP-заголовок «Link», клиент может быть проинформирован
 об ошибке, как показано ниже. HTTP/1.1 400 Неверный запрос
 Ссылка: ;
 отн = "описано"; тип = "текст/html"
 При попытке повторно использовать ключ идемпотентности с другим
 запрашивать полезную нагрузку, сервер ресурсов ДОЛЖЕН ответить HTTP «422»
 код состояния с телом, содержащим ссылку, указывающую на соответствующий
 документация. Код состояния «422» определен в разделе 11.2.
 [RFC4918].
HTTP/1.1 422 Необрабатываемый объект
Content-Type: приложение/проблема+json
Язык содержания: en
{
 "тип": "https://developer.example.com/idempotency",
 "title": "Ключ идемпотентности уже используется",
 "detail": "Эта операция является идемпотентной и требует правильного использования ключа идемпотентности. Ключ идемпотентности НЕ ДОЛЖЕН повторно использоваться в разных полезных нагрузках этой операции.",
}
 Сервер также может информировать клиента, используя HTTP-заголовок «Link».
 как показано ниже.
 HTTP/1.1 422 Необрабатываемый объект
 Ссылка:  example.com/idempotency>;
 отн = "описано"; тип = "текст/html"
 Если запрос повторяется, в то время как первоначальный запрос все еще обрабатывается
 обрабатывается, сервер ресурсов ДОЛЖЕН ответить HTTP "409" положение дел
 код с телом, содержащим описание проблемы.
HTTP/1.1 409 Конфликт
Content-Type: приложение/проблема+json
Язык содержания: en
{
 "тип": "https://developer.example.com/idempotency",
 "title": "Ожидается запрос на этот ключ идемпотентности",
 "detail": "Запрос с тем же ключом идемпотентности для той же операции обрабатывается или находится в обработке.",
}
 Или, поочередно, используя HTTP-заголовок «Ссылка», указывающий на соответствующий
 документация
 HTTP/1.1 409 Конфликт
 Ссылка: ;
 отн = "описано"; тип = "текст/html"
 Сценарии ошибок выше описывают состояние отказавшего идемпотента.
 запросы после их обработки сервером ресурсов. Клиенты ДОЛЖНЫ
 исправить запросы (за исключением 409где нет исправления
 требуется) перед выполнением повторной операции, или ресурс
 сервер ДОЛЖЕН отклонить запрос и вернуть одну из вышеуказанных ошибок. Для других ошибок 4xx/5xx, таких как 401, 403, 500, 502, 503, 504, 429,
 или любой другой код ошибки HTTP, не указанный здесь, клиент
 СЛЕДУЕТ действовать надлежащим образом, следуя указаниям сервера ресурсов.
 документация.
3. Соображения IANA
3.1. Поле заголовка HTTP-запроса Idempotency-Key
 Имя поля Idempotency-Key должно быть добавлено в «Hypertext
 Реестр имен полей протокола передачи (HTTP).
 Имя поля: Ключ идемпотентности
 Статус: постоянный
 Документ спецификации: Эта спецификация, Раздел 2
4. Статус реализации
 Примечание для редактора RFC: удалите этот раздел перед публикацией.
 В этом разделе записывается состояние известных реализаций
 протокол, определенный этой спецификацией на момент публикации этого
 Internet-Draft и основан на предложении, описанном в [RFC7942].
 Описание реализаций в этом разделе предназначено для
 помогать IETF в процессах принятия решений по продвижению проектов к
 RFC. Обратите внимание, что перечисление любой отдельной реализации
 здесь не означает одобрения со стороны IETF. Кроме того, никаких усилий
 было потрачено на проверку представленной здесь информации, которая была
 предоставлено участниками IETF. Это не предназначено и не должно
 истолковываться как каталог доступных реализаций или их
 Особенности. Читателям рекомендуется принять к сведению, что другие реализации могут
 существует.
 Согласно RFC 7942, "это позволит рецензентам и рабочим группам
 уделять должное внимание документам, имеющим значение для
 работающий код, который может служить свидетельством ценных экспериментов
 и отзывы, которые сделали реализованные протоколы более зрелыми.
 Отдельные рабочие группы могут использовать эту информацию как
 они считают нужным».
 Организация: Полоса
 * Описание: Stripe использует собственный HTTP-заголовок с именем «Idempotency-
 Ключ"
 * Ссылка: https://stripe.com/docs/idempotency
 Организация: Адьен
 * Описание: Adyen использует собственный HTTP-заголовок с именем «Idempotency-Key».
 * Ссылка: https://docs.adyen. com/development-resources/api-
 идемпотентность/
 Организация: Дволла
 * Описание: Dwolla использует собственный HTTP-заголовок с именем «Idempotency-
 Ключ"
 * Ссылка: https://docs.dwolla.com/
 Организация: Интерледжер
 * Описание: Interledger использует пользовательский HTTP-заголовок с именем
 «Ключ идемпотентности»
 * Ссылка: https://github.com/interledger/
 Организация: WorldPay
 * Описание: WorldPay использует собственный HTTP-заголовок с именем «Idempotency-
 Ключ"
 * Ссылка: https://developer.worldpay.com/docs/wpg/idempotency
 Организация: Яндекс
 * Описание: Яндекс использует собственный HTTP-заголовок с именем «Idempotency-
 Ключ"
 * Ссылка: https://cloud.yandex.com/docs/api-design-
 руководство/концепции/идемпотентность
 Организация: http4s.org
 * Описание: Http4s — это минимальный идиоматический интерфейс Scala для
 HTTP-сервисы.
 * Ссылка: https://github.com/http4s/http4s
 Организация: Финастра
 * Описание: Finastra использует собственный HTTP-заголовок с именем «Idempotency-
 Ключ"
 * Ссылка: https://developer. fusionfabric.cloud/
 Организация: Дататранс
 * Описание: Datatrans занимается технической обработкой
 платежи, в том числе размещение интеллектуальных платежных форм и правильное
 маршрутизация платежной информации.
 * Ссылка: https://docs.datatrans.ch/docs/api-endpoints
4.1. Реализация концепции
 Это список реализаций, реализующих общую концепцию,
 но сделать это с помощью разных механизмов:
 Организация: Джанго
 * Описание: Django использует собственный HTTP-заголовок с именем
 "HTTP_IDEMPOTENCY_KEY"
 * Ссылка: https://pypi.org/project/django-idempotency-key
 Организация: Твилио
 * Описание: Twilio использует собственный HTTP-заголовок с именем «I-Twilio-
 Idempotency-Token» в веб-перехватчиках
 * Ссылка: https://www.twilio.com/docs/usage/webhooks/webhooks-
 переопределение соединения
 Организация: PayPal
 * Описание: PayPal использует собственный HTTP-заголовок с именем «PayPal-Request-
 Идентификатор"
 * Ссылка: https://developer. paypal.com/docs/business/develop/
 идемпотентность
 Организация: RazorPay
 * Описание: RazorPay использует собственный HTTP-заголовок с именем «X-Payout-
 Идемпотентность"
 * Ссылка: https://razorpay.com/docs/razorpayx/api/idempotency/
 Организация: ОпенБанкинг
 * Описание: OpenBanking использует настраиваемый HTTP-заголовок под названием «x-
 ключ идемпотентности"
 * Ссылка: https://openbankinguk.github.io/read-write-api-
 site3/v3.1.6/profiles/read-write-data-api-profile.html#request-
 заголовки
 Организация: Сквер
 * Описание: Чтобы сделать идемпотентный вызов API, Square рекомендует
 добавление свойства с именем «idempotency_key» с уникальным значением в
 тело запроса.
 * Ссылка: https://developer.squareup.com/docs/build-basics/using-
 остальные API
 Организация: Стандартные платежи Google
 * Описание: Google Standard Payments API использует свойство с именем
 «requestId» в теле запроса для обеспечения идемпотентности провайдера в
 различные варианты использования. * Ссылка: https://developers.google.com/standard-payments/
 API-интерфейс платежного процессора/отдых/v1/TopLevel/захват
 Организация: ББВА
 * Описание: BBVA Open Platform использует настраиваемый HTTP-заголовок под названием «X-
 Уникальный идентификатор транзакции"
 *  Ссылка:
 https://bbvaopenplatform.com/apiReference/APIbasics/content/x-
 уникальный идентификатор транзакции
 Организация: WebEngage
 * Описание: WebEngage использует настраиваемый заголовок HTTP под названием «x-request-
 id" для уникальной идентификации POST-запросов webhook для достижения событий
 идемпотентность.
 * Ссылка: https://docs.webengage.com/docs/webhooks
5. Вопросы безопасности
 Этот раздел предназначен для информирования разработчиков, поставщиков информации,
 и пользователи известных проблем безопасности, характерных для идемпотентности
 ключи.
 Серверы ресурсов, которые не реализуют сильные ключи идемпотентности, такие как
 как UUID или иметь соответствующие элементы управления для проверки идемпотентности
 ключи, могут стать жертвами различных форм атак безопасности из
 вредоносные клиенты:
 * Инъекционные атаки — когда ресурсный сервер не проверяет
 ключ идемпотентности в клиентском запросе и выполняет идемпотентный
 поиск в кеше, возможны атаки на безопасность (прежде всего в виде
 инъекции), скомпрометировав сервер. * Утечки данных — когда реализация идемпотентности допускает низкую энтропию
 ключей, злоумышленники МОГУТ определить другие ключи и использовать их для извлечения
 существующие записи идемпотентного кэша, принадлежащие другим клиентам.
 Для предотвращения подобных ситуаций спецификация рекомендует
 следуя рекомендациям по реализации ключа идемпотентности в
 ресурсный сервер.
 * Установить фиксированный формат ключа идемпотентности и опубликовать
 Спецификация ключа.
 * Всегда проверяйте ключ в соответствии с его опубликованной спецификацией перед
 обработка любого запроса.
 * На сервере ресурсов внедрите уникальный составной ключ в качестве
 ключ поиска в идемпотентном кэше. Например, составной ключ МОЖЕТ быть
 реализуется путем объединения ключа идемпотентности, отправленного клиентом
 с другими специфическими атрибутами клиента, известными только ресурсу
 сервер.
6. Примеры
 В первом примере показано поле заголовка ключа идемпотентности с ключом
 значение с использованием схемы UUID версии 4:
 Ключ идемпотентности: "8e03978e-40d5-43e8-bc93-6894a57f9324"
 Во втором примере показано поле заголовка ключа идемпотентности со значением ключа. используя генератор случайных строк:
 Ключ идемпотентности: "clkyoesmbgybucifusbbtdsbohtyuuwz"
7. Ссылки
7.1. Нормативные ссылки
 [RFC4122] Лич, П., Миллинг, М., и Р. Зальц, «Универсально
 Уникальный идентификатор (UUID) URN Namespace", RFC 4122,
 DOI 10.17487/RFC4122, июль 2005 г., .
 [RFC4918] Dusseault, L., Ed., "Расширения HTTP для
 Создание и управление версиями (WebDAV)", RFC 4918,
 DOI 10.17487/RFC4918, июнь 2007 г., .
 [RFC5234] Крокер, Д., изд. и П. Оверелл, "Расширенный BNF для синтаксиса".
 Технические характеристики: ABNF", STD 68, RFC 5234,
 DOI 10.17487/RFC5234, январь 2008 г., .
 [RFC7230] Филдинг, Р., изд. и Дж. Решке, изд., "Передача гипертекста
 Протокол (HTTP/1.1): синтаксис и маршрутизация сообщений»,
 RFC 7230, DOI 10. 17487/RFC7230, июнь 2014 г., .
 [RFC7231] Филдинг, Р., изд. и Дж. Решке, изд., "Передача гипертекста
 Протокол (HTTP/1.1): семантика и содержимое", RFC 7231,
 DOI 10.17487/RFC7231, июнь 2014 г., .
 [RFC7807] Ноттингем, М. и Э. Уайлд, «Подробности проблемы для HTTP
 API», RFC 7807, DOI 10.17487/RFC7807, март 2016 г., .
 [RFC8941] Ноттингем, М. и П.-Х. Камп, «Структурированные значения полей для
 HTTP», RFC 8941, DOI 10.17487/RFC8941, февраль 2021 г., .
7.2. Информативные ссылки
 [RFC7942] Шеффер, Ю. и А. Фаррел, «Повышение осведомленности о беге
 Код: Раздел статуса реализации", BCP 205,
 RFC 7942, DOI 10.17487/RFC7942, июль 2016 г.,  ietf.org/doc/html/rfc7942>.
Приложение A. Импортированный ABNF
 Следующие основные правила включены посредством ссылки, как определено в
 Приложение B.1 [RFC5234]: ALPHA (буквы), CR (возврат каретки),
 CRLF (CR LF), CTL (управление), DIGIT (десятичные 0-9), DQUOTE (двойной
 цитата), HEXDIG (шестнадцатеричный 0-9/A-F/a-f), LF (перевод строки), OCTET (любой
 8-битная последовательность данных), SP (пробел) и VCHAR (любой видимый символ US-ASCII).
 персонаж).
 Приведенные ниже правила определены в [RFC7230]:
 obs-text =  Благодарности
 Авторы хотели бы поблагодарить Марка Ноттингема за его поддержку
 этот интернет-драфт. Мы хотели бы признать, что этот проект
 вдохновлен шаблонами, связанными с идемпотентностью, описанными в API
 документация PayPal (https://github.com/paypal/api-
 Standards/blob/master/patterns.md#idempotency) и Stripe
 (https://stripe.com/docs/idempotency), а также Internet Draft на
 POST точно один раз (https://tools.