Ошибка HTTP 406 Not Acceptable: причины и исправление

Ошибка 406 Not Acceptable — это код ответа HTTP, который появляется, когда сервер не может вернуть данные в формате, совместимом с клиентом, сделавшим запрос. Поскольку ошибка происходит на стороне сервера, клиентский обработчик не получает ожидаемых данных и дальнейший код не выполняется.

Проблема особенно критична для сервисов, которые обрабатывают множество запросов ежедневно. К счастью, большинство случаев решается правкой заголовков или сериализацией данных. Ниже — практическое руководство по диагностике и исправлению.

Что это значит

Кратко: клиент указывает, какие форматы он принимает (через заголовок Accept). Сервер отвечает в формате, который не входит в список допустимых — возникает 406.

Определение термина:

• Accept — заголовок HTTP-запроса, в котором клиент перечисляет допустимые MIME-типы.
• Content-Type — заголовок HTTP-ответа/запроса, обозначающий формат тела сообщения.

Важно: 406 — защитная мера. Если клиент не поддерживает формат ответа, выполнение кода, ожидающего иной формат, приведет к ошибкам или уязвимостям.

Быстрый план действий (мини-методология)

1. Проверить запросы клиента (Accept, Content-Type, тело).
2. Убедиться, что сервер отдаёт один из допустимых типов (application/json, text/csv и т. п.).
3. Сериализовать объекты в JSON при необходимости.
4. Добавить или поправить заголовок User-Agent, если сервер блокирует «подозрительные» клиенты.
5. Логировать и повторять шаги, пока запросы не проходят.

Как исправить ошибку 406

1. Настройка параметра Accept в коде клиента

Откройте ваш код и найдите место, где отправляется запрос. Пример для API, где требуется явно указать Accept:

profile = personality_insights.profile(
    profile_text,
    accept='application/json',
    content_type='text/plain'
).get_result()

Сохраняйте изменения. Параметр accept обычно допустим только со значениями application/json или text/csv в контексте многих API.

2. Сериализация данных: используйте JSON.stringify для браузерных запросов

Если вы отправляете объект из JavaScript, убедитесь, что тело запроса сериализовано в JSON и указан соответствующий заголовок:

$.ajax({
  url: 'http://example.com:9200/incidents/incidents',
  type: 'POST',
  data: JSON.stringify(this.incident),
  dataType: 'json',
  contentType: 'application/json'
})

Этот подход нужен, если у вас в теле — JavaScript-объект, а не строка JSON. После правки сохраните файл и протестируйте.

3. Указание заголовка User-Agent

Некоторые серверы отказывают в обслуживании запросов без корректного User-Agent. Добавьте заголовок в ваш HTTP-запросы:

import requests

page_url = 'https://examplepage.com'
headers = {
  'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) '
                'AppleWebKit/537.36 (KHTML, like Gecko) '
                'Chrome/102.0.0.0 Safari/537.36'
}
rawpage = requests.get(page_url, headers=headers)

После добавления заголовка сохраните код и проверьте доступность ресурса.

Примеры альтернативных подходов

• Если сервер ожидает XML, укажите Accept: application/xml и сериализуйте тело в XML.
• На стороне сервера можно настроить ответ так, чтобы он возвращал fallback-формат (например, JSON), если предпочтительный формат недоступен.
• В Nginx можно добавить правило для изменения заголовков запроса или ответа (см. раздел Nginx ниже).

Когда перечисленные методы не помогут (контрпримеры)

• Сервер жёстко настроен возвращать только специфический формат (например, устаревший проприетарный формат) — тогда клиент должен поддерживать этот формат или обращаться к другому API.
• Проблема не в заголовках, а в ошибке на сервере (500, неправильная сериализация на сервере). В этом случае исправляется серверный код.

Важно: не все случаи 406 связаны с клиентом — иногда сервер возвращает 406 по внутренней логике или из-за промежуточного прокси/веб-фаервола.

Чек-листы по ролям

Разработчик:

• Проверить Accept и Content-Type.
• Сериализовать объекты в JSON/XML в зависимости от API.
• Добавить обработку ошибок и логирование тел запроса/ответа.

DevOps / SRE:

• Проверить конфигурации Nginx/Apache и правила мод_security.
• Проверить промежуточные прокси и WAF, которые могут менять заголовки.
• Настроить логирование 4xx и фильтрацию по Accept.

QA:

• Написать тесты, которые посылают запросы с разными Accept-заголовками.
• Проверить поведение при отсутствии заголовков и при некорректных заголовках.

Шпаргалка: часто используемые MIME-типы

• application/json — JSON (современные API).
• text/csv — CSV для табличных данных.
• application/xml, text/xml — XML.
• text/html — HTML-страницы.

Если клиент принимает несколько форматов, можно использовать q-параметры: Accept: application/json, text/csv;q=0.8.

Nginx: краткие советы по исправлению 406

• Проверьте, не добавляет ли Nginx лишние правила, которые отбрасывают запросы с определёнными заголовками.
• Убедитесь, что proxy_pass/fastcgi не изменяют ожидаемый Content-Type.
• При необходимости добавьте proxy_set_header Accept $http_accept; чтобы пропустить заголовок на бэкенд.

Пример простого фрагмента конфигурации:

location /api/ {
  proxy_pass http://backend;
  proxy_set_header Accept $http_accept;
  proxy_set_header Content-Type $http_content_type;
}

Критерии приёмки

• Клиент получает ответ с Content-Type, соответствующим указанному Accept, и парсит его без ошибок.
• Логи не показывают новых 406 для обработанных путей.
• Интеграционные тесты проходят для основных форматов (JSON, CSV и т. п.).

Риск-матрица и рекомендации по смягчению

• Неправильный Accept в клиенте — низкий риск, лёгкое исправление: обновить код клиента.
• Серверная ошибка/конфигурация — средний риск: требуется деплой и тестирование.
• Прокси/WAF блокирует — высокий риск: возможно вмешательство сетевой команды и тестовый разворот правил.

Короткое объявление для команды (100–200 слов)

Мы обнаружили и устранили источник ошибки HTTP 406 в одном из наших сервисов: клиентские запросы не указывали корректный Accept или не сериализовали тело в JSON. Рекомендуем всем командам проверить места отправки HTTP-запросов: добавить Accept: application/json там, где ожидается JSON, и использовать JSON.stringify для сериализации объектов в браузерных запросах. Команде операций следует убедиться, что Nginx/прокси не изменяют заголовки и что mod_security не блокирует легитимные запросы. После правок — прогон интеграционных тестов и мониторинг логов 4xx в течение 24 часов.

Итог и рекомендации

• Ошибка 406 — признак несоответствия форматов между клиентом и сервером.
• Начните с проверки заголовков Accept/Content-Type и сериализации данных.
• При необходимости правьте серверную конфигурацию (Nginx, прокси) и добавляйте заголовок User-Agent для обхода блокировок.

Важно: логирование и автоматические тесты помогут быстрее выявлять такие несовместимости в будущем.

Summary:

• Проверьте Accept/Content-Type.
• Сериализуйте данные правильно (JSON.stringify).
• Укажите User-Agent, если сервер блокирует запросы.

Спасибо за чтение. Какой метод сработал у вас для исправления 406 в Nginx? Поделитесь в комментариях.