Toxiproxy povas stari antaŭ la HTTP-prokurilo

Trakonduku la HTTP-prokurilan konekton de SDK tra Toxiproxy al ekzistanta antaŭa prokurilo, kiu komprenas CONNECT.

Toxiproxy plusendas TCP-fluon al agordita supraĵo kaj povas difekti tiun fluon. Ĝia HTTP-regada APIo tamen ne igas la trafikan aŭdilon HTTP-antaŭa prokurilo.

Por SDK agordita uzi HTTP-prokurilon, ekzistanta antaŭa prokurilo povas stari malantaŭ ĝi:

SDK → Toxiproxy 127.0.0.1:7890 → HTTP proxy 127.0.0.1:8888 → S3:443

Agordu la aŭdilon de Toxiproxy sur 7890 kun 127.0.0.1:8888 kiel ĝia supraĵo. Direktu la HTTP-prokuran agordon de la SDK al http://127.0.0.1:7890. La aŭdilo plusendas la peton CONNECT de la SDK; la HTTP-prokurilo interpretas CONNECT kaj malfermas la tunelon al la celo.

Ĉi tiuj loopback-adresoj supozas, ke ĉiuj tri lokaj komponantoj dividas la saman retan nomspacon. Komponantoj en ujoj bezonas adresojn atingeblajn el siaj propraj nomspacoj.

Ĉi tiu aranĝo ŝanĝas la vojon de la kliento al la antaŭa prokurilo. Ĝi ne anstataŭigas la TLS de la celo nek la servan aŭtentikigon. Kiam vi pritaksas enŝovitan misfunkcion, kalkulu la ripetojn de la SDK aparte: riparita operacio povas kaŝi antaŭan malsukcesan provon.

Rilataj artikoloj