POSTs исчезают, прибывают как GET
У нас возникли проблемы, когда пользователи попадали на наш сайт с "пустыми запросами GET". Под этим я подразумеваю, что они возникли на внешнем сайте как POST-запросы с несколькими параметрами, но браузер будет выполнять только простой GET без параметров для нашего сервера.
Это произошло более или менее независимо от браузера и т. Д. И с многочисленными сайтами с различными технологиями.
По какой-то причине обновление нашего сертификата (который работал в течение 18 месяцев) решило проблему. Старый сертификат был от Verisign, а новый сертификат от Thawte.
Ниже горизонтального правила находится оригинальный вопрос.
У нас есть служба, в которой мы ожидаем, что различные интернет-магазины будут отправлять нам данные POST через HTTPS и данные в качестве параметров POST nvp. Немногие из них где-то преобразуются в запросы GET, и полезная нагрузка теряется, поэтому они поступают на наш сервер в виде запросов GET без каких-либо параметров.
Когда мы получаем запросы GET, на нашем балансировщике нагрузки или брандмауэре нет никаких признаков запроса POST, который каким-либо образом был бы подключен к полученному нами GET. GET обычно является первым входящим запросом, который мы можем видеть с данного IP.
Кажется, что нет никакого другого общего фактора, кроме того, что почти все клиентские компьютеры являются Windows разных версий. Браузеры могут быть любыми Firefox, IE или Chrome.
Другой сайт, отправляющий данные через браузер пользователя (форма с методом POST), может использовать любой из следующих способов, но не ограничиваясь ими;
PHP, Java, Ruby on rails,.NET
Linux, Windows
Apache, Nginx, IIS, Tomcat, Ковбой
Drupal, Magento, Joomla, Prestashop, проприетарные и собственные решения
Эта проблема затрагивает клиентов с разных сайтов, которые, похоже, не имеют ничего общего. Кроме того, это не похоже на определенного интернет-провайдера, из которого приходят пользователи.
Кажется, что происходит, что запрос POST исчезает и никогда не достигает ни одного из наших серверов. Каким-то образом браузер вместо этого отправляет запрос GET без каких-либо параметров. Однако реферер не поврежден, что в соответствии с нашим тестированием означает, что пользователь не может выбрать поле адреса браузера и нажать клавишу ввода, поскольку это теряет заголовок реферера. При одной или нескольких повторных попытках (браузер вернулся, нажмите "Отправить" на ссылающемся сайте), POST проходит как следует
Кроме того, согласно тому, что мы слышали о комментариях конечных пользователей, они не получают сообщений об ошибках браузера.
Звонки с сервера на сервер, похоже, не затрагиваются этой проблемой. Похоже, что проблема началась 14 июля, так как после этой даты мы ежедневно получали эти запросы о проблемах. Он начинался всего с нескольких дней в день и с тех пор неуклонно растет, и теперь он удовлетворяет примерно 5% в день всех запросов, которые мы получаем к нашему API.
Таким образом, это не похоже на проблему на ссылающихся сайтах, так как это влияет на сайты с такой изменяющейся платформой без общего фактора. Похоже, что это проблема Windows, так как проблемными пользовательскими агентами являются практически все окна разных версий, но это влияет на все браузеры, так что же это может быть?
Любые предложения приветствуются на этом этапе.
РЕДАКТИРОВАТЬ: мы увидим, если это было перенаправление http -> https с нашей стороны, как мы протестировали это и нашли запрос http в журналах балансировки нагрузки. Перенаправление не с www на www будет также происходить на нашем балансировщике нагрузки AFAIK, и мы также увидим это. Также забыл упомянуть, что мы получаем в основном действительные данные с затронутых сайтов, это лишь небольшая часть запросов, которые работают с ошибками.
РЕДАКТИРОВАТЬ: * РЕШЕНО (вроде) * Как один из тех, "теперь есть способ, которым это поможет, но давайте все равно попробуем, поскольку мы понятия не имеем, что не так", мы установили новый сертификат. Эта проблема перестала существовать с момента установки нового сертификата.
В настоящее время мы не имеем ни малейшего представления о том, как сертификат мог вызвать поведение, которое мы испытывали. AFAIK, если есть проблемы с сертификатом, браузер предложит пользователю выполнить действие (из того, что мы слышали, никто не получал никаких подсказок) и либо вообще не будет общаться с сервером, либо будет работать в обычном режиме. Чего я не ожидал бы, так это чтобы браузер изменил POST на GET и выгрузил все параметры. Старый сертификат был установлен правильно, или как еще он мог работать безупречно в течение полутора лет?
В любом случае, около недели не было случаев заболевания. Последняя запись в журнале, показывающая один из этих проблемных случаев, рассчитана примерно за несколько минут до установки нового сертификата...
1 ответ
Сложно догадаться, но моим будет перенаправление, точнее HTTP -> HTTPS-перенаправление. В таком случае на вашем сервере нужно будет перенаправить с HTTP на HTTPS, и вы, возможно, не увидите их в своих журналах, потому что они могут быть в другом месте.
Таким образом, сценарий может состоять в том, что клиент по какой-то причине (в некоторой форме где-то не хватает правильной схемы) отправляет POST в HTTP, получает код перенаправления и переходит с GET на HTTPS.
Если это не так, это может быть другое перенаправление (например, префикс без www на www или аналогичный). Вы должны увидеть их в журналах, но по какой-то причине вы можете их пропустить (как-то фильтровать по HTTP-коду?). Но это не так вероятно, как перенаправление HTTP-> HTTPS.
Так это или вы можете доказать, что это не так?