Нам сложно исправить 400 ошибок на нашем сайте. У нас много таких ошибок:
10.0.0.1 - - [08/Oct/2018:14:28:07 +0200]
"GET /les-news/palmares/detail/article/la-lettre-de-motivation-ideale-pour-une-demande-de-stage-5224/
HTTP/1.1" 400 131844
"https://www.google.com/"
"Mozilla/5.0 (Linux; Android 7.0; TECNO K7 Build/NRD90M) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36"
Пользователь сообщил о проблеме по электронной почте, и она была решена путем сброса файлов cookie в его браузере, поскольку других сбросов файлов cookie было недостаточно (но мы не можем быть уверены, что это было сделано правильно).
Платформа довольно сложная и обслуживается Балансировщик нагрузки F5, в зависимости от пути, по которому запрос перенаправляется на разные серверы.
Сначала я хотел бы воспроизвести ошибку, потому что при доступе к URL-адресу у нас его нет, и все работает нормально.
Мы заметили, что большая часть ошибок возникает из-за Android / Chrome: около 85% из всех 400 ошибок.
Вот полный журнал:
timestamp October 8th 2018, 16:26:52.000
version 1
_id BmQSVGYB5vF-Dw_g1gVi
_index f5_access-2018.10.08
_score -
t _type doc
t agent Mozilla/5.0 (Linux; Android 8.1.0; MI 8 Build/OPM1.171019.026) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36
client_ip 10.0.0.1
client_port 41,068
facility local2
host mydomain.fr
httpversion 1
id 2,503,307,391
length 0
logsource mydomain.network.local
message virtual=/Common/mydomain.fr_HTTP client_ip=10.0.0.1 client_port=41068 lb_server=10.153.161.12:80 host=mydomain.fr request_port=80 username= request="GET / HTTP/1.1" server_status=400 content_length=0 resp_time=23 user_agent="Mozilla/5.0 (Linux; Android 8.1.0; MI 8 Build/OPM1.171019.026) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.91 Mobile Safari/537.36" referer=http://mydomain.fr/article/100-millions-d-euros-sciences-po-lance-la-plus-grande-levee-de-fonds-de-son-histoire_095255b4-caef-11e8-896c-7d05c73a49da/ ID=2503307391 timestamp=2018-10-08T16:26:52+0200 pool=/Common/POOL_ETUDIANT_v2_nocache
pool POOL_MYDOMAIN_v2_nocache
program f5_access
referer http://mydomain.fr/article/100-millions-d-euros-sciences-po-lance-la-plus-grande-levee-de-fonds-de-son-histoire_095255b4-caef-11e8-896c-7d05c73a49da/
request /
request_port 80
server_ip 10.0.0.1
server_port 80
severity Informational
status 400
stdstatus 4xx
stdvirtual mydomain_fr_HTTP
tags f5_access
time 23
timestamp October 8th 2018, 16:26:52.000
type f5_access
verb GET
virtual mydomain.fr_HTTP
Скорее всего, это вызвано клиентом, а не сервером (ну, косвенно это может быть). Если это не просто неправильный URL-адрес (тот, который заблокирован 400 до того, как сможет вызвать 404), в 99% случаев это вызвано
Если вы хотите проверить допущение о блокировке файлов cookie, заблокируйте файлы cookie в своем браузере и посмотрите, получите ли вы ошибку 400, остальное немного сложнее, см. https://airbrake.io/blog/http-errors/400-bad-request
Поскольку вы уже сказали, что это было исправлено с обновлением файлов cookie, я предполагаю, что это связано с файлами cookie.
Редактировать:
У меня есть другая точка зрения: запрос был через http (незашифрованный) и включает реферер с запросом GET, который включает строку «имя пользователя». Это фактически делает пользователей, которые посещают сайт с этим реферером в заголовке, узнаваемыми, более того, запрос может быть просмотрен человеком посередине в виде открытого текста.
Поскольку Google начал своего рода войну с незашифрованным HTTP-трафиком, я мог предположить, что Chrome вызывает некоторые проблемы. Это всего лишь предположение, я не могу это подтвердить или подтвердить. Но попробовать стоит, так как вы в любом случае должны шифровать свой трафик.
У вас настроен https на вашем сервере, и если да, можете ли вы попытаться воспроизвести ту же ошибку при использовании https?