Чаму CONNECT не запаўняе аб’ектны кэш Squid
Чаму звычайны HTTPS-тунэль можа перадаваць шмат байтаў, не даючы прамому проксі прыдатных да паўторнага выкарыстання HTTP-адказаў.
Звычайны тунэль CONNECT дае Squid зашыфраваныя байты, а не адказ сайта, прыдатны для кэшавання. Таму вялікая HTTPS-спампоўка можа стварыць шмат трафіку і ніводнага паўторна выкарыстоўванага запісу аб’ектнага кэша.
Squid можа запісваць адрасат тунэлю, працягласць і колькасць байтаў. Ён не атрымлівае ўнутраны URL-шлях, дырэктывы кэша, прадстаўленне і валідатары як звычайныя HTTP-паведамленні для захавання і паўторнага выкарыстання. Больш дыска ці вышэйшая мяжа памеру аб’екта іх не раскрываюць.
Праверце метады запытаў і запісы тунэляў, перш чым лічыць кэшаванне зламаным. Нагрузка пераважна з CONNECT адпавядае вялікім перадачам і малому паўторнаму выкарыстанню аб’ектаў. Для сапраўднай праверкі выкарыстоўвайце свой HTTP-рэсурс з яўнымі загалоўкамі кэша і вядомым змесцівам; пераканайцеся, што правяраеце аб’ектны шлях Squid, а не тунэль, кэш браўзера ці CDN адрасата.
TLS да проксі — асобны слой. Завяршыўшы TLS уласнага слухача, Squid можа апрацаваць звычайны запыт да HTTP-адрасата. Калі злучэнне замест гэтага запытвае CONNECT да HTTPS, унутраны TLS адрасата застаецца асобным і непразрыстым.
Перахоп HTTPS змяняе патрабаванні да даверу сертыфікатаў, аўтарызацыі і прыватнасці. Гэта не звычайная налада месца для кэша; нармальнаму прамому проксі перахоп для працы не патрэбны.