KuznecovvIvan
21.11.22
✎
14:07
Пытаюсь сделать JSON запрос, он выдает ошибку 400. Вроде все правильно сделал. Сервер поднял на IIS. Причем если открываю через браузер, то обращение происходит к HTTP-сервису. Но если пытаюсь сделать этим кодом, то ошибка 400. Высылаю код
Функция ОтправитьHTTPЗапрос(СтруктураОтправки)
Логин = СтруктураОтправки.Логин;
Пароль = СтруктураОтправки.Пароль;
Сервер = СтруктураОтправки.Сервер;
Порт = СтруктураОтправки.Порт;
АдресРесурса = СтруктураОтправки.АдресРесурса;
СтрокаJSON = СтруктураОтправки.СтрокаJSON;
МетодСервиса = СтруктураОтправки.МетодСервиса;
#Если Клиент Тогда
SSL = Новый ЗащищенноеСоединениеOpenSSL(Новый СертификатКлиентаWindows(СпособВыбораСертификатаWindows.Выбирать),Новый СертификатыУдостоверяющихЦентровWindows());
#Иначе
SSL = Новый ЗащищенноеСоединениеOpenSSL(Неопределено,Неопределено);
#КонецЕсли
HTTPСоединение = Новый HTTPСоединение(Сервер,Порт,Логин,Пароль,,,SSL);// // не забыть вернуть Кузнецов ИВ
HTTPЗапрос = новый HTTPЗапрос(МетодСервиса);
HTTPЗапрос.АдресРесурса = АдресРесурса;
HTTPЗапрос.УстановитьТелоИзСтроки(СтрокаJSON, КодировкаТекста.UTF8 ,ИспользованиеByteOrderMark.НеИспользовать);//
HTTPЗапрос.Заголовки.Вставить(«Content-type», «application/json-rpc»);
//HTTPЗапрос.Заголовки.Вставить(«Content-type», «application/x-www-form-urlencoded»);
ДокументJSON = HTTPЗапрос.ПолучитьТелоКакСтроку();
ваплво = ПрочитатьСтрокуJSON(ДокументJSON);
Попытка
РезультатВыполнения = HTTPСоединение.ВызватьHTTPМетод(МетодСервиса,HTTPЗапрос);
Исключение
Сообщить(ОписаниеОшибки());
КонецПопытки;
Возврат РезультатВыполнения;
КонецФункции
Irbis
21.11.22
✎
14:10
400 — «плохой запрос», ошибка, возможно, в синтаксисе и сервер ни бельмеса ни ферштейн.
KuznecovvIvan
21.11.22
✎
14:13
(1) Скажем так в какую сторону нужно смотреть? Возможно не правильно сформирован JSON запрос. Или что-то возможно в настройках не так тика в адресе ресурса или в не правильно методе сервиса?
KuznecovvIvan
21.11.22
✎
14:14
(1) Просто я редко работаю с HTTP-сервисами, задача не моя, по наследству осталось. Поэтому особо не понимаю что значит может быть ошибка в синтаксисе
Галахад
21.11.22
✎
14:28
Так непонятно, что в переменных. Возможно в данных проблема.
И что это за мусор:
ДокументJSON = HTTPЗапрос.ПолучитьТелоКакСтроку();
ваплво = ПрочитатьСтрокуJSON(ДокументJSON);
KuznecovvIvan
21.11.22
✎
14:33
(4) Да это мусор в переменных следующее:
СтруктураОтправки = новый Структура;
СтруктураОтправки.Вставить(«Логин», «»); //
СтруктураОтправки.Вставить(«Пароль», «»);
СтруктураОтправки.Вставить(«Сервер»,»192.168.65.140″);
СтруктураОтправки.Вставить(«Порт», 443);
СтруктураОтправки.Вставить(«АдресРесурса», «https://192.168.65.140/Working_KuznecovIV/hs/APIService/V1/SoglasovanieObmenDO»);
СтруктураОтправки.Вставить(«СтрокаJSON», ДокументJSON);
СтруктураОтправки.Вставить(«МетодСервиса», «POST»);
Если я пытаюсь адрес ввести в браузере в поисковую строку, то он выполняет метод GET HTTP-сервиса. И авторизация там норм проходит
Irbis
21.11.22
✎
14:33
(2) Всё смотреть, вплоть до того как ответит сервис если сунуть запрос в строку браузера. Иногда лишний слэш или ещё какой мусорный символ мешает.
Irbis
21.11.22
✎
14:34
Имхается что в адресе ресурса толь IP должен остаться, остальное в метод перехать должно
Галахад
21.11.22
✎
14:38
(7) +1. Протокол тоже не нужно указывать. Достаточно 192.168.65.140
И по авторизации, скорее всего не пройдет. В браузере возможно кто-то пароль уже вводил и теперь он в кэше.
Галахад
21.11.22
✎
14:40
(9) + 9 Т.е. наоборот из адреса ресурса нужно выкинуть все что до имени базы.
KuznecovvIvan
21.11.22
✎
15:02
(10) Спасибо большое) Да именно в этом было дело) /Working_KuznecovIV/hs/APIService/V1/SoglasovanieObmenDO оставил так, все заработало) Спасибо)
1CNachalo
12.12.20 — 21:21
Есть веб-сервис и общая команда. В общей команде код:
Попытка
ВСОпределение = Новый 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).
(1с и Apache2.2 переустановил — не помогло)
При этом базу в браузере вижу, xml-файл тоже.
————————————
Примерно в момент возникновения этой ошибки началось следующее: даже если база нигде не открыта (ни в браузере, ни на ПК), выдается сообщение: “Достигнуто предельное количество подключений к ИБ”. Чтобы выходить из этой ситуации приходится часто чистить кэш и останавливать сервер.
Что это может быть? Как исправить?
SuperMario
1 — 12.12.20 — 21:43
Старо как Мир — это код ответа HTTP, который означает, что сервер не смог обработать запрос)
Залезьте каким-нить SOAPUI по ссылке «http://192.168.___.__/t10/ws/OD.1cws?wsdl»; (или вставьте в браузер)
Что в ответ?
1CNachalo
2 — 12.12.20 — 21:54
В ответ в браузере xml-схема.
SuperMario
3 — 12.12.20 — 22:35
(2) сори. Не дочитал полностью (0)
1CNachalo
4 — 13.12.20 — 13:14
Вбил неверный адрес http://192.168.___.__/t10/ws/OD?wsdl
Т.е. не OD.1cws?wsd, а OD?wsd — всё равно дает xml-схему. Это как вообще? Может ошибка связана как-то с этим?
acht
5 — 13.12.20 — 14:08
Приведи полный текст ошибки, которое выбрасывает исключение.
Вангую, что у тебя учебная платформа и в пуле застревает твой же предыдущий сеанс.
1CNachalo
6 — 13.12.20 — 16:02
(5) Платформа учебная. Да, есть ощущение, что действительно застревает предыдущий сеанс. Но что с этим делать?
———-
{ОбщаяКоманда.ВыполнитьСинхронизацию.МодульКоманды(15)}:Ошибка при вызове конструктора (WSОпределения): при создании описания сервиса произошла ошибка URL: http://192.168.___.__/t10/ws/OD.1cws?wsdl Код ответа сервера: 400
acht
7 — 13.12.20 — 20:28
(6) В файле default.vrd установить размер пула в 1 и время жизни соединения в пула во что нибудь минимальное.
SuperMario
8 — 13.12.20 — 22:31
Припоминаю, у меня подобное было когда-то с базовой БП 3.0.
Она локально/однопользовательская. Начались проблемы с работой через WEB, когда там пользователь работает.
Был уверен, что WEB/HTTP сервисы не занимают клиентскую лицензию. Но практика показала обратное.
У учебной версии то же самое: «количество одновременных сеансов работы с информационной базой ограничено одним сеансом».
Случайно никто в это время не работает в базе (http://192.168.___.__/t10) когда соединение поднимается?
Вот что пишет:
https://forum.infostart.ru/forum9/topic128169/
seevkik
9 — 14.12.20 — 04:05
(8) Они занимают лицензию во время выполнения запроса
1CNachalo
10 — 14.12.20 — 08:36
(7) Т.е в файле изначально 2 таких фрагмента:
<>
poolSize=»10″
poolTimeout=»5″/>
</>
Исправляю в обоих на
<>
poolSize=»1″
poolTimeout=»1″/>
</>
Пока дает ту же ошибку.
1CNachalo
11 — 14.12.20 — 08:38
(8) Случайно никто в это время не работает в базе (http://192.168.___.__/t10) когда соединение поднимается?
——————————
Не, я ж тут вообще один, сижу, тренируюсь, застрял.
1CNachalo
12 — 14.12.20 — 08:41
(9) Что именно занимает лицензию?
И как это исправить?
Как-то работало до определенного момента, переходило дальше по функции, ошибку не давало. Потом резко — ошибка 400.
acht
13 — 14.12.20 — 08:45
(10) > изначально 2 таких фрагмента
Там больше двух. В standardOdata, в ws, в httpServices и в pool. В последнем оно size и maxAge, а не то, что ты поставил
1CNachalo
14 — 14.12.20 — 12:56
(13) Не нахожу. У меня вот так:
<?xml version=»1.0″ encoding=»UTF-8″?> //1
<point xmlns=»http://v8.1c.ru/8.2/virtual-resource-system»; //2
xmlns:xs=»http://www.w3.org/2001/XMLSchema»//3
xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»//4
base=»/t10″//5
ib=»File="D:1Cтесткр6";»>//6
<debug enable=»true»//7
protocol=»http»//8
url=»192.168.___._»/>//9
<httpServices publishByDefault=»false»/>//10
<standardOdata enable=»true»//11
reuseSessions=»autouse»//12
sessionMaxAge=»1″//13 было 20
poolSize=»1″ //14 было 10
poolTimeout=»1″/>//15 было 5
<analytics enable=»true»/>//16
<ws>//17
<point name=»OD»//18
alias=»OD.1cws»//19
enable=»true»//20
reuseSessions=»autouse»//21
sessionMaxAge=»1″ //22 было 20
poolSize=»1″ //23 было 10
poolTimeout=»1″/> //24 было 5
</ws>//25
</point>//26
Что нужно исправить? Ошибку пока выдает ту же
acht
15 — 14.12.20 — 13:09
1CNachalo
16 — 14.12.20 — 18:27
(15) пример из статьи
<pool size=»50″ maxAge=»10″ attempts=»2″ attepmtTimeout=»1″
waitTimeout=»1″/>
ставлю в standardOdata, в ws, в httpServices и в pool.
Получаю так
<?xml version=»1.0″ encoding=»UTF-8″?>
<point xmlns=»http://v8.1c.ru/8.2/virtual-resource-system»;
xmlns:xs=»http://www.w3.org/2001/XMLSchema»;
xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»;
base=»/fm»
ib=»File="D:1CтестWebSer_активныеСистемы";»>
<debug enable=»true»
protocol=»http»
url=»127.0.0.1″/>
<ws enable=»false» poolsize=»5″ maxAge=»1″ attempts=»2″ attepmtTimeout=»1″
waitTimeout=»1″/>
<httpServices publishByDefault=»false» poolsize=»5″ maxAge=»1″ attempts=»2″ attepmtTimeout=»1″
waitTimeout=»1″/>
<standardOdata enable=»true»
reuseSessions=»autouse»
sessionMaxAge=»2″
poolSize=»1″
poolTimeout=»5″/>
<analytics enable=»true»/>
</point>
1CNachalo
12.12.20 — 21:21
Есть веб-сервис и общая команда. В общей команде код:
Попытка
ВСОпределение = Новый 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).
(1с и Apache2.2 переустановил — не помогло)
При этом базу в браузере вижу, xml-файл тоже.
————————————
Примерно в момент возникновения этой ошибки началось следующее: даже если база нигде не открыта (ни в браузере, ни на ПК), выдается сообщение: “Достигнуто предельное количество подключений к ИБ”. Чтобы выходить из этой ситуации приходится часто чистить кэш и останавливать сервер.
Что это может быть? Как исправить?
SuperMario
1 — 12.12.20 — 21:43
Старо как Мир — это код ответа HTTP, который означает, что сервер не смог обработать запрос)
Залезьте каким-нить SOAPUI по ссылке «http://192.168.___.__/t10/ws/OD.1cws?wsdl»; (или вставьте в браузер)
Что в ответ?
1CNachalo
2 — 12.12.20 — 21:54
В ответ в браузере xml-схема.
SuperMario
3 — 12.12.20 — 22:35
(2) сори. Не дочитал полностью (0)
1CNachalo
4 — 13.12.20 — 13:14
Вбил неверный адрес http://192.168.___.__/t10/ws/OD?wsdl
Т.е. не OD.1cws?wsd, а OD?wsd — всё равно дает xml-схему. Это как вообще? Может ошибка связана как-то с этим?
acht
5 — 13.12.20 — 14:08
Приведи полный текст ошибки, которое выбрасывает исключение.
Вангую, что у тебя учебная платформа и в пуле застревает твой же предыдущий сеанс.
1CNachalo
6 — 13.12.20 — 16:02
(5) Платформа учебная. Да, есть ощущение, что действительно застревает предыдущий сеанс. Но что с этим делать?
———-
{ОбщаяКоманда.ВыполнитьСинхронизацию.МодульКоманды(15)}:Ошибка при вызове конструктора (WSОпределения): при создании описания сервиса произошла ошибка URL: http://192.168.___.__/t10/ws/OD.1cws?wsdl Код ответа сервера: 400
acht
7 — 13.12.20 — 20:28
(6) В файле default.vrd установить размер пула в 1 и время жизни соединения в пула во что нибудь минимальное.
SuperMario
8 — 13.12.20 — 22:31
Припоминаю, у меня подобное было когда-то с базовой БП 3.0.
Она локально/однопользовательская. Начались проблемы с работой через WEB, когда там пользователь работает.
Был уверен, что WEB/HTTP сервисы не занимают клиентскую лицензию. Но практика показала обратное.
У учебной версии то же самое: «количество одновременных сеансов работы с информационной базой ограничено одним сеансом».
Случайно никто в это время не работает в базе (http://192.168.___.__/t10) когда соединение поднимается?
Вот что пишет:
https://forum.infostart.ru/forum9/topic128169/
seevkik
9 — 14.12.20 — 04:05
(8) Они занимают лицензию во время выполнения запроса
1CNachalo
10 — 14.12.20 — 08:36
(7) Т.е в файле изначально 2 таких фрагмента:
<>
poolSize="10" poolTimeout="5"/> </> Исправляю в обоих на <> poolSize="1" poolTimeout="1"/> </>
Пока дает ту же ошибку.
1CNachalo
11 — 14.12.20 — 08:38
(8) Случайно никто в это время не работает в базе (http://192.168.___.__/t10) когда соединение поднимается?
——————————
Не, я ж тут вообще один, сижу, тренируюсь, застрял.
1CNachalo
12 — 14.12.20 — 08:41
(9) Что именно занимает лицензию?
И как это исправить?
Как-то работало до определенного момента, переходило дальше по функции, ошибку не давало. Потом резко — ошибка 400.
acht
13 — 14.12.20 — 08:45
(10) > изначально 2 таких фрагмента
Там больше двух. В standardOdata, в ws, в httpServices и в pool. В последнем оно size и maxAge, а не то, что ты поставил
1CNachalo
14 — 14.12.20 — 12:56
(13) Не нахожу. У меня вот так:
<?xml version=»1.0″ encoding=»UTF-8″?> //1
<point xmlns=»http://v8.1c.ru/8.2/virtual-resource-system»; //2
xmlns:xs=»http://www.w3.org/2001/XMLSchema»//3
xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»//4
base="/t10"//5 ib="File="D:1Cтесткр6";">//6 <debug enable="true"//7 protocol="http"//8 url="192.168.___._"/>//9 <httpServices publishByDefault="false"/>//10 <standardOdata enable="true"//11 reuseSessions="autouse"//12 sessionMaxAge="1"//13 было 20 poolSize="1" //14 было 10 poolTimeout="1"/>//15 было 5 <analytics enable="true"/>//16 <ws>//17 <point name="OD"//18 alias="OD.1cws"//19 enable="true"//20 reuseSessions="autouse"//21 sessionMaxAge="1" //22 было 20 poolSize="1" //23 было 10 poolTimeout="1"/> //24 было 5 </ws>//25 </point>//26 Что нужно исправить? Ошибку пока выдает ту же
acht
15 — 14.12.20 — 13:09
1CNachalo
16 — 14.12.20 — 18:27
(15) пример из статьи <pool size="50" maxAge="10" attempts="2" attepmtTimeout="1" waitTimeout="1"/> ставлю в standardOdata, в ws, в httpServices и в pool. Получаю так <?xml version="1.0" encoding="UTF-8"?>
<point xmlns=»http://v8.1c.ru/8.2/virtual-resource-system»;
xmlns:xs=»http://www.w3.org/2001/XMLSchema»;
xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance»;
base="/fm" ib="File="D:1CтестWebSer_активныеСистемы";"> <debug enable="true" protocol="http" url="127.0.0.1"/> <ws enable="false" poolsize="5" maxAge="1" attempts="2" attepmtTimeout="1" waitTimeout="1"/> <httpServices publishByDefault="false" poolsize="5" maxAge="1" attempts="2" attepmtTimeout="1" waitTimeout="1"/> <standardOdata enable="true" reuseSessions="autouse" sessionMaxAge="2" poolSize="1" poolTimeout="5"/> <analytics enable="true"/> </point>
Ошибка 400 Bad Request – это код ответа HTTP, который означает, что сервер не смог обработать запрос, отправленный клиентом из-за неверного синтаксиса. Подобные коды ответа HTTP отражают сложные взаимоотношения между клиентом, веб-приложением, сервером, а также зачастую сразу несколькими сторонними веб-сервисами. Из-за этого поиск причины появления ошибки может быть затруднён даже внутри контролируемой среды разработки.
В этой статье мы разберём, что значит ошибка 400 Bad Request (переводится как «Неверный запрос»), и как ее исправить
- На стороне сервера или на стороне клиента?
- Начните с тщательного резервного копирования приложения
- Диагностика ошибки 400 Bad Request
- Исправление проблем на стороне клиента
- Проверьте запрошенный URL
- Очистите соответствующие куки
- Загрузка файла меньшего размера
- Выйдите и войдите
- Отладка на распространённых платформах
- Откатите последние изменения
- Удалите новые расширения, модули или плагины
- Проверьте непреднамеренные изменения в базе данных
- Поиск проблем на стороне сервера
- Проверка на неверные заголовки HTTP
- Просмотрите логи
- Отладьте код приложения или скриптов
Все коды ответа HTTP из категории 4xx считаются ошибками на стороне клиента. Несмотря на это, появление ошибки 4xx не обязательно означает, что проблема как-то связана с клиентом, под которым понимается веб-браузер или устройство, используемое для доступа к приложению. Зачастую, если вы пытаетесь диагностировать проблему со своим приложением, можно сразу игнорировать большую часть клиентского кода и компонентов, таких как HTML, каскадные таблицы стилей (CSS), клиентский код JavaScript и т.п. Это также применимо не только к сайтам. Многие приложения для смартфонов, которые имеют современный пользовательский интерфейс, представляют собой веб-приложения.
С другой стороны, ошибка 400 Bad Request означает, что запрос, присланный клиентом, был неверным по той или иной причине. Пользовательский клиент может попытаться загрузить слишком большой файл, запрос может быть неверно сформирован, заголовки HTTP запроса могут быть неверными и так далее.
Мы рассмотрим некоторые из этих сценариев (и потенциальные решения) ниже. Но имейте в виду: мы не можем однозначно исключить ни клиент, ни сервер в качестве источника проблемы. В этих случаях сервер является сетевым объектом, генерирующим ошибку 400 Bad Request и возвращающим её как код ответа HTTP клиенту, но возможно именно клиент ответственен за возникновение проблемы.
Важно сделать полный бэкап вашего приложения, базы данных и т.п. прежде, чем вносить какие-либо правки или изменения в систему. Ещё лучше, если есть возможность создать полную копию приложения на дополнительном промежуточном сервере, который недоступен публично.
Подобный подход обеспечит чистую тестовую площадку, на которой можно отрабатывать все возможные сценарии и потенциальные изменения, чтобы исправить или иную проблему без угрозы безопасности или целостности вашего «живого» приложения.
Ошибка 400 Bad Request означает, что сервер (удалённый компьютер) не может обработать запрос, отправленный клиентом (браузером), вследствие проблемы, которая трактуется сервером как проблема на стороне клиента.
Существует множество сценариев, в которых ошибка 400 Bad Request может появляться в приложении. Ниже представлены некоторые наиболее вероятные случаи:
- Клиент случайно (или намеренно) отправляет информацию, перехватываемую маршрутизатором ложных запросов. Некоторые веб-приложения ищут особые заголовки HTTP, чтобы обрабатывать запросы и удостовериться в том, что клиент не предпринимает ничего зловредного. Если ожидаемый заголовок HTTP не найден или неверен, то ошибка 400 Bad Request – возможный результат.
- Клиент может загружать слишком большой файл. Большинство серверов или приложений имеют лимит на размер загружаемого файла, Это предотвращает засорение канала и других ресурсов сервера. Во многих случаях сервер выдаст ошибку 400 Bad Request, когда файл слишком большой и поэтому запрос не может быть выполнен.
- Клиент запрашивает неверный URL. Если клиент посылает запрос к неверному URL (неверно составленному), это может привести к возникновению ошибки 400 Bad Request.
- Клиент использует недействительные или устаревшие куки. Это возможно, так как локальные куки в браузере являются идентификатором сессии. Если токен конкретной сессии совпадает с токеном запроса от другого клиента, то сервер/приложение может интерпретировать это как злонамеренный акт и выдать код ошибки 400 Bad Request.
Устранение ошибки 400 Bad Request (попробуйте позже) лучше начать с исправления на стороне клиента. Вот несколько советов, что следует попробовать в браузере или на устройстве, которые выдают ошибку.
Наиболее частой причиной ошибки 400 Bad Request является банальный ввод некорректного URL. Доменные имена (например, internet-technologies.ru) нечувствительны к регистру, поэтому ссылка, написанная в смешанном регистре, такая как interNET-technologies.RU работает так же, как и нормальная версия в нижнем регистре internet-technologies.ru. Но части URL, которые расположены после доменного имени, чувствительными к регистру. Кроме случаев, когда приложение/сервер специально осуществляет предварительную обработку всех URL и переводит их в нижний регистр перед исполнением запроса.
Важно проверять URL на неподходящие специальные символы, которых в нем не должно быть. Если сервер получает некорректный URL, он выдаст ответ в виде ошибки 400 Bad Request.
Одной из потенциальных причин возникновения ошибки 400 Bad Request являются некорректные или дублирующие локальные куки. Файлы куки в HTTP – это небольшие фрагменты данных, хранящиеся на локальном устройстве, которые используются сайтами и веб-приложениями для «запоминания» конкретного браузера или устройства. Большинство современных веб-приложений использует куки для хранения данных, специфичных для браузера или пользователя, идентифицируя клиента и позволяя делать следующие визиты быстрее и проще.
Но куки, хранящие информацию сессии о вашем аккаунте или устройстве, могут конфликтовать с другим токеном сессии от другого пользователя, выдавая кому-то из вас (или вам обоим) ошибку 400 Bad Request.
В большинстве случаев достаточно рассматривать только ваше приложение в отношении файлов куки, которые относятся к сайту или веб-приложению, выдающему ошибку 400 Bad Request.
Куки хранятся по принципу доменного имени веб-приложения, поэтому можно удалить только те куки, которые соответствуют домену сайта, сохранив остальные куки не тронутыми. Но если вы не знакомы с ручным удалением определённых файлов куки, гораздо проще и безопаснее очистить сразу все файлы куки.
Это можно сделать разными способами в зависимости от браузера, который вы используете:
- Google Chrome;
- Internet Explorer;
- Microsoft Edge;
- Mozilla Firefox;
- Safari.
Если вы получаете ошибку 400 Bad Request при загрузке какого-либо файла, попробуйте корректность работы на меньшем по размеру файле, Это включает в себя и «загрузки» файлов, которые не загружаются с вашего локального компьютера. Даже файлы, отправленные с других компьютеров, считаются «загрузками» с точки зрения веб-сервера, на котором работает ваше приложение.
Попробуйте выйти из системы и войти обратно. Если вы недавно очистили файлы куки в браузере, это приводит к автоматическому выходу из системы при следующей загрузке страницы. Попробуйте просто войти обратно, чтобы посмотреть, заработала ли система корректно.
Также приложение может столкнуться с проблемой, связанной с вашей предыдущей сессией, являющейся лишь строкой, которую сервер посылает клиенту, чтобы идентифицировать клиента при будущих запросах. Как и в случае с другими данными, токен сессии (или строка сессии) хранится локально на вашем устройстве в файлах куки и передаётся клиентом на сервер при каждом запросе. Если сервер решает, что токен сессии некорректен или скомпрометирован, вы можете получить ошибку 400 Bad Request.
В большинстве веб-приложений выход повторный вход приводит к перегенерации локального токена сессии.
Если вы используете на сервере распространённые пакеты программ, которые выдают ошибку 400 Bad Request, изучите стабильность и функциональность этих платформ. Наиболее распространённые системы управления контентом, такие как WordPress, Joomla! и Drupal, хорошо протестированы в своих базовых версиях. Но как только вы начинаете изменять используемые ими расширения PHP, очень легко спровоцировать непредвиденные проблемы, которые выльются в ошибку 400 Bad Request.
Если вы обновили систему управления контентом непосредственно перед появлением ошибки 400 Bad Request, рассмотрите возможность отката к предыдущей версии, которая была установлена, как самый быстрый и простой способ убрать ошибку 400 bad request.
Аналогично, любые расширения или модули, которые были обновлены, могут вызывать ошибки на стороне сервера, поэтому откат к предыдущим версиям этих расширений также может помочь.
Но в некоторых случаях CMS не предоставляют возможности отката к предыдущим версиям. Так обычно происходит с популярными платформами, поэтому не бойтесь, если вы не можете найти простой способ вернуться к использованию старой версии той или иной программной платформы.
В зависимости от конкретной CMS, которую использует приложение, имена этих компонентов будут различаться. Но во всех системах они служат одной и той же цели: улучшение возможностей платформы относительно её стандартной функциональности.
При этом имейте в виду, что расширения могут так или иначе получать полный контроль над системой, вносить изменения в код PHP, HTML, CSS, JavaScript или базу данных. Поэтому мудрым решением может быть удаление любых новых расширений, которые были недавно добавлены.
Даже если удалили расширение через панель управления CMS, это не гарантирует, что внесенные им изменения были полностью отменены. Это касается многих расширений WordPress, которым предоставляется полный доступ к базе данных.
Расширение может изменить записи в базе данных, которые «не принадлежат» ему, а созданы и управляются другими расширениями (или даже самой CMS). В подобных случаях модуль может не знать, как откатить назад изменения, внесенные в записи базы данных.
Я лично сталкивался с такими случаями несколько раз. Поэтому лучшим путём будет открыть базу данных и вручную просмотреть таблицы и записи, которые могли быть изменены расширением.
Если вы уверены, что ошибка 400 Bad Request не связана с CMS, вот некоторые дополнительные советы, которые могут помочь найти проблему на стороне сервера.
Ошибка, которую вы получаете от приложения, является результатом недостающих или некорректных специальных заголовков HTTP, которые ожидает получить приложение или сервер. В подобных случаях нужно проанализировать заголовки HTTP, которые отправляются на сторону сервера.
Почти любое веб-приложение будет вести логи на стороне сервера. Они представляют собой историю того, что делало приложение. Например, какие страницы были запрошены, к каким серверам оно обращалось, какие результаты предоставлялись из базы данных и т.п.
Логи сервера относятся к оборудованию, на котором выполняется приложение, и зачастую представляют собой детали о статусе подключённых сервисов или даже о самом сервере. Поищите в интернете “логи [ИМЯ_ПЛАТФОРМЫ]”, если вы используете CMS, или “логи [ЯЗЫК_ПРОГРАММИРОВАНИЯ]” и “логи [ОПЕРАЦИОННАЯ_СИСТЕМА]”, если у вас собственное приложение, чтобы получить подробную информацию по поиску логов.
Если это не помогло, проблема может быть в исходном коде, который выполняется внутри приложения. Попытайтесь диагностировать, откуда может исходить проблема, отлаживая приложение вручную и параллельно просматривая логи приложения и сервера.
Создайте копию всего приложения на локальном устройстве для разработки и пошагово повторите тот сценарий, который приводил к возникновению ошибки 400 Bad Request. А затем просмотрите код приложения в тот момент, когда что-то пойдёт не так.
Независимо от причины возникновения ошибки, даже если вам удалось исправить её в этот раз, появление в вашем приложении такой проблемы — это сигнал для того, чтобы внедрить инструмент обработки ошибок, который поможет автоматически обнаруживать их и оповещать в момент возникновения.
Я уже как-то писал о муках разработки web service (веб сервисов) на C# (.NET) для 1С. Продолжаем разбираться с проблемами.
При разработке веб сервиса на C# под MS Visual Studio для 1С 8.2 столкнулись с невразумительной ошибкой. В качестве сервера — Microsoft-IIS/8.5. Поиск решения занял немало времени. 🙁 Но обо всем по порядку.
Название вызываемого метода веб сервиса — BarcodeFontIsInstalled. В качестве единственного аргумента передается строка. Ошибка выглядит так:
{Форма.Форма.Форма(22)}: Ошибка при вызове метода контекста (BarcodeFontIsInstalled)
НоваяСтрока = Прокси.BarcodeFontIsInstalled(WSПараметр);
по причине:
http://tempuri.org/Ошибка вызова операции сервиса: {
}:BarcodeWebService:BarcodeFontIsInstalled()
по причине:
Неизвестная ошибка. Ошибка разбора XML: - [1,1]
Фатальная ошибка:
Extra content at the end of the document
по причине:
Ошибка разбора XML: - [1,1]
Она ни о чем не говорит, поскольку 1С безбожно переврала то, что вернул IIS.
Обращение из 1С к web service (веб сервису)
Вызов метода из 1С производился как описано в статье. Код веб сервиса в C#:
using
System.Web;
using
System.Web.Services;
using
System.Xml.Serialization;
namespace
BarcodeWebService
{
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(
false
)]
public
class
BarcodeWebService : System.Web.Services.WebService
{
[WebMethod]
public
bool
BarcodeFontIsInstalled(
string
fontName)
{
return
BarcodeUtils.IsFontInstalled(fontName);
}
}
}
Замечу, что вызов проходил через BarcodeWebServiceSoap — т.е. SOAP версии 1.1. BarcodeWebServiceSoap12 — соотвественно для работы через SOAP 1.2. 1C действительно меняет обращение к сервису, если вместо BarcodeWebServiceSoap указать BarcodeWebServiceSoap12, проверено опытным путем. 🙂
Вызов в 1С выглядел таким образом:
Прокси = WSСсылки.WSBarcodeService.СоздатьWSПрокси(
http://tempuri.org/"
"
,
"BarcodeWebService"
,
"BarcodeWebServiceSoap"
);
ТипWSПараметра = Прокси.ФабрикаXDTO.Пакеты.Получить(
http://tempuri.org/"
"
).Получить(
"BarcodeFontIsInstalled"
);
WSПараметр = Прокси.ФабрикаXDTO.Создать(ТипWSПараметра);
WSПараметр.fontName =
"Code 128"
;
НоваяСтрока = Прокси.BarcodeFontIsInstalled(WSПараметр);
Все делаем «по учебнику» но так не работает. 🙁
Отладка обращений 1С к web service (веб сервису)
Поскольку в 1С не понятно как отлаживать что-то в части работы с веб-сервисами, обращаемся за помощью к Fiddler, который покажет как-же 1С обращается к разработанному на C# web service:
Бросается в глаза странный кусок XML:
Зачем 1С сгенерировал для такого простого аргумента такую вложенную иерархию fontName не понятно. Ответ веб сервиса (MS IIS) на такую конструкцию:
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 14 Oct 2015 10:19:14 GMT
Content-Length: 0
Как видно по ответу, ошибка выдаваемая 1С рядом не лежала с тем, что на самом деле вернул IIS, а он вообще не вернул XML, сообщив, что запрос «кривой» (HTTP/1.1 400 Bad Request).
Чтобы узнать какой request должен быть, пишем пару строк на C#:
BarcodeWebService.BarcodeWebService svc =
new
BarcodeWebService.BarcodeWebService();
checkBox1.Checked = svc.BarcodeFontIsInstalled(
"Code 128"
);
и запустив Fiddler видим какой простой и красивый request получается:
Расстраиваемся, поскольку ситуация выглядит тупиковой, но пытаемся найти решение.
Перехват обращений из 1С к web service (веб сервису) cbr.ru
Обратимся к исходной статье и посмотрим как выглядит request к web service (веб сервису) www.cbr.ru. Код 1С описан в статье, а request будет таким:
В данном случае все красиво, как при обращении из кода C#:
CBRWebService.DailyInfo info =
new
CBRWebService.DailyInfo();
DataSet ds = info.GetCursOnDate(DateTime.Now);
Разбираться в WSDL, который генерирует веб сервис «Центробанка» и разработанный мною на .NET — дело неблагодарное, тем более, что даже поняв ошибку в генерации 1С request к внешнему веб сервису, повлиять на это нельзя, нужно ждать обновления платформы. Чтобы проверить одну мысль я сделал простой метод в веб сервисе:
[WebMethod]
public
DateTime Checker(DateTime date)
{
return
date;
}
У меня была мысль, что проблема связана с тем, что string аргумент может быть null, соответственно, в WSDL minOccurs=»0″, в отличие от DateTime (который передавался cbr.ru методу GetCursOnDate), для которого minOccurs=»1″ . Однако, даже для такого варианта 1С сформировал столь же «кривой» запрос, т.е. дело не в этом.
Решение
Поиск решения заняло немало времени, как обычно, оно оказалось очень простым. Спасибо моим 1С разработчикам с которыми мы вымучивали столь красивое и столь многострадальное решение. 🙂
Итак, фанфары, рабочий код на 1С при обращении к внешнему веб сервису (web service) написанному на C# (.NET) и работающему под IIS выглядит следующим образом:
Прокси = WSСсылки.WSBarcodeService.СоздатьWSПрокси(
http://tempuri.org/"
"
,
"BarcodeWebService"
,
"BarcodeWebServiceSoap"
);
Результат = Прокси.BarcodeFontIsInstalled(
"Code 128"
);
И это всё! 🙂 Предельно кратко и очень похоже на обращение к web service в C#. В этом случае перехваченный Fiddler-ом запрос 1С к веб сервису выглядит следующим образом:
При таком вызове web service (веб сервис) возвращает корректное значение. Ошибка исчезла. В качестве аргумента в метод веб сервиса из 1С передавали бинарные данные (фотографии), массивы, ну и простые типы, вроде даты, строки и пр.
Полезные ссылки
- Fiddler — перехват http траффика для анализа обмена данными
- WireShark — мощный сниффер для перехвата и анализа различных протоколов переадчи данных.
Уже много было написано про http-сервисы, но то и дело всплывают «Новые» статьи по обмену между базами V8 по COM, что «Немножко» удивляет. Решил внести свои 5 копеек, поработаем с http-сервисом.
Я уже писал статью с использованием HTTP-сервисов (Мобильный клиент + HTTP Сервис + Расширение конфигурации), но там было все сумбурно без объяснений, почему именно так. В данном цикле статей расскажу и покажу в примерах накопленный опыт в данном вопросе, и мы сделаем простой легко разворачиваемый каркас HTTP-сервиса.
Примеры будут сделаны в расширении конфигурации, на платформе 8.3.10.2650. Для опытов установил ERP 2.4.3.145(Но вообще непринципиально, ставим любую свежую конфигурацию под 8.3.10). Так как параллельно в свободное время веду разработку универсального решения под названием Pretty API или «PAPI», расширение будет содержать данную аббревиатуру.
Начнем.
Почему http-сервис?
А) HTTP сервисы на платформе 1С 8.3.5.1068 появились летом 2014 года, то есть 4 года назад, а Web-сервисы и того больше. Это кощунство не использовать их до сих пор.
Б) На Хабре в официальном блоге Фирмы 1С есть статья Способы интеграции с 1С от 25 августа 2023, почитайте ее, особенно в части устаревших технологий.
В) Геморрои с разными версиями и «comcntr.dll» забываем как страшный сон! Опубликовали и пользуемся, плюсом мы получаем Вэб клиент, мобильный клиент, легкое использование нашего сервиса другими программистами (собственно API) и другие пряники.
Г) Скорость! Использую Com последние 3 года только для того чтобы показать сравнение со стандартным интерфейсом oData или http-сервисом. Когда люди видят вживую, они даже иной раз не верят, что обмен прошел!
Это все равно, что ездить каждый год на поезде по 3 суток в сторону Сочи и вдруг слетать на самолете за 2,5 часа.
!!! Использование технологии COM (доступно только на платформе Windows) !!!
Д) С версии 8.3.7.1759 могут быть встроены через расширение, а с версии 8.3.9 плюсом к ним можно встроить модули для более простой работы с ними.
E) Простота и гибкость разработки.
Ж) Стагнация — это плохо! В работе можешь не использовать, но быть всегда готов. Нельзя стоять на месте, если пошел в IT сферу.
Еще много чего можно перечислить. Минусы, тоже есть, но плюсов в разы больше.
Самый главный минус. Нужно установить и настроить веб сервер (IIS, Apache, 1С: Публикатор или 1С: Линк – Apache с интерфейсом для простого пользователя). Тут вот в чем проблема: Чаще всего администраторы почему-то не в состоянии это сделать, и приходится настраивать самому, либо они тупо устанавливают по дефолту и там начинаются пляски с бубном. Благо сейчас статей по настройки пруд пруди, ниже приведу парочку загугленных:
Пошаговая инструкция настройки web-сервисов для 1Сv8.3 и IIS 8.5, в данной инструкции особенно выделю пункт 8.
Настройка веб сервера Apache + 1С (Пошаговое руководство)
Лично я использую IIS, но на вкус и цвет как говорится.
Ближе к делу.
Создадим демо конфигурацию для опытов и добавим в него расширение. Можно создавать все объекты и не в расширении, я просто показываю вариант без изменения конфигурации. (В расширении добавление HTTP-сервисов появилось с версии 8.3.7.1759.)
Давайте перед созданием нашего HTTP-сервиса разберемся из чего складывается URL (подробнее описано на ИТС в главе 17.2.2. HTTP-сервисы):
http://host/base/hs/корневойURL/относительныйURL?ПараметрыЗапроса
host – IP адрес или доменное имя веб сервера.
base – Имя базы. Указывается при публикации.
hs — признак того, что выполняется обращение к HTTP-сервису.
корневойURL — имя ресурса, которое определяет группу ресурсов, связанных общим смыслом.
относительныйURL — определяет ресурс, к которому будет выполняться обращение. Относительный URL, указанный в запросе, будет использован для определения конкретного ресурса, к которому выполнялось обращение. Правило сопоставления задается в объекте Шаблон URL.
ПраметрыЗапроса – Не всегда обязательные параметры передаются после знака «?», чаще всего дополнительные параметры или параметры выборки, например формат ответа(format=json или format=atom).
Теперь по порядку:
Создаем сервис и задаем ему корневойURL:
Создаем Шаблон URL:
При создании шаблона можно использовать следующие символы:
Любые символы, допустимые в идентификаторах языка «1С:Предприятие».
Символ «/»;
Символы «{}» с непустым текстом между ними;
Символ *.
Наш шаблон выглядит следующим образом: /V1/{ИмяМетода}
Где {ИмяМетода} является параметром. Параметр может состоять из букв, цифр и символа подчеркивания «_».
Почему такой шаблон?
Когда смотришь различные примеры, коих очень много в шаблоны запихивают параметры. Создают по несколько методов с разными параметрами. А зачем так делать?
Вот пример с ИТС (17.2.2.3.2. Работа с документами):
Видно, что создано два Шаблона с методом Get, но по большому счету отличаются они только тем, что один ищет по номеру документ, а второй выводит все.
Все это можно реализовать одним методом, список или документ подавать в параметр ИмяМетода, а дополнительными параметрами передавать номер. А давайте сделаем!
Добавляем метод GET.
Берем код из примера ИТС.
17.2.2.3.2. Работа с документами (Тестовый пример)
Функция СписокGET(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
Результат = "Расходная накладная, 1, 01.01.2014
|Расходная накладная, 2, 01.01.2014";
Ответ.УстановитьТелоИзСтроки(Результат);
Возврат Ответ;
КонецФункции
Функция ДокументGET(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
Номер = Число(Запрос.ПараметрыURL.Получить("number"));
Если Номер > 2 Тогда
Ответ.КодСостояния = 404;
Ответ.УстановитьТелоИзСтроки("Отсутствует документ с номером: " + Номер);
Иначе
Если Номер=1 Тогда
Ответ.УстановитьТелоИзСтроки("Расходная накладная, 1, 01.01.2014");
Иначе
Ответ.УстановитьТелоИзСтроки("Расходная накладная, 2, 01.01.2014");
КонецЕсли;
КонецЕсли;
Возврат Ответ;
КонецФункции
Видоизменяем его и добавляем код обработки метода:
Функция PrettyAPIGET(Запрос)
Ответ = Новый HTTPСервисОтвет(200);
ИмяМетода = Запрос.ПараметрыURL.Получить("ИмяМетода");
Если ИмяМетода = "Список" Тогда
Результат = "Расходная накладная, 1, 01.01.2014
|Расходная накладная, 2, 01.01.2014";
ИначеЕсли ИмяМетода = "Документ" Тогда
//ПраметрыЗапроса - number
ПарНомер = Запрос.ПараметрыЗапроса.Получить("number");
Номер = Число(?(ПарНомер=Неопределено,0,ПарНомер));
Если Номер > 2 Тогда
Ответ.КодСостояния = 404;
Результат = "Отсутствует документ с номером: " + Номер;
Иначе
Если Номер = 1 Тогда
Результат = "Расходная накладная, 1, 01.01.2014";
Иначе
Результат = "Расходная накладная, 2, 01.01.2014";
КонецЕсли;
КонецЕсли;
Иначе
Ответ.КодСостояния = 405;
Результат = "Отсутствует Метод " + ИмяМетода;
КонецЕсли;
Ответ.УстановитьТелоИзСтроки(Результат,КодировкаТекста.UTF8);
//Ответ.Заголовки.Вставить("Content-Type","text/html; charset=utf-8");
Возврат Ответ;
КонецФункции
Выполняем публикацию нашего сервиса:
Проверяем результат:
1 Получим список. Запрос: http://127.0.0.1/DemoEnterprise2_4_3_145/hs/PrettyAPI/V1/Список
Результат:
Получаем какие-то «кракозябры»! Первый раз я нарвался на этот момент с кодировкой около 4-х лет назад, ну и так как на ИТС пример как раз приводит к этому, решил показать и рассказать, как исправить.
Вы обратили внимание, что в коде функции PrettyAPIGET я оставил в самом конце закомментированную строку
//Ответ.Заголовки.Вставить(«Content—Type«,»text/html; charset=utf-8″);
Разкомментируем ее и проверим, как теперь отработает наш сервис.
2 Получим документ с номером 1. Запрос: http://127.0.0.1/DemoEnterprise2_4_3_145/hs/PrettyAPI/V1/Документ?number=1
Результат:
Важно: Хотелось бы обратить внимание на коды состояния из примера выше. Мне раза три в моей практике попадались API, которые всегда возвращали ответ с кодом 200 (200 OK («хорошо»)) и только в теле ответа, можно было понять, была ли ошибка. Это грубейшая ошибка разработчиков! Ну или это неуважение к конечному потребителю…
Передавая ответ, не забывайте про коды состояния (Список кодов состояния)!
Вот тут хороший пример по работе с ответом в зависимости от кода состояния, обратите внимание на ошибку с кодами 3XX.
Как Вы видите, мы обошлись одним Шаблоном для той же задачи. По сути можно сделать некий универсальный каркас для HTTP-метода и решать любую задачу Интеграции.
Давайте разобьем все возможные сервисы на блоки, чтобы понять, как сделать некое универсальное решение.
Сервис выполняет следующие действия:
- Получение входящих параметров и проверка их корректности
- Выполнение основных действий
- Формирование ответа
Если посмотреть пример выше, то понимаем, что все идет в вперемешку, не структурированно. Отлаживать такой сервис не очень приятно!
Я предпочитаю для HTTP-методов создавать отдельные модули и «Выполнение основных действий» осуществлять в созданном модуле. Создание отдельного модуля позволяет отлаживать HTTP-сервис через внешнюю обработку, это бывает необходимо при получении ошибки, которая говорит, что в коде есть ошибка, но отладка по HTTP не останавливается на точке остановы. Давайте «причешем» пример выше.
Создадим модуль и переделаем «получение параметров» и «формирование ответа».
Функция PrettyAPIGET(Запрос)
СтруктураВхПараметров = Новый Структура;
//Получаем имя метода
перИмяМетода = Запрос.ПараметрыURL["ИмяМетода"];
//Помещаем имя метода в структуру
СтруктураВхПараметров.Вставить("ИмяМетода",перИмяМетода);
//Забираем параметры из запроса
ВхПараметрыЗапроса = Новый Соответствие;
Для каждого Параметр Из Запрос.ПараметрыЗапроса Цикл
ВхПараметрыЗапроса.Вставить(Параметр.Ключ,Параметр.Значение);
КонецЦикла;
СтруктураВхПараметров.Вставить("ПараметрыЗапроса",ВхПараметрыЗапроса);
//Передаем входящие параметры (Модуль для метода GET)
СтруктураОтвет = PAPI_ОбработкаМетодовGET.PAPI_ОбработкаМетодовGET(СтруктураВхПараметров);
//Создаем ответ с кодом состояния
Ответ = Новый HTTPСервисОтвет(СтруктураОтвет.КодОтвета);
Если СтруктураОтвет.Отработало Тогда
Ответ.УстановитьТелоИзСтроки(СтруктураОтвет.ДанныеОтвета,КодировкаТекста.UTF8);
Иначе
Ответ.УстановитьТелоИзСтроки(СтруктураОтвет.ТекстОшибки,КодировкаТекста.UTF8);
КонецЕсли;
Ответ.Заголовки.Вставить("Content-Type","text/html; charset=utf-8");
Возврат Ответ;
КонецФункции
Модуль PAPI_ОбработкаМетодовGET
//Функция экспортная, специально чтобы можно было отлаживать как по HTTP(https://its.1c.ru/db/metod8dev#content:5756:hdoc)
//Так и через внешнюю обработку
Функция PAPI_ОбработкаМетодовGET(СтруктураВхПараметров) Экспорт
//структура ответа. Собственна нужна для формирования ответа
СтруктураОтвет = Новый Структура("ДанныеОтвета,Отработало,ТекстОшибки,КодОтвета","",Истина,"",200);
//Переправляем на нужный метод
Если ВРег(СтруктураВхПараметров.ИмяМетода) = ВРег("Список") Тогда
ПолучитьСписок(СтруктураОтвет,СтруктураВхПараметров);
ИначеЕсли ВРег(СтруктураВхПараметров.ИмяМетода) = ВРег("Документ") Тогда
ПолучитьДокумент(СтруктураОтвет,СтруктураВхПараметров);
Иначе
ЗаполнитьСтруктуруОтвета(СтруктураОтвет,405,"Отсутствует Метод " + ?(СтруктураВхПараметров.ИмяМетода=Неопределено,"",СтруктураВхПараметров.ИмяМетода),ложь,"");
КонецЕсли;
Возврат СтруктураОтвет;
КонецФункции
//Заполняем структуру ответа
Процедура ЗаполнитьСтруктуруОтвета(СтруктураОтвет,КодОтвета,ТекстОшибки,Отработало,ДанныеОтвета)
СтруктураОтвет.КодОтвета = КодОтвета;
СтруктураОтвет.ТекстОшибки = ТекстОшибки;
СтруктураОтвет.Отработало = Отработало;
СтруктураОтвет.ДанныеОтвета = ДанныеОтвета;
КонецПроцедуры
//МЕТОДЫ
Процедура ПолучитьСписок(СтруктураОтвет,СтруктураВхПараметров)
Результат = "Расходная накладная, 1, 01.01.2014
|Расходная накладная, 2, 01.01.2014";
СтруктураОтвет.ДанныеОтвета = Результат;
КонецПроцедуры
Процедура ПолучитьДокумент(СтруктураОтвет,СтруктураВхПараметров)
//ПраметрыЗапроса - number
ПарНомер = СтруктураВхПараметров.ПараметрыЗапроса.Получить("number");
Номер = Число(?(ПарНомер=Неопределено,0,ПарНомер));
Если Номер > 2 Тогда
ЗаполнитьСтруктуруОтвета(СтруктураОтвет,404,"Отсутствует документ с номером: " + Номер,ложь,"");
Иначе
Если Номер = 1 Тогда
Результат = "Расходная накладная, 1, 01.01.2014";
Иначе
Результат = "Расходная накладная, 2, 01.01.2014";
КонецЕсли;
СтруктураОтвет.ДанныеОтвета = Результат;
КонецЕсли;
КонецПроцедуры
Как вы видите, размер кода увеличился, но стало гораздо проще добавлять новые методы.
Нужно просто добавить в проверку (PAPI_ОбработкаМетодовGET.PAPI_ОбработкаМетодовGET) новое имя метода и процедуру для этого метода.
По отладке HTTP-сервисов рекомендую статью с ИТС (https://its.1c.ru/db/metod8dev#content:5756:hdoc)
Первую часть заканчиваю. Мы рассмотрели с Вами как создать каркас для Get метода. В следующих частях поговорим про другие методы, про oData и JSON. Как и в этой статье будут примеры, но более интересные.
Статьи из данного цикла:
HTTP Сервисы: Путь к своему сервису. Часть 2
HTTP Сервисы: Путь к своему сервису. Часть 3
HTTP Сервисы: Путь к своему сервису. Часть 4
5 / 5 / 5
Регистрация: 17.12.2013
Сообщений: 200
1
07.06.2016, 12:43. Показов 10264. Ответов 3
Добрый день
Есть запрос, который хотим отправлять через http
Кликните здесь для просмотра всего текста
1C | ||
|
При выполнении получаю ошибку
Invoke-RestMethod : Bad Request — Invalid URL
HTTP Error 400. The request URL is invalid.
В чем может быть ошибка?
Добавлено через 3 минуты
Также пробуем вместо двойных кавычек использовать !!! и вместо запятых %%%,
Кликните здесь для просмотра всего текста
1C | ||
|
, но результат такой же
0
Я уже как-то писал о муках разработки web service (веб сервисов) на C# (.NET) для 1С. Продолжаем разбираться с проблемами.
При разработке веб сервиса на C# под MS Visual Studio для 1С 8.2 столкнулись с невразумительной ошибкой. В качестве сервера — Microsoft-IIS/8.5. Поиск решения занял немало времени. 🙁 Но обо всем по порядку.
Название вызываемого метода веб сервиса — BarcodeFontIsInstalled. В качестве единственного аргумента передается строка. Ошибка выглядит так:
{Форма.Форма.Форма(22)}: Ошибка при вызове метода контекста (BarcodeFontIsInstalled)
НоваяСтрока = Прокси.BarcodeFontIsInstalled(WSПараметр);
по причине:
http://tempuri.org/Ошибка вызова операции сервиса: {
}:BarcodeWebService:BarcodeFontIsInstalled()
по причине:
Неизвестная ошибка. Ошибка разбора XML: - [1,1]
Фатальная ошибка:
Extra content at the end of the document
по причине:
Ошибка разбора XML: - [1,1]
Она ни о чем не говорит, поскольку 1С безбожно переврала то, что вернул IIS.
Обращение из 1С к web service (веб сервису)
Вызов метода из 1С производился как описано в статье. Код веб сервиса в C#:
using
System.Web;
using
System.Web.Services;
using
System.Xml.Serialization;
namespace
BarcodeWebService
{
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
[System.ComponentModel.ToolboxItem(
false
)]
public
class
BarcodeWebService : System.Web.Services.WebService
{
[WebMethod]
public
bool
BarcodeFontIsInstalled(
string
fontName)
{
return
BarcodeUtils.IsFontInstalled(fontName);
}
}
}
Замечу, что вызов проходил через BarcodeWebServiceSoap — т.е. SOAP версии 1.1. BarcodeWebServiceSoap12 — соотвественно для работы через SOAP 1.2. 1C действительно меняет обращение к сервису, если вместо BarcodeWebServiceSoap указать BarcodeWebServiceSoap12, проверено опытным путем. 🙂
Вызов в 1С выглядел таким образом:
Прокси = WSСсылки.WSBarcodeService.СоздатьWSПрокси(
http://tempuri.org/"
"
,
"BarcodeWebService"
,
"BarcodeWebServiceSoap"
);
ТипWSПараметра = Прокси.ФабрикаXDTO.Пакеты.Получить(
http://tempuri.org/"
"
).Получить(
"BarcodeFontIsInstalled"
);
WSПараметр = Прокси.ФабрикаXDTO.Создать(ТипWSПараметра);
WSПараметр.fontName =
"Code 128"
;
НоваяСтрока = Прокси.BarcodeFontIsInstalled(WSПараметр);
Все делаем «по учебнику» но так не работает. 🙁
Отладка обращений 1С к web service (веб сервису)
Поскольку в 1С не понятно как отлаживать что-то в части работы с веб-сервисами, обращаемся за помощью к Fiddler, который покажет как-же 1С обращается к разработанному на C# web service:
Бросается в глаза странный кусок XML:
Зачем 1С сгенерировал для такого простого аргумента такую вложенную иерархию fontName не понятно. Ответ веб сервиса (MS IIS) на такую конструкцию:
HTTP/1.1 400 Bad Request
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 14 Oct 2015 10:19:14 GMT
Content-Length: 0
Как видно по ответу, ошибка выдаваемая 1С рядом не лежала с тем, что на самом деле вернул IIS, а он вообще не вернул XML, сообщив, что запрос «кривой» (HTTP/1.1 400 Bad Request).
Чтобы узнать какой request должен быть, пишем пару строк на C#:
BarcodeWebService.BarcodeWebService svc =
new
BarcodeWebService.BarcodeWebService();
checkBox1.Checked = svc.BarcodeFontIsInstalled(
"Code 128"
);
и запустив Fiddler видим какой простой и красивый request получается:
Расстраиваемся, поскольку ситуация выглядит тупиковой, но пытаемся найти решение.
Перехват обращений из 1С к web service (веб сервису) cbr.ru
Обратимся к исходной статье и посмотрим как выглядит request к web service (веб сервису) www.cbr.ru. Код 1С описан в статье, а request будет таким:
В данном случае все красиво, как при обращении из кода C#:
CBRWebService.DailyInfo info =
new
CBRWebService.DailyInfo();
DataSet ds = info.GetCursOnDate(DateTime.Now);
Разбираться в WSDL, который генерирует веб сервис «Центробанка» и разработанный мною на .NET — дело неблагодарное, тем более, что даже поняв ошибку в генерации 1С request к внешнему веб сервису, повлиять на это нельзя, нужно ждать обновления платформы. Чтобы проверить одну мысль я сделал простой метод в веб сервисе:
[WebMethod]
public
DateTime Checker(DateTime date)
{
return
date;
}
У меня была мысль, что проблема связана с тем, что string аргумент может быть null, соответственно, в WSDL minOccurs=»0″, в отличие от DateTime (который передавался cbr.ru методу GetCursOnDate), для которого minOccurs=»1″ . Однако, даже для такого варианта 1С сформировал столь же «кривой» запрос, т.е. дело не в этом.
Решение
Поиск решения заняло немало времени, как обычно, оно оказалось очень простым. Спасибо моим 1С разработчикам с которыми мы вымучивали столь красивое и столь многострадальное решение. 🙂
Итак, фанфары, рабочий код на 1С при обращении к внешнему веб сервису (web service) написанному на C# (.NET) и работающему под IIS выглядит следующим образом:
Прокси = WSСсылки.WSBarcodeService.СоздатьWSПрокси(
http://tempuri.org/"
"
,
"BarcodeWebService"
,
"BarcodeWebServiceSoap"
);
Результат = Прокси.BarcodeFontIsInstalled(
"Code 128"
);
И это всё! 🙂 Предельно кратко и очень похоже на обращение к web service в C#. В этом случае перехваченный Fiddler-ом запрос 1С к веб сервису выглядит следующим образом:
При таком вызове web service (веб сервис) возвращает корректное значение. Ошибка исчезла. В качестве аргумента в метод веб сервиса из 1С передавали бинарные данные (фотографии), массивы, ну и простые типы, вроде даты, строки и пр.
Полезные ссылки
- Fiddler — перехват http траффика для анализа обмена данными
- WireShark — мощный сниффер для перехвата и анализа различных протоколов переадчи данных.
Ошибка «Неправильный запрос» при работе с опубликованной на IIS базы 1С 8.2/8.3
Опубликовал fora-4a в раздел Администрирование — Системное
При работе с базой 1С:БП 3.0, опубликованной на IIS 7, в момент проведения документов или открытия элементов справочников возникает ошибка «Неправильный запрос».
В данной статье опишу решение, которое помогло лично мне.
Конкретно в моем случае данная ошибка проявлялась:
1. При проведении документов «Авансовый отчет» (причем нерегулярно);
2. При попытке открыть элемент справочника «Контрагенты» (регулярно);
При работе с базой через WEB-клиента — ошибка выглядит так:
Выяснилось следующее — при авторизации возникает ошибка 400–Bad Request.
Решение оказалось достаточно простым — по умолчанию сервер IIS 7 не отдает полный код ошибки для удаленных запросов.
1. Необходимо в пункте меню «Страницы ошибок»
2. «Изменить параметры»
3. поставить значение «Подробные сообщение об ошибках»
После проделанных процедур со стороны сервера IIS ошибка пропала.
По материалам http://infostart.ru/public/337413/
Так же для Вашего бизнеса может понадобиться:
- Обслуживание компьютеров
- Сервер для небольшого офиса
- Компьютеры, ноутбуки, оргтехника
- Локальные сети
- Системы IP видеонаблюдения
Если Вы хотите получить консультацию, воспользоваться услугами специалиста по 1С, пожалуйста обращайтесь:
- звоните по телефону +7-812-385-55-66 в Санкт-Петербурге
- пишите на адрес office@statusspb.com
- оставляйте заявку у нас на сайте на странице «Онлайн заявка» /on-line-zayavka
При публикации баз 1С для работы через web-клиент, которые были развернуты на IIS7.5 ОС Windows 2008R2 может возникнуть ошибка следующего характера: «Неправильный запрос» (см. рис.)
Данная проблема была воспроизведена на конфигурациях БП 3.0
и УТ 11. При более детальном изучении проблемы было выяснено что, при
авторизации возникает ошибка 400 –Bad Request. Причем проблема
не возникает при подключении с того же сервера, где установлен IIS.
Решение оказалось очень простым — по умолчанию сервер IIS 7.5 не отдает полный код ошибки для
удаленных запросов. Соответственно необходимо в пункте меню «Страницы ошибок»-
«Изменить параметры» поставить значение «Подробные сообщение об ошибках». После
чего ошибка в 1С исчезнет.
Денис Григорьев
Рассмотрим вопрос по публикации баз 1С на IIS. Есть что сказать по настройке. Потому как регулярно возникают похожие вопросы. Например, ошибка «0x800700c1» в IsapiModule или «HTTP 500.0 Internal Server Error».
Общие моменты
1. Состав компонентов IIS — в Интернете полно инструкций и указаний. Повторяться не будем.
2. Установка 1С необходимой разрядности. Варианта 2: x86 (32-разрядное приложение) или x64. Обязательно выбираем «Модули расширения веб-сервера».
3. Права для встроенной группы веб-сервера (IUSR) на папки:
- с установленной платформой (для старта процессов);
- самих расположений ИБ (в случае файлового варианта).
4. Публикация базы через Конфигуратор 1С. Возможно потребуется открыть программу с повышенными правами — «Запуск от имени администратора».
5. Для 32-разрядного клиента 1С в диспетчере IIS включаем разрешение запуска (DefaultAppPool — Дополнительные параметры — Разрешены 32-разрядные приложения = True). Для 1C x64 — значение не меняем.
6. На странице сопоставления обработчиков для «1С Web-service Extension» потребуется указать путь к исполняемому модулю:
- x86 — «C:\Program Files (x86)\1cv8\8.3.x.xx\bin\wsisapi.dll»;
- x64 — «C:\Program Files\1cv8\8.3.x.xx\bin\wsisapi.dll».
Либо изменяем путь к библиотеке в файлах web.config через Блокнот (располагается, как правило, в c:\inetpub\wwwroot\<имя базы>).
Если в п. 2 все сделано правильно — по указанному пути должен присутствовать файл wsisapi.dll.
7. В некоторых случаях потребуется перезапуск служб IIS. Выполните «Перезапустить» в оснастке управления или перезагрузите сервер.
Соблюдаем соответствие разрядности: если запускаем и публикуем 64-разрядный клиент 1С:Предприятие, то dll также должна быть 64-битной версии.
Если публикуем 32-разрядную версию 1С, то ставим разрешение запуска 32-разрядных приложений на IIS и проверяем путь к wsisapi из каталога x86.
Ищете подробное описание? Обратите внимание на статьи:
- Публикация баз 1С на веб-сервере IIS и возможные ошибки;
- Установка веб-сервера IIS на Windows 10 Pro для 1С.
Использование веб-сервера и публикаций информационных баз — один из способов оптимизации 1С. Особенно при работе с ИБ в файловом варианте. Так безопаснее. Сотрудники подключаются к ИБ 1С через браузер или тонкий клиент, не имея прямого доступа к файлам.
В статье расскажем, как решали возникающие вопросы по настройкам Internet Information Services. Через призму своего опыта и коллег.
Как правило, ошибки повторяются. Например, ошибка 0x800700c1 в IsapiModule или HTTP 500.0 Internal Server Error.
I. Как перевести опубликованные базы 1С на HTTPS-протокол
Подробнее описано здесь. В проекте использовали бесплатный SSL-сертификат Let’s Encrypt. Но поспешили отключить внешние соединения на 80-й порт — что было ошибкой.
Сертификат выдается сроком на 90 дней. Для автоматического продления создается периодическое задание в Планировщике. При запуске задачи сайт должен быть доступен (пройти проверку домена) по 80-му порту.
Вопрос решили установкой переадресации на 443-й порт средствами IIS (301-й редирект с http на https). Использовали стандартный модуль URL Rewrite. Запросы http автоматически перенаправляются сайтом на защищенный https.
II. Типовая настройка и публикация информационных баз на IIS
На что обратить внимание:
1. Состав компонентов IIS — в Интернете полно инструкций и указаний. Повторяться не будем.
2. Установка 1С необходимой разрядности. Варианта 2: x86 (32-разрядное приложение) или x64. Обязательно выбираем «Модули расширения веб-сервера».
Установка модулей расширения веб-сервера
3. Права для встроенной группы/пользователю веб-сервера (IUSR) на папки:
- с установленной платформой — на «чтение и выполнение» (для старта процессов);
- самих расположений ИБ — на «изменение» (в случае файлового варианта).
4. Публикация базы через Конфигуратор 1С. Возможно потребуется открыть программу с повышенными правами — «Запуск от имени администратора».
5. Для 32-разрядного клиента 1С в диспетчере IIS включаем разрешение запуска (DefaultAppPool — Дополнительные параметры — Разрешены 32-разрядные приложения = True). Для 1C x64 — значение не меняем.
6. На странице сопоставления обработчиков для «1С Web-service Extension» потребуется указать путь к исполняемому модулю:
- x86 — «C:\Program Files (x86)\1cv8\8.3.x.xx\bin\wsisapi.dll»;
- x64 — «C:\Program Files\1cv8\8.3.x.xx\bin\wsisapi.dll».
Либо изменяем путь к библиотеке в файлах web.config через Блокнот (располагается, как правило, в c:\inetpub\wwwroot\<имя базы>).
Если в п. 2 все сделано правильно — по указанному пути должен присутствовать файл wsisapi.dll.
7. В частных случаях требуется перезапуск служб IIS. Выполните «Перезапустить» в оснастке управления или перезагрузите сервер.
✅ Соблюдаем соответствие разрядности: если запускаем и публикуем 64-разрядный клиент 1С:Предприятие, то dll также должна быть 64-битной версии.
Если публикуем 32-разрядную версию 1С, то ставим разрешение запуска 32-разрядных приложений на IIS и проверяем путь к wsisapi из каталога x86.
Пример с более подробным описанием — установка веб-сервера IIS на Windows 10 Pro для 1С.
III. Если клиент 1С зависает при подключении к базе по web
Прежде посмотрите этот материал — там общие рекомендации.
Другой случай. Файловая ИБ опубликована на IIS. После авторизации зависает на эмблеме 1С. При открытии Конфигуратора — все нормально.
В журналах Windows ошибка «Процесс, обслуживающий пул приложений «1С», не ответил на команду ping».
Что посмотреть:
- проверьте права на папку с базой 1С для IUSR/IIS_IUSRS, уровень доступа — на «изменение»;
- в оснастке IIS «Пулы приложений — <пул_1С> — Дополнительные параметры — Модель процесса» задайте для «Максимальная задержка отклика при проверке связи» значение, превышающее 90 секунд;
- посмотрите на поведение IIS при «Проверка связи включена» = False.
? Из справки: установка [pingingEnabled] (Проверка связи) в значение false не позволит IIS проверять, выполняется ли рабочий процесс, и таким образом сохранит его активным до остановки процесса отладки.
✅ Установка «Максимальное время отклика пинга» в большое значение позволит IIS продолжать наблюдение за рабочим процессом.
IV. Ошибка сервера в приложении ‘/AO_SSR’
Информационная база 1C опубликована на IIS. При работе через тонкий клиент, при нажатии на «Отчеты» вываливается ошибка.
«Ошибка сервера в приложении ‘/AO_SSR’. Обнаружено потенциально опасное значение Request.Path, полученное от клиента.
Описание: Необработанное исключение при выполнении текущего веб-запроса. Изучите трассировку стека для получения дополнительных сведений о данной ошибке и о вызвавшем ее фрагменте кода.
Сведения об исключении: System. Web. HttpException».
✅ Откройте настройки пула приложений и проверьте «Режим управляемого конвейера» = «Classic».
Диспетчер служб IIS — Пулы приложений — DefaultAppPool — Дополнительные параметры — Общие ↴
Настройка режима управляемого конвейера
V. Работа IIS с разными релизами платформ 1С
Частный вариант. Установлены два сервера 1С версий 8.3.16 и 8.3.18 (на разных диапазонах портов). Есть опубликованная база на 8.3.16, а также база на 8.3.18.
При этом база на 8.3.16 доступна, а на 8.3.18 появляется ошибка «HTTP 500.0 — Internal Server Error».
Если перезапустить службы IIS, то получается наоборот. База на 8.3.18 становится доступной, а на 8.3.16 — с той же ошибкой. И так по кругу.
✅ Возможный выход — разнесение публикаций на разные пулы приложений через оснастку управления IIS.
VI. Подробнее об ошибке HTTP 500.0
В первую очередь смотрим официальную статью Microsoft и рекомендации по дополнительному коду HResult. Например, по 0x800700c1 сообщается следующее.
0x800700c1 — «Сопоставление сценария является не допустимым»
Далее плавно переходим в пункт «II. Типовая настройка и публикация информационных баз на IIS» и проверяем сопоставление обработчиков.
✅ Если требуется одновременная поддержка 32 и 64-битных версий 1С, то добавьте в конфигурацию IIS дополнительный пул (например, DefaultAppPool32), включив у него поддержку 32-битных приложений.
У всех 32-битных публикаций в основных настройках web-сервера выберите этот пул приложений. У 64-битных публикаций — оставьте пул приложений DefaultAppPool (по умолчанию), у которого поддержка 32-битных приложений отключена.