Wêrom CONNECT-ferkear de objektcache fan Squid net follet
Wêrom in gewoane HTTPS-tunnel in soad bytes oerdrage kin sûnder werbrûkbere HTTP-antwurdobjekten oan in forward-proxy te jaan.
In gewoane CONNECT-tunnel jout Squid fersifere bytes ynstee fan in webside-antwurd dat yn de cache bewarre wurde kin. In grutte HTTPS-download kin dus in soad ferkear opsmite sûnder ien werbrûkbere yngong yn de objektcache ta te foegjen.
Squid kin de bestimming fan de tunnel, de doer en it tal bytes registrearje. It ûntfangt it binnenste URL-paad, cache-oanwizingen, de represintaasje en falidators net as gewoane HTTP-berjochten dy't it bewarje en werbrûke kin. Mear skiifromte of in hegere limyt foar objektgrutte makket dy net sichtber.
Kontrolearje fersykmetoaden en tunnelregistraasjes foardat jo konkludearje dat de cache net wurket. By in wurklêst dêr't CONNECT yn oerhearsket, kinne grutte gegevensoerdrachten en in bytsje werbrûk fan objekten tegearre foarkomme. Brûk foar in echte cachekontrôle in HTTP-boarne ûnder jo eigen behear mei eksplisite cachekoppen en bekende ynhâld; befêstigje dat jo it objektferwurkingspaad fan Squid teste en net in tunnel, de browsercache of de CDN fan de bestimming.
TLS nei de proxy is in aparte laach. Nei it beëinigjen fan de TLS-ferbining op syn eigen lústerpunt kin Squid in gewoan fersyk nei in HTTP-bestimming ferwurkje. As dy ferbining ynstee CONNECT nei HTTPS freget, bliuwt de binnenste TLS nei de bestimming apart en ûntrochsichtich.
HTTPS-ûnderskepping feroaret de easken foar fertrouwen yn sertifikaten, autorisaasje en privacy. It is gjin gewoane oanpassing fan cacheromte, en in normale forward-proxy hat gjin ûnderskepping nedich om te wurkjen.