При работе с веб-клиентом 1С на платформе версии 8.3.18 (в частности, релизы 1208, 1289 и соседние) системные администраторы и пользователи часто сталкиваются с критической ошибкой при попытке сформировать отчет или печатную форму. Текст ошибки выглядит следующим образом: Uncaught TypeError: Cannot read property 'toUpperCase' of undefined (в некоторых браузерах — reading 'toUpperCase').
Эта проблема делает невозможной работу с табличными документами в браузерах на движке Chromium (Chrome, Яндекс.Браузер, Edge). В данной статье мы подробно разберем причины возникновения этого сбоя и рассмотрим проверенные способы его устранения через настройку веб-серверов и прокси-серверов.
Проанализируем ситуацию: ошибка возникает в клиентском JavaScript-коде платформы 1С. Когда пользователь нажимает кнопку «Сформировать», код веб-клиента пытается инициализировать объект табличного документа (ТабДок). Для этого системе необходимо разобрать URL-адрес и определить протокол и хост, с которых загружаются ресурсы.
Если ваша публикация 1С работает за прокси-сервером (например, Nginx, Apache в роли реверс-прокси или IIS с модулем переписывания URL), может возникнуть ситуация, когда внутренний порт веб-сервера не совпадает с внешним портом, по которому обращается пользователь. В этот момент внутренняя логика 1С некорректно определяет параметры соединения, переменная, содержащая имя хоста или протокол, принимает значение undefined, и попытка применить к ней метод .toUpperCase() приводит к фатальному сбою всей страницы.
Рассмотрим наиболее распространенный случай, когда перед основным веб-сервером стоит Nginx. Для корректной трансляции протокола и хоста в конфигурационный файл Nginx необходимо добавить специфические заголовки. Разберем по шагам, какие именно строки исправляют ситуацию.
Основная проблема заключается в том, что 1С должна «знать», какой протокол (HTTP или HTTPS) и какой хост (включая порт) использует клиент на самом деле. Добавьте в блок location вашего конфига следующие параметры:
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Scheme $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
Обратите особое внимание на параметр proxy_set_header Host $http_host;. Использование переменной $http_host критически важно, если порт входа отличается от стандартных 80/443. В отличие от $host, переменная $http_host передает имя сервера вместе с номером порта из адресной строки браузера. Если использовать $proxy_host, это может направить клиентские запросы напрямую на внутренний адрес Apache, что и вызывает ошибку toUpperCase.
Проанализируем технические нюансы проброса портов. Платформа 1С 8.3.18 крайне чувствительна к так называемому «маппингу» портов. Если на сетевом оборудовании настроен проброс, например, с внешнего порта 15000 на внутренний 80, веб-клиент может начать вести себя нестабильно.
Рекомендуемая стратегия: постарайтесь обеспечить соответствие портов «один в один». Если внешний адрес доступен по https://mybase.com:10443, то и внутренний веб-сервер должен принимать запросы на порт 10443. Если это невозможно, использование заголовка X-Forwarded-Proto и Host (как описано выше) является единственным способом «объяснить» платформе топологию вашей сети.
Если публикация выполнена на Internet Information Services (IIS) и используется переадресация портов или протоколов (например, через модуль Application Request Routing), ситуация аналогична. Посмотрим на алгоритм действий:
Host, что и для Nginx.Практика показывает, что проброс внешнего 443 на внутренний 443 (без смены номера порта) решает проблему в 100% случаев на IIS.
Если у вас нет возможности оперативно изменить настройки сетевого экрана или веб-сервера, рассмотрим альтернативные варианты:
toUpperCase.Для исправления ошибки Uncaught TypeError при выводе ТабДок необходимо:
Host (включая порт).X-Forwarded-Proto.Соблюдение этих правил обеспечит стабильную работу отчетов в любом современном браузере.