Dlaczego CONNECT nie zapełnia cache obiektów Squida
Dlaczego zwykły tunel HTTPS może przenosić wiele bajtów bez dostarczania proxy wielokrotnie używalnych obiektów odpowiedzi HTTP.
Zwykły tunel CONNECT daje Squidowi zaszyfrowane bajty, a nie odpowiedź witryny nadającą się do cache. Duże pobranie HTTPS może więc wygenerować dużo ruchu i nie dodać żadnego obiektu do ponownego użycia.
Squid może zapisać cel, czas trwania i liczbę bajtów tunelu. Nie otrzymuje wewnętrznej ścieżki URL, dyrektyw cache, reprezentacji i walidatorów jako zwykłych komunikatów HTTP do zapisania i użycia ponownie. Większy dysk lub większy limit obiektu ich nie ujawni.
Sprawdź metody żądań i wpisy tuneli, zanim uznasz cache za uszkodzony. Obciążenie zdominowane przez CONNECT pasuje do dużych transferów i małego ponownego użycia obiektów. Do prawdziwej kontroli użyj własnego zasobu HTTP z jawnymi nagłówkami cache i znaną treścią; upewnij się, że testujesz ścieżkę obiektów Squida, nie tunel, cache przeglądarki ani CDN celu.
TLS do proxy to osobna warstwa. Po zakończeniu własnego TLS na nasłuchu Squid może przetworzyć zwykłe żądanie do celu HTTP. Jeśli połączenie żąda zamiast tego CONNECT do HTTPS, wewnętrzny TLS celu pozostaje oddzielny i nieprzejrzysty.
Przechwytywanie HTTPS zmienia wymagania zaufania do certyfikatów, autoryzacji i prywatności. Nie jest zwykłą regulacją miejsca w cache, a normalne proxy przekazujące nie potrzebuje przechwytywania do działania.