Директ максимальная длина заголовка: Символы объявлений Я.Директ

Как использовать увеличенный заголовок в Директе

Раньше два заголовка в Яндекс.Директе суммарно могли составлять до 65 символов. Кроме того, в каждый заголовок можно было добавить еще по 15 знаков препинания, которые не учитывались. Это вызывало неудобства, поскольку в рекламной выдаче на десктопах было ограничение в 517 пикселей на ширину двух заголовков объявления, что примерно соответствовало 56 символам с учетом знаков препинания или 53 без их учета.

Также нужно было учитывать разную пиксельную ширину букв, например заглавная «Ш» намного шире, чем строчная «к». Эти нюансы нередко приводили к тому, что второй заголовок не отображался, а объявление теряло привлекательность и проценты CTR. Самостоятельные рекламодатели и начинающие специалисты могли вообще не знать об этих ограничениях, поскольку нигде в интерфейсе, даже в функции предпросмотра, информации о них не было.

Как мне сказали специалисты Яндекса, расширенный до 56 символов заголовок всегда будет отображаться вне зависимости от ширины в пикселях. Это сделает настройку кампании более прозрачной и простой. По крайней мере из первого заголовка не будут вырезаны важные тезисы.

Это обновление гораздо важнее для рекламы в РСЯ, чем для поиска. По моим наблюдениям, сейчас основной формат в РСЯ — это фоновое изображение, крупный первый заголовок и домен или кнопка. А 35 символов часто не хватало, чтобы сделать действительно интересный и привлекательный текст, 56 знаков — гораздо лучше.

Несмотря на увеличение первого заголовка, второй нужно писать обязательно. Он будет показан на десктопах в случаях, если первый заголовок меньше 56 символов. Тогда Яндекс.Директ подтянет из второго заголовка столько слов, сколько поместится до лимита. При этом Директ не будет обрезать слова.

Важно помнить, что 56 символов — это лимит на десктопах. На смартфонах лимит на два заголовка больше и составляет 65 символов. Выходит, что второй заголовок нужен, но если в первом вы использовали все 56, то длина второго не должна превышать девяти символов. Подойдет информация об акции, короткий оффер, призыв к действию и т. д. Можно делать второй заголовок и длиннее девяти символов, но надо учитывать то, как будет выглядеть объявление при подстановке.

Новичкам всё равно будет сложно сориентироваться, ведь технически можно добавить 86 символов на два заголовка, но некоторые слова могут быть вырезаны, а это повлияет на смысл и содержание объявления.

Хотелось бы, чтобы в интерфейсе Директа появилась рекомендация, что в некоторых объявлениях сумма символов двух заголовков больше 65, следовательно, остальные слова отбросятся. Так рекламодатель мог бы сразу это увидеть и отредактировать объявления. Пока рекомендую ориентироваться на функцию предварительного просмотра и следить, чтобы важные слова и тезисы не потерялись.

Длина заголовка Яндекс Директ — как её увеличить?

Здравствуйте, уважаемые читатели!

Используете ли вы возможности контекстной рекламы Яндекс.Директ? Благодаря этой системе многие рекламодатели – предприниматели, владельцы сайтов – получают целевых клиентов и увеличивают свою прибыль.

Яндекс, в свою очередь, постоянно модернизирует Директ и добавляет в него новые «фишки». Некоторые из этих нововведений являются весьма полезными, так как позволяют повысить кликабельность объявлений. Что благотворно сказывается как на трафике, идущем на сайт рекламодателя, так и на доходах самого Яндекса.

Быстрые ссылки, уточнения, контактная информация – это лишь часть инструментов, которые вы можете использовать.

Кстати, совсем недавно Яндекс анонсировал кое-что новенькое. Теперь в тексты можно добавлять спецсимволы: знаки копирайта, торговой марки, рубля, градуса и т.д. Но сейчас не об этом.

В данной статье речь пойдёт том, как сделать своё объявление более заметным и цепляющим за счёт увеличения длины заголовка. Это достигается путём использования одного интересного механизма — подстановки части текста в заголовок.

Когда я открываю поиск Яндекса, то вижу, что не во всех объявлениях, помеченных меткой «Реклама», используется эта функция. Считаю, что нужно рассказать о ней подробнее. Начнём мы с основ.

Составление объявлений в Директе

Сколько символов можно уместить в рекламном сообщении контекстной рекламы?

Длина заголовка Яндекс Директ не может превышать 33 символов – так было всегда и так есть сейчас. Что касается текста, то здесь простора для фантазии больше – его длина ограничена 75 символами.

Настраивая рекламную кампанию вы должны учитывать эти лимиты и составлять такие заголовки и тексты, которые кратко, но ёмко, отражали бы суть вашего предложения.

Подробнее о том, как произвести качественную настройку Яндекс Директа, читайте ТУТ.

Как увеличить длину заголовка?

В 2015 году Яндекс внедрил новую функцию – подстановку части текста объявления в заголовок. В статье, которая была опубликована на «Блоге рекламных технологий» Яндекса 27 мая 2015 года, сказано, что это позволит увеличить кликабельность рекламы на 2,5-3%.

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

Выглядят расширенные объявления так:

Согласитесь, что такая реклама цепляет больше. Кроме того, появляется возможность добавить в заголовок больше информации.

Как это использовать?

Чтобы такая «фишка» начала работать в вашей рекламной кампании, вы должны запомнить следующие правила:

1. Максимальная длина расширенного заголовка в Яндекс Директе составляет 56 символов.
2. В заголовок всегда подставляется первое предложение из текста объявления.
3. Если суммарное количество символов получается больше 56, то Яндекс автоматически подставляет адрес рекламируемого веб-сайта.

При настройке рекламной кампании нужно учитывать этот механизм и составлять тексты таким образом, чтобы реклама смотрелась привлекательнее.

Кстати, при добавлении нового объявления вы всегда можете посмотреть, как оно будет выглядеть на поиске.

Всю ли рекламу в Директе нужно подстраивать под расширенные заголовки? Не обязательно. Вы всегда можете отключить эту функцию в параметрах рекламной кампании. Для этого перейдите на страницу настроек и в самом низу раскройте «Расширенные настройки».

Моё мнение такое: данной функцией пренебрегать не стоит. Посмотрев объявления крупных рекламодателей, я заметил, что большинство из них имеют длинные заголовки. Если бы толку от этого не было, то их бы отключали.

Какие плюсы вы можете получить от этого?

Самый важный плюс, который хочется выделить особо – повышение кликабельности объявления и увеличение CTR.

Напомню, CTR – это отношение числа кликов к числу показов, выраженное в процентах.

Высокий CTR, в свою очередь, приведёт к снижению стоимости клика в вашей рекламной кампании (подробнее об этом читайте ЗДЕСЬ). Что в итоге приведёт к тому, что вы будете получать то же (или большее) число клиентов за меньшие деньги.

Друзья, есть ли у вас какие-либо вопросы по теме статьи? Отвечу всем!

Если вы испытываете трудности с настройкой Яндекс Директа, то вы можете обратиться ко мне. Я занимаюсь настройкой рекламных кампаний под ключ и готов помочь вам. Более подробно с данной услугой вы можете ознакомиться на ЭТОЙ странице.

Буду рад сотрудничать с вами!

С уважением, автор блога Сергей Чесноков

Как составить 1000 объявлений контекстной рекламы из YML-файла

Запуск рекламной кампании неразрывно связан с подбором ключевых фраз и составлением продающих объявлений. Для интернет-магазинов с 20-30 товарами этот процесс не занимает много времени, даже если все делать вручную. Но если нужно прорекламировать 200, 500 или даже 1000 товаров, то задача становится слишком трудоемкой.

Решить проблему поможет генератор из YML. За пару кликов он сгенерирует ключевые фразы и объявления для каждой позиции в вашем ассортименте.

Рассмотрим, что умеет инструмент и как с ним работать.

Кому и для каких задач подходит генератор из YML

Как работать с генератором ключей и объявлений

Шаг 1. Добавление YML-файла

Шаг 2. Генерация ключевых слов

Шаг 3. Генерация объявлений для Яндекс.Директ

Шаг 4. Генерация объявлений для Google Ads

Шаг 5. Получение результата

Сколько стоит инструмент

Кому и для каких задач подходит генератор из YML

Генератор из YML позволяет собрать ключевые фразы из YML–файла. Сгенерированные ключевики используются для расширения семантики сайта и запуска контекстной рекламы.

Инструмент подходит интернет-магазинам с широким ассортиментом товаров, которые выставляют свои предложения на Яндекс.Маркете в формате YML.

Возможности генератора из YML:

• Быстрая генерация ключевых фраз из файла YML для поискового продвижения или контекстной рекламы.
• Автоматическое создание объявлений для каждого товара (отдельно для Яндекс.Директа и Google Ads).
• Настраиваемые шаблоны ключей и объявлений.
• Создание нескольких шаблонов объявлений для одного и того же товара.
• Ограничение длины заголовков и описаний объявлений (по количеству слов или символов).
• Доступно 4 элемента объявления: заголовок 1, заголовок 2, описание, отображаемая ссылка.
• Для всех объявлений доступен предварительный просмотр.

Преимущества использования генератора из YML:

• Не нужно специально загружать YML файл — достаточно указать ссылку на него.
• Результат выгружается в формате XLS.
• По завершении формирования отчета на e-mail приходит уведомление.
• Отчет хранится в «облаке» неограниченное время.
• Инструмент бесплатный.

Как работать с генератором ключей и объявлений

Зарегистрированные пользователи Click.ru могут бесплатно пользоваться возможностями генератора из YML.

Если у вас еще нет аккаунта, заведите его. Подробнее о процессе регистрации и запуске рекламы через Click.ru читайте в статье «Как запустить рекламу в Яндекс.Директ и Google Ads через Click.ru».

Шаг 1. Добавление YML-файла

После авторизации перейдите на страницу инструмента. Для этого в левом меню в разделе «Инструменты» выберите «Объявления» — «Генератор из YML»:

Нажмите «Добавить задачу». Укажите ссылку на свой YML-файл.

Для справки: Что такое файл YML и где его взять

YML (Yandex Market Language) — это стандарт на основе XML, разработанный Яндексом. Служит для передачи данных о товарах интернет-магазинов в Яндекс.Маркет.

Файл YML содержит в структурированном и стандартизированном виде информацию о товарах магазина: название, цена, категория, описание и т. д. Преимущество YML перед другими форматами — в возможности автоматизировать обновление информации о товарах в Яндекс.Маркете.

Структура документа YML выглядит так:

Может быть 2 ситуации:

• ваш магазин уже принят в Яндекс.Маркет. Если прайс-лист создан в формате YML, то файл будет располагаться в корне сайта. Если вы подгружаете товары с помощью XLS, CSV и TSV, то файл YML нужно создать и разместить в корневой папке;
• ваш магазин не добавлен в Яндекс.Маркет. В такой ситуации у вас не будет YML, и его надо сгенерировать.

Создается YML-файл разными способами: вручную, с помощью CMS, скрипта или генератора.

Шаг 2. Генерация ключевых слов

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

Доступные элементы:

• Название товара (в синтаксисе YML — name).
• Название бренда (vendor).
• Тип товара (typePrefix).
• Категория (category).
• Описание (description).
• Цена (price).

Для добавления переменного элемента в шаблон просто перетащите его из поля справа в поле шаблона:

При необходимости вы можете добавить столько шаблонов, сколько нужно (кнопка «Добавить шаблон для генерации слов»).

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

В этом режиме для каждого переменного элемента шаблона вы можете:

• Указать регистр слов («С заглавной буквы», «Нижний регистр», «Верхний регистр», «Название Товара»).
• Задать правила обрезки фраз (например, оставить только 3 первых слова или 40 первых символов).

После сохранения изменений ключевые фразы формируются с учетом заданных правил:

Как составить шаблоны ключевых фраз:

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

Пример. В Яндекс Wordstat вводим запрос «электродрель» и получаем ориентировочный список фраз:

На основе проанализированной информации можно сформировать такие шаблоны:

• Купить [Название товара]
• [Тип товара] [Название бренда] цена
• [Категория] интернет-магазин
• [Категория] Москва
• Купить [Название товара] Москва
• Купить [Категория] [Название бренда] недорого

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

Следите, чтобы статические слова не конфликтовали с переменными элементами. Например, если в ассортименте магазина есть дрели и сверла, то шаблон вида «[Категория] аккумуляторные» даст адекватную фразу «дрели аккумуляторные» и бессмысленную «сверла аккумуляторные». Но если в ассортименте большинство товаров — именно дрели, то использование специфических статических слов оправдано (путем чистки в Excel вы сможете быстро убрать нерелевантные фразы).

Шаг 3. Генерация объявлений для Яндекс.Директ

С помощью шаблона генерируются объявления для рекламы в Яндексе. Принцип работы аналогичен шаблону для генерации ключей.

Помните, что длина полей имеет ограничения:

• Заголовок 1-35 символов с пробелами.
• Заголовок 2-30 символов с пробелами.
• Описание — 81 символ с пробелами.
• Отображаемая ссылка — 20 символов с пробелами.

Для «обрезания» фраз в каждом поле можно пойти одним из двух путей:

1. Задать максимальное количество символов (значок шестеренки). Так вы будете точно знать, что длина полей не превышает максимальную. Но в этом случае придется вручную корректировать массу объявлений, поскольку будут встречаться такие варианты:

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

2. Ограничить максимальное количество слов. Например, для заголовка 1 обычно устанавливают не более 2-3 слов. Этот способ менее трудоемкий, чем предыдущий. Тем не менее необходимо просмотреть и при необходимости откорректировать объявления перед размещением, ведь из-за длинных слов лимит может быть превышен.

Шаг 4. Генерация объявлений для Google Ads

Здесь все аналогично созданию объявлений для Яндекс.Директа. Отличие лишь в том, что тут 2 поля для отображаемого URL:

Также отличается максимальная длина текста в полях:

• Заголовок 1-30 символов с пробелами.
• Заголовок 2-30 символов с пробелами.
• Описание — 80 символов с пробелами.
• Отображаемая ссылка 1 — 15 символов с пробелами.
• Отображаемая ссылка 2 — 15 символов с пробелами.

Шаг 5. Получение результата

После генерации ключей и объявлений отчет в формате XLSX доступен в списке задач. Здесь же есть ссылка, по которой вы можете проверить частотность сгенерированных ключей с помощью парсера Wordstat. О том, как с его помощью отобрать фразы, которые обеспечивают трафик, читайте здесь.

В отчете 2 листа. На первом собраны ключи и объявления для Яндекса, на втором — для Google.

Если вы генерируете несколько сотен или тысяч объявлений, это займет пару минут. После запуска процесса не обязательно держать браузер открытым. По завершении генерации вам на почту придет уведомление.

Сколько стоит инструмент

Инструмент бесплатный для всех пользователей, зарегистрированных в Click.ru. Ограничений по количеству сгенерированных ключей и объявлений нет.

С генератором из YML создание 1000 объявлений за 5 минут становится реальностью. Конечно, нужно потратить пару часов на «шлифовку», но эта работа несравнима с полностью ручным составлением текстов.

Хотите увеличить доход от ведения контекстной и таргетированной рекламы? Регистрируйтесь в Click.ru, подключайте аккаунты своих клиентов к системе и получайте вознаграждение до 12% от их расходов на контекст и до 18% — на таргет.

Второй заголовок в Яндекс.Директе | medoed1.ru

Контекстная реклама

Яндекс.Директ не устает вводить разнообразные нововведения. Радует, что многие из них оказываются полезными. Так, например, недавно появилась возможность добавить второй заголовок в объявления, а кроме того увеличилось допустимое количество символов в объявлении. 

Кто занимается контекстной рекламой, понимает, что идея не новое — двойной заголовок уже хорошо известен по Google AdWords. Яндекс, как это часто бывает, перенял опыт (иногда это происходит и не с очень хорошими идеями, как например, введения статуса «Мало показов») и функционал рекламы возрос за счет небольшого новшества.

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

Особенности использования второго заголовка в объявлении

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

Что изменилось вместе с введением второго заголовка:

• политика по отношению к знакам препинания
• количество символов

Теперь в объявлении можно использовать до 15 знаков препинания, и они не учитываются при подсчете общего числа символов, так что сейчас проще написать складный текст, не заботясь о символах. Знаки препинания, которые не учитываются:

• точка
• запятая
• восклицательный знак
• двоеточие
• кавычки

Максимальная длина первого заголовка — 35 символов, второго — 30 символов. Максимальная длина одного слова — 22 знака. Сам же текст объявления может быть в длину до 81 символа (не забываем о 15 знаках препинания). Таким образом, текст можно составить большой и подробный, куда влезут все ваши фишки и УТП.

Но небольшая сложность все равно присутствует: второй заголовок показывается не всегда. Это зависит от того, сколько всего места занимают заголовки. Если вы используете оба по максимуму, то Директ может отсечь автоматически второй заголовок. Поэтому прежде, чем заливать объявления с укомплектованными заголовками, проверьте на одном объявлении, как оно будет отображаться.

В целом же о внедрении второго заголовка в объявления можно сказать только хорошее: CTR в среднем повышается на 5-10%, и в объявлении проще описать свое предложение. Пока это работает только на поиске, ждем подобных изменений в РСЯ.

Рекламные объявления Яндекс Директ: правила и особенности составления

Рекламные объявления Директ

Прежде, чем подавать рекламные объявления в Директ, необходимо узнать о том, что представляют собой такие описания предложений и из чего они должны состоять. Итак, Объявления в Яндекс Директ — это рекламные предложения интернет-пользователей, в составе которых имеется прежде всего заголовок. Длина заголовка должна быть не более 33 символов, включая знаки препинания и пробелы. Кроме того, объявления содержат и основную часть — рекламный текст. Его максимальная длина — до 75 знаков, включая все символы и пробелы. Текст должен содержать контактные данные или/и ссылку на сайт с рекламным предложением.

Подавая объявления в Директ группой, вы можете включить в нее как несколько, так и один вариант предложения. К примеру, объявления с аналогичным текстом, но имеющими разные заголовки. Для всех объявлений из группы будут одни и те же ключевые фразы, и все они будут демонстрироваться в одних и тех же регионах. Другими словами, между настройками показа различий не будет.

Объявления в Яндекс Директ могут принести пользу лишь в том случае, если они будут составлены грамотно и точно. И здесь есть несколько советов, которые помогут достичь высокой эффективности. Прежде всего, помните о том, что объявления должны максимально точно соответствовать пользовательским запросам, по которым они демонстрируются. А это значит, что:

• в заголовке должны быть значимые «ключи» по тематике;
• в тексте следует писать не о компании, а о ее товарах/услугах/предложениях;
• избегайте «воды» в тексте, используйте больше конкретики;
• пользователи обращают внимание на заголовки. А значит, в них должна быть обозначена главная суть всего вашего рекламного объявления. Приветствуется «цепляющая интрига»;
• длинные тексты читают не все. Делайте текст разумно кратким;
• для акцентирования внимания используйте восклицательный знак. Но не злоупотребляйте им;
• определить статистику по «ключам» будет проще, если в одном объявлении использовать лишь одно ключевое слово.

Объявления в Яндекс Директ — это один из самых эффективных способов рекламы в сети. Используйте этот инструмент правильно, и вы сможете привлечь максимальное количество пользователей, заказчиков и покупателей.

Создание группы объявлений Яндекс Директ

Переходим ко второму шагу по настройке рекламы. Здесь мы будем заниматься созданием группы объявлений Яндекс Директ.

Однако хочу сразу сказать, что перед этим вы должны выполнить первый шаг по созданию рекламной кампании в интернете.

Эта часть является продолжением предыдущей статьи.

Поэтому рекомендую изучить материал из первой части и только потом переходить к этому посту.

А мы идем дальше.

Группы объявлений Яндекс Директ

Для начала, нужно присвоить название нашей будущей группы объявлений Яндекс Директ. В одну такую группу можно создавать и размещать 50 разных рекламных объявлений.

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

Далее, я рекомендую начать создавать свое объявление не с заголовка, а с поля “Новые ключевые фразы”. Нас интересует фраза “перфоратор купить”. Обратите внимание, что справа есть подсказки.

Однако мы их не используем, так как одно объявление должно затачиваться под один запрос. Рекомендую всем соблюдать это правило. Особенно тем, кто не знает, как пользоваться Яндекс Директом.

Это высокочастотный ключ, который мы можем взять в кавычки. Его мы вставляем в основное поле. Обратите внимание, как добавить ключевые слова.

Дальше уже мы будем исходить от этой основной фразы для создания контекстной рекламы. То есть у нас есть главный ключевой запрос и теперь нам нужно, руководствуясь правилами составления эффективного объявления, добавить этот запрос в поле “Заголовок” и “Текст объявления”.

Справа мы видим пример отображения рекламы. Можно посмотреть пример базового объявления, поисковой рекламы или РСЯ.

Также обратите внимание, что рядом показано сколько символов мы еще можем использовать. Максимальная длина заголовка Yandex Direct составляет 33 символа. А количество символов в объявлении должно быть не более 75.

Название “Перфоратор купить” мы можем так и оставить. Однако согласитесь, так некрасиво будет выглядеть. Поэтому давайте попробуем сделать по-другому. К примеру, можно вставить “Купите перфоратор”.

При этом оба варианта ключевой фразы присутствуют в заголовке. Давайте посмотрим на хороший пример объявления. Там фразы выделены жирным. К тому же заголовки составлены правильно.

Теперь давайте попробуем дополнить свой заголовок. Опять же смотрим на примеры выше. В первом случае мы можем указать выгодную цену, которая даст высокую кликабельность по рекламе.

Во втором примере можно указать регион, что также подогревает интерес у пользователя. Я для своего примера буду ориентировать человека на акцию по стоимости. В итоге мое название будет таким “Купите перфоратор со скидкой 15%!”

Так, заголовок мы составили. Теперь переходим к тексту объявления. В описание лучше включать те же ключевые слова и дополнительные стимулы, которые упоминались в названии. Это нужно для того, чтобы реклама не была двусмысленной.

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

В итоге текст объявления будет выглядеть так “Успейте купить перфоратор со скидкой 15% до конца июня. 237 моделей. Кликай”.

Если при составлении у вас не будет хватать символов, то можете некоторые слова заменить на более короткие синонимы. Также в некоторых местах можно убрать пробелы и знаки препинания.

Спускаемся еще ниже и доходим до ссылки на сайт. В моем примере мне нужно вставить ссылку на каталог с перфораторами.

Теперь обратите внимание на демонстрацию примера нашей контекстной рекламы. После того как я вставил адрес страницы, в генераторе объявлении появилась ссылка в виде домена.

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

Однако ваш урл должен быть не более 20 символов. Также если домен сайта имеет SSl-сертификат, то не забывайте ставить на https.

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

Сейчас я покажу, как сделать быстрые ссылки в Директе. Итак, нажимаем кнопку “Добавить”. Выше отображается демонстрационный вид будущего объявления. Спускаемся чуть ниже и заполняем анкор (текст ссылки) и сам адрес на страницу.

Далее, после заполнения сохраняем настройки рекламной кампании. Помимо задания быстрых ссылок, можно использовать еще и изображение. Нажмите на “Добавить изображение”.

Хочу вас предупредить, что тут более значимы три параметра, без которых изображение не появится в объявлении:

Для примера давайте загрузим одно изображение. Однако сначала обратите внимание на следующие требования к изображениям Яндекс Директ:

• Принимаются три основных формата файла: jpg, png и gif;
• При стандартном соотношении сторон (от 1:1 до 4:3) размер изображения должен быть в пределах 450 — 5000 px со всех сторон;
• Для широкоформатных картинок (16:9) размер будет от 1080 x 607 до 5000 x 2812 px;
• Вес файл должен быть меньше 10 Mb.

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

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

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

Все это делается в этой же группе. Просто ниже создайте такую же рекламу (кнопка «+Объявление»), но уже с другим форматом картинки. Если вы делаете контекстную рекламу под мобильный сегмент, то не забудьте отметить пункт «Мобильное объявление«.

А мы идем дальше. Следующий пункт у нас будет “Адрес и телефон”. Повторяться уже не буду. Об этом я говорил в первом шаге настройки Директа (ссылка в начале поста). Поэтому этот момент я пропущу и пойду дальше по настройкам.

Новые ключевые фразы мы уже заполнили. У нас, это один главный ключ. Больше в это поле мы ничего не добавляем. Так мы соблюдаем золотое правило контекстной рекламы в интернете – “Один запрос – одно объявление.”

Теперь подходим к минус-словам. В принципе, тут в yandex ru директ тоже можно ничего не добавлять, так как минус-слова мы добавили еще в первом шаге настройки. Поэтому этот пункт тоже пропускаем.

Условия ретаргетинга вы пока не задавайте. Об этом я буду более подробно говорить в отдельной статье про эффективность рекламной кампании средствами веб-аналитики.

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

Регионы показа мы тоже указывали в первом шаге. У меня это Москва и область. Вы конечно же, можете тут уточнить. Но я рекомендую такой параметр настраивать сразу на первом шаге по созданию Yandex рекламы.

Дальше идут у нас метки. Они нужны для того, чтобы вам потом было проще найти какие-то свои объявления. Это полезно, когда в вашей рекламной кампании находится несколько сотен рекламных объявлений.

Таким образом, можно воспользоваться поиском по меткам. Поскольку, мое объявление нацелено на общий каталог продукции, то для него я создам метку “Все перфораторы каталог”.

Итак, на этом у нас все.

Второй шаг по настройке рекламной кампании в Яндекс Директ мы уже сделали. То есть у нас есть рекламное объявление, указаны быстрые ссылки Yandex Direct, поработали с изображением, ключевыми словами и метками.

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

Из чего состоит рекламное объявление Яндекс.Директ

about.PPC
Свалка подсказок на тему

Полностью заполненное и правильно настроенное объявление Яндекс.Директ на страницах поиска выглядит так:



Разберем его по составляющим. Первая строчка состоит из иконки сайта и заголовка объявления:



В роли иконки сайта выступает фавиконка (файл favicon.ico из корневой папки сайта), она подгружается автоматически и редактируется заменой данного файла на хостинге. Заголовок объявления является обязательным элементом и заполняется при создании объявления. Его максимальная длина — 33 символа, однако он будет увеличен за счет добавления домена сайта или, при выполнении некоторых условий, за счет добавления к заголовку первого предложения из текста сайта.

Вторая строчка объявления состоит из блока «быстрых ссылок»:



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

Третью строчку занимает ссылка на сайт:



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

Далее идет строка с текстом объявления:



Это обязательная часть объявления, заполняется рекламодателем, не может состоять более, чем из 75 символов с учетом пробелов.

Строкой ниже выводится блок «Уточнения»:



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

Последней строкой объявления идет контактная информация:



Эта часть выводится в том случае, если рекламодатель заполнил виртуальную визитку объявления — добавил информацию об адресе, способах связи (телефон, e-mail, мессенджер) и времени работы. При клике на ссылку «Контактная информация» пользователю откроется типовое окно с контактной информацией о фирме, предоставляющей рекламируемую услугу:



Страница с визиткой содержит элементы объявления (заголовок, текст, ссылку), дополняя их картой и контактными данными — e-mail, номер телефона, время работы и адрес.

Мы рассмотрели все ключевые составляющие объявления Яндекс.Директ, видимые пользователям. Внешний вид объявления меняется в зависимости от места показа (например на мобильной версии яндекса не отображается виртуальная визитка — вместо нее используется иконка с телефонной трубкой, при клике на которую происходит звонок). Но три составляющие у объявления будут всегда — заголовок, текст и основная ссылка на рекламируемую страницу.

©about-ppc.ru
Пишем про трафик.

HTTP / 1.1: определения методов

HTTP / 1.1: определения методов

9 Определения методов

Набор общих методов для HTTP / 1.1 определен ниже. Хотя
этот набор может быть расширен, дополнительные методы не могут быть
используют одну и ту же семантику для отдельно расширенных клиентов и серверов.

Поле заголовка запроса хоста (раздел 14.23) ДОЛЖНО сопровождать все
HTTP / 1.1 просьба.

9.1 Безопасные и идемпотентные методы

9.1.1 Безопасные методы

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

В частности, было установлено, что GET и
Методы HEAD НЕ ДОЛЖНЫ иметь значение выполнения действия
кроме поиска.Эти методы следует считать «безопасными».
Это позволяет пользовательским агентам представлять другие методы, такие как POST, PUT.
и DELETE особым образом, чтобы пользователь знал о
тот факт, что запрашивается возможно небезопасное действие.

Естественно, нельзя гарантировать, что сервер не
генерировать побочные эффекты в результате выполнения запроса GET; в
Фактически, некоторые динамические ресурсы считают это функцией. Важный
различие в том, что пользователь не запрашивал побочные эффекты,
поэтому поэтому не может нести за них ответственность.

9.1.2 Идемпотентные методы

Методы также могут обладать свойством «идемпотентности» в этом (помимо
из-за ошибки или истечения срока действия) побочные эффекты N> 0 идентичны
запросы такие же, как и для одиночного запроса. Методы GET, HEAD,
PUT и DELETE совместно используют это свойство. Также методы OPTIONS и
TRACE НЕ ДОЛЖЕН иметь побочных эффектов, и поэтому они по своей сути идемпотентны.

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

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

9.2 ОПЦИИ

Метод OPTIONS представляет собой запрос информации о
варианты связи, доступные в цепочке запросов / ответов
идентифицируется Request-URI. Этот метод позволяет клиенту
определять варианты и / или требования, связанные с ресурсом,
или возможности сервера, не подразумевая действия ресурса
или инициируя поиск ресурса.

Ответы на этот метод не кэшируются.

Если запрос OPTIONS включает тело объекта (как указано
наличие Content-Length или Transfer-Encoding), затем тип носителя
ДОЛЖЕН быть обозначен полем Content-Type. Хотя это
спецификация не определяет использование такого тела, будущее
расширения HTTP могут использовать тело OPTIONS, чтобы сделать более подробными
запросы на сервере. Сервер, не поддерживающий такой
extension МОЖЕТ отбросить тело запроса.

Если Request-URI является звездочкой («*»), запрос OPTIONS
предназначен для применения к серверу в целом, а не к конкретному
ресурс.Поскольку параметры связи сервера обычно зависят от
ресурс, запрос «*» полезен только как «пинг» или «без операции»
тип метода; он ничего не делает, кроме того, что позволяет клиенту протестировать
возможности сервера. Например, это можно использовать для проверки
прокси на соответствие HTTP / 1.1 (или его отсутствие).

Если Request-URI не является звездочкой, применяется запрос OPTIONS.
только к тем параметрам, которые доступны при общении с этим
ресурс.

Ответ 200 ДОЛЖЕН включать любые поля заголовка, которые указывают
дополнительные функции, реализованные сервером и применимые к нему
ресурс (например, Разрешить), возможно, включая расширения, не определенные
эта спецификация. В текст ответа, если таковой имеется, СЛЕДУЕТ также включать
информация о вариантах связи. Формат такого

тело не определено этой спецификацией, но может быть определено
будущие расширения HTTP.Согласование содержимого МОЖЕТ использоваться для выбора
соответствующий формат ответа. Если тело ответа не включено,
ответ ДОЛЖЕН включать поле Content-Length со значением поля
«0».

Поле заголовка запроса Max-Forwards МОЖЕТ использоваться для нацеливания на
конкретный прокси в цепочке запросов. Когда прокси получает ОПЦИИ
запрос на absoluteURI, для которого разрешена пересылка запроса,
прокси-сервер ДОЛЖЕН проверять поле Max-Forwards.Если Max-Forwards
значение поля равно нулю («0»), прокси-сервер НЕ ДОЛЖЕН пересылать сообщение;
вместо этого прокси-сервер ДОЛЖЕН отвечать своими собственными параметрами связи.
Если значение поля Max-Forwards является целым числом больше нуля,
прокси-сервер ДОЛЖЕН уменьшить значение поля при пересылке запроса. Если
в запросе нет поля Max-Forwards, тогда перенаправленное
запрос НЕ ДОЛЖЕН включать поле Max-Forwards.

9,3 ПОЛУЧИТЬ

Метод GET означает получение любой информации (в виде
entity) идентифицируется Request-URI.Если Request-URI ссылается на
для процесса производства данных именно произведенные данные должны быть
возвращается как объект в ответе, а не как исходный текст
процесса, если только этот текст не является результатом процесса.

Семантика метода GET меняется на «условный GET», если
сообщение запроса включает If-Modified-Since, If-Unmodified-Since,
Поле заголовка If-Match, If-None-Match или If-Range. Условный GET
метод требует, чтобы объект был передан только под
обстоятельства, описанные условным полем (ями) заголовка.В
условный метод GET предназначен для сокращения ненужных сетевых
использование, позволяя обновлять кэшированные объекты без необходимости
множественные запросы или передача данных, уже имеющихся у клиента.

Семантика метода GET меняется на «частичный GET», если
сообщение запроса включает поле заголовка диапазона. Частичные запросы GET
что только часть предприятия будет передана, как описано в разделе
14.35. Частичный метод GET предназначен для сокращения ненужных
использование сети, позволяя частично извлеченным объектам быть
завершено без передачи данных, уже имеющихся у клиента.

Ответ на запрос GET кэшируется тогда и только тогда, когда он соответствует
требования к HTTP-кешированию, описанные в разделе 13.

См. Раздел 15.1.3 для ознакомления с соображениями безопасности при использовании для форм.

ГОЛОВКА 9,4

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН
вернуть тело сообщения в ответ. Метаинформация содержала
в заголовках HTTP в ответ на запрос HEAD ДОЛЖНЫ быть идентичными
к информации, отправленной в ответ на запрос GET.Этот метод может
использоваться для получения метаинформации о сущности, подразумеваемой
запрос без передачи самого тела объекта. Этот метод
часто используется для проверки гипертекстовых ссылок на валидность, доступность,
и недавняя модификация.

Ответ на запрос HEAD МОЖЕТ быть кэшируемым в том смысле, что
информация, содержащаяся в ответе, МОЖЕТ использоваться для обновления
ранее кэшированный объект из этого ресурса. Если новые значения поля
указывают, что кэшированный объект отличается от текущего объекта (как
будет обозначено изменением Content-Length, Content-MD5, ETag
или Last-Modified), то кеш ДОЛЖЕН обрабатывать запись кэша как
несвежий.

9,5 ПОСТ

Метод POST используется для запроса, чтобы исходный сервер принял
сущность, заключенная в запрос как новый подчиненный ресурс
идентифицируется Request-URI в строке запроса. POST разработан
чтобы единый метод охватывал следующие функции:

 - Аннотация существующих ресурсов;
 

 - Отправка сообщения на доску объявлений, группу новостей, список рассылки,
        или аналогичная группа статей;
 

 - Предоставление блока данных, например, в результате отправки
        форма для процесса обработки данных;
 

 - Расширение базы данных с помощью операции добавления.

Фактическая функция, выполняемая методом POST, определяется
server и обычно зависит от Request-URI. Размещенная сущность
подчиняется этому URI так же, как файл подчиняется
к каталогу, содержащему его, новостная статья подчиняется
группа новостей, в которой она размещена, или запись подчиняется
база данных.

Действие, выполняемое методом POST, может не привести к
ресурс, который можно идентифицировать по URI.В этом случае либо 200
(ОК) или 204 (Нет содержимого) — соответствующий статус ответа,
в зависимости от того, включает ли ответ объект, который
описывает результат.

Если ресурс был создан на исходном сервере, ответ
ДОЛЖЕН быть 201 (Создано) и содержать объект, который описывает
статус запроса и относится к новому ресурсу, а Location
заголовок (см. раздел 14.30).

Ответы на этот метод не кэшируются, если только ответ
включает соответствующие поля заголовка Cache-Control или Expires.Однако,
ответ 303 (см. прочее) можно использовать для направления пользовательского агента на
получить кэшируемый ресурс.

Запросы POST ДОЛЖНЫ подчиняться изложенным требованиям к передаче сообщений.
в разделе 8.2.

См. Раздел 15.1.3 по соображениям безопасности.

9,6 PUT

Метод PUT запрашивает, чтобы закрытый объект был сохранен в
предоставленный Request-URI. Если Request-URI ссылается на уже
существующий ресурс, закрытый объект СЛЕДУЕТ рассматривать как
модифицированная версия того, что находится на исходном сервере.Если
Request-URI не указывает на существующий ресурс, и этот URI
может быть определен как новый ресурс запрашивающим пользователем
агент, исходный сервер может создать ресурс с этим URI. Если
создается новый ресурс, исходный сервер ДОЛЖЕН проинформировать пользовательский агент
через ответ 201 (Создано). Если существующий ресурс изменен,
ДОЛЖНЫ быть отправлены коды ответа 200 (ОК) или 204 (Нет содержимого)
чтобы указать на успешное выполнение запроса.Если ресурс
не может быть создан или изменен с помощью Request-URI, подходящего
СЛЕДУЕТ дать ответ об ошибке, который отражает характер
проблема. Получатель объекта НЕ ДОЛЖЕН игнорировать любой Content- *
(например, Content-Range) заголовки, которые он не понимает или не реализует
и ДОЛЖЕН возвращать ответ 501 (Не реализовано) в таких случаях.

Если запрос проходит через кеш и Request-URI идентифицирует
один или несколько кэшированных в настоящее время объектов, эти записи ДОЛЖНЫ быть
считается устаревшим.Ответы на этот метод не кэшируются.

Принципиальная разница между запросами POST и PUT заключается в следующем:
отражено в другом значении Request-URI. URI в
Запрос POST определяет ресурс, который будет обрабатывать вложенные
юридическое лицо. Этот ресурс может быть процессом приема данных, шлюзом к
какой-то другой протокол или отдельный объект, принимающий аннотации.
Напротив, URI в запросе PUT идентифицирует вложенный объект
с запросом — пользовательский агент знает, какой URI предназначен и
сервер НЕ ДОЛЖЕН пытаться применить запрос к какому-либо другому ресурсу.Если сервер желает, чтобы запрос был применен к другому URI,

он ДОЛЖЕН отправить ответ 301 (перемещен навсегда); пользовательский агент МОЖЕТ
затем принять собственное решение относительно того, перенаправлять или нет
запрос.

Один ресурс МОЖЕТ идентифицироваться множеством разных URI. Для
Например, у статьи может быть URI для идентификации «текущего
версия «, который отличается от URI, идентифицирующего каждый конкретный
версия.В этом случае запрос PUT для общего URI может привести к
несколько других URI, определяемых исходным сервером.

HTTP / 1.1 не определяет, как метод PUT влияет на состояние
исходный сервер.

Запросы PUT ДОЛЖНЫ подчиняться изложенным требованиям к передаче сообщений.
в разделе 8.2.

Если иное не указано для конкретного заголовка объекта,
заголовки объектов в запросе PUT ДОЛЖНЫ применяться к ресурсу
создан или изменен PUT.

9,7 УДАЛИТЬ

Метод DELETE запрашивает у исходного сервера удаление ресурса.
идентифицируется Request-URI. Этот метод МОЖЕТ быть переопределен человеком.
вмешательство (или другие средства) на исходный сервер. Клиент не может
гарантировать, что операция была проведена, даже если
код состояния, возвращенный исходным сервером, указывает, что действие
был успешно завершен. Однако серверу НЕ СЛЕДУЕТ
указывает на успех, если в момент получения ответа
намеревается удалить ресурс или переместить его в недоступный
расположение.

Успешный ответ ДОЛЖЕН быть 200 (ОК), если ответ включает
сущность, описывающая статус, 202 (Принято), если действие не
еще не было выполнено, или 204 (Нет содержимого), если действие было выполнено
но ответ не включает сущность.

Если запрос проходит через кеш и Request-URI идентифицирует
один или несколько кэшированных в настоящее время объектов, эти записи ДОЛЖНЫ быть
считается устаревшим. Ответы на этот метод не кэшируются.

9,8 СЛЕД

Метод TRACE используется для вызова удаленного цикла на уровне приложения.
обратная сторона сообщения запроса. Конечный получатель запроса
ДОЛЖЕН отражать полученное сообщение обратно клиенту как
entity-body ответа 200 (OK). Конечным получателем является либо

исходный сервер или первый прокси или шлюз для получения Max-Forwards
значение нуля (0) в запросе (см. раздел 14.31). Запрос TRACE
НЕ ДОЛЖЕН включать сущность.

TRACE позволяет клиенту видеть, что получает другой
конец цепочки запросов и использовать эти данные для тестирования или диагностики
Информация. Значение поля заголовка Via (раздел 14.45) равно
особый интерес, поскольку он действует как след цепочки запросов.
Использование поля заголовка Max-Forwards позволяет клиенту ограничивать
длина цепочки запросов, что полезно для тестирования цепочки
прокси пересылают сообщения в бесконечном цикле.

Если запрос действителен, ответ ДОЛЖЕН содержать все
сообщение запроса в теле объекта с Content-Type равным
«сообщение / http». Ответы на этот метод НЕ ДОЛЖНЫ кэшироваться.

9.9 ПОДКЛЮЧИТЬ

Эта спецификация резервирует имя метода CONNECT для использования с
прокси, который может динамически переключаться на туннель (например, SSL
туннелирование [44]).

Настройка пределов запросов | Barracuda Campus

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

Пределы запросов включены по умолчанию, запросы, превышающие указанную длину, считаются атаками переполнения буфера. Обычно подходят значения по умолчанию, но вы можете изменить одно или несколько значений по умолчанию при определенных условиях.

Когда менять значения по умолчанию:

Значения по умолчанию можно изменить, если у службы или сервера могут быть проблемы, длина которых меньше значений по умолчанию.Если для действия Action задано значение Deny и Log или Deny без журнала для службы под URL: Allow / Deny Rules на странице WEBSITES> Allow / Deny , брандмауэр веб-приложений Barracuda продолжает проверку запрос, пока он не достигнет настроенной длины по умолчанию. Меньшие ограничения приведут к небольшому повышению производительности, поскольку перед отклонением запросов анализируется меньшее количество байтов. Значения по умолчанию можно изменить на более высокие, если исходные значения по умолчанию приводят к ложным срабатываниям.

Шаги по настройке лимитов запросов

1. Перейдите на страницу ПОЛИТИКИ БЕЗОПАСНОСТИ> Лимиты запросов .
2. Выберите политику из раскрывающегося списка Имя политики , для которой вы хотите изменить параметры ограничения запросов.
3. В разделе Пределы запросов укажите значения для следующих полей:
   
   1. Включить лимиты запросов — Если задано значение Да , для заголовков запросов принудительно проверяются ограничения размера.
      
      • Значения : Да, Нет
      • Рекомендуется : Да
   2. Максимальная длина запроса — Введите максимально допустимую длину запроса. Это включает строку запроса и все заголовки HTTP-запроса (например, User Agent, Cookies, Referer и т. Д.). Предел длины запроса не включает тело запроса, которое обычно присутствует для запросов POST. Любой запрос, длина которого превышает этот предел, будет отклонен.
      • Диапазон : от 1 байта до 65536 байтов.
      • Рекомендуемая : 32768 байтов
   3. Максимальная длина строки запроса — Введите максимально допустимую длину строки запроса. Строка запроса состоит из метода, URL-адреса (включая любые строки запроса) и версии HTTP. Пример:
      GET /index.cgi?page=home HTTP / 1.1
      В приведенной выше строке запроса GET — это метод, /index.cgi?page=home — это URL, а HTTP / 1.1 — версия. При проверке длины строки запроса учитывается длина всей строки.
      • Диапазон : от 1 байта до 65536 байтов.
      • Рекомендуемый : 4096 байт
   4. Макс. Длина URL-адреса — введите максимально допустимую длину URL-адреса, включая часть строки запроса URL-адреса.
      • Диапазон : от 1 байта до 128 килобайт. Отсутствие значения (пустое) означает неограниченное.
      • Рекомендуемый : 4096 байт
   5. Максимальная длина запроса — введите максимально допустимую длину для части строки запроса URL-адреса.
      • Диапазон : от 1 байта до 60000 байтов. Отсутствие значения (пустое) означает неограниченное.
      • Рекомендуемый : 4096 байт
   6. Максимальное количество файлов cookie — введите максимальное количество файлов cookie, которое будет разрешено.
      • Диапазон : от 1 до 1024. Если значение не указано или поле оставлено пустым, это означает неограниченное значение.
      • Рекомендуемый : 40
   7. Максимальная длина имени файла cookie — введите максимально допустимую длину имени файла cookie.
      • Диапазон : от 1 байта до 1024 байтов. Отсутствие значения (пустое) означает неограниченное.
      • Рекомендуемый : 64 байта
   8. Максимальная длина значения cookie — Введите максимально допустимую длину значения cookie. Запросы со значениями cookie, превышающими заданный параметр, отклоняются.
      • Диапазон : от 1 байта до 32768 байтов. Отсутствие значения (пустое) означает неограниченное.
      • Рекомендуемый : 4096 байт
   9. Максимальное количество заголовков — Введите максимальное количество заголовков в запросе.Если количество заголовков в запросе превышает этот предел, запрос отклоняется.
      • Диапазон : от 1 до 40. Отсутствие значения (пустое) означает неограниченное.
      • Рекомендуется : 20
   10. Максимальная длина имени заголовка — Введите максимально допустимую длину имени заголовка.
       • Диапазон : от 1 байта до 1024 байтов. Отсутствие значения (пустое) означает неограниченное.
       • Рекомендуемый : 32 байта

   11. Максимальная длина значения заголовка — Введите максимально допустимую длину для любого заголовка запроса.Заголовок запроса может быть заголовком протокола HTTP, например «Host», «User-Agent» и т. Д., Или настраиваемым заголовком, например «IIS Translate». Запрос может содержать любое количество этих заголовков.

       • Диапазон : от 1 байта до 64 килобайт. Отсутствие значения (пустое) означает неограниченное.

       • Рекомендуется : 1024 байта

   Этот параметр не применяется к файлам cookie. Вместо этого длина файлов cookie контролируется параметрами, связанными с файлами cookie: Максимальная длина имени файла cookie, и Максимальная длина значения файла cookie .

4. Нажмите Сохранить
   .

Длина полезной нагрузки — обзор

IPv6 и фрагментация

Что произойдет, если мы поместим IPv6 в ситуацию, когда он должен фрагментировать содержимое пакета, чтобы оно поместилось во фрейм? Давайте воспользуемся Illustrated Network, чтобы узнать. Двумя полезными параметрами ping являются размер пакета, возвращаемого удаленным устройством, и количество отправленных пакетов. Мы будем перехватывать пакеты, отправленные, когда bsdserver отправляет маршрутизатору пакет размером 2000 байт (слишком большой для кадра Ethernet).

bsdserver # ping6 -s 2000 -c 1 fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb

PING6 (2048 = 40 + 8 + 2000 байт) fc00: fe67: d4: b: 20e : cff: fe3b: 8732 ->

fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb

2008 байты из fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb, icmp_seq = 0 hlim = 64 время = 2,035 мс

— fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb статистика ping6 —

1 пакет передан, 1 пакет получен, 0% потеря пакетов

туда и обратно min / avg / max / std-dev = 2.035 / 2.035 / 2.035 / 0.000 мс

bsdserver #

Это делает 2008 байтов с заголовком IPv6. Вот что у нас есть (поля данных, которые содержат тестовые строки, опущены):

bsdserver # tethereal -V

Захват на em0

Кадр 1 (1510 байтов на проводе, 1510 байтов захвачено)

Прибытие Время: 25 мая 2008 г. 08: 39: 21.231993000

Разница во времени от предыдущего пакета: 0,000000000 секунд

Время с момента ссылки или первого кадра: 0.000000000 секунд

Номер кадра: 1

Длина пакета: 1510 байтов

Длина захвата: 1510 байтов

Ethernet II, Src: 00: 0e: 0c: 3b: 87: 32, Dst: 00: 05: 85: 8b : bc: db

Назначение: 00: 05: 85: 8b: bc: db (JuniperN_8b: bc: db)

Источник: 00: 0e: 0c: 3b: 87: 32 (Intel_3b: 87: 32)

Тип: IPv6 (0x86dd)

Версия Интернет-протокола 6

Версия: 6

Класс трафика: 0x00

Flowlabel: 0x00000

Длина полезной нагрузки: 1456

Следующий заголовок: фрагмент IPv6 (0x2c)

Исходный адрес: fc00: fe67: d4: b: 20e: cff: fe3b: 8732 (fc00: fe67: d4: b: 20e: cff: fe3b: 8732)

Целевой адрес: fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb (fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb)

Заголовок фрагментации

Следующий заголовок: ICMPv6 (0x3a)

Смещение: 0

Другие фрагменты: Да

Идентификация: 0x000000e5 900 08

Протокол управляющих сообщений Интернета v6

Тип: 128 (эхо-запрос)

Код: 0

Контрольная сумма: 0x74df

ID: 0x0e60

Последовательность: 0x0000

Данные (1440 байт) (OMIT0007 Frame 20008

) (622 байта на проводе, 622 байта захвачены)

Время прибытия: 25 мая 2008 г. 08:39:21.232007000

Разница во времени от предыдущего пакета: 0,000014000 секунд

Время с момента ссылки или первого кадра: 0,000014000 секунд

Номер кадра: 2

Длина пакета: 622 байта

Длина захвата: 622 байта

Ethernet II, Src: 00 : 0e: 0c: 3b: 87: 32, Dst: 00: 05: 85: 8b: bc: db

Назначение: 00: 05: 85: 8b: bc: db (JuniperN_8b: bc: db)

Источник: 00: 0e: 0c: 3b: 87: 32 (Intel_3b: 87: 32)

Тип: IPv6 (0x86dd)

Версия Интернет-протокола 6

Версия: 6

Класс трафика: 0x00

Метка потока: 0x00000

Длина полезной нагрузки: 568

Следующий заголовок: фрагмент IPv6 (0x2c)

Ограничение переходов: 64

Исходный адрес: fc00: fe67: d4: b: 20e: cff: fe3b: 8732 (fc00: fe67: d4: b: 20e : cff: fe3b: 8732)

Адрес назначения: fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb (fc00: fe67: d4: b: 205: 85ff: fe8b: bcdb)

Заголовок фрагментации

Nex t заголовок: ICMPv6 (0x3a)

Смещение: 1448

Дополнительные фрагменты: Нет

Идентификация: 0x000000e5

Данные (560 байтов) (ОПРЕДЕЛЕНА)

(Фреймы 3 и 4, эхо-кадры, отправленные обратно в ответ, являются зеркальные изображения кадров 1 и 2 и для краткости опущены.)

bsdserver #

Поскольку хост не может упаковать 2000 байтов в кадр Ethernet, хост IPv6 выполняет фрагментацию перед тем, как отправит биты в LAN. Однако в заголовке IPv6 нет полей фрагментации, поэтому IPv6 включает второй заголовок (следующий заголовок), который несет информацию, необходимую для места назначения для повторной сборки фрагментов (в данном случае двух из них). Важные поля выделены жирным шрифтом в предыдущем коде.

Первый кадр (в захвате указано «пакет») имеет длину 1510 байтов, включая 1456 байтов полезной нагрузки (заданной в поле «Длина полезной нагрузки»).Значение следующего заголовка 0x2c указывает, что следующий заголовок является заголовком фрагмента IPv6. Поля заголовка фрагментации перечислены полностью:

•

Следующий заголовок (0x3a) — заголовок, следующий за заголовком фрагментации, является заголовком сообщения ICMPv6.

•

Смещение (0) — это первый фрагмент серии.

•

Дополнительные фрагменты (Да) — впереди еще несколько фрагментов.

•

Идентификация (0x000000e5) — только повторно собирайте фрагменты, которые имеют это значение идентификатора.

Длина поля данных в сообщении ICMPv6 составляет 1440 байт. Остальные 1510 байтов относятся к различным заголовкам, вставленным в эти байты.

Кадр 2 содержит оставшиеся 2000 байтов в проверке связи. Этот кадр имеет длину 622 байта и содержит 568 байтов полезной нагрузки. Следующий заголовок по-прежнему является фрагментом IPv6 (0x2c). Поля заголовка фрагментации следующие:

•

Следующий заголовок (0x3a) — заголовок, следующий за заголовком фрагментации, является заголовком сообщения ICMPv6.

•

Смещение (1448) — эти байты начинаются на 1448 байтов после содержимого первого кадра. («Дополнительные» 8 байтов предназначены для заголовка ICMPv6.)

•

Дополнительные фрагменты (Нет) — содержимое этого пакета завершает серию.

•

Идентификация (0x000000e5) — этот фрагмент идет с предыдущим с этим значением идентификатора.

Длина поля данных в сообщении ICMPv6 составляет 560 байт.Вместе с 1440 байтами в первом фрагменте они составляют 2000 отправленных байтов.

Ошибка буфера заголовка сообщения HTTP

AEM / CQ имеет буфер для содержимого заголовка запроса HTTP. Содержимое заголовков HTTP-запроса и ответа должно умещаться в буфере. В CQ 5.5 и AEM 5.6 размер этого буфера по умолчанию составляет 8 КБ. Размер буфера заголовка по умолчанию больше в AEM 6.

Все сообщения HTTP состоят из двух частей: заголовка сообщения и тела сообщения.

Тело сообщения содержит всю информацию, которую мы считаем содержанием сообщения. Примерами тела сообщения может быть HTML-текст веб-страницы или двоичный файл изображения. Для сообщений HTTP, использующих запросы POST, тело сообщения может содержать параметры почтового запроса.

Заголовок содержит информацию о запросе или ответе. Сюда входит используемый метод HTTP и запрошенный URL-адрес. Для сообщений HTTP-ответа также включается HTTP-статус ответа.Другая информация о HTTP-сообщении может быть включена в виде пар ключ / значение, которые называются полями заголовка. Файлы cookie браузера также отправляются и принимаются в виде пар ключ / значение в заголовках сообщений.

Заголовок сообщения предназначен для оценки при получении и обрабатывается как единое целое до того, как сервер или браузер выполнят действия с содержимым сообщения. AEM считывает заголовок сообщения HTTP в буфер, который должен быть достаточно большим, чтобы содержать весь заголовок. Если содержимое заголовка сообщения HTTP слишком велико для размещения в буфере, сообщение не будет выполнено.

Существует несколько условий, при которых заголовок сообщения HTTP может оказаться слишком большим, чтобы поместиться в буфер сервера. Любое из этих условий само по себе или в сочетании с другими условиями может привести к тому, что HTTP станет слишком большим.

URL-адрес в запросе может быть слишком длинным для буфера. Это может произойти, например, когда запрос содержит сотни аргументов URL. Или это может произойти, когда отдельные аргументы URL-адреса огромны.

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

Разработчики могут создавать собственные поля заголовков. Часто реализации единого входа используют настраиваемые поля заголовка. Поскольку размер значений в полях заголовков не ограничен в спецификации HTTP, разработчики могут создавать поля заголовков с большим объемом содержимого.

См. Также

Спецификация сообщения HTTP
Спецификация веб-хранилища HTTP

HTTP-маршрутизация | Центр разработки Heroku

Последнее обновление: 20 июля 2021 г.

Платформа Heroku автоматически направляет HTTP-запросы, отправленные на имя (а) вашего приложения, на ваши веб-серверы.Точкой входа для всех приложений в стеке Common Runtime является домен herokuapp.com , который предлагает прямой путь маршрутизации к вашим веб-серверам.

В этой статье содержится подробная информация о том, как ведет себя маршрутизатор и как он соответствует спецификации HTTP.

Маршрут

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

Маршрутизаторы отвечают за определение местоположения веб-серверов вашего приложения и переадресацию HTTP-запроса на один из этих серверов.

Необфусцированный путь запроса от конечного клиента через инфраструктуру Heroku к вашему приложению обеспечивает полную поддержку функций HTTP 1.1, таких как фрагментированные ответы, длительный опрос, веб-сокеты и использование асинхронного веб-сервера для обработки нескольких ответов от одного веб-процесса. Также поддерживается совместимость с HTTP 1.0.

Распределение запросов

Маршрутизаторы

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

Параллелизм запросов

Каждый маршрутизатор поддерживает внутренний счетчик запросов для каждого приложения. В Common Runtime маршрутизаторы ограничивают количество одновременных запросов на приложение. Однако между маршрутизаторами нет координации, поэтому этот лимит запросов установлен для каждого маршрутизатора. Счетчик запросов на каждом маршрутизаторе имеет максимальный размер 200n (n = количество веб-серверов, работающих в вашем приложении). Если счетчик запросов на конкретном маршрутизаторе заполняется, последующие запросы к этому маршрутизатору немедленно вернут ответ h21 (слишком глубокий бэклог).

Поведение Dyno-соединения в Common Runtime

Когда Heroku получает HTTP-запрос, маршрутизатор устанавливает новое восходящее TCP-соединение со случайно выбранным веб-дино, работающим в Common Runtime. Если соединение отклонено или не было успешно установлено через 5 секунд, дино будет помещено в карантин, и никакие другие соединения не будут перенаправлены от этого маршрутизатора к дино в течение 5 секунд. Карантин применяется только к одному маршрутизатору. Поскольку каждый маршрутизатор хранит свой собственный список помещенных в карантин динамометрических станций, другие маршрутизаторы могут продолжать перенаправлять подключения к динамометрическим станциям.

При отказе в соединении с динамометрическим станком или истечении времени ожидания маршрутизатор, обрабатывающий запрос, повторит запрос на другом диностенде. Будет сделано не более 10 попыток (или меньше, если у вас нет 10 работающих веб-динамометров), прежде чем будет возвращена ошибка h29 или h31.

Если все динамометрические станции помещены в карантин, маршрутизатор будет повторять попытку в течение 75 секунд (с постепенным откатом) перед обработкой ошибки H99.

Поведение подключения Dyno в частных пространствах

Dynos в частном пространстве работают в собственной сети и на уровне маршрутизации и обмениваются данными друг с другом через частную сеть.Маршрутизатор в частных пространствах получает исходящие HTTP-запросы по набору разрешенных стабильных IP-адресов.

В отличие от поведения маршрутизатора в Common Runtime с веб-диностендами, маршрутизатор в Private Spaces не пересылает какие-либо соединения HTTP-запросов от одного веб-динамометрического стенда к другому, если в соединении отказано или истекло время ожидания. Вместо этого соединение прерывается через 30 секунд и возвращает ошибку h22. Дополнительные сведения о поведении маршрутизации в частных пространствах можно найти в статье «Маршрутизация в частных пространствах».

Таймауты

После того, как установлено динамическое соединение, HTTP-запросы имеют начальное 30-секундное окно, в котором веб-процесс должен вернуть данные ответа (либо завершенный ответ, либо некоторый объем данных ответа, чтобы указать, что процесс активен). Процессы, которые не отправляют данные ответа в течение начального 30-секундного окна, увидят в своих журналах ошибку h22.

После первоначального ответа каждый отправленный байт (либо от клиента, либо от процесса вашего приложения) сбрасывает скользящее 55-секундное окно.Если в течение этого 55-секундного окна данные не отправляются, соединение разрывается и регистрируется ошибка h25 или h38.

Дополнительную информацию можно найти в статье Тайм-аут запроса.

Одновременные подключения

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

Почти все современные веб-фреймворки и встраиваемые веб-серверы поддерживают несколько одновременных подключений. Примеры веб-серверов, которые позволяют одновременную обработку запросов в динамометрическом стенде, включают Unicorn (Ruby), Goliath (Ruby), Puma (JRuby), Gunicorn (Python) и Jetty (Java).

Буферизация запросов

При обработке входящего запроса маршрутизатор устанавливает буфер для приема всей строки HTTP-запроса и заголовков запросов.У каждого из них есть дополнительные ограничения, описанные в разделе «Проверка и ограничения HTTP». Тело запроса с четко определенной длиной содержимого передается с использованием буфера размером 1024 байта, непрерывно заполняется и сбрасывается. Это представляет собой размер, который охватывает подавляющее большинство запросов с точки зрения объема. Потоковые тела запросов (кодирование фрагментов) будут передаваться по мере поступления данных. Запрос начнет отправляться на динамометрический стенд только после того, как будет получен весь набор заголовков HTTP.

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

Буферизация ответа

Маршрутизатор поддерживает буфер размером 1 МБ для ответов от динамометрического стенда на каждое соединение.Это означает, что вы можете отправить ответ размером до 1 МБ до того, как скорость, с которой клиент получит ответ, повлияет на динамический диапазон — даже если он закрывает соединение, маршрутизатор будет продолжать отправлять буфер ответа клиенту. Скорость передачи ответов, размер которых превышает размер буфера 1 МБ, будет ограничиваться тем, насколько быстро клиент может получать данные.

Все заголовки считаются нечувствительными к регистру согласно спецификации HTTP. Заголовки X-Forwarded-For , X-Forwarded-By , X-Forwarded-Proto и X-Forwarded-Host не являются доверенными по соображениям безопасности, поскольку невозможно узнать порядок в котором были добавлены уже существующие поля (согласно перенаправленному расширению HTTP).

• X-Forwarded-For : исходный IP-адрес клиента, подключающегося к маршрутизатору Heroku
• X-Forwarded-Proto : исходный протокол HTTP-запроса (пример: https)
• X-Forwarded-Port : исходный порт HTTP-запроса (пример: 443)
• X-Request-Start : временная метка unix (миллисекунды), когда запрос был получен маршрутизатором
• X-Request-Id : идентификатор HTTP-запроса Heroku
• Via : кодовое имя маршрутизатора Heroku

Формат журнала маршрутизатора Heroku

Информационные журналы

Это то, что отправляется в сток:

  264 <158> 1 2012-10-11T03: 47: 20 + 00: 00 host heroku router - at = info method = GET path = / host = myapp.herokuapp.com request_id = 8601b555-6a83-4c12-8269-97c8e32cdb22 fwd = "204.204.204.204" dyno = web.1 connect = 1ms service = 18ms status = 200 байт = 13 tls_version = tls1.1 protocol = http
  

Это та же строка журнала при просмотре с журналами heroku :

  2012-10-11T03: 47: 20 + 00: 00 heroku [router]: at = info method = GET path = / host = myapp.herokuapp.com request_id = 8601b555-6a83-4c12-8269-97c8e32cdb22 fwd = " 204.204.204.204 "dyno = web.1 connect = 1ms service = 18ms status = 200 байт = 13 tls_version = tls1.1 протокол = http
  

• метод : метод HTTP-запроса
• путь : путь HTTP-запроса и строка запроса
• хост : HTTP-запрос Хост значение заголовка
• request_id : идентификатор HTTP-запроса Heroku
• fwd : HTTP-запрос X-Forwarded-For значение заголовка
• dyno : имя dyno, обслуживающего запрос
• подключение : время в миллисекундах, затраченное на установление соединения с внутренним веб-процессом
• служба : количество времени в миллисекундах, затраченное на проксирование данных между внутренним веб-процессом и клиентом
• статус : код ответа HTTP
• байтов : количество байтов, переданных из внутреннего веб-процесса клиенту
• протокол : указывает протокол запроса
• tls_version : версия TLS, используемая для подключения.Возможные значения: ssl3.0, tls1.0, tls1.1, tls1.2, tls1.3 или unknown. Примечание: это только для частных пространств.

Журналы ошибок

Это то, что отправляется в сток:

  277 <158> 1 2012-10-11T03: 47: 20 + 00: 00 host heroku router - at = error code = h22 desc = "Request timeout" method = GET path = / host = myapp.herokuapp.com request_id = 8601b555-6a83-4c12-8269-97c8e32cdb22 fwd = "204.204.204.204" dyno = web.1 connect = service = 30000ms status = 503 байта = 0 протокол = http
  

Это та же строка журнала при просмотре с журналами heroku :

  2012-10-11T03: 47: 20 + 00: 00 heroku [маршрутизатор]: at = код ошибки = h22 desc = «Тайм-аут запроса» метод = GET path = / host = myapp.herokuapp.com request_id = 8601b555-6a83-4c12-8269-97c8e32cdb22 fwd = "204.204.204.204" dyno = web.1 connect = service = 30000ms status = 503 bytes = 0 protocol = http
  

Кэширование

Приложения, обслуживающие большие объемы статических ресурсов, могут использовать кеширование HTTP для повышения производительности и снижения нагрузки.

Веб-сокеты

Функциональность

WebSocket поддерживается для всех приложений.

Ответов в архиве Gzip

Поскольку запросы к приложениям Common Runtime выполняются непосредственно на сервер приложений, а не через прокси-сервер HTTP, например nginx, любое сжатие ответов должно выполняться в вашем приложении.

Поддерживаемые методы HTTP

Стек HTTP Heroku поддерживает любой HTTP-метод (иногда называемый «глаголом»), даже те, которые не определены в RFC, за исключением следующего: CONNECT.

Обычно используемые методы включают GET, POST, PUT, DELETE, HEAD, OPTIONS и PATCH. Имена методов ограничены длиной 127 символов.

Ожидать: 100-продолжить

Протокол HTTP имеет несколько встроенных механизмов, помогающих клиентам взаимодействовать с
серверов, чтобы улучшить обслуживание в целом.Одним из таких механизмов является
Expect: 100-continue Заголовок , который можно отправить вместе с
запросы [1].

Этот заголовок и значение должны использоваться дружественными клиентами при отправке
большие HTTP-запросы и хотите знать, может ли сервер их безопасно принять раньше
отправляя его, чтобы предотвратить проблемы с отказом в обслуживании и разрешить некоторые
оптимизации. HTTP-клиент cURL является наиболее известным
библиотека, использующая этот механизм, делая это для любого тела содержимого размером более 1 КБ
(недокументированное поведение).

Всякий раз, когда запрашивается разрешение, сервер может ответить
100 Продолжить статус HTTP,
что позволяет клиенту знать, что он готов к
принять запрос и позволить клиенту продолжить. Если сервер не может работать
с его помощью он может возвращать любой другой ответ HTTP, который имеет смысл для него, например
413 Слишком большой объект запроса
если он не хочет справляться с нагрузкой, и может
при желании закрыть соединение сразу после факта.

Таким образом, между любыми двумя клиентами и сервером механизм, который имеет место, может
выглядят примерно так для обычного звонка:

  [Клиент] [Сервер]
   | -------- Частичный запрос --------> |
   | <--------- 100 Продолжить ---------- |
   | --------- Тело запроса ----------> |
   | <----------- Ответ ------------ |
  

Или, если запрос отклонен:

  [Клиент] [Сервер]
   | -------- Частичный запрос --------> |
   | <- 413 Слишком большой объект запроса - |
  

Однако механизм должен быть более устойчивым, потому что не все серверы и
клиенты могут понять этот механизм.Таким образом, если клиент не знает
может ли сервер принимать и соблюдать заголовки Expect: 100-Continue ,
он должен отправлять фактическое тело после определенного периода времени:

  [Клиент] [Сервер]
   | -------- Частичный запрос --------> |
   | |
   | |
   | |
   | --------- Тело запроса ----------> |
   | <----------- Ответ ------------ |
  

По умолчанию многие веб-серверы не обрабатывают Expect: 100-continue как механизм.Следовательно, HTTP-маршрутизаторы Heroku автоматически вставят ответ 100 Continue от имени приложения, к которому он направляется, и позже пересылают данные.

Это более или менее полностью отключает механизм в том, что касается веб-сервера дино.

Включение поддержки 100-Continue

Теперь доступна сквозная поддержка (для участников бета-программы Heroku) через функцию лабораторий Heroku:

  $ heroku labs: включить http-end-to-end-continue
  

Если расширение включено, общий поток функции 100-Continue восстанавливается, и маршрутизатор прозрачно передает заголовки expect: 100-continue и связанные с ними ответы 100 continue .

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

Угловые шкафы

Есть набор специальных угловых футляров, которые могут поставляться с этим типом
запрос.

Исходный HTTP 1.1 RFC (RFC 2068)
разрешено использование частичного ответа 100 Continue , чтобы сервер мог сказать «
весь запрос не был проанализирован, но продолжайте, я не отрицаю
далеко". Более поздние RFC (RFC
2616 например)
содержать механизм Expect: 100-continue , а также переназначить 100
Продолжить частичный ответ как часть механизма, определенного в предыдущем
раздел текста.

По причинам обратной совместимости сервер может отправить 100
Продолжить , не получив соответствующий заголовок Expect , но сильно
посоветовал не делать этого.

Второй угловой случай заключается в том, что сервер может решить не отправлять обратно 100
Продолжить ответ , если он сначала начал получать и обрабатывать данные тела
рука, о которой клиент должен знать.

Серверы

также должны быть осторожны при разборе заголовков Expect , учитывая, что они
может содержать более одного значения .Например, Expect: 100-continue, auth .
может быть отправлен, когда ожидается, что сервер обработает большое тело, при запросе
пройти аутентификацию перед тем, как сделать это. Технически может быть столько значений, сколько
желательно в заголовке Expect с поведением, определенным исключительно для
ради клиента и сервера.

Другие особые случаи возникают из-за неожиданных взаимодействий, возникающих в результате
несколько заголовков, управляющих потоком подключения. Например:

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

Требования к прокси

Несмотря на то, что заголовок Expect определен как сквозной заголовок (только
клиент и сервер должны заботиться о них, объясняя, почему любой термин
может быть использован в нем), сам механизм 100 Continue (и общий
Expect. Поддержка поведения ) требует координации с прокси-серверами и выполняется поэтапно.
В RFC для них добавлены особые условия:

• Прокси-сервер должен передавать заголовок как есть, знает ли он, может ли сервер
  справиться или нет
• Если прокси-сервер знает, что сервер, к которому он направляется, имеет версию HTTP 1.0
  или ниже, он должен отклонить запрос со статусом 417 Expectation Failed ,
  но возможно, он об этом не знает.
• Клиент HTTP 1.0 (или более ранней версии) мог отправить запрос без
  Expect: 100-Continue Заголовок , и сервер все еще может ответить на него, используя
  HTTP-код 100 Continue (как часть RFC 2068),
  в этом случае прокси должен полностью удалить ответ и дождаться ретрансляции
  окончательный статус.

Маршрутизатор Heroku 100-продолжить поддержку

Маршрутизатор допускает некоторые вольности в отношении неопределенного поведения и углов
случаев, упомянутых ранее:

• 100 Продолжить будет удален как ответ, если клиент является HTTP 1.0 (или
  ранее) и заголовок Expect: 100-continue не является частью
  запрос, и будет перенаправлен в противном случае, несмотря ни на что.
• Маршрутизатор будет , а не , для запуска потребуется ответ 100 Continue
  отправка тела запроса, но оставит время ожидания на усмотрение клиента (без
  нарушение правил обычного бездействия
  для подключений на Heroku)
• Маршрутизатор автоматически ответит сообщением об ошибке 417 Ожидание не выполнено
  ответ и закройте соединение с динамометрическим станком, если заголовок Expect
  содержит любое значение, кроме 100 Продолжить (без учета регистра)
• Если запрошено обновление WebSocket, оно будет отправлено на динамометрический стенд как есть, а
  маршрутизатор выполнит любой ответ: 100 Продолжить статус может игнорировать
  обновление WebSocket и возврат любого кода (как обычно) и переключение 101
Протокол
  игнорирует поведение заголовков Expect .Обратите внимание, что для соблюдения
  HTTPbis Draft,
  Маршрутизатор по-прежнему будет искать протокол коммутации 101 после
  100 Продолжить получено от сервера.
• Маршрутизатор будет игнорировать Соединение: закрыть на 100 Продолжить и только
  соблюдайте его после получения окончательного ответа. Учитывая, что RFC указывает, что
  соединение должно быть закрыто «после завершения текущего запроса / ответа»,
  и что 100 не является статусом терминала, соединение будет закрыто только после
  получив терминальный статус.Однако обратите внимание, что, поскольку соединение : закрыть
  является поэтапным механизмом, маршрутизатор не обязательно закроет
  соединение с клиентом, и может не пересылать его.
• Маршрутизатор удаляет все заголовки из ответа 100 Continue , если нет
  заголовок предписан RFC, что значительно упрощает реализацию.
• Маршрутизатор вернет код ошибки 5xx, если сервер вернет
  100 Продолжить после первоначального ответа 100 Продолжить .Роутер
  пока не поддерживает бесконечные потоки 1xx.
• Маршрутизатор закроет соединение с сервером после
  код состояния терминала, независимо от того, предшествовал ли ему код 100 Продолжить или нет
  заранее - подключения к динамометрическим станциям не поддерживаются.
• Маршрутизатор закроет соединение с клиентом после
  код состояния терминала, который был , а не , которому предшествовал ответ 100 Continue .
  Это избавит клиента от необходимости отправлять тело запроса до того, как
  наличие возможности сервера обработать следующий запрос.

Остальные механизмы должны соблюдаться как есть протоколом и маршрутизатором.
должен пересылать запросы, как указано в RFC.

Поддерживаемые версии HTTP

В мире используются четыре основных версии HTTP: HTTP / 0.9, HTTP / 1.0, HTTP / 1.1 и HTTP / 2.

Маршрутизатор Heroku поддерживает только клиентов HTTP / 1.0 и HTTP / 1.1. HTTP / 0.9 и
ранее больше не поддерживаются. SPDY и HTTP / 2 здесь не поддерживаются.
время.

Поведение маршрутизатора должно максимально соответствовать HTTP / 1.1
технические характеристики. Однако для HTTP / 1.0 должны быть сделаны особые исключения:

• Маршрутизатор будет рекламировать себя как использующий HTTP / 1.1 независимо от того,
  клиент использует HTTP / 1.0 или нет.
• Маршрутизатор возьмет на себя необходимые преобразования из
  фрагментированный ответ на обычный HTTP-ответ. Чтобы обойтись без
  накопив потенциально гигабайты данных, ответ клиенту будет
  ограничены прекращением соединения (см. пункт
  4.4.5)
• Маршрутизатор предполагает, что клиент хочет закрыть соединение на каждом
  запрос (без сохранения активности).
• Клиент HTTP / 1.0 может отправить запрос с явным соединением: keep-alive
  заголовок. Несмотря на то, что механизм поддержания активности не был определен еще в 1.0 (он был
  ad-hoc), маршрутизатор предполагает, что запрошенное поведение
  аналогично поведению HTTP / 1.1 на этом этапе.

HTTP-проверка и ограничения

Запрос на подтверждение:

• В случае фрагментированного кодирования и длины содержимого оба присутствуют в
  запрос, маршрутизатор будет отдавать предпочтение фрагментированным
  кодирование.
• Если присутствует несколько полей длины содержимого, и что они имеют одинаковые
  length, они будут объединены в один заголовок длины содержимого
• Если заголовок длины содержимого содержит несколько значений ( длина содержимого: 15,24 )
  или запрос содержит несколько заголовков длины содержимого с несколькими значениями,
  запрос будет отклонен с кодом 400.
• Заголовки ограничены 8192 байтами на строку (и 1000 байтов для заголовка
  имя)
• Поэтапные заголовки будут удалены во избежание путаницы
• Максимальное количество заголовков в запросе - 1000
• Строка запроса HTTP-запроса ограничена 8192 байтами
• Строка запроса предполагает разделение отдельных пробелов между глаголом, путем и версией HTTP.

Подтверждение ответа:

• Поэтапные заголовки будут удалены, чтобы избежать путаницы
• Заголовки ограничены 512 КБ на строку
• Файлы cookie явно ограничены 8192 байтами. Это для защиты от
  общие ограничения (например, налагаемые CDN), которые редко принимают большие
  значения cookie. В таких случаях разработчик мог случайно установить большой
  файлы cookie, которые будут отправлены обратно пользователю, который затем увидит все
  его или ее запросы отклонены.
• Строка состояния ( HTTP / 1.1 200 OK ) ограничена 8192 байтами длиной

Приложения, которые нарушают эти ограничения в ответах, увидят, что их запросы завершаются ошибкой с ответом 502 Bad Gateway, и в поток журнала приложения будет вставлена ​​ошибка h35. Клиенты, которые нарушают эти ограничения в запросах, увидят, что их запрос завершился ошибкой с ответом 400 Bad Request.

Кроме того, ожидается, что запросы и ответы HTTP / 1.1 будут
keep-alive по умолчанию, если исходный запрос имел явное соединение :
закройте заголовок от маршрутизатора к динамометрическому станку, динамометрический стенд может отправить ответ
ограничены завершением соединения, без конкретной кодировки содержимого или
явная длина содержимого.

Обновления протокола

В то время как предыдущий маршрутизатор Heroku ограничивал обновления протокола HTTP до WebSockets.
только новый роутер вообще допускает любое обновление.

Конкретные моменты, связанные с внедрением:

• Любая HTTP-команда может использоваться с обновляемым соединением
• Хотя HEAD HTTP-глаголы обычно не требуют правильного ответа
  отправлено по линии (например, относительно длины содержимого), HEAD запросов
  явно предназначены для работы с ответами 101 Switching Protocols .Динозавр
  который не хочет обновляться, должен отправить другой код статуса, а
  соединение не будет модернизировано

Не поддерживается

• SPDY
• HTTP / 2
• IPv6
• Ожидайте заголовки с любым содержимым, кроме 100-continue (дает 417)
• HTTP-расширения, такие как WEBDAV
• Ответ HEAD, 1xx, 204 или 304 с кодировкой длины содержимого или фрагментированной кодировкой
  прокси-сервер не пытается передать тело, которое никогда не придет
• Окончание строки заголовка, отличное от CRLF ( \ r \ n )
• Кэширование содержимого HTTP
• Кэширование HTTP-версий серверов, работающих на dynos
• Давние предварительно выделенные холостые соединения.Лимит установлен на 1 минуту.
  перед закрытием незанятого соединения.
• HTTP / 1.0 запросы без заголовка Host , даже если полный URL
  отправлено в строке запроса.
• Маршрутизация TCP

сообщений о недоставке с "552 # 5.3.4 размер заголовка сообщения превышает предел"

Введение

В этом документе описаны сообщения, отклоненные и возвращенные из-за больших заголовков на Cisco Email Security Appliance (ESA).

отказов сообщений с "552 # 5.3.4 размер заголовка сообщения превышает предел "

"

Когда хост пытается отправить почту с большим заголовком, ESA может отклонить его. Конечный пользователь может увидеть одно из следующих сообщений об ошибке:

 "552 # 5.3.4 размер заголовка сообщения превышает предел" 
 "500 # 5.5.1 команда не распознана" 
 "421 Превышен предел недопустимой команды SMTP" 

В других случаях хост может повторять то же сообщение.

Максимальное количество строк для заголовка сообщения - 1000 строк. Когда длина заголовка превышает 1000 строк, ESA отправляет сообщение «552 # 5.3.4 размер заголовка сообщения превышает предел "отправляющему узлу.

Некоторые хосты могут игнорировать это сообщение и продолжать отправлять данные. ESA интерпретирует эти данные как команды SMTP и возвращает «500 # 5.5.1 команда не распознана» для каждой строки.

После превышения предела в 4 неверных команды SMTP, ESA затем возвращает сообщение «421 Превышен предел неверных команд SMTP» и разрывает соединение.

Этот параметр можно изменить только в интерфейсе командной строки:

 myesa.local>  listenerconfig  
 Текущие настроенные слушатели: 
 1. listener_myesa.local (в Management, 192.168.0.199) SMTP TCP Port 25 Public 
 
 Выберите операцию, которую вы хотите выполнить: 
 - NEW - Создать нового слушателя. 
 - РЕДАКТИРОВАТЬ - Изменить слушателя. 
 - УДАЛИТЬ - Удалить слушателя. 
 - НАСТРОЙКА - Изменить глобальные настройки. 
 []>  setup  
 
 Введите глобальный предел для одновременных подключений, разрешенных через 
 всех слушателей.
 [50]> 
 
 Слушатель istener_myesa.local Политика $ TRUSTED максимальное значение параллелизма, равное 300, 
 будет ограничено этим параметром параллелизма до 50. 
 Введите глобальный предел для одновременных подключений TLS, разрешенный для всех слушателей 
. 
 [100]> 
 
 Значение 100 для одновременных подключений TLS будет ограничено до 50 глобальным пределом 
 для одновременных подключений. 
 
 Введите максимальное количество строк заголовка сообщения. 0 означает отсутствие ограничения. 
 [1000]> 
 
 Введите скорость, с которой сбрасываются счетчики управления впрыском.
 [1h]> 
 
 Введите время ожидания для неудачных входящих подключений. 
 [5 м]> 
 
 Введите максимальное время соединения для входящих соединений. 
 [15m]> 
 
 Какое имя хоста должно быть получено: заголовки должны быть отмечены? 
 1. Имя хоста виртуального шлюза (tm), используемого для доставки сообщения 
 2. Имя хоста интерфейса, на котором сообщение получено 
 [2]> 
 
 Система всегда будет добавлять заголовок Message-ID к исходящим сообщениям. у которых нет 
 уже есть.Хотите сделать то же самое для входящих сообщений? (Не рекомендуется 
.) [N]> 
 
 По умолчанию соединения с политикой HAT REJECT будут закрыты с баннерным сообщением 
 в начале SMTP-диалога. Хотите ли вы выполнить отклонение 
 на уровне получателя сообщения вместо более подробного ведения журнала отклоненных сообщений 
? [N]> 
 

Если были внесены какие-либо изменения или обновления, вернитесь в главное приглашение CLI и запустите commit , чтобы сохранить и применить изменения.

Дополнительная информация

Справочник по настройке Apache Tomcat 8 (8.0.53)

Стандартные соединители HTTP (BIO, NIO, NIO2 и APR / native) поддерживают все
следующие атрибуты в дополнение к общим атрибутам коннектора
вышеперечисленное.