1с линк ошибка 405

“1C:Link” tunnel is closed!

Please ensure that:

1. you have active «1C:ITS» support contract;
2. your products are registered at ITS Portal;
3. PC with «1C:Link» agent is powered on;
4. Agent is installed to the path with ASCII characters only;
5. Agent setup is complete (auth. keys are installed and tunnel is opened);
6. Antivirus or firewall are not blocking Agent components.

Try to reboot PC with «1C:Link» Agent, temporarily disable antivirus & firewall, reinstall Agent via User’s manual.

If it didn’t help, please contact us via support@1c.link and provide:

1. link-agent.log file;
2. type of published infobases (file-based, client-server);
3. «System information» diagnostic file about PC with «1C:Link» agent.

Туннель “1С: Линк” закрыт!

Проверьте, что:

1. у вас не закончился договор сопровождения “1С: ИТС”;
2. ваши программные продукты зарегистрированы на портале Информационно-технологического сопровождения;
3. компьютер с Агентом “1С: Линк” включен;
4. Агент запущен из папки, в полном пути которой не содержится кириллических символов;
5. в Агенте установлены ключи авторизации и открыт туннель;
6. антивирус или брандмауэр не блокируют запуск компонентов Агента.

Попробуйте перезагрузить компьютер с линк-агентом, временно отключите антивирус и брандмауэр, переустановите Агент согласно руководству пользователя.

Источник

В результате POST запроса КодСостояния=405

Комрады! Направьте в нужную сторону с POST запросом к API с авторизацией по ключу.
Исходные данные: https://ekfgroup.com/podderzhka/download раздел «API для партнеров»

APIKey = ПолученныйПоEmailКлюч;
Соединение = Новый HTTPСоединение(«ekfgroup.com». Новый ЗащищенноеСоединениеOpenSSL());
Заголовки = Новый Соответствие;
Заголовки.Вставить(«Authorization», «Bearer «+APIKey);
Заголовки.Вставить(«Accept-Language», «ru»);
Заголовки.Вставить(«Accept-Charset», «utf-8»);
Заголовки.Вставить(«Content-Language», «ru»);
Заголовки.Вставить(«Content-Charset», «utf-8»);
Заголовки.Вставить(«Content-type», «application/x-www-form-urlencoded; charset=utf-8»);
Запрос = Новый HTTPЗапрос(«/api/1/ekf/catalog/files», Заголовки);
Запрос.УстановитьТелоИзСтроки(«vendorCode=mcb4763-1-01C-pro»,КодировкаТекста.UTF8);
Результат = Соединение.ОтправитьДляОбработки(Запрос);

Соответственно, Результат.КодСостояния = 405, данные не загружаются.
Как победить?

(5) 405: Method Not Allowed
Выполнение метода, определенного в запросе, не разрешено для ресурса, идентифицированного конкретным адресом. Ответ должен содержать Allow заголовок, со списком разрешенных методов для запрашиваемого ресурса.

Не к тому ресурсу обращаюсь раз поддерживается только GET, HEAD?

Источник

Ошибка сервера 405 Method Not Allowed: что за ошибка и как ее исправить

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

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

В этом материале речь пойдет об ошибке 405 Method Not Allowed. В деталях опишу проблему и расскажу, как ее побороть.

Что означает код ошибки сервера 405?

Код 405 Method Not Allowed говорит нам о том, что сервер получил определенный запрос с заданным HTTP-методом, смог его распознать, но не дает добро на его реализацию. То есть пользователь не получит доступ к контенту, который запросил.

В отличие от 404, 405 уточняет, что запрашиваемая страница существует и функционирует. Только вот стоит изменить используемый в HTTP-запросе метод. Иначе ничего не выйдет.

Из-за чего я вижу эту ошибку?

Есть 9 HTTP-методов, которые используются браузерами для общения с серверами. Из них два задействуются чаще остальных. Это метод GET для запроса информации с ресурса и метод POST для передачи какой-нибудь информации на ресурс. Два метода покрывают почти все существующие сценарии взаимодействия клиента и сервера от запроса статьи до отправки логина и пароля на сайт. Так как они выполняют разные задачи, для сервера нет никакой нужды принимать GET для авторизации на сайте или POST для загрузки данных. Если же клиент так делает и отправляет некорректный запрос (не с тем методом, который должен быть), то сервер ответит ему ошибкой. То же произойдет, если ресурс будет настроен так, что не сможет принимать специфичный набор запросов, не попадающих в «стандарт». Такие дела.

Как исправить 405 Method Not Allowed?

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

Что может сделать пользователь?

Ошибка Method Not Allowed под номером 4хх вроде бы говорит о вине клиента. Но несмотря на это, пользователь мало что может сделать, чтобы устранить проблему. В его компетенции только убедиться в том, что он не допустил ошибку в базовых вещах, и попробовать повторить те же действия в надежде на успех.

Заново открыть ту же страницу

Иногда 405 Method Not Allowed может исчезнуть после перезагрузки страницы. Так что перед тем как принимать сложные решения и жаловаться на владельцев сайта, нажмите F5 или Cmd + R раза два.

Проверить, правильно ли он ввел URL-адрес

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

Так что пользователю стоит заглянуть в адресную строку браузера и убедиться в корректности введенной ссылки. Если что-то нет так, то лучше открыть главную страницу сайта и искать нужную информацию там, а не пытаться попасть на нее, вводя адрес вручную.

Что может сделать владелец сайта?

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

Проверить настройки сервера

Тут будут инструкции для владельцев сайтов на базе Apache и Nginx в Timeweb. Понятно, что есть другие варианты конфигураций, но эти два — чуть ли стандарт, использующийся повсеместно. А информация, касающаяся конкретно Timeweb, заденет только расположение файлов и работу с панелью управления хостинга. Остальные моменты универсальны.

Инструкция для пользователей Apache

Наша задача состоит в том, чтобы в файле .htaccess найти записи, которые могут провоцировать появление ошибки 405. А потом их закомментировать или удалить. Чтобы это сделать:

• Открываем панель управления Timeweb.
• Ищем внутри вкладку «Файловая система» и переходим на нее.
• Открываем файл .htaccess.
• Внутри .htaccess ищем директивы Rewrite… (обычно это RewriteEngine, RewriteCond и RewriteRule).

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

За появление ошибки отвечает запись [R=405,L]. То есть в настройках указано, как себя будет вести сервер при определенном запросе. Надо найти все такие директивы и закомментировать их, поставив # перед записью.

Инструкция для пользователей Nginx

Здесь нужно сделать примерно то же. Разница в том, как выглядит файл с настройками и в его расположении.

• Ищем файл nginx.conf по пути /usr/local/nginx/conf или /usr/local/etc/nginx .
• Открываем его любым текстовым редактором.
• Находим код, включающий в себя упоминание ошибки 405.

В Nginx код выглядит немного сложнее. Например, запрос метода для ссылки https://moysait.com/ru/services/create будет выглядеть так:

Делаем ту же процедуру. Останавливаемся везде, где находим директиву с ошибкой 405. Анализируем ее (вдруг, она тут случайно). И при необходимости комментируем или удаляем.

Исправить проблемы, связанные с PHP-скриптами

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

Обойти ограничение можно тремя путями:

• Попробовать экспортировать БД через phpMyAdmin.
• Разбить файл БД на несколько мелких частей, передача каждого из которых займет меньше 30 секунд.
• Использовать для передачи БД Cron-задачу. На них сервер выделяет больше времени.

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

Исправить эксклюзивные для Nginx ошибки

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

Первый вариант — убедить сервер в том, что вместо кода 405 надо отправлять код 200, и это вполне нормально:

Для тех, у кого Nginx-сервер — это proxy, понадобится вот такой код:

Аналогичная ошибка возникает при работе с модулем FastCGI. Из-за него сервер неправильно считывает запросы с методом POST, поэтому необходимо делить параметры и адрес скрипта вот так:

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

Проанализировать все недавние изменения в коде

Если недавно что-то поменяли, а после этого все сломалось, то надо это «поменяли» рассмотреть подробнее. Провести ручной дебаггинг, если можно это так назвать. Наверняка где-то затесалась несерьезная, но обидная ошибка.

Удалить сторонние дополнения для CMS

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

Так что при подозрении на наличие сбойного дополнения, лучше попробовать от него избавиться и посмотреть, что будет. Возможно, ошибка исчезнет.

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

Главное, не забудьте сделать резервную копию CMS перед тем, как что-то удалять и менять. И продолжайте делать бэкапы после, чтобы всегда можно было восстановить рабочую версию сайта.

Откатиться на более старую версию CMS

Бывает так, что сама CMS несет в себе баги и ошибки. Ну или криво установилась. В таком случае можно восстановиться из старой резервной копии и откатиться на одну или несколько версий в прошлое. Когда все работало без ошибок.

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

Расширения могут вносить изменения в базу данных сайта. Иногда не очень полезные. Надо проверить, не появилось ли после установки свежего дополнения каких-либо непрошенных изменений в базе данных. Может, появились подозрительные записи, которых не должно быть. Лучше подвергнуть анализу всю БД от начала до конца (если другие методы исправления ошибки 405 не помогли, конечно).

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

Источник

Ошибка 405 или 500 в HTTP сервисе 1С

Ошибка 405 и 500 в HTTP сервисе 1С. Поиск и устранение.

Добрый день, хотел поделиться с вами результатом преодоления этих ошибок при работе с http сервисами 1С. С данной ошибкой мне пришлось столкнуться при переписывании мобильного приложения с web сервисов на http. Ошибка возникала при отправке http сервису POST запроса.

Ошибка 405

При работе с некорректным HTTP сервисом из мобильного приложения возвращалась ошибка 405, которая указывает на конкретную проблему. «405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу.» Долго не мог разобраться с данной ошибкой, так как в сервисе запрос был разрешен и шаблоны были настроены корректно.

Ошибка 500

При работе с некорректным HTTP сервисом из внешних программ возвращалась ошибка 500, которая ни о чем конкретном не говорит. «500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса».

Вроде HTTP сервис один, а при использовании запросов к нему из разных программ возвращались разные ошибки.

Расследование ошибок 405 и 500 в HTTP сервисе 1С

Времени на выяснение причин ушло очень много. За несколько дней до этой задачи мною были проведены десятки экспериментов по сборке и настройке web сервера apache 2.4 x64 SSL для работы с 1С. Все настройки в основном были связаны с кросс доменными запросами из web приложения на javascript. Столкнувшись с ошибками 405 и 500 на другом проекте я сразу полез в дебри конфигурации apache. После полного удаления apache поставил IIS и на нем вышла такая же ошибка. Поднял на виртуальной машине чистую систему, попробовал apache и iss, но ошибка так и проявлялась. Потом я вспомнил, что одна функция мобильного приложения уже давно использует http сервис и там все прекрасно работает. Создал http сервис с базовыми настройками и все заработало.

Как только я переносил код из web сервиса в функции http сервиса, сразу появлялись ошибки. Самое интересное, что отладка не срабатывала, т.е. POST запрос в пустую функцию приходил и отрабатывал, а в функцию с кодом нет.

На многих форумах ошибку 405 описывают как ошибку доступа, либо не корректную настройку http сервиса.

Итог разбора ошибок 405 и 500 в HTTP сервисе 1С.

В итоге все оказалось довольно просто. Функция, которая вызывалась внутри функции http сервиса 1с не могла быть вызвана из данного модуля. Странно, что при сохранении конфигурации никакой ошибки на вызов отсутствующей функции не было. Возможно это глюк версии платформы и будет доработан. При использовании web сервисов, даже если код внутри функции был не корректный, отладка работала. В http сервисе сразу идет возврат с ошибками 405 или 500.

P.S. В последней версии платформы ошибка 405 перестала выходить.

Обновление 12.01.2019

В процессе работы часто приходится сталкиваться с ошибками 405 и 500 в HTTP сервисах. Но проблема в 99% случаев в коде сервиса. Возможно это не явно, код вас может уводить глубоко в другие модули, но решение надо искать именно там.

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

В данный момент я начинаю с того, что отключаю вызов всех функций и процедур начиная со входа в обработчики HTTP сервиса и смотрю как проходят запросы. Если все хорошо, то я начинаю включать код небольшими кусочками и проверять работу сервиса. Данный метод не самый быстрый, но дает 100% результат.

Если у вас остались вопросы, то вы можете задать мне их в социальных сетях или оставить комментарий ниже.

Источник

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

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

В этом материале речь пойдет об ошибке 405 Method Not Allowed. В деталях опишу проблему и расскажу, как ее побороть.

Что означает код ошибки сервера 405?

Код 405 Method Not Allowed говорит нам о том, что сервер получил определенный запрос с заданным HTTP-методом, смог его распознать, но не дает добро на его реализацию. То есть пользователь не получит доступ к контенту, который запросил.

В отличие от 404, 405 уточняет, что запрашиваемая страница существует и функционирует. Только вот стоит изменить используемый в HTTP-запросе метод. Иначе ничего не выйдет. 

Из-за чего я вижу эту ошибку?

Есть 9 HTTP-методов, которые используются браузерами для общения с серверами. Из них два задействуются чаще остальных. Это метод GET для запроса информации с ресурса и метод POST для передачи какой-нибудь информации на ресурс. Два метода покрывают почти все существующие сценарии взаимодействия клиента и сервера от запроса статьи до отправки логина и пароля на сайт. Так как они выполняют разные задачи, для сервера нет никакой нужды принимать GET для авторизации на сайте или POST для загрузки данных. Если же клиент так делает и отправляет некорректный запрос (не с тем методом, который должен быть), то сервер ответит ему ошибкой. То же произойдет, если ресурс будет настроен так, что не сможет принимать специфичный набор запросов, не попадающих в «стандарт». Такие дела.

Как исправить 405 Method Not Allowed?

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

Что может сделать пользователь?

Ошибка Method Not Allowed под номером 4хх вроде бы говорит о вине клиента. Но несмотря на это, пользователь мало что может сделать, чтобы устранить проблему. В его компетенции только убедиться в том, что он не допустил ошибку в базовых вещах, и попробовать повторить те же действия в надежде на успех.

Заново открыть ту же страницу

Иногда 405 Method Not Allowed может исчезнуть после перезагрузки страницы. Так что перед тем как принимать сложные решения и жаловаться на владельцев сайта, нажмите F5 или Cmd + R раза два. 

Проверить, правильно ли он ввел URL-адрес

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

Так что пользователю стоит заглянуть в адресную строку браузера и убедиться в корректности введенной ссылки. Если что-то нет так, то лучше открыть главную страницу сайта и искать нужную информацию там, а не пытаться попасть на нее, вводя адрес вручную. 

Что может сделать владелец сайта?

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

Проверить настройки сервера

Тут будут инструкции для владельцев сайтов на базе Apache и Nginx в Timeweb. Понятно, что есть другие варианты конфигураций, но эти два — чуть ли стандарт, использующийся повсеместно. А информация, касающаяся конкретно Timeweb, заденет только расположение файлов и работу с панелью управления хостинга. Остальные моменты универсальны. 

Инструкция для пользователей Apache

Наша задача состоит в том, чтобы в файле .htaccess найти записи, которые могут провоцировать появление ошибки 405. А потом их закомментировать или удалить. Чтобы это сделать:

• Открываем панель управления Timeweb.
• Ищем внутри вкладку «Файловая система» и переходим на нее.
• Открываем файл .htaccess.
• Внутри .htaccess ищем директивы Rewrite… (обычно это RewriteEngine, RewriteCond и RewriteRule).

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

RewriteEngine on 
RewriteCond %{REQUEST_URI} ^/ru/services/?.$ 
RewriteCond %{REQUEST_METHOD} =GET 
RewriteRule ^(.)$ http://timeweb/ru/new$1 [R=405,L]

За появление ошибки отвечает запись [R=405,L]. То есть в настройках указано, как себя будет вести сервер при определенном запросе. Надо найти все такие директивы и закомментировать их, поставив # перед записью.

Инструкция для пользователей Nginx

Здесь нужно сделать примерно то же. Разница в том, как выглядит файл с настройками и в его расположении. 

• Ищем файл nginx.conf по пути /usr/local/nginx/conf или /usr/local/etc/nginx.
• Открываем его любым текстовым редактором.
• Находим код, включающий в себя упоминание ошибки 405.

В Nginx код выглядит немного сложнее. Например, запрос метода для ссылки https://moysait.com/ru/services/create будет выглядеть так:

server { listen 80; listen 443 ssl;

server_name moysait.com;

location /users/create { if ($request_method = POST) { return 405 https://moysait.com/services/create$request_uri; } } }

Делаем ту же процедуру. Останавливаемся везде, где находим директиву с ошибкой 405. Анализируем ее (вдруг, она тут случайно). И при необходимости комментируем или удаляем.

Исправить проблемы, связанные с PHP-скриптами

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

Обойти ограничение можно тремя путями:

• Попробовать экспортировать БД через phpMyAdmin.
• Разбить файл БД на несколько мелких частей, передача каждого из которых займет меньше 30 секунд.
• Использовать для передачи БД Cron-задачу. На них сервер выделяет больше времени.

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

Исправить эксклюзивные для Nginx ошибки

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

Первый вариант — убедить сервер в том, что вместо кода 405 надо отправлять код 200, и это вполне нормально:

server { 
   listen 80; 
   server_name localhost;
location / { 
   root html; 
   index index.html index.htm; } 
error_page 404 /404.html; 
  error_page 403 /403.html; 
error_page 405 =200 $uri;

…

}

Для тех, у кого Nginx-сервер — это proxy, понадобится вот такой код:

error_page 405 =200 @405; 

location @405 { root /htdocs; proxy_pass http://localhost:8080; }

Аналогичная ошибка возникает при работе с модулем FastCGI. Из-за него сервер неправильно считывает запросы с методом POST, поэтому необходимо делить параметры и адрес скрипта вот так:

location ~.php(.*) {
 fastcgi_pass 127.0.0.1:9000;
 fastcgi_split_path_info ^(.+.php)(.*)$;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
 fastcgi_param PATH_INFO $fastcgi_path_info;
 fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
 include /etc/nginx/fastcgi_params;
}

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

Проанализировать все недавние изменения в коде

Если недавно что-то поменяли, а после этого все сломалось, то надо это «поменяли» рассмотреть подробнее. Провести ручной дебаггинг, если можно это так назвать. Наверняка где-то затесалась несерьезная, но обидная ошибка. 

Удалить сторонние дополнения для CMS

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

Так что при подозрении на наличие сбойного дополнения, лучше попробовать от него избавиться и посмотреть, что будет. Возможно, ошибка исчезнет. 

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

Главное, не забудьте сделать резервную копию CMS перед тем, как что-то удалять и менять. И продолжайте делать бэкапы после, чтобы всегда можно было восстановить рабочую версию сайта.

Откатиться на более старую версию CMS

Бывает так, что сама CMS несет в себе баги и ошибки. Ну или криво установилась. В таком случае можно восстановиться из старой резервной копии и откатиться на одну или несколько версий в прошлое. Когда все работало без ошибок.

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

Расширения могут вносить изменения в базу данных сайта. Иногда не очень полезные. Надо проверить, не появилось ли после установки свежего дополнения каких-либо непрошенных изменений в базе данных. Может, появились подозрительные записи, которых не должно быть. Лучше подвергнуть анализу всю БД от начала до конца (если другие методы исправления ошибки 405 не помогли, конечно).

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

При программировании http-сервиса в 1С Предприятии 8.3 в случае появления ошибки

HTTP Error 405.0 — Method not allowed

The page you are looking for cannot be displayed because an invalid method (HTTP verb) is being used

убедитесь, что Вы не забыли добавить обработчик метода GET (или POST). Если обработчик написан, его нужно связать с HTTP-сервисом с помощью веточки дерева метаданных.

Запись опубликована в рубрике Без рубрики с метками 1С, http error 405, http сервис. Добавьте в закладки постоянную ссылку.