Почему ломается Web-сервис в 1С при перепубликации и как исправить ошибку HTTP 406?

← На главную

При активной разработке интеграционных решений на платформе 1С:Предприятие программисты часто сталкиваются со следующей проблемой: после первой публикации собственный Web-сервис функционирует без нареканий. Однако стоит внести минимальные изменения в конфигурацию (даже не связанные напрямую с кодом самого Web-сервиса) и сохранить её, как при обращении к ресурсу начинает возвращаться критическая ошибка:

«Ошибка работы с Интернет: запрос не допустим для заданного ресурса (406). Истекло время ожидания сеанса»

Временным спасением становится полная перезагрузка сервера приложений 1С или веб-сервера (IIS / Apache), но при следующем же обновлении конфигурации ситуация повторяется. Примечательно, что типовые Web-сервисы (например, входящие в состав БСП) в этот момент могут продолжать работать стабильно. В данной статье мы подробно разберем, почему возникает этот сбой, заглянем в физику процессов взаимодействия веб-сервера с платформой 1С и изучим надежные способы решения этой проблемы.

Физика процесса: почему возникает ошибка HTTP 406

Основная причина такого поведения кроется в механизме пула сеансов (Session Pooling), реализованном в платформе 1С:Предприятие для оптимизации производительности веб-сервисов.

Когда к опубликованному Web-сервису поступает внешний запрос, веб-сервер не создает новый полноценный сеанс 1С с нуля (ведь инициализация сеанса — ресурсоемкий процесс, требующий времени). Вместо этого платформа использует готовые, предварительно запущенные «спящие» сеансы из пула.

Давайте проанализируем цепочку событий, приводящую к сбою:

В файле параметров публикации default.vrd по умолчанию для Web-сервисов активирован параметр автоматического переиспользования сеансов (reuseSessions="autouse").
В пуле веб-сервера находятся активные рабочие сеансы, которые хранят в оперативной памяти кэш метаданных старой версии конфигурации.
Разработчик вносит изменения в конфигураторе и выполняет обновление базы данных (в том числе динамическое).
При поступлении очередного запроса от внешнего клиента веб-сервер пытается назначить этот запрос одному из свободных сеансов из пула.
Сеанс пытается обработать запрос, но из-за несоответствия версии кэша метаданных в памяти и фактической конфигурации в базе данных происходит конфликт. Сеанс блокируется или зависает в процессе попытки обновить метаданные в монопольном режиме.
Новые входящие запросы выстраиваются в очередь. Веб-сервер ожидает освобождения или успешной инициализации сеанса в течение времени, заданного системным параметром poolTimeout.
По истечении таймаута веб-сервер понимает, что живых сеансов для обработки запроса нет, и возвращает клиенту ошибку HTTP 406 с XML-описанием исключения: Истекло время ожидания сеанса.

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

---

Решение 1. Отключение пула сеансов (простой и быстрый способ)

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

Разберем по шагам, как это сделать:

Перейдем в каталог, куда была выполнена публикация Web-сервиса на веб-сервере (путь к каталогу указывается при публикации в Конфигураторе).
Найдем в этом каталоге файл конфигурации публикации с именем default.vrd и откроем его любым текстовым редактором (желательно с правами администратора).
Найдем XML-тег, описывающий ваш Web-сервис. Он выглядит примерно так:


<ws>
    <point name="MyWebService"
           alias="myws.1cws"
           enable="true"
           reuseSessions="autouse"/>
</ws>

Заменим значение атрибута reuseSessions со значения autouse на значение dontuse.


<ws>
    <point name="MyWebService"
           alias="myws.1cws"
           enable="true"
           reuseSessions="dontuse"/>
</ws>

Сохраним изменения в файле default.vrd и выполним мягкий перезапуск веб-сервера.

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

---

Решение 2. Тонкая настройка пула сеансов (для высоконагруженных систем)

Если отключение пула сеансов неприемлемо по соображениям производительности (например, Web-сервис обрабатывает постоянный поток мелких запросов от кассовых аппаратов или ТСД), нам необходимо правильно настроить параметры жизни сеансов в файле default.vrd.

Рассмотрим структуру параметров управления пулом внутри тега <pool>, которые помогут избежать зависаний при обновлении:

sessionMaxAge — максимальное время жизни сеанса в пуле (в секундах). Если установить здесь небольшое значение (например, от 20 до 60 секунд), система будет регулярно уничтожать старые сеансы и создавать новые. Это позволит автоматически обновлять кэш метаданных без ручного вмешательства.
poolTimeout — время ожидания свободного сеанса из пула (в миллисекундах) перед тем, как вернуть ошибку клиенту. Увеличение этого параметра поможет избежать ошибок 406 при кратковременных задержках инициализации.
size — максимальный размер пула сеансов.

Проанализируем пример конфигурации файла 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="/WorkHours"
       ib="Srvr="nipi-1c-00";Ref="WorkHours";">
    <ws reuseSessions="autouse"
        sessionMaxAge="30"
        poolSize="10"
        poolTimeout="2000">
        <point name="MyWebService" alias="myws.1cws" enable="true"/>
    </ws>
</point>

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

---

Решение 3. Быстрый сброс зависшего пула сеансов без перезагрузки ОС

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

Для веб-сервера IIS (Internet Information Services):

Нет необходимости перезапускать весь веб-сервер. Достаточно перезапустить пул приложений, обслуживающий публикацию вашей базы 1С:

Откройте Диспетчер служб IIS.
Перейдите в раздел «Пулы приложений» (Application Pools).
Найдите пул, на котором работает ваша публикация (обычно это DefaultAppPool или выделенный пул для 1С).
Нажмите кнопку «Перезапустить» (Recycle) на панели действий справа.

Это мгновенно выгрузит из памяти библиотеку расширения веб-сервисов 1С (wsisapi.dll) вместе со всеми зависшими фоновыми сеансами пула.

Для веб-сервера Apache:

Используйте команду мягкого перезапуска (graceful restart), которая обновляет конфигурацию процессов веб-сервера без жесткого разрыва текущих активных пользовательских соединений. В командной строке сервера выполните:

httpd -k graceful

Или выполните перезапуск соответствующей службы через оснастку services.msc в Windows.

---

Решение 4. Устранение несовпадения версий платформ и библиотек

Бывают ситуации, когда ошибка 406 возникает из-за того, что при обновлении платформы 1С веб-сервер продолжает обращаться к библиотеке расширения (wsisapi.dll для IIS или wsap24.dll для Apache) от старого релиза платформы.

Разберем, как проверить это соответствие:

При публикации новой версии платформы обязательно запускайте Конфигуратор от имени Администратора, чтобы у платформы была возможность перезаписать системные файлы сопоставления обработчиков на веб-сервере.
В веб-сервере IIS перейдите в настройки вашей виртуальной базы, откройте раздел «Сопоставление обработчиков» (Handler Mappings).
Найдите сопоставление для веб-сервисов 1С (обычно называется 1C Web-service Extension) и убедитесь, что путь к исполняемому файлу ведет к DLL-файлу в каталоге актуальной (запущенной на сервере) версии платформы 1С.
Если пути различаются, измените путь вручную, указав верную директорию (например, C:\Program Files\1cv8\8.3.22.1709\bin\wsisapi.dll).

---

Решение 5. Анализ нехватки портов и прав доступа

Иногда веб-сервер не может запустить сеанс в пуле из-за банальной нехватки свободных портов рабочего сервера в кластере 1С или ограничений операционной системы:

Проанализируйте диапазон портов в настройках кластера 1С (по умолчанию 1560-1591). Если в кластере запущено множество фоновых заданий и других сеансов, веб-сервису может просто не хватить свободного порта для инициализации нового сеанса в пуле. В этом случае расширьте диапазон портов в свойствах рабочего сервера кластера.
Проверьте права доступа к каталогу публикации. При повторной публикации Конфигуратор перезаписывает файл default.vrd. Убедитесь, что у учетной записи, от имени которой запущен пул веб-сервера (например, IIS_IUSRS в Windows или www-data в Linux), сохранились права на чтение и выполнение файлов в каталоге публикации, а также права на запись в системную временную папку (Temp), используемую платформой 1С для генерации временных файлов сеанса.