У нас были проблемы, когда пользователи попадали на наш сайт с «пустыми запросами 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 без каких-либо параметров. Однако реферер не поврежден, что, согласно нашему тестированию, означает, что пользователь не мог выбрать адресное поле браузера и нажать Enter, так как это теряет заголовок реферера. С одной или несколькими повторными попытками (возврат браузера, повторное нажатие на отправку на ссылающемся сайте) POST проходит должным образом.
Кроме того, согласно тому, что мы слышали о комментариях конечных пользователей по этому поводу, они не получают сообщения об ошибке браузера.
На вызовы с сервера на сервер эта проблема не влияет. Похоже, что проблема началась 14 июля, так как после этой даты мы получаем эти запросы о проблемах ежедневно. Это началось всего с нескольких запросов в день и с тех пор неуклонно росло, а теперь составило около 5% в день от всех запросов, которые мы получаем к нашему API.
Таким образом, это не похоже на проблему для ссылающихся сайтов, так как это влияет на сайты с такой разной платформой без общего фактора. Похоже, что это проблема Windows, поскольку проблемные пользовательские агенты - это практически все окна разных версий, но это влияет на все браузеры, так что это может быть?
Здесь приветствуются любые предложения.
РЕДАКТИРОВАТЬ: Мы бы увидели, было ли это перенаправлением http -> https на нашей стороне, поскольку мы тестировали это и нашли HTTP-запрос в журналах балансировщика нагрузки. Перенаправление без www на www также произойдет в нашем балансировщике нагрузки AFAIK, и мы это тоже увидим. Также забыл упомянуть, что мы получаем в основном достоверные данные с затронутых сайтов, это лишь небольшая часть запросов, которые ведут себя беспорядочно.
РЕДАКТИРОВАТЬ: * РЕШЕНО (вроде) * В качестве одного из тех, «есть способ, который поможет, но давайте все равно попробуем, поскольку мы понятия не имеем, что не так», мы установили новый сертификат. Эта проблема исчезла с момента установки нового сертификата.
В настоящее время мы не знаем, как сертификат мог вызвать такое поведение. AFAIK, если есть проблемы с сертификатом, браузер будет предлагать пользователю действие (из того, что мы слышали, никто не получал никаких запросов) и либо вообще не разговаривал с сервером, либо продолжал нормально. Чего я не ожидал, так это того, что браузер изменит POST на GET и сбросит все параметры. Старый сертификат установили правильно, а иначе как еще он мог безупречно работать полтора года?
В любом случае, примерно за неделю случаев не было. Последняя запись в журнале, показывающая один из этих проблемных случаев, рассчитана примерно за несколько минут до установки нового сертификата ...
Трудно догадаться, но я бы предпочел перенаправление, а точнее перенаправление HTTP -> HTTPS. Чтобы это было так, на вашем сервере потребуется перенаправление с HTTP на HTTPS, и вы, возможно, не увидите их в своих журналах, потому что они могут быть в другом месте.
Итак, сценарий будет таков, что клиент по какой-то причине (какая-то форма где-то пропускает правильную схему) отправляет POST в HTTP, получает код перенаправления и переходит с GET на HTTPS.
Если это не так, это может быть другое перенаправление (например, префикс без www на префикс www или подобное). Вы должны видеть их в журналах, но по какой-то причине можете их пропустить (фильтрация как-то на основе кода HTTP?). Но это не так вероятно, как перенаправление HTTP-> HTTPS.
Итак, так ли это, или вы можете доказать, что это не так?