Сообщения об ошибках HTTP 400 на HTTP-запросы — Internet Information Services
Twitter LinkedIn Facebook Адрес электронной почты- Статья
Если HTTP-запрос, требующий проверки подлинности Kerberos, отправляется на веб-сайт, размещенный в службах IIS и настроенный для использования проверки подлинности Kerberos, заголовок HTTP-запроса будет очень длинным.
Оригинальная версия продукта: Windows Server 2016
Оригинальный номер базы знаний: 2020943
Симптомы
HTTP-запрос, для которого требуется проверка подлинности Kerberos, отправляется из браузера на веб-сайт, размещенный в службах IIS. Веб-сайт настроен для использования проверки подлинности Kerberos. Однако вместо получения ожидаемой веб-страницы отобразится сообщение об ошибке примерно такого содержания:
HTTP 400 — ошибочный запрос (превышена допустимая длина заголовка запроса)
Этот ответ может быть создан любым HTTP-запросом, который включает доступ к удаленному управлению Windows (WinRM).
Причина
Эта проблема может возникнуть, если пользователь является членом нескольких групп пользователей Active Directory.
HTTP-запрос к серверу содержит маркер Kerberos в заголовке WWW-Authenticate.
Размер заголовка увеличивается вместе с количеством групп пользователей. Если размер HTTP-заголовка или пакета превышает пределы, установленные на сервере, сервер может отклонить запрос и отправить в качестве ответа сообщение об ошибке.
Решение 1. Уменьшение числа групп Active Directory
Уменьшите количество групп Active Directory, участником которых является пользователь.
Решение 2. Задание записей реестра MaxFieldLength и MaxRequestBytes
Увеличьте параметры для записей реестра MaxFieldLength и MaxRequestBytes на сервере, чтобы заголовки запросов пользователя не превышали эти значения. Чтобы определить соответствующие параметры, используйте следующие вычисления:
Вычислите размер маркера Kerberos пользователя с помощью формулы, описанной в следующей статье:
Проблемы с проверкой подлинности Kerberos, возникающие в том случае, когда пользователь принадлежит к нескольким группам.Задайте для
MaxFieldLengthиMaxRequestBytesна сервере значение 4/3 * Т байт, где T — это размер маркера пользователя в байтах.
HTTP кодирует маркер Kerberos с помощью кодировки base64.Примечание.
Это приводит к замене каждых трех байтов в маркере четырьмя байтами в кодировке base64. Изменения, внесенные в реестр, вступают в силу только после перезапуска службы HTTP. Кроме того, может потребоваться перезапуск любых связанных служб, таких как службы IIS.
HTTP кодирует маркер Kerberos с помощью кодировки base64.В зависимости от среды приложения вы также можете обойти эту проблему, настроив веб-сайт для использования Windows NT LAN Manager (NTLM) вместо Kerberos. В некоторых средах приложений для делегирования требуется проверка подлинности Kerberos. Мы считаем проверку безопасности Kerberos более безопасной по сравнению с NTLM. Мы рекомендуем не отключать проверку подлинности Kerberos до того, как вы проанализируете последствия для безопасности и делегирования.
По умолчанию запись реестра MaxFieldLength отсутствует. В этой записи указывается максимальный размер каждого заголовка HTTP-запроса. Запись реестра MaxRequestBytes указывает верхний предел общего размера строки запроса и заголовков.
MaxRequestBytes. Если значение MaxRequestBytes меньше значения MaxFieldLength, значение MaxFieldLength корректируется. В средах большого размера Active Directory у пользователей могут возникать проблемы со входом в систему, если значения для обеих этих записей не имеют достаточно высокого значения.Для IIS 6.0 и более поздних версий разделы реестра MaxFieldLength и MaxRequestBytes находятся в следующем подразделе:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters
Задайте значения ключей, как показано в следующей таблице:
| Имя | Тип значения | Значение |
|---|---|---|
| MaxFieldLength | DWORD | (4/3 * T байт) + 200 |
| MaxRequestBytes | DWORD | (4/3 * T байт) + 200 |
Вы также можете задать максимальные значения для разделов реестра, как показано в следующей таблице.
Прежде чем вносить изменения в параметры реестра, учитывайте все возможные последствия для безопасности.
| Имя | Тип значения | Значение |
|---|---|---|
| MaxFieldLength | DWORD | 65536 (десятичный формат) или 10000 (шестнадцатеричный формат) |
| MaxRequestBytes | DWORD | 16777216 (десятичный формат) или 1000000 (шестнадцатеричный формат) |
Важно!
Изменение этих разделов реестра следует считать крайне опасным. Эти разделы позволяют отправлять HTTP-пакеты большего размера в IIS. Это, в свою очередь, может привести к тому, что Http.sys будет использовать больше памяти. Таким образом, такие изменения могут повысить уязвимость компьютера к вредоносным атакам.
Если для MaxFieldLength установлено максимальное значение 64 КБ, то для реестра MaxTokenSize должно быть задано значение 3/4 * 64 = 48 КБ. Дополнительные сведения о параметре 
в разделе Проблемы с проверкой подлинности Kerberos, возникающие в том случае, когда пользователь принадлежит к нескольким группам.
Ссылки
Параметры реестра Http.sys для IIS
Протоколирование ошибок в API HTTP
Проблемы с проверкой подлинности Kerberos, возникающие в том случае, когда пользователь принадлежит к нескольким группам
Что такое ошибка 400 Bad Request и как ее исправить – База знаний Timeweb Community
Раздражает, когда какой-то сайт не загружается и отзывается непонятными ошибками. Обычно они сопровождаются одним из десятков HTTP-кодов, которые как раз намекают на характер сбоя, а также его вероятные причины.
В этом материале поговорим об ошибке 400 Bad Request. Почему она появляется и как ее исправить.
Чуть подробнее об ошибке 400
Как и другие коды, начинающиеся на четверку, 400 Bad Request говорит о том, что возникла проблема на стороне пользователя.
Зачастую сервер отправляет ее, когда появившаяся неисправность не подходит больше ни под одну категорию ошибок.
Стоит запомнить — код 400 напрямую связан с клиентом (браузером, к примеру) и намекает на то, что отправленный запрос со стороны пользователя приводит к сбою еще до того, как его обработает сервер (вернее, так считает сам сервер).
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
ПодписатьсяИз-за чего всплывает Bad Request?Есть 4 повода для возникновения ошибки сервера 400 Bad Request при попытке зайти на сайт:
- Некорректно настроенные HTTP-заголовки в запросе со стороны клиента. Некоторые приложения и сайты мониторят заголовки на предмет наличия в них чего-нибудь подозрительного. Если ваш запрос не соответствует ожиданиям сервера, то высока вероятность появления ошибки 400 (но это не всегда вина пользователя).
- Такой же сбой появляется, если клиент пытается загрузить на сервер файл слишком большого размера. Это происходит, потому что на большинстве сайтов есть ограничения по размеру загружаемых данных. Причем ограничение может быть как в 2 гигабайта, так и в 600 килобайт.
- Еще ошибка 400 появляется, когда пользователь пытается получить доступ к несуществующей странице. То есть в браузер банально ввели ссылку с опечаткой, некорректным доменом или поддоменом.
- Устаревшие или измененные куки-файлы. Сервер может воспринять подмену куки-файлов как попытку атаковать или воспользоваться дырой в безопасности. Поэтому такие запросы сходу блокируются.
Это происходит, потому что на большинстве сайтов есть ограничения по размеру загружаемых данных. Причем ограничение может быть как в 2 гигабайта, так и в 600 килобайт.Читайте также
Исправляем ошибку 400 Bad Request на стороне клиента
Так как ошибка 400 в 99 случаев из 100 возникает на стороне клиента, начнем с соответствующих методов. Проверим все элементы, участвующие в передаче запроса со стороны клиента (браузера).
Проверяем адрес сайта
Банальщина, но необходимая банальщина. Перед тем как бежать куда-то жаловаться и предпринимать более серьезные шаги, повнимательнее взгляните на ссылку в адресной строке.
Может, где-то затесалась опечатка или вы случайно написали большую букву вместо маленькой. Некоторые части адреса чувствительны к регистру.
А еще стоит поискать запрашиваемую страницу через поисковик, встроенный в сайт. Есть вероятность, что конкретная страница куда-то переехала, но сервер не может показать подходящий HTTP-код в духе 404 Not Found. Если, конечно, сам сайт работает.
Сбрасываем параметры браузера
Этот метод срабатывает, если сервер отказывается принимать запросы из-за «битых» куки или других данных. Дело в том, что сайт использует куки-файлы, чтобы хранить информацию о пользователе у него же в браузере. При входе конкретного человека на ресурс, он пытается распознать куки и сравнить информацию с той, что уже есть на сервере.
Иногда случается, что куки-файлы одного или нескольких пользователей вступают в конфликт. В таком случае надо открыть настройки браузера, а потом удалить весь кэш, куки и прочие связанные элементы.
В зависимости от браузера процесс удаления куки-файлов может немного отличаться.
В Chrome это работает так:
- Открываем настройки браузера.
- Переходим в раздел «Конфиденциальность и безопасность».
- Выбираем «Файлы cookie и другие данные».
- Нажимаем на кнопку «Удалить все».
Для чистки cookies можно использовать стороннюю программу в духе CCleaner или CleanMyPC.
Загружаем файл подходящего размера
Если ошибка 400 Bad Request появляется при попытке загрузить на сайт какой-нибудь файл, то стоит попробовать загрузить файл поменьше. Иногда вебмастера ленятся грамотно настроить ресурс, и вместо понятного объяснения вроде «Загружаемые файлы не должны быть размером больше 2 мегабайт» люди получают Bad Request. Остается только гадать, какой там у них лимит.
Устраняем проблемы, связанные с Windows и сторонним софтом
Помимо браузера, на работу сети могут влиять другие программные продукты (экраны, защищающие от «непонятных подключений»). И вирусы. Да и сама Windows может стать проблемой.
Почти любой ее компонент. Поэтому надо бы проделать следующее:
- Повторно установить NET.Framework. Желательно перед этим удалить предыдущую версию.
- Установить какой-нибудь приличный антивирус (а лучше два) и запустить глубокую проверку систему. Возможно, подключению и входу на ресурс мешает вредоносная программа.
- Если у вас уже установлен антивирус, то, наоборот, попробуйте его отключить. Иногда встроенные в них экраны проверки подключений блокируют работу браузера целиком или отдельных страниц. Лучше выдать браузеру больше прав на выполнение своих задач или установить антивирус, который более лояльно относится к установленному на компьютере софту.
- Еще надо поменять параметры брандмауэра. Его можно разыскать в панели управления Windows. Там надо добавить в список исключений ваш браузер. Тогда брандмауэр не будет мешать подключению к запрашиваемому сайту.
- Почистить Windows от программного мусора. Можно пройтись приложением CCleaner.
- Обновить драйверы для сетевых устройств.
- Обновить Windows или просканировать систему на наличие погрешностей в системных компонентах.
Ищем проблему на стороне сервера
Если что-то происходит на стороне ресурса, то это редко заканчивается ошибкой 400. Но все-таки есть несколько сценариев, при которых клиента обвиняют в сбое зря, а настоящая вина лежит на сервере.
Проверяем требования к HTTP-заголовкам
Пока настраиваешь сайт, несложно допустить ошибку или даже парочку. Возможно, требования к HTTP-заголовком указаны некорректно, и сервер ожидает запросы с ошибками, которые по объективным причинам не может распознать адекватно. Тогда администратору стоит перепроверить ожидаемые заголовки на своем сайте или в приложении.
Удаляем свежие обновления и плагины
Иногда ошибка 400 Bad Request появляется после обновления CMS или установки новых плагинов. Если у вас она появилась из-за этого, то наиболее логичное решение — откатиться до более ранней версии CMS и удалить все новые плагины.
Главное, перед этим сделать резервную копию данных. И перед установкой обновлений тоже стоило бы.
Проверяем состояние базы данных
Некоторые сторонние расширения для того же WordPress получают полный доступ к ресурсу и имеют право вносить изменения даже в подключенную базу данных. Если после удаления свежих плагинов ошибка 400 никуда не исчезла и появляется у всех, кто пытается зайти на сайт, стоит проверить, в каком состоянии находится база данных. Нужно вручную проверить все записи на наличие подозрительных изменений, которые могли быть сделаны установленными расширениями.
Исправляем ошибки в коде и скриптах
Ничего из вышеперечисленного не помогло? Тогда осталось проверить свой код и работающие скрипты. Лучше провести дебаггинг вручную и не надеяться на помощь компьютера. Сделать копию приложения или сайта, потом пошагово проверить каждый отрезок кода в поисках ошибок.
В крайнем случае придется кричать «полундра» и звать на помощь техподдержку хостинга.
Возможно, возникли сложности на их стороне. Тогда вообще ничего не надо будет делать. Просто ждать, пока все исправят за вас.
На этом все. Основные причины появления 400 Bad Request разобрали. Как ее лечить — тоже. Теперь дело за вами. Пользуйтесь полученной информацией, чтобы больше не пришлось мучиться в попытках зайти на нужный ресурс.
Ошибка HTTP 400. Размер заголовков запроса слишком велик. | Форум поддержки Firefox
Эта тема была заархивирована. Пожалуйста, задайте новый вопрос, если вам нужна помощь.
Майкл
— это ошибка, которую я получаю при попытке открыть некоторые окна MSN в новой вкладке Firefox. Любые предложения, чтобы предотвратить эту ошибку?
— Это ошибка, которую я получаю при попытке открыть некоторые окна MSN в новой вкладке Firefox.
Любые предложения, чтобы предотвратить эту ошибку?
Выбранное решение
Все ответы (2)
кор-эль- 10 ведущих участников
- Модератор
Выбранное решение
Обычно эта проблема возникает из-за слишком длинного поврежденного файла cookie.
Очистите кэш и удалите файлы cookie для веб-сайтов, которые вызывают проблемы, с помощью кнопки меню Firefox с тремя полосами (Параметры/Настройки).
«Удалить файлы cookie» для веб-сайтов, которые вызывают проблемы:
- Параметры/Настройки -> Конфиденциальность и безопасность
Файлы cookie и данные сайта: «Управление данными»
«Очистить кэш»:
- Параметры/Настройки -> Конфиденциальность и безопасность
Файлы cookie и данные сайта -> Очистить данные -> Кэшированный веб-контент: Очистить
Если очистка файлов cookie не помогла, возможно, поврежден файл cookie.
sqlite в папке профиля Firefox, в которой хранятся файлы cookie.
- переименовать/удалить cookies.sqlite (cookies.sqlite.old) и, если они есть, удалить cookies.sqlite-shm и cookies.sqlite-wal в папке профиля Firefox с закрытым Firefox на случай повреждения cookies.sqlite.
Вы можете использовать кнопку на странице «Справка -> Информация для устранения неполадок» (about:support), чтобы перейти к текущей папке профиля Firefox, или использовать страницу about:profiles .
- Справка -> Информация для устранения неполадок -> Папка/каталог профиля:
Windows: Открыть папку; Linux: открытый каталог; Mac: Показать в Finder - https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data
Майкл Владелец вопроса
Исправлено удаление файлов cookie MSN и перезапуск Firefox! Спасибо поддержке Мозиллы!
Изменено Майклом
Firefox — Неверный запрос — Слишком длинный запрос HTTP Ошибка 400. Размер заголовков запроса слишком длинный
спросил
Изменено 9 месяцев назад
Просмотрено 68 тысяч раз
Некоторые из моих пользователей иногда получают следующую ошибку при запросе некоторых страниц моего сайта: Неверный запрос — запрос слишком длинный HTTP-ошибка 400. Размер заголовков запроса слишком длинный
Похоже, это происходит только в Firefox.
Удаление файлов cookie пользователей помогает.
Чего я не понимаю, так это следующего: я думал, что куки добавляются к каждому запросу. Почему эта ошибка появляется только на одной или двух моих страницах, а на большинстве никогда?
Также не зависит от страницы сервера. Если пользователь запрашивает http://example.com/user/Мое имя он может получить ошибку. Если он просто изменит заглавные буквы URL-адреса, он снова сработает (например, http://example.com/user/myname). (Я использую IIS, который не слишком заботится о капитализации).
Для браузера два URL разные, для сервера — нет.
Есть идеи, что происходит?
- firefox
- куки
Похоже, куки было слишком много. Убедился, что их не так много и теперь работает.
1 Некоторые из наших пользователей также столкнулись с этим же исключением в IE 8 для некоторых наших сайтов интрасети, размещенных в IIS. Оказалось, что проблема связана с использованием проверки подлинности Kerberos, когда пользователь принадлежит ко многим группам Active Directory.
Мы нашли решения в следующих статьях службы поддержки Microsoft:
- HTTP 400 — неверный запрос (слишком длинный заголовок запроса)» в службах IIS (IIS)
- Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит ко многим группам
Исправление для нас состояло в том, чтобы установить следующие ключи реестра с увеличенными значениями и/или создать их, если они не существовали:
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxFieldLength DWORD (32 бита) — присвоено значение данных 32000 (десятичное)
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\MaxRequestBytes DWORD (32 бита) — данные присвоенного значения 8777216 (десятичное число)
1[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters] «MaxFieldLength»=dword:00007d00 «MaxRequestBytes»=dword:0085ee00
Решение 1
удалить все файлы cookie домена из браузера
В Firefox 53
- Alt -> Инструменты -> Информация о странице
- Безопасность
- Просмотр файлов cookie
- Удалить все
В хроме проверьте это решение суперпользователя
Решение 2
- Установить расширение Web Developer (Firefox, Chrome, Opera)
- перейдите на вкладку куки-файлы -> Удалить куки-файлы домена , как показано на скриншоте ниже
Раствор 3
- используйте режим инкогнито и посмотрите, работает ли он у вас
Подробнее:
У меня была такая же проблема в Chrome и при использовании списка из SharePoint.
после диагностики на вкладке сети панели разработчика Chrome. Я проверил заголовки и нашел большой файл cookie , начинающийся с имени WSS_exp , и удалив их все из chrome cookie manager , решил мою проблему
2Проблема связана с повреждением файла cookie. Простое решение — удалить все ваши файлы cookie, но вот лучший способ решить эту конкретную проблему. Я создал индивидуальное руководство для Firefox, Chrome и Internet Explorer. См. здесь: http://timourrashed.com/how-to-fix-the-400-bad-request-error-message-from-a-website/
Другая причина этой ошибки связана с тем, что пользователь находится в слишком группы активного каталога. В более современных версиях SSRS этой проблемы нет.
Похоже, что список групп AD передается вместе с заголовком HTTP. Более старые версии служб отчетов SQL Server имеют ограничение на размер заголовка. Поэтому, если пользователь находится в чрезмерном количестве групп, самым простым решением будет удаление ненужных групп.
Если удаление групп невозможно, вы должны иметь возможность отредактировать файл web.config и увеличить ограничение. Как это сделать можно посмотреть здесь… https://www.mssqltips.com/sqlservertip/4688/resolving-the-maximum-request-length-exceeded-exception-in-sql-server-reporting-services/
Этот ответ только в случае использования локального хранилища браузера для хранения данных пользователей.
Поскольку локальное хранилище имеет ограничение в 5 МБ на домен, оно никогда не очищается само по себе, и для удаления данных нет срока действия. Когда локальное хранилище достигает предела 5 МБ, данные начинают храниться в виде файлов cookie. Позже, когда размер файлов cookie достигает 1 МБ, браузер показывает ошибку 400 (слишком длинный размер заголовков запроса).
В этом случае лучше удалить ненужные данные из локального хранилища после их использования.
Я использовал ViewData вместо TempData , и проблема решена.