Zergatik CONNECT trafikoak ez duen Squid-en objektu-cachea betetzen
HTTPS tunel arrunt batek byte asko transferi ditzake, irteerako proxyari berrerabil daitezkeen HTTP erantzun-objekturik eman gabe.
CONNECT tunel arrunt batek byte zifratuak ematen dizkio Squid-i, eta ez cachean gorde daitekeen webgunearen erantzun bat. Beraz, HTTPS deskarga handi batek trafiko ugari sor dezake objektu-cachean sarrera berrerabilgarririk sortu gabe.
Squid-ek tunelaren helmuga, iraupena eta byte kopurua erregistra ditzake. Ez ditu barruko URLaren bidea, cachearen direktibak, irudikapena eta balioztatzaileak jasotzen, gorde eta berrerabil ditzakeen HTTP mezu arrunt gisa. Disko-leku gehiago edo objektu-tamainaren muga handiagoa izateak ez ditu datu horiek agerian uzten.
Eskaeren metodoak eta tunelen erregistroak begiratu cachea hondatuta dagoela esan aurretik. CONNECT nagusi den lan-karga batean transferentzia handiak eta objektuen berrerabilera txikia bateragarriak dira. Cachea benetan egiaztatzeko, erabili zuk kontrolatzen duzun HTTP baliabide bat, cache-goiburu esplizituak eta eduki ezaguna dituena; ziurtatu Squid-en objektuen prozesamendu-bidea probatzen ari zarela, eta ez tunel bat, nabigatzailearen cachea edo helmugako CDNa.
Proxyrainoko TLSa geruza independente bat da. Bere entzuleko TLS konexioa amaitu ondoren, Squid-ek HTTP helmuga baterako eskaera arrunt bat prozesa dezake. Konexio horrek HTTPSrako CONNECT eskatzen badu, helmugako barneko TLSak independente eta opaku jarraitzen du.
HTTPS atzemateak ziurtagiriekiko konfiantzaren, baimenen eta pribatutasunaren eskakizunak aldatzen ditu. Ez da cache-lekuaren ohiko doikuntza bat, eta irteerako proxy arrunt batek ez du atzematerik behar funtzionatzeko.