Непрозрачный кеш HTTPS с истечением срока последнего доступа
Я бы хотел настроить сервер кеширования для загруженных файлов. Один поворот заключается в том, что я хочу, чтобы он работал с HTTPS (включая перенаправления с HTTP на HTTPS). Я понимаю обычные проблемы с этим, но для меня разница в том, что это не должен быть прозрачным прокси. Например:
# Usually you'd do something like this:
curl --proxy myserver:8080 https://example.com/file.tar.gz
# But it's fine for our scripts to call something like this instead:
curl myserver:8080 --data-raw https://example.com/file.tar.gz
Обратите внимание, что здесь клиент специально направляет свой запрос на мой сервер, поэтому он не собирается пытаться проверить, что ответ исходит от example.com . (Хотя мой сервер должен! )
Другой поворот заключается в том, что это будет использоваться только для файлов, которые никогда не меняются (URL-адреса включают номер версии), поэтому обычные вещи о свежести кеша не применяются. Если файл (или ответ перенаправления) кэширован, его следует вернуть без проверки Интернета вообще. Кэшированная копия должна быть удалена через определенный период времени после того, как она последний запрошена, независимо от того, когда она была впервые загружена на нашем конце.
Вопрос: Я надеялся использовать HTTP-прокси, такой как Squid, но я не вижу, как настроить его на что-то подобное. В качестве альтернативы можно написать немного кода, но я бы предпочел этого избежать. Что я мог сделать, чтобы установить такой кеш?
Справочная информация: Это должно использоваться в основном для сторонних библиотек, которые мы будем использовать в нашем исходном коде, при сборке образов Docker и когда разработчики создают за пределами контейнеров. Иногда мы в настоящее время проверяем сторонний код в наших собственных репозиториях, но это не идеально. Я уверен, что мы не единственные, кто сталкивается с этой проблемой, но я не могу найти хорошее решение в Интернете ... возможно, мне просто не хватает подходящего поискового запроса.
Это возможно и требует трех изменений конфигурации:
- Настроить SSL Bump для выполнения дешифрования «человек посередине», чтобы сделать контент доступным. для кеширования
- Используйте параметр Squid refresh_pattern , чтобы убедиться, что Squid кэширует (и удерживает) объекты, которые вы хотите сохранить.
- Отрегулируйте параметр maximum_object_size , чтобы он был как минимум таким же большим как максимальный файл, который вы планируете загрузить.
Вы должны знать, что после настройки SSL bump, Squid создаст и выдаст самозаверяющий сертификат для каждого домена, для которого он настроен. Ваш клиент должен принять этот сертификат, чтобы передача произошла. cURL может сделать это с помощью параметра --cacert (позволяющего принимать центры сертификации, чей открытый ключ указан в списке) или параметра -k (полностью отключает проверку SSL).
Кроме того, существует тонкая (но важная) разница в как работают две команды cURL, которые вы разместили выше. Первый заставит cURL открыть соединение, как если бы он разговаривал с прокси, т. Е. Открыть порт, выдать команду «CONNECT», затем дождаться подтверждения SSL, а затем начать разговор по HTTP. Второй вызов заставит cURL открыть соединение и сразу же попытаться установить соединение SSL. В этом случае хост (на котором запущен Squid) должен выяснить, к какому хосту подключиться, обычно из части SNI рукопожатия. Squid может это сделать, но вам нужно настроить его с помощью оператора https_port transparent . Я бы порекомендовал сделать это с помощью первого метода, если вы можете, поскольку он требует меньше настроек на стороне Squid и дает понять на стороне клиента, что задействован прокси.