Prokuraj CONNECT-tempolimoj post sukcesa TCP-konekto
Trovu la tempolimon aktivan dum CONNECT anstataŭ supozi, ke finita TCP-konekto ankaŭ finis la tunelan agordon.
TCP-konekta tempolimo plenumis sian taskon tuj kiam la kliento konektiĝas al la prokura servilo. La sekva atendo—ricevi kompletan CONNECT-respondon—povas esti regata de alia tempomasko.
La prokura servilo eble ankoraŭ konektiĝas al la supra servilo, interŝanĝas aŭtentikigajn mesaĝojn aŭ atendas alian servon. La kutima respondo de la retejo ankoraŭ ne komenciĝis.
| Lasta finita paŝo | Kio ankoraŭ atendas? |
|---|---|
| TCP konektita al la prokura servilo | La prokura manpremo, inkluzive de akcepto de CONNECT |
| CONNECT akceptita | TLS de la celo, kiam la celo uzas ĝin |
| Peto al la celo sendita | La respondo de la celo |
Trovu la tempomaskon aktivan dum la konektilo legas kaj skribas tiun manpremon. Eco nomata “response timeout” eble efikiĝos nur post establado de la itinero. Ĉe HttpClient 5, distingi ConnectionConfig kaj ĝian ingan tempolimon, la TLS-manpreman agordon kaj la respondan tempolimon je petnivelo. Apliku la taŭgan konektan agordon per la administrilo uzata de la reala kliento. Pli malnovaj generacioj de Apache HttpClient uzas malsamajn API-ojn, do pli malnova fragmento ne estas fidinda mapo de ĉi tiuj respondecoj.
Konservu finan CONNECT-rifuzon kiel respondon de la prokura servilo. Sukcesa respondo sekvata de TLS-halto estas alia fiaska stadio. „TCP konektita; neniu kompleta CONNECT-respondo antaŭ la agorda limdato“ priskribas la problemon pli precize ol ĝenerala prokura tempolimo.
Tuteca limdato povas limigi la atendon de la alvokanto apud ĉi tiuj fazaj limoj. Kiam ĝi finiĝas, nuligu aŭ fermu la operacion per la vivociklo subtenata de la kliento antaŭ ol plia provo konsumos konektan kapaciton.