HTTP 200 - не гарантия: как проверить, что веб-форма действительно принимает обращения

24 июля 2026 · infolimp.ru

Проблема особенно заметна в связке «сайт - HTTP-сервис 1С - CRM». Мониторинг доступности видит только транспортный уровень. Бизнесу же нужен ответ на другой вопрос: может ли посетитель пройти согласованный путь и увидеть ожидаемое подтверждение?

Ниже - схема проверки на примере проекта FormUptime, который использует отдельный браузер Chromium для разрешённых синтетических проверок. Название инструмента здесь вторично: важнее принцип, по которому строится контроль.

Симптом: сервер доступен, заявок нет

Обычная проверка выглядит так:

GET https://example.ru/contact → 200 OK

Этого недостаточно. Код 200 подтверждает, что сервер отдал ответ, но не подтверждает, что:

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

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

Три уровня достоверной проверки

1. Транспорт

Проверяем DNS, TLS, доступность HTTPS и код ответа. Этот уровень нужен всегда, но он отвечает только на вопрос «сервер reachable?».

2. Браузерный сценарий

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

3. Ожидаемый бизнес-сигнал

После отправки нужно проверить заранее выбранный признак успеха: видимый текст («Спасибо, заявка принята»), CSS-селектор блока подтверждения или часть URL страницы результата. Если сигнал не появился за отведённое время, попытка считается неуспешной, даже если браузер получил 200.

Такой порядок не смешивает причины сбоя. В отчёте можно отдельно сказать: «страница доступна», «форма отправилась», «подтверждение не найдено».

Как устроен безопасный браузерный тест

В FormUptime сценарий начинается не с отправки, а с доказательства контроля над точным HTTPS-источником. Владелец размещает файл /.well-known/formuptime-verification.txt или добавляет DNS TXT-запись. Редирект на другой домен не считается подтверждением. Сырой токен не хранится: сохраняется только его SHA-256-дайджест.

После подтверждения браузер:

1. открывает согласованный URL;
2. обнаруживает формы и предлагает выбрать нужную;
3. показывает синтетические значения до отправки;
4. выполняет только разрешённые действия fill, check и select;
5. отправляет одну явно одобренную попытку;
6. проверяет текст, селектор или URL успеха;
7. сохраняет результат и при ошибке - снимок экрана, если он доступен.

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

Что нельзя автоматизировать от имени владельца

Безопасность должна быть частью сценария, а не примечанием после него. Такой тест не должен:

• обходить CAPTCHA, OTP и другие средства защиты от ботов;
• принимать за владельца согласие на рассылку, обработку данных или маркетинг;
• заполнять поля пароля, файла, платёжных и транзакционных данных;
• отправлять запросы изменения состояния на другой origin;
• обращаться к localhost, приватной сети или непубличному адресу;
• продолжать работу после отзыва или истечения разрешения.

В проекте это обеспечивается проверкой публичного HTTPS-адреса, повторной проверкой origin перед отправкой и сетевым ограничителем браузера. Если форма содержит подозрительное поле, CAPTCHA или внешний action, она блокируется для синтетической отправки и остаётся предметом ручной проверки.

Что важно учесть на стороне 1С

Если форма передаёт данные в HTTP-сервис 1С, успешный ответ сервиса должен означать именно приём события, а не завершение всей дальнейшей обработки. Практичнее принять запись в очередь, вернуть однозначный ответ и обработать её регламентным или фоновым заданием.

Схематично обработчик выглядит так (имена объектов зависят от конфигурации):

Функция ПринятьЗаявку(Запрос) Экспорт
    Тело = Запрос.ПолучитьТелоКакСтроку();
    Данные = ПрочитатьJSON(Тело);

    Идентификатор = Строка(Данные.idempotencyKey);
    Если ПустаяСтрока(Идентификатор) Тогда
        Ответ = Новый HTTPСервисОтвет(400);
        Ответ.УстановитьТелоИзСтроки("idempotencyKey is required");
        Возврат Ответ;
    КонецЕсли;

    // Повторная отправка той же заявки не создаёт дубль.
    Если ОчередьУжеСодержит(Идентификатор) Тогда
        Ответ = Новый HTTPСервисОтвет(202);
        Ответ.УстановитьТелоИзСтроки("accepted");
        Возврат Ответ;
    КонецЕсли;

    ПоместитьВОчередь(Идентификатор, Данные);
    Ответ = Новый HTTPСервисОтвет(202);
    Ответ.УстановитьТелоИзСтроки("accepted");
    Возврат Ответ;
КонецФункции

Ключевые свойства такой интеграции:

• idempotencyKey защищает от дублей при повторе запроса;
• 202 Accepted показывает, что сообщение принято в обработку;
• результат фоновой обработки логируется отдельно;
• журнал содержит время, ключ события, итог и текст ошибки;
• тестовые контакты отделены от реальных клиентов и помечены в CRM.

Если бизнес-сигналом является только 200 OK, монитор снова будет проверять транспорт, а не результат. Лучше возвращать пользователю страницу подтверждения и проверять именно её текст или селектор. Для асинхронной обработки можно показывать понятный статус «Заявка принята» и отдельно контролировать очередь 1С.

Типовые причины ложного «всё работает»

Чек-лист перед включением регулярного мониторинга

1. Записать владельца сайта и ссылку на разрешение тестирования.
2. Подтвердить точный HTTPS-origin файлом или DNS TXT.
3. Выделить отдельные синтетические имя, email и сообщение.
4. Указать ожидаемый текст, селектор или URL успеха.
5. Проверить, что action формы и изменяющие состояние запросы остаются в том же origin.
6. Убедиться, что тестовые данные помечаются или попадают в отдельный delivery sink.
7. Выполнить базовую успешную попытку, затем безопасно проверить отказ и восстановление.
8. Настроить уведомление о переходе в ошибку и о восстановлении.
9. Задать срок хранения доказательств и проверить удаление старых записей.
10. Остановить монитор сразу после отзыва разрешения или изменения формы.

Итог

Проверка веб-формы - это не запрос к URL, а воспроизводимый пользовательский путь с ожидаемым результатом. Для интеграций с 1С полезно разделять три вещи: доступность страницы, успешную отправку браузером и подтверждённую обработку события в очереди или CRM.

Практическое правило простое: зелёный 200 OK - только начало проверки. Достоверный результат появляется тогда, когда разрешённый браузер заполнил форму синтетическими данными, отправил её в правильный origin и увидел заранее определённый сигнал успеха. Всё остальное должно быть видно в отчёте как отдельный диагностический слой.