Przekroczenia limitu czasu CONNECT przez proxy po udanym połączeniu TCP
Ustal limit czasu obowiązujący podczas CONNECT, zamiast zakładać, że zakończone połączenie TCP zakończyło także konfigurację tunelu.
Limit czasu połączenia TCP spełnił swoją rolę, gdy klient połączył się z proxy. Kolejne oczekiwanie—na pełną odpowiedź CONNECT—może podlegać innemu timerowi.
Proxy może nadal łączyć się z serwerem nadrzędnym, wymieniać komunikaty uwierzytelniania lub czekać na inną usługę. Zwykła odpowiedź witryny jeszcze się nie rozpoczęła.
| Ostatni ukończony krok | Na co jeszcze czekamy? |
|---|---|
| TCP połączone z proxy | Uścisk dłoni proxy, w tym akceptacja CONNECT |
| CONNECT zaakceptowany | TLS miejsca docelowego, gdy cel go używa |
| Żądanie do celu wysłane | Odpowiedź miejsca docelowego |
Znajdź timer aktywny, gdy łącznik czyta i zapisuje ten uścisk dłoni. Właściwość o nazwie „response timeout” może zacząć obowiązywać dopiero po ustanowieniu trasy. W HttpClient 5 rozróżnij ConnectionConfig i jego limit czasu gniazda, konfigurację uścisku dłoni TLS oraz limit czasu odpowiedzi na poziomie żądania. Zastosuj odpowiednią konfigurację połączenia przez menedżera używanego przez rzeczywistego klienta. Starsze generacje Apache HttpClient używają innych interfejsów API, więc starszy fragment kodu nie jest wiarygodną mapą tych obowiązków.
Ostateczne odrzucenie CONNECT traktuj nadal jako odpowiedź proxy. Udana odpowiedź, po której następuje zatrzymanie TLS, to inny etap awarii. „TCP połączone; brak pełnej odpowiedzi CONNECT przed terminem konfiguracji” opisuje problem dokładniej niż ogólny limit czasu proxy.
Ogólny termin może ograniczyć oczekiwanie wywołującego obok tych limitów faz. Gdy wygaśnie, anuluj lub zamknij operację przez obsługiwany przez klienta cykl życia, zanim kolejna próba zużyje pojemność połączeń.