libproxy vel ei rute; klienten din opnar sambandet

Bruk libproxy-resultat som rutevalkandidatar per URL i staden for å vente at oppdaginga omdirigerer sokkane til programmet.

Viss libproxy returnerer ein proxy-URI medan neste sokkel koplar til direkte, undersøk overleveringa. libproxy oppdagar policy; det fangar ikkje opp kvar sokkel programmet opnar.

  1. Spør etter ressursen. I det dokumenterte libproxy 0.5 C-API-et lagar du ein proxyfabrikk og ber om den faktiske mål-URL-en.
  2. Tolk dei ordna kandidatane. HTTP-, SOCKS- og direkte resultat krev ulik handsaming. Hald på preferanserekkjefølgja og den tiltenkte feilpolicyen.
  3. Set opp forbrukaren. Gje den valde proxytypen, endepunktet og autentiseringsoppsettet til ein transport som støttar dei. Ein rå TCP-sokkel får ikkje CONNECT- eller SOCKS-forhandling frå ein returnert URI.

Ikkje lagre eitt svar som ruta for alle mål, og gjer ikkje direkte ruting permanent fordi den første proxyen feila éin gong.

Viss HTTP-klienten alt integrerer systemproxy eller PAC-oppdaging, vel éin eigar av valet. To uavhengige veljarar pluss ein ekstra innpakning kan gje ei rute ingen av dei to policyane hadde til hensikt.

I innebygd kode, følg livssyklusen til fabrikken og resultatminnet i det installerte API-et. Gjenbruk av ein fabrikk kan halde på nyttig oppdagingstilstand, men han treng framleis ei førespurnad for kvart mål. Logg valet skilt frå sambandsresultatet: ein returnert URI provar ikkje vellukka autentisering, oppslag eller vidare tilgang.

Relaterte artiklar