Ĉu la URL-riperanto de Squid povas modifi respondkorpojn?
Tenadu la elekton de peto-URL aparte de responda adaptado kaj TLS-malĉifrado kiam vi etendas antaŭan prokuran servantaron.
url_rewrite_program laboras pri decidoj de peto-URL. Ĝi ricevas informojn pri la peto kaj respondas per la helpila protokolo de Squid; ĝi ne ricevas elŝutitan dosieron por prilabori kaj redoni ĝin.
| Dezirata operacio | Rilata limo |
|---|---|
| Alidirekti la retumilon aŭ elekti alian peto-URL | La rolo de la URL-riperanta helpilo en la peto-etapo |
| Modifi videblan HTTP-respondkorpon | Responda adaptilo, ekzemple agordita ICAP-responda modifo |
| Legi HTTP ene de ordinara CONNECT | La TLS de la celo unue devas esti finita sub taŭga deploja aranĝo |
| Malĉifri dosieron ĉifritan de aplikaĵo | La formato, algoritmo kaj ŝlosilo de la dosiero, sendepende de ĝia transporto |
La lastaj du vicoj facile konfuziĝas. Ordinara dosiero transportata per HTTPS estas protektata de TLS. Dosiero ĉifrita de aplikaĵo povas resti ĉifrita eĉ post kiam HTTPS estas finita. Elekti adaptan interfacon liveras nek la ŝlosilon de la aplikaĵo nek ĝian malĉifran algoritmon.
Ordinara CONNECT plusendas ĉifritajn tunelajn bitokojn. URL-helpilo ne malkaŝas la internan respondon; dezajno postulanta inspekton devas determini ĉu tiu trafiko povas kaj devas esti malĉifrita en la deplojo.
Kie Squid povas inspekti la HTTP-mesaĝon, respondmodifa servo ankoraŭ respondecas pri enhavkodadoj, ŝanĝitaj longoj kaj fiaskokonduto. Elektu la interfacon post difini la transformon, anstataŭ etendi funkciantan ekzemplon de URL-riperado al prilabora etapo kiun ĝi neniam ricevas.