Проблема доставки запросов от клиента к серверу

WEB-приложение Сведение отчетности (29.04.2026) | (раздел целиком) (одним файлом) (cсылка)
Проблема доставки запросов от клиента к серверу
Описание проблемы: На клиенте - проходит авторизация, проходит получение данных дерева каталогов и гридов. При этом не проходят запросы на совершение действий и не проходят запросы после задания условий отбора. На сервере - В отладочном мониторе появляются сообщения "Socket became inactive in first line" или "Bad first line". Причины проблемы: Проблема связана с особенностями провайдера клиента. У провайдера установлено ограничение на длину любого http-запроса, либо POST-запроса в 1KB или немногим более. Обычно проблема проявляется при использовании Microsoft (ISA) Internet Security and Acceleration Server на маршрутизаторе локальной сети. Для диагностики такой ситуации можно использовать командный сценарий проверки провайдера (пример) . Сценарий покажет, что отказ происходит именно при отправке запроса, размер которого превышает 1 КВ. Вы можете написать собственный сценарий проверки, лучше соответствующий вашей ситуации, и распространить его своим клиентам. Запуск файла производится из окружения интерпретатора командной строки Windows (cmd.exe) Решение проблемы лежит не в области функциональности программного продукта, а в области его эксплуатации, конкретнее - в области организации взаимодействия между web-сервером и клиентскими рабочими местами пользователей. Проблема должна решаться специалистами, отвечающими за сопровождение программного продукта у тех клиентов, у которых имеет место описанное выше ограничение. Пути решения проблемы: 1. Обратиться к провайдеру с просьбой о снятии ограничения на размер запросов. 2. Использовать нестандартный TCP/IP порт, договорившись с провайдером о его открытии с серверной и клиентской стороны. Данный путь не гарантирует решения проблемы, но может помочь. В данном случае "провайдером" может выступать как администратор локальной сети организации, так и ISP (интернет-провайдер), в зависимости от того, как организовано подключение конечного пользователя. 3. Использовать протокол https. В этом случае провайдер не сможет анализировать содержимое обмена и, следовательно, не сможет применять ограничения. Для использования протокола https необходимо иметь сертификат, а также внести изменения в настройки web-сервера. Первые два пути могут способствовать быстрому решению проблемы. При этом стратегически правильным является путь 3 - использование протокола https. Взаимодействие по протоколу https может быть организовано с использованием сертификатов двух видов: 1) Сертификат, выдаваемый уполномоченными организациями ("настоящий" сертификат). Инструкция по получению "настоящего" сертификата включена в данное руководство, а также доступна по адресу: http://app.techmill.ru/paruspub/current/documentation/ED01679A80A74E999952269A89D95D36.html 2) Самостоятельно сгенерированный сертификат. Инструкция по генерации такого сертификата приведена Здесь. При использовании самостоятельно сгенерированного сертификата браузер пользователя будет выдавать предупреждение о сомнении в его достоверности. О том как избежать отображения такого предупреждения также написано Здесь. Действия по установке настроек web-сервера для работы по протоколу https описаны Здесь.
Сценарий проверки провайдера (пример)