Zašto CONNECT ne popunjava Squidov objektni keš
Zašto običan HTTPS tunel može prenositi mnogo bajtova bez davanja forward proxyju HTTP odgovora koji se mogu ponovo koristiti.
Običan CONNECT tunel daje Squidu šifrovane bajtove umjesto kešabilnog odgovora sajta. Veliko HTTPS preuzimanje tako može stvoriti puno saobraćaja bez ijednog ponovo upotrebljivog objekta u kešu.
Squid može zabilježiti odredište tunela, trajanje i broj bajtova. Ne dobija unutrašnju URL putanju, keš direktive, reprezentaciju i validatore kao normalne HTTP poruke koje može čuvati i ponovo koristiti. Više diska ili veća granica veličine objekta to ne mogu otkriti.
Prije nego što proglasite keširanje pokvarenim, provjerite metode zahtjeva i tunelske zapise. Opterećenje s dominantnim CONNECT-om odgovara velikim transferima i maloj ponovnoj upotrebi objekata. Za stvaran test koristite svoj HTTP resurs s eksplicitnim keš zaglavljima i poznatim sadržajem; provjerite da testirate Squidovu putanju objekata, ne tunel, keš preglednika ili odredišni CDN.
TLS do proxyja je zaseban sloj. Poslije terminiranja TLS-a na vlastitom slušaocu, Squid može obraditi običan zahtjev za HTTP odredište. Ako veza umjesto toga zatraži CONNECT do HTTPS-a, unutrašnji TLS odredišta ostaje poseban i neproziran.
Presretanje HTTPS-a mijenja zahtjeve povjerenja certifikata, autorizacije i privatnosti. Nije rutinsko podešavanje keš prostora, a normalan forward proxy ne zahtijeva presretanje za rad.