Чому CONNECT не заповнює об’єктний кеш Squid
Чому звичайний HTTPS-тунель може передавати багато байтів, не даючи прямому проксі придатних до повторного використання HTTP-відповідей.
Звичайний тунель CONNECT дає Squid зашифровані байти, а не кешовану відповідь сайту. Тож велике HTTPS-завантаження може створити багато трафіку й жодного повторно використовуваного запису об’єктного кешу.
Squid може записувати адресат тунелю, тривалість і кількість байтів. Він не отримує внутрішній URL-шлях, директиви кешу, представлення та валідатори як звичайні HTTP-повідомлення для зберігання й повторного використання. Більше диска чи вища межа розміру об’єкта їх не розкривають.
Перевірте методи запитів і записи тунелів, перш ніж вважати кешування зламаним. Навантаження переважно з CONNECT узгоджується з великими передаваннями й малим повторним використанням об’єктів. Для справжньої перевірки використайте свій HTTP-ресурс із явними кеш-заголовками та відомим вмістом; переконайтеся, що перевіряєте об’єктний шлях Squid, а не тунель, кеш браузера чи CDN адресата.
TLS до проксі — окремий шар. Завершивши TLS власного слухача, Squid може обробити звичайний запит до HTTP-адресата. Якщо з’єднання натомість запитує CONNECT до HTTPS, внутрішній TLS адресата лишається окремим і непрозорим.
Перехоплення HTTPS змінює вимоги до довіри сертифікатів, авторизації та приватності. Це не звичайне налаштування місця для кешу; нормальному прямому проксі перехоплення для роботи не потрібне.