код ответа сервера 400 web сервис 1с
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 при работе с 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, все отлично работало. Вчера перевели на защищенное соединение и пипец. походу надо копать именно сам сервис, что-то в нем случилось.
Ошибка 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-сервисов на платформе «1С:Предприятие»
В этой статье разбираются демонстрационные HTTP-сервисы, созданные в демонстрационной конфигурации «Управляемое приложение» для платформы «1С:Предприятие» версии 8.3.5 и старше.
Цель статьи – помочь разобраться с использованием технологии HTTP-сервисов и показать практическое применение некоторых неочевидных механизмов.
Демонстрационная база «Управляемое приложение» представляет собой простую конфигурацию, в которой создано большинство объектов, которые могут понадобиться при автоматизации деятельности небольшой торговой фирмы. В частности, в ней присутствует справочник «Товары». Элементами этого справочника мы будем управлять при помощи HTTP-сервиса. Такой сценарий может возникнуть, например, при интеграции с интернет-магазином или другой корпоративной ИС, в которую заносится первичная информация о товарах.
Для удобства изучения описываемых HTTP-сервисов рекомендуется включить авторизацию ОС при публикации на веб-сервере и настроить пользователю с ролью «Администратор» использование windows-аутентификации от имени пользователя ОС, под которым будет проходить изучение.
HTTP-сервис «Товары»
HTTP-сервис «Товары» написан в REST-стиле. Он позволяет получать и удалять элементы и группы в справочнике товаров. Доступ к элементу осуществляется с помощью его пути в иерархии.
Например, для того чтобы получить информацию о товаре «Ряженка» с кодом 000000027, входящем в группу «Молочные» с кодом 000000099, которая входит, в свою очередь в группу «Продукты» с кодом 000000011, в браузере надо будет набрать http:// /hs/Products/000000011/000000099/000000027. Если база опубликована по пути http://localhost:8090/Platform8Demo/, то путь будет:
http://localhost:8090/Platform8Demo/ hs /Products/000000011/000000099/000000027.
Из чего состоит путь? Рассмотрим по частям:
В нашем случае у сервиса один дочерний объект шаблон URL. В свойстве «Шаблон» этого объекта записана строка “/*». Звездочка – это специальное значение, указывающее на то, что к данному шаблону подходят любые URL. В нашем случае необходимость использования такого шаблона (т.е. по сути отказа от ограничения URL) обусловлена произвольной глубиной иерархии товаров.
У нашего шаблона URL имеются два дочерних объекта, соответствующих HTTP-методам GET (получение) и DELETE (удаление). Именно в них указаны обработчики, которые будут вызываться при обращении к HTTP-сервису.
Для обработки запроса с использованием HTTP-метода GET (а именно такой будет создан, если вставить указанные выше URL в браузер) используется функция ПутьКТоваруGET. Рассмотрим эту функцию немного подробнее:
Сформированное XML-представление используется в ответе сервиса:
HTTP-сервис «ОписанияТоваров»
HTTP-сервис «ОписанияТоваров» предназначен для получения и редактирования информации о товарах. Он написан в RPC (Remote Procedure Call) стиле, похожем на SOAP. В качестве дополнительного условия также предположим, что заказчик, для которого мы разрабатываем конфигурацию, потребовал предусмотреть наличие нескольких версий API где-то в будущем.
Обращение к сервису выполняется при помощи запросов с использование метода POST к URL следующего вида:
Рассмотрим, из чего состоит путь:
Видно, что сервер передал описание товара в формате html.
Рассмотрим, как реализован сервис. Объект метаданных HTTP-сервиса имеет единственный дочерний шаблон URL, в котором прописан следующий шаблон:
Т.к. у нас пока нет разных версий сервиса, сегмент с номером версии фиксирован, а вот второй сегмент может принимать разные значения, соответствующие именам методов. В коде получение имени метода выглядит следующим образом:
Обращаем внимание, что коллекция «ПараметрыURL» запроса содержит единственное значение – согласно количеству сегментов, которые могут принимать разные значение.
Для возврата описания товара мы устанавливаем тело запроса:
Аналогично, для установки описания товара мы получаем его из запроса:
При установке описания из тела запроса мы проводим минимальную проверку корректности того, что прислал нам клиент, в данном случае – только типа содержимого, изучая заголовок «Content-type».
Для того чтобы протестировать установку тела запроса достаточно заполнить его в Fiddler:
Отладка кода HTTP-сервиса
Отладка кода HTTP-сервиса аналогична отладке код SOAP веб-сервиса. Для включения отладки нужно:
Разрешение отладки на веб-сервере
Для разрешения отладки на веб-сервере нужно перейти на вкладку «Прочие» диалога публикации на веб-сервере, установить флаг «разрешить отладку» и указать адрес отладчика. Для локальной отладки можно указать tcp://localhost
То же самое можно сделать вручную, исправив vrd-файл, см документацию.
Включение автоматического подключения
Для того чтобы платформа автоматически подключалась для отладки к вызываемым HTTP-сервисам нужно:
Помните, что флажок следует устанавливать при каждом запуске конфигуратора, в котором требуется отладка HTTP-сервисов.
Заключение
В статье рассмотрены основные аспекты программирования HTTP-сервисов в «1С:Предприятии», в частности:
Также показано, как можно их тестировать при помощи программы Fiddler. Более полные справочные материалы можно найти в ИТС по постоянному адресу.
Ошибка 400: что такое и как исправить
Интернет ― это сложная схема взаимодействия устройств. Между компьютером и сервером сайта легко могут появиться проблемы с сетью: код ошибки 400, 406, 410. В этой статье мы рассмотрим ошибку 400.
Что значит ошибка 400
Все ошибки, которые начинаются на 4, говорят о том, что проблема на стороне пользователя.
Ошибка 400 bad request переводится как «плохой запрос». Она возникает тогда, когда браузер пользователя отправляет некорректный запрос серверу, на котором находится сайт.
Чаще всего проблема действительно обнаруживается на стороне пользователя, но бывают и исключения, когда проблема на стороне провайдера или владельца сайта.
Причины появления ошибки 400
Как исправить ошибку 400
Перед тем как заниматься серьёзной настройкой устройства, проверьте правильность написания URL-адреса. Если ссылка была скопирована с сайта, попробуйте найти нужную страницу по ключевым словам. Как только вы найдёте правильную ссылку, сайт заработает.
Если причина не в этом, переходите к другим настройкам, которые описаны ниже.
Очистите файлы cookies и кэш браузера
Файлы куки и кэш созданы для того, чтобы запоминать сайты и персональные данные пользователя. За счёт этой памяти ускоряется процесс повторной загрузки страницы. Но cookies и кэш, которые хранят данные предыдущей сессии, могут конфликтовать с другим токеном сессии. Это приведёт к ошибке 400 Bad Request.
Очистите кэш браузера по инструкции и попробуйте зайти на страницу заново.
Очистить кэш и куки можно не только вручную, но и с помощью программ CCleaner и Advanced SystemCare.
CCleaner ― эффективное решение для оптимизации работы системы. За пару кликов можно очистить кэш и cookies в нескольких браузерах одновременно. Также можно быстро почистить все временные файлы, которые могут замедлять работу системы. Интуитивный интерфейс не требует специальных знаний:
Ещё одним популярным приложением для оптимизации ПК является Advanced SystemCare. Эта программа поможет удалить ненужные файлы, очистить реестр, ускорить работу системы, освободить память и место на диске. Также она может контролировать безопасность просмотра веб-страниц, защищая конфиденциальные данные, блокируя вредоносные веб-сайты и предотвращая майнинг криптовалюты.
Очистите кэш DNS
DNS-кэш — это временная база данных вашего компьютера, которая хранит IP-адреса часто посещаемых веб-сайтов. Такая база данных ускоряет связь с сервером.
Вы можете изменить DNS, однако данные из кэша отправляют на старый IP-адрес. После очистки браузер начнёт обращаться к новому IP-адресу. Чаще всего проблема несоответствия DNS приводит к ошибке 502, но также может появиться ошибка 400.
В зависимости от вашей операционной системы очистите кэш по одной из инструкций.