Ошибка 411 Length Required означает, что сервер отказался принять запрос без определённого Content-Length — заголовка с длиной тела в байтах. Сначала проверьте, что отправляет клиент, затем выясните, кто вернул отказ: прокси, веб-сервер или приложение. Определение кода дано в RFC 9110.
Если главная страница открывается, а отправка формы или API-запрос получает 411, проверяйте именно эту операцию. Успешный GET главной страницы не подтверждает работоспособность POST с данными.
1. Зафиксируйте запрос, который не проходит
В браузере откройте инструменты разработчика, вкладку Network («Сеть»), и найдите запрос с кодом 411. Запишите метод, путь, время с часовым поясом, тип содержимого и наличие Content-Length или Transfer-Encoding. Для интеграции те же сведения ищут в диагностике HTTP-клиента.
Проверьте исходный ответ и переходы: форма могла обратиться к другому адресу. Заголовок Server и оформление страницы ошибки дают подсказку, но сами по себе не доказывают, какой компонент отказал.
Сравнивать нужно одинаковые условия: URL, метод, тело и маршрут через прокси. Cookie, Authorization и реальные данные пользователя в отчёт не включайте.
2. Разделите три возможные ситуации
Длина тела не указана
Клиент может отправлять поток, размер которого заранее неизвестен. В HTTP/1.1 для этого используется передача частями — Transfer-Encoding: chunked, однако отдельные сервисы требуют длину заранее и отвечают 411 даже на такой запрос. Это поведение описано в RFC 9112.
Если API требует фиксированную длину, подготовьте тело целиком либо используйте поддерживаемый способ загрузки. Для больших потоков заранее согласуйте ограничения памяти, временного хранения и самого API; бездумная буферизация может создать новую проблему.
Заголовок есть, но его собрали вручную
Content-Length считают по готовым байтам после сериализации и кодирования, а не по числу символов в исходной строке. Для JSON с кириллицей эти значения могут различаться. У multipart-запроса учитывается всё тело, включая разделители и поля, а не только размер прикреплённого файла.
Передайте расчёт HTTP-библиотеке. Не подставляйте случайное число и не добавляйте одновременно Content-Length и Transfer-Encoding: неоднозначные границы сообщения опасны. Правила длины изложены в RFC 9110, раздел 8.6.
Тело пустое
Проверьте контракт endpoint: ожидается ли вообще POST без данных. При предусмотренном пустом POST клиент обычно отправляет Content-Length: 0; подставлять ноль в запрос с реальным телом нельзя. Правило для POST есть в том же разделе RFC 9110.
Не добавляйте этот заголовок ко всем GET-запросам «на всякий случай»: это не исправляет причину отказа.
3. Сравните с запросом из готового файла
Разработчик может воспроизвести операцию на тестовом endpoint, который принимает POST и не создаёт заказы, письма или платежи. В файл payload.json помещают обезличенный JSON, соответствующий контракту API.
curl --http1.1 --verbose \
--header 'Content-Type: application/json' \
--data-binary @payload.json \
'https://example.test/api/validate'Адрес здесь условный: замените его своим тестовым endpoint. Команда отправляет POST; выполнять её против рабочей операции записи без безопасного сценария не следует.
Опция --data-binary передаёт содержимое файла с сохранением переводов строк; её поведение описано в документации curl. В подробном выводе найдите исходящий Content-Length и код ответа. Сам вывод может содержать чувствительные сведения: перед передачей удалите секреты и персональные данные.
Если запрос из файла проходит, а исходный клиент получает 411, сравните способ формирования тела, заголовки и маршрут. Это сужает поиск, но не доказывает ошибку конкретной библиотеки. Принудительный HTTP/1.1 в примере нужен для отдельного сравнения; он не является универсальной настройкой исправления.
4. Найдите место отказа по логам
Сопоставьте время и идентификатор запроса в логах внешнего прокси, веб-сервера и приложения. Начните с первого доступного слоя и двигайтесь внутрь:
- Если прокси зафиксировал локальный отказ без отправки upstream, проверьте его правила обработки тела.
- Если запрос передан дальше, сравните входящие заголовки следующего слоя: длина могла измениться при пересборке запроса.
- Если приложение получило запрос и вернуло 411, проверьте требования маршрута и код обработки загрузки.
Отсутствие строки в одном журнале не доказывает отсутствие запроса: возможны другой узел, отключённое логирование или несовпадение времени. Для поиска полезен отдельный разбор связи запроса с логами сервера.
Не повышайте лимит загрузки только из-за 411. Отказ из-за слишком большого тела относится к ошибке 413, а требования к длине проверяют отдельно.
Как подтвердить исправление
Повторите безопасный тест тем же клиентом через обычный внешний маршрут. Убедитесь, что возвращается предусмотренный контрактом ответ и тестовые данные действительно обработаны; исчезновение 411 без проверки результата недостаточно.
Затем проверьте варианты, которые поддерживает API: пустое тело, текст в используемой кодировке, обычный файл или поток. Зафиксируйте, какие варианты разрешены, чтобы следующий релиз клиента не вернул ошибку.
Web-Puls может регулярно проверять доступность безопасного публичного URL, но успешная проверка этого адреса не воспроизводит проблемный POST. Схему таких проверок объясняет материал о мониторинге API.
Если отказ теряется между прокси и приложением, можно отправить заявку на диагностику. Укажите публичный адрес без секретов, время, метод, ожидаемый результат и очищенные фрагменты логов — этого достаточно для первичного разбора ситуации.