Много 400 ошибок в логах Apache

Нам сложно отладить 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
Источник

1 ответ

Решение

Скорее всего, это вызвано клиентом, а не сервером (ну косвенно). Если это не просто неверно сформированный URL-адрес (заблокированный 400, прежде чем он сможет вызвать 404), в 99% случаев это вызвано

  • поврежденные файлы cookie (например, могут быть вызваны расширениями)
  • заблокированные куки
  • слишком много куки (некоторые браузеры блокируют огромное количество куки)
  • клиент пытается ввести в заблуждение запрос (я полагаю, непреднамеренно)

Если вы хотите проверить предположение о заблокированных cookie-файлах, заблокируйте cookie-файлы в своем браузере и посмотрите, нет ли ошибок 400, остальное немного сложнее, см.: https://airbrake.io/blog/http-errors/400-bad-request

Поскольку вы уже сказали, что это исправлено с помощью обновления файлов cookie, я предполагаю, что это связано с файлами cookie.

Редактировать:

У меня есть другой угол: запрос был через http (незашифрованный) и включает в себя реферер с запросом GET, который включает строку "username". Это фактически делает пользователей, которые посещают сайт с этим реферером в их заголовке, идентифицируемыми, более того, запрос может быть просмотрен человеком посередине в виде открытого текста.

Так как Google начал своего рода войну против незашифрованного http-трафика, я могу предположить, что Chrome вызывает некоторые проблемы. Это всего лишь предположение, но я не могу подтвердить это или подтвердить это. Но стоит попробовать, так как вы должны зашифровать свой трафик в любом случае.

У вас настроен https на вашем сервере, и если да, можете ли вы попытаться воспроизвести ту же ошибку при использовании https?

Источник
Другие вопросы по тегам