Konekti ICAP-HTML-respondservon al Squid 7

Konektu ekzistantan ICAP-respondservon al Squid 7 antaŭa prokuro kaj decidu, kiujn respondojn ĝi transformu.

Por Squid antaŭa prokuro, kiu devas transformi HTML-respondon, uzu la adaptan vojon. Squid pritraktas la prokurpeton de la retumilo; ICAP-respondservo plenumas la korpan transformon kaj redonas la adaptitan HTTP-mesaĝon.

Tio donas al la transformo difinitan lokon en la vivo de la peto. Responda kaplinio ne povas anstataŭigi HTML-analizilon, kaj aparta retservila filtrilo ne aŭtomate prilaboras trafikon pasantan tra Squid.

Konekti respondservon

Por Squid 7-konstruaĵo kun ICAP-subteno kaj ekzistanta kongrua servo, la agorda formo estas:

acl adaptation_clients src 192.0.2.0/24

icap_enable on
icap_service html_editor respmod_precache bypass=0 icap://127.0.0.1:1344/modify

adaptation_access html_editor allow adaptation_clients
adaptation_access html_editor deny all

La klienta gamo kaj la serva URI estas ekzemploj. La URI devas nomi realan ICAP-servon, kiu efektivigas la respondan transformon; deklari /modify ne kreas ĝin. La fragmento kompletigas la ekzistantan aŭskultilon de la prokuro kaj la alirkontrolojn.

respmod_precache elektas respondan adaptadon ĉe la punkto antaŭ la kaŝmemoro. adaptation_access elektas transakciojn por tiu servo. La agordo bypass=0 signifas, ke Squid ne povas silente preterpasi ĉi tiun servon, kiam aplikebla transakcio renkontas servan fiaskon. Elektu tiun fiaskan konduton laŭ tio, ĉu la transformo estas deviga.

La adaptaj direktivoj dependas de la versio. Specife, ĉi tiuj agordaj referencoj listigas la interfacojn de ICAP-servo kaj adapta aliro por Squid 7 kaj pli fruaj subtenataj linioj, kaj markas ilin nehaveblaj en Squid 8. Konsideru la fragmenton kiel ekzemplon por Squid 7 anstataŭ kopii ĝin en arbitran eldonon.

Donu al la servo precizan transforman kontrakton

Specifu, kiuj respondoj estas elekteblaj kaj kiuj ŝanĝoj necesas. Transformo nur de HTML devus lasi bildojn, arkivojn kaj nerilatajn amaskomunikilojn netuŝitaj. La servo ankaŭ devas pritrakti la prezenton, kiun ĝi efektive ricevas: kunpremitajn korpojn, signokodigojn kaj la metadatenojn priskribantajn la ŝanĝitan korpon. Enmeti tekston en arbitrajn respondajn bitokojn ne estas ĝenerala HTML-transformo.

Konsideru kaŝmemoradon, kiam la anstataŭaĵo estas uzantospecifa. Transformo antaŭ la kaŝmemoro kaj komuna kaŝmemoro estas malbona kombinaĵo, se la rezulta prezento validas nur por unu leganto. Tenu kaŝeblecon kaj transforman politikon kongruaj, kaj respektu aplikeblajn direktivojn no-transform.

Fine, ordinara HTTPS CONNECT-tunelo portas ĉifritajn bitokojn. Ĝi ne elmontras HTML al responda adaptilo. Intence administrata TLS-inspektada aranĝo bezonas sian propran kongruan agordon kaj klientan fidon, antaŭ ol malĉifritaj respondoj povas eniri ĉi tiun vojon. La ICAP-regulo sola ne aldonas tiun videblecon.

Rilataj artikoloj