Waarom CONNECT-verkeer Squids objectcache niet vult
Waarom een gewone HTTPS-tunnel veel bytes kan overdragen zonder herbruikbare HTTP-antwoordobjecten aan een forward proxy te leveren.
Een gewone CONNECT-tunnel geeft Squid versleutelde bytes in plaats van een cachebaar websiteantwoord. Een grote HTTPS-download kan dus veel verkeer opleveren zonder een herbruikbare objectcachevermelding.
Squid kan tunnelbestemming, duur en byteaantal vastleggen. Het ontvangt intern URL-pad, cache-instructies, representatie en validators niet als gewone HTTP-berichten die het kan opslaan en hergebruiken. Meer schijfruimte of een hogere objectgroottelimiet onthult ze niet.
Controleer aanvraagmethoden en tunnelregistraties voordat je de cache defect noemt. Een CONNECT-gedomineerde belasting past bij grote overdrachten en weinig objecthergebruik. Gebruik voor een echte controle een eigen HTTP-resource met expliciete cacheheaders en bekende inhoud; bevestig dat je Squids objectpad test, niet een tunnel, browsercache of bestemmings-CDN.
TLS naar de proxy is een aparte laag. Nadat Squid zijn eigen TLS-listener termineert, kan het een gewone HTTP-bestemmingsaanvraag verwerken. Vraagt die verbinding in plaats daarvan CONNECT naar HTTPS, dan blijft de interne bestemming-TLS apart en ondoorzichtig.
HTTPS-onderschepping verandert eisen aan certificaatvertrouwen, autorisatie en privacy. Het is geen gewone aanpassing van cacheruimte, en een normale forward proxy heeft geen onderschepping nodig om te werken.