Ответ 1
Я предполагаю, что многие люди используют HTTP-запросы без User-Agent, главным образом, когда они используют API для выполнения запроса.
Мы заметили, что время от времени мы получаем HTTP-запрос без действительной строки User-Agent. Есть ли какой-либо реальный реальный случай для принятия этого типа HTTP-запроса?
то есть. Почему бы нам не заблокировать весь IP-адрес, из которого получен этот тип запроса?
UPDATE Мое намерение с фразой "реальный мир" состояло в том, чтобы указать, что я не спрашиваю о том, что технически может или не может произойти. Очевидно, что он может отправлять HTTP-запросы без каких-либо заголовков. Мне интересно, что такое "реальное" дело, которое вы могли бы разрешить для этого типа HTTP-запроса на вашем сервере.
Я предполагаю, что многие люди используют HTTP-запросы без User-Agent, главным образом, когда они используют API для выполнения запроса.
Как указано в RFC 7231 (но почти тот же абзац можно найти в RFC2616):
5.5.3 User-Agent
Поле заголовка "Пользователь-агент" содержит информацию о пользовательском агенте, инициирующем запрос, который часто используется серверами для определения объема сообщенных проблем совместимости, обходиться или адаптировать ответы, чтобы избежать определенных ограничений пользовательского агента, а также для аналитики в отношении использования браузером или операционной системы. Пользовательскому агенту ДОЛЖНО отправлять поле User-Agent в каждом запрос, если специально не настроен на это.
Ключевое слово здесь СЛЕДУЕТ. И да, есть RFC, который определяет, что должно означать это слово, RFC 2119:
- СЛЕДУЕТ Это слово или прилагательное "РЕКОМЕНДУЕТСЯ" означает, что там могут существовать обоснованные причины в определенных обстоятельствах, чтобы игнорировать конкретный пункт, но следует понимать все последствия и тщательно взвешивается, прежде чем выбирать другой курс.
Итак, хотя агенты, которые не отправляют User-Agent, не следуют тому, что можно считать лучшей практикой, они не нарушают никакого правила (rfc). Таким образом, на мой взгляд, на самом деле нет реальной технической причины блокировать их.