Тайм-ауты CONNECT через прокси после успешного TCP-соединения
Определите тайм-аут, действующий во время CONNECT, вместо того чтобы считать, что завершённое TCP-соединение завершило и настройку туннеля.
Тайм-аут TCP-соединения выполнил свою задачу, как только клиент подключился к прокси. Следующее ожидание—получение полного ответа CONNECT—может управляться другим таймером.
Прокси может всё ещё подключаться к вышестоящему серверу, обмениваться сообщениями аутентификации или ждать другой сервис. Обычный ответ сайта ещё не начался.
| Последний завершённый шаг | Чего ещё ждём? |
|---|---|
| TCP подключён к прокси | Рукопожатие с прокси, включая принятие CONNECT |
| CONNECT принят | TLS назначения, когда цель его использует |
| Запрос к назначению отправлен | Ответ назначения |
Найдите таймер, который активен, пока коннектор читает и записывает это рукопожатие. Свойство с именем «response timeout» может вступать в силу только после установления маршрута. В HttpClient 5 различайте ConnectionConfig и его тайм-аут сокета, конфигурацию рукопожатия TLS и тайм-аут ответа на уровне запроса. Применяйте соответствующую конфигурацию соединения через менеджер, который использует фактический клиент. Старые поколения Apache HttpClient используют другие API, поэтому старый фрагмент не является надёжной картой этих обязанностей.
Полный отказ CONNECT по-прежнему считайте ответом прокси. Успешный ответ, за которым следует зависание TLS, — это другая стадия сбоя. «TCP подключён; полного ответа CONNECT нет до крайнего срока настройки» точнее описывает проблему, чем общий тайм-аут прокси.
Общий крайний срок может ограничить ожидание вызывающей стороны наряду с этими фазовыми лимитами. Когда он истекает, отмените или закройте операцию через поддерживаемый клиентом жизненный цикл, прежде чем очередная попытка израсходует ёмкость соединений.