код состояния 400 httpсоединение 1с

Ошибка 400 при работе с HTTPs соединением

До перехода на HTTPs, обращался к веб-сервису без проблем по HTTP соединению (авторизация доменная):

Когда сделали HTTPs, то доделал строку соединения до вида:

Методы веб-сервиса и структура базы веб-сервиса не менялась. Просто администраторы сделали HTTPs.

Теперь при выполнении PUT-запроса получаю ошибку 400. Подскажите, пожалуйста, в чем может быть дело? Проблема на стороне веб-сервиса или я что-то не правильно указал в HTTPСоединении?

HTTP Error 400. The request verb is invalid.

(0) > The request verb is invalid

Не надо в него PUT, не хочет он этого.

(1) а ведь до этого (до перехода на HTTPs) именно PUT-запрос происходил из 1С в сервис и все отлично было.

К администратору надо обратиться?)

(2) Не знаю, что у вас там под веб-сервисом понимается, но SOAP, он какбе вообще-то POST подразумевает.

Пытай админов, почему типы запросов стали по разному обрабатываться. А то сейчас окажется что, например, перед аппликейшн сервером возник какой нить энджинх для поддержки SSL со своими представлениями о мире.

(3) не совсем понимаю в веб-технологиях, но разработчики веб-сервиса сделали сервис не в 1С. Сказали выгружать данные в сервис PUT-запросами, а тело запроса в формате JSON.

До HTTPs, все отлично работало. Вчера перевели на защищенное соединение и пипец. походу надо копать именно сам сервис, что-то в нем случилось.

Источник

Не работает подключение к http сервису 1С ошибка 400

Проблема заключается в том, что на тестовой базе 1с77 подключение к сервису и работа с ним идет без ошибок. Но на рабочем сервере где крутится 1с77 вылетают ошибки:
Если подключаться к хттп сервису на 1с83 в файловом варианте, то возвращает ошибку 400,
Если подключаться к хттп сервису на 1с83 в серверном варианте (MS SQL), то возвращает ошибку 500.

Пробовал разворачивать 1с83 и публикацию на другом сервере. Ошибка возникает только когда обращаешься с рабочего сервера где стоит рабочая база 1с77. С других ПК все работает без ошибок.

Система на рабочем сервере с 1с77 Win 2008 R2. Где что можно посмотреть? Может какие-то версии MSXML влияют?

Вобщем проблему решил самостоятельно. И чисто случайно.
Оказывается есть 2 разных объекта для работы с хттп-запросами:
MSXML2.XMLHTTP.4.0
и
MSXML2.ServerXMLHTTP.4.0

Заменил первый на второй. Плюс еще разобрался с тем, что второй в текст ответа добавляет мусор. Зато корректно заполняет свойство ResponseXml.
Не знаю, почему в сети того предприятия работает только серверный вариант. Да и разбираться уже не стал. Отмечаю это сообщение как решение.

Источник

Web-сервис. Ошибка 400

Есть веб-сервис и общая команда. В общей команде код:

Попытка
ВСОпределение = Новый WSОпределения(«http://192.168.___.__/t10/ws/OD.1cws?wsdl";); //#1
ВСервер = ВСОпределение.Сервисы.Получить(«OD»,»OD»);
ВТочкаВхода = ВСервер.ТочкиПодключения.Получить(«ODSoap»);
ВТОперация = ВТочкаВхода.Интерфейс.Операции.Получить(«Sinhron»);
Данные = Новый ХранилищеЗначения(«Некие данные»,Новый СжатиеДанных(9));
ДанныеXDTO = ВСОпределение.ФабрикаXDTO.Создать(ВТОперация.Параметры.Получить(«Dan»).Тип,Данные);
ВСПрокси = Новый WSПрокси(ВСОпределение,»OD»,»OD»,»ODSoap»);
Ответ = ВСПрокси.Синхронизация(ДанныеXDTO);
Возврат Истина;
Исключение
Сообщить(ОписаниеОшибки());
Возврат Ложь;
КонецПопытки;

При нажатии на кнопку ВыполнитьСинхронизацию сначала было все хорошо, т.е. выполнение шло по ветке Попытка, до Ответ доходило точно, в ветку Исключение выполнение не переходило.

Но затем, не понятно почему, при очередном тестировании кнопки с общей командой, сразу после прохождения строки кода #1 выполнение стало переходить к Исключению и в
результате — ошибка (указывает именно на эту строку кода (выше) и код ошибки 400).

При этом базу в браузере вижу, xml-файл тоже.
————————————
Примерно в момент возникновения этой ошибки началось следующее: даже если база нигде не открыта (ни в браузере, ни на ПК), выдается сообщение: “Достигнуто предельное количество подключений к ИБ”. Чтобы выходить из этой ситуации приходится часто чистить кэш и останавливать сервер.

Что это может быть? Как исправить?

Источник

Ошибка 400 Bad Request: что это означает и как ее исправить

Ошибка 400 Bad Request – это код ответа HTTP , который означает, что сервер не смог обработать запрос, отправленный клиентом из-за неверного синтаксиса. Подобные коды ответа HTTP отражают сложные взаимоотношения между клиентом, веб-приложением, сервером, а также зачастую сразу несколькими сторонними веб-сервисами. Из-за этого поиск причины появления ошибки может быть затруднён даже внутри контролируемой среды разработки.

В этой статье мы разберём, что значит ошибка 400 Bad Request ( переводится как « Неверный запрос »), и как ее исправить

На стороне сервера или на стороне клиента?

С другой стороны, ошибка 400 Bad Request означает, что запрос, присланный клиентом, был неверным по той или иной причине. Пользовательский клиент может попытаться загрузить слишком большой файл, запрос может быть неверно сформирован, заголовки HTTP запроса могут быть неверными и так далее.

Мы рассмотрим некоторые из этих сценариев ( и потенциальные решения ) ниже. Но имейте в виду: мы не можем однозначно исключить ни клиент, ни сервер в качестве источника проблемы. В этих случаях сервер является сетевым объектом, генерирующим ошибку 400 Bad Request и возвращающим её как код ответа HTTP клиенту, но возможно именно клиент ответственен за возникновение проблемы.

Начните с тщательного резервного копирования приложения

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

Диагностика ошибки 400 Bad Request

Ошибка 400 Bad Request означает, что сервер ( удалённый компьютер ) не может обработать запрос, отправленный клиентом ( браузером ), вследствие проблемы, которая трактуется сервером как проблема на стороне клиента.

Существует множество сценариев, в которых ошибка 400 Bad Request может появляться в приложении. Ниже представлены некоторые наиболее вероятные случаи:

Исправление проблем на стороне клиента

Устранение ошибки 400 Bad Request ( попробуйте позже ) лучше начать с исправления на стороне клиента. Вот несколько советов, что следует попробовать в браузере или на устройстве, которые выдают ошибку.

Проверьте запрошенный URL

Очистите соответствующие куки

Одной из потенциальных причин возникновения ошибки 400 Bad Request являются некорректные или дублирующие локальные куки. Файлы куки в HTTP – это небольшие фрагменты данных, хранящиеся на локальном устройстве, которые используются сайтами и веб-приложениями для « запоминания » конкретного браузера или устройства. Большинство современных веб-приложений использует куки для хранения данных, специфичных для браузера или пользователя, идентифицируя клиента и позволяя делать следующие визиты быстрее и проще.

Куки хранятся по принципу доменного имени веб-приложения, поэтому можно удалить только те куки, которые соответствуют домену сайта, сохранив остальные куки не тронутыми. Но если вы не знакомы с ручным удалением определённых файлов куки, гораздо проще и безопаснее очистить сразу все файлы куки.

Это можно сделать разными способами в зависимости от браузера, который вы используете:

Загрузка файла меньшего размера

Если вы получаете ошибку 400 Bad Request при загрузке какого-либо файла, попробуйте корректность работы на меньшем по размеру файле, Это включает в себя и «загрузки» файлов, которые не загружаются с вашего локального компьютера. Даже файлы, отправленные с других компьютеров, считаются «загрузками» с точки зрения веб-сервера, на котором работает ваше приложение.

Выйдите и войдите

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

В большинстве веб-приложений выход повторный вход приводит к перегенерации локального токена сессии.

Отладка на распространённых платформах

Откатите последние изменения

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

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

Удалите новые расширения, модули или плагины

Проверьте непреднамеренные изменения в базе данных

Расширение может изменить записи в базе данных, которые «не принадлежат» ему, а созданы и управляются другими расширениями ( или даже самой CMS ). В подобных случаях модуль может не знать, как откатить назад изменения, внесенные в записи базы данных.

Я лично сталкивался с такими случаями несколько раз. Поэтому лучшим путём будет открыть базу данных и вручную просмотреть таблицы и записи, которые могли быть изменены расширением.

Поиск проблем на стороне сервера

Проверка на неверные заголовки HTTP

Просмотрите логи

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

Отладьте код приложения или скриптов

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

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

Пожалуйста, оставляйте свои отзывы по текущей теме статьи. Мы крайне благодарны вам за ваши комментарии, отклики, дизлайки, подписки, лайки!

Источник

Http 400 Bad Request (Запрос загона слишком долго) ответы на запросы HTTP

Если запрос HTTP, который нуждается в проверке подлинности Kerberos, отправляется на веб-сайт, который находится на службы IIS (IIS) и настроен на использование проверки подлинности Kerberos, загон http-запроса будет очень длинным. Эта статья поможет вам обойти ошибку HTTP 400, которая возникает при слишком долгом заглаве 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 до 4/3 * T-bytes, где T — это размер маркера пользователя MaxRequestBytes в bytes. HTTP кодирует маркер Kerberos с помощью кодирования base64.

Это заменяет каждые три bytes в маркере с четырьмя базовыми64-кодируемыми bytes. Изменения, внесенные в реестр, не вступает в силу, пока не перезапустите службу HTTP. Кроме того, может потребоваться перезапустить все связанные службы, например службы IIS.

В зависимости от среды приложения можно также решить эту проблему, настроив веб-сайт на использование Windows NT lan-менеджера (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 bytes) + 200
MaxRequestBytes	DWORD	(4/3 * T bytes) + 200

Вы также можете установить ключи реестра к максимальным значениям, как показано в следующей таблице. Рассмотрите все возможные последствия безопасности, прежде чем вносить изменения в параметры реестра.

Имя	Тип значения	Значение
MaxFieldLength	DWORD	65536 (декабрь) или 10000 (Hex)
MaxRequestBytes	DWORD	16777216 (dec) или 1000000 (Hex)

Изменение этих ключей реестра следует считать крайне опасным. Эти ключи позволяют отправить более крупные пакеты HTTP в IIS. Это, в свою очередь, может Http.sys использовать больше памяти. Таким образом, такие изменения могут повысить уязвимость компьютера к вредоносным атакам.

Если установлено максимальное значение 64 КБ, значение реестра должно быть задано MaxFieldLength MaxTokenSize 3/4 * 64 = 48 КБ. Дополнительные сведения о параметре см. в ссылке Проблемы с MaxTokenSize проверкой подлинности Kerberos,когда пользователь принадлежит к многим группам.

Источник