История из жизни.
Как-то переводили с одного домена на другой проект.
Доменов много, рулсов много, в одном из пунктов плана перехода была организация редиректов.
Ну типа запилили новый домен, а со старого домена прямо в CloudFlare сделали редирект (+ rules).
Сильно застрял при проверке старого домена с редиректом на новый.
Ну не проходят POST запросы с пейлоад до конечного бекэнда при помощи curl.
Признаюсь честно - долго просидел и тогда не было нейронок, чтобы попробовала бы помочь при дебагинге.
Сейчас бы я сам себя тогда
Копал в редиректы, новый домен, неверную архитектуру, терраформ, DNS клауд провайдера и многое другое.
Оказалось дело было не в самом редиректе или домене, а в curl.
То есть всё итак работало, но сами тесты при помощи curl были неправильными.
Ведь обидно, всё облазил, все интернеты, а ответ, как всегда, был на видном месте - в документации
В моем случае надо было добавить два флага:
- --location (чтобы курл последовал за редиректом)
- --post302 (not convert POST requests into GET requests when following a 302 redirection)
Source:
https://curl.se/docs/manpage.html#--post301
https://curl.se/docs/manpage.html#--post302
Почему так?
Согласно RFC 7231, при 302 редиректе клиент (например, curl) может по умолчанию изменить метод с POST на GET.
И ваш пейлоад просто аннигилируется, тесты не проходят.🚶♀
Чтобы избежать этого, нужно явно указывать --post302 или же использовать 307 редирект* , который сохраняет метод запроса.
Source:
https://www.ietf.org/rfc/rfc7231.txt
Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead.
Вывод: Перед переключением доменов читайте документацию и проверяйте, как редиректы влияют на запросы и разные методы.
* Некоторые DNS/CDN провайдеры имеют лишь ограниченный список поддерживаемых кодов редиректа.