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