После редиректа POST может превратиться в GET: для 301 и 302 это допустимое поведение клиента. Если новый обработчик должен получить исходные данные, проверьте всю цепочку и используйте прямой адрес отправки либо подходящий редирект с сохранением метода.
Но переход на GET не всегда означает потерю заявки. Если сервер уже обработал POST и ответил 303 на страницу результата, это нормальная схема; сначала установите, на каком шаге должна происходить запись.
Какие коды сохраняют POST
POST передаёт данные формы или команды в теле запроса. GET обычно запрашивает представление ресурса; при такой смене метода исходное тело POST не переносится в следующий запрос.
| Код | Что означает для отправки | | --- | --- | | 301 | Постоянный перенос; клиент может заменить POST на GET | | 302 | Временный переход; клиент может заменить POST на GET | | 303 | Переход к отдельному результату через GET, без повторения POST | | 307 | Временный переход с сохранением метода и тела | | 308 | Постоянный перенос с сохранением метода и тела |
Различие описано в RFC 9110, раздел 15.4. Сохранение метода не гарантирует успешную обработку: целевой адрес должен принимать эти данные, а клиент — уметь повторно отправить тело.
Найдите первый переход, на котором исчезли данные
Проверяйте в тестовой среде с обезличенными значениями. Не повторяйте реальный платёж или создание заказа ради диагностики: сначала выясните, не была ли операция уже выполнена.
- Откройте инструменты разработчика, вкладку Network, и включите Preserve log, чтобы сохранить запросы при переходе страницы.
- Отправьте тестовую форму один раз. Найдите исходный запрос и проверьте Request URL, Request Method и Payload — адрес, метод и отправленные поля.
- У каждого ответа 3xx запишите код и заголовок Location. Затем проверьте метод и наличие тела у следующего запроса.
- Найдите первый шаг POST → GET. Проверьте, кто выдал редирект: CDN, веб-сервер или приложение. Сопоставьте время с журналами этих слоёв.
- По журналу приложения и тестовой записи выясните, успел ли исходный обработчик сохранить результат до перехода. Не ограничивайтесь финальным HTTP 200.
Если POST не появляется в Network, исследуйте обработчик кнопки и JavaScript. Если он доходит до конечного адреса с нужными полями, переходите к валидации, правам и обработке тела: редирект уже не объясняет потерю данных.
Для проблемы с лишними переходами и петлями пригодится отдельное руководство по цепочке редиректов. Здесь важен именно момент смены метода.
Пример: слеш изменил маршрут формы
Условная форма отправляет POST на https://example.com/submit. Веб-сервер возвращает 301 на https://example.com/submit/, браузер запрашивает этот адрес через GET, а приложение получает запрос без полей формы.
Первое исправление для проверки — указать окончательный HTTPS-адрес со слешем в action формы или настройке API-клиента. Если после этого обработчик получает POST и сохраняет тестовые данные, причина локализована в правиле нормализации адреса.
При этом правило могло сработать ещё раньше: например, при смене домена с www на основной. Проверяйте каждый переход, а не только последний ответ.
Как проверить через curl и не исказить результат
На своём тестовом обработчике сначала получите первый ответ без автоматического перехода. Пример использует зарезервированный адрес: замените его адресом стенда, где отправка не создаёт реальные заявки.
curl -sS -D - -o /dev/null \
--data 'probe=redirect-test' \
https://example.com/submitЗатем добавьте --location --max-redirs 5 --verbose: в диагностическом выводе будут видны методы запросов и ответы по цепочке. Сверяйте приём тела с журналом тестового приложения; перед передачей вывода удалите Cookie, Authorization, токены в URL и личные данные.
Согласно документации curl, при следовании 301, 302 и 303 с --location обычный POST сменяется на GET. Не добавляйте -X POST или --post301/--post302/--post303 в исходную проверку: они меняют поведение клиента и могут скрыть то, что происходит у посетителя.
curl не воспроизводит JavaScript формы и ограничения браузера. Совпадение результата полезно для локализации HTTP-перехода, но не заменяет проверку исходного сценария в Network.
Выберите исправление по назначению перехода
Перенаправление происходит до обработки
Исправьте адрес отправки: используйте конечный HTTPS-URL, нужный домен и маршрут. Не отправляйте конфиденциальные поля по HTTP в надежде, что редирект затем защитит соединение.
Если перенос обработчика необходим, рассматривайте 307 для временного перехода или 308 для постоянного. Перед изменением убедитесь, что целевой URL доверенный, принимает тот же метод и тело, а все используемые клиенты поддерживают такой переход.
Не заменяйте все 301 на 308 одним правилом. Для публичных страниц и для операций записи могут требоваться разные маршруты; пересылка тела на другой домен требует отдельной проверки.
Перенаправление происходит после записи
Оставьте 303, если приложение успешно выполняет действие, а затем открывает страницу результата. Это помогает отделить отправку формы от просмотра подтверждения.
Проверьте связь страницы результата с созданной тестовой записью. Надпись «Спасибо» сама по себе не доказывает сохранение, доставку письма или передачу заявки в CRM.
Метод остался POST, но операция не проходит
Сравните Content-Type и состав полей на входе приложения. Затем проверьте сессию, CSRF и права на целевом маршруте; смена домена может изменить условия авторизации даже без смены метода.
Не исправляйте это пересылкой паролей или секретных заголовков на любой адрес из Location. Сначала подтвердите назначение нового адреса и договорённости между клиентом и сервером.
Как подтвердить восстановление
Повторите один безопасный тест в исходном браузере и, если проблема была у интеграции, в её клиенте. Проверьте метод и тело до обработчика, ожидаемую запись и ровно одно выполнение операции; после обработки допустим предусмотренный переход на GET.
Web-Puls помогает контролировать доступность публичных URL, но обычная проверка страницы не отправляет вашу форму и не доказывает сохранение POST. Для этого нужен отдельный тест сценария после изменений маршрутов, HTTPS или правил прокси.
Если источник перехода остаётся неясным, отправьте заявку на диагностику: укажите публичный URL, время сбоя, ожидаемый маршрут и обезличенную последовательность «метод → код → Location → следующий метод». Специалист оценит задачу и предложит формат работ; пароли и реальные поля клиентов для первичной оценки не нужны.