При интеграции систем «1С:Предприятие» с внешними сервисами разработчики часто сталкиваются с ситуацией, когда база успешно опубликована на веб-сервере (например, Apache или IIS) и открывается в браузере, но при попытке вызвать собственный HTTP-сервис возвращается классическая ошибка 404 Not Found («Страница не найдена» или «Запрашиваемый ресурс перемещен»).
В этой статье мы подробно разберем, почему возникает данная проблема, как на нее влияют особенности платформы 1С и настройки веб-серверов, а также рассмотрим по шагам методы диагностики и лучшие практики проектирования API, исключающие подобные сбои.
Главная причина, по которой при вызове HTTP-сервиса возникает ошибка 404, чаще всего кроется в чувствительности к регистру символов (Case-Sensitivity). Давайте проанализируем, почему это происходит:
wsisapi.dll для IIS или mod_wsap24 для Apache) принимает входящий URL-запрос и передает его в платформу «1С:Предприятие» в исходном виде. Платформа сопоставляет входящий URI с именами сервисов и шаблонами URL в метаданных конфигурации, используя строгое сравнение строк.MyService, а запрос отправляется на адрес myservice или MYSERVICE, платформа 1С не сможет найти совпадений в своей внутренней таблице маршрутизации и вернет веб-серверу статус ответа 404.В зависимости от того, какой веб-сервер используется для публикации информационной базы 1С, поведение и текст ошибки при неверно указанном регистре могут различаться:
На веб-сервере Apache:
При обращении к несуществующему (из-за регистра букв) HTTP-сервису Apache возвращает стандартную страницу «404 Not Found» или сообщение в браузере «Страница localhost не найдена». При этом сама база данных 1С продолжает исправно функционировать в веб-клиенте.
На веб-сервере IIS (Internet Information Services):
IIS обрабатывает такие ситуации аналогично, однако текст ошибки в русскоязычной локализации операционной системы Windows Server чаще всего выглядит следующим образом: «Запрашиваемый ресурс перемещен, переименован либо временно недоступен» (что также соответствует HTTP-статусу 404).
Важно уметь отличать эту ошибку от ошибки с кодом 500 (Internal Server Error). Ошибка 500 обычно свидетельствует о внутренних сбоях в работе самой платформы 1С, проблемах с правами доступа к каталогу публикации или ошибках непосредственно в коде модуля HTTP-сервиса. Если же возвращается код 404, то проблема почти наверняка заключается в неверном пути (URL) или отсутствии публикации конкретного сервиса.
При публикации HTTP-сервисов конфигурация прописывается в специальном файле разметки default.vrd, который находится в каталоге публикации на веб-сервере. Давайте разберем по шагам, как проверить корректность этого файла:
default.vrd и откроем его с помощью любого текстового редактора (например, Notepad++).<httpServices>. Она должна содержать описание вашего HTTP-сервиса. Обратите внимание на регистр атрибутов name и rootUrl.Рассмотрим пример корректно заполненного файла default.vrd:
<?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="/BAS"
ib="File="C:\Base1C";">
<ws>
<point name="CommonWeb" enable="true"/>
</ws>
<httpServices publishByDefault="false">
<service name="MyService" rootUrl="My" enable="true"/>
</httpServices>
</point>
Если в конфигураторе 1С имя HTTP-сервиса задано как MyService, а в файле default.vrd в атрибуте name ошибочно указано myservice (с маленькой буквы), веб-сервер не сможет корректно пробросить входящий запрос, и клиент получит ошибку 404.
Чтобы избежать ошибок, связанных с человеческим фактором при интеграции сторонних систем с 1С, рекомендуется использовать проверенные на практике подходы.
Современным стандартом разработки REST API на платформе 1С является использование исключительно строчных (маленьких) букв во всех элементах пути: в имени публикации базы, в корневом URL HTTP-сервиса и во всех шаблонах URL. Например:
http://localhost/bas/hs/v1/orders/get/
Такой подход полностью исключает путаницу при ручном тестировании запросов через утилиты вроде Postman или при написании кода интеграции на стороне других систем.
Если внешние системы не могут гарантировать отправку запросов в нужном регистре, можно настроить автоматическое приведение всех входящих URL к нижнему регистру на уровне веб-сервера.
Настройка для IIS (модуль URL Rewrite):
Для этого необходимо установить официальное расширение URL Rewrite для IIS и добавить в конфигурационный файл web.config, находящийся в каталоге публикации, следующее правило:
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="Convert to Lower Case" stopProcessing="true">
<match url="[A-Z]" ignoreCase="false" />
<action type="Redirect" url="{ToLower:{URL}}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Настройка для Apache (модуль mod_rewrite):
Убедимся, что в файле конфигурации Apache httpd.conf раскомментирована строка загрузки модуля mod_rewrite. Затем добавим в конфигурационный файл или файл .htaccess в каталоге публикации правила принудительного перевода путей в нижний регистр:
RewriteEngine On
RewriteMap lc int:tolower
RewriteCond %{REQUEST_URI} [A-Z]
RewriteRule (.*) ${lc:$1} [R=301,L]
В некоторых случаях, когда нет возможности настраивать веб-серверы, разработчики используют обходной путь непосредственно в конфигураторе 1С. В свойствах одного и того же HTTP-сервиса создается несколько шаблонов URL, которые дублируют друг друга с разным регистром символов:
/my/test/My/TestОба шаблона привязываются к одному и тому же методу-обработчику модуля HTTP-сервиса. Это позволяет минимизировать риски возникновения ошибок со стороны внешних разработчиков.
При возникновении ошибки "Страница не найдена" (404) в процессе вызова HTTP-сервиса 1С в первую очередь необходимо проверить точное совпадение регистра букв в адресной строке запроса, свойствах HTTP-сервиса в конфигураторе и файле публикации default.vrd. Использование единого стандарта проектирования API (в нижнем регистре) и настройка модулей перенаправления на веб-сервере помогут навсегда решить эту проблему и обеспечить стабильную интеграцию систем.