Я хочу настроить кеш-сервер для загружаемых файлов. Один поворот заключается в том, что я хочу, чтобы он работал с 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
Обратите внимание, что здесь клиент специально направляет свой запрос на myserver, поэтому он не собирается пытаться проверять, что ответ исходит от example.com. (Хотя мой сервер должен!)
Другой поворот заключается в том, что это будет использоваться только для файлов, которые никогда не меняются (URL-адреса включают номер версии), поэтому обычные вещи о свежести кеша не применяются. Если файл (или ответ перенаправления) кэширован, его следует вернуть, вообще не проверяя Интернет. Кэшированная копия должна быть удалена через определенный период после ее удаления. последний запрашивается, независимо от того, когда он был впервые загружен с нашей стороны
Вопрос: Я надеялся использовать прокси-сервер HTTP, такой как Squid, но не вижу, как его настроить для выполнения чего-либо подобного. В качестве альтернативы можно написать немного кода, но я бы предпочел этого избежать. Что я мог сделать, чтобы установить такой кеш?
Задний план: Это будет использоваться в основном для сторонних библиотек, которые мы будем использовать в нашем исходном коде, при создании образов Docker и когда разработчики создают вне контейнеров. Иногда мы в настоящее время проверяем сторонний код в наших собственных репозиториях, но это не идеально. Я уверен, что мы не единственные, кто сталкивается с этой проблемой, но я не могу найти хорошее решение в Интернете ... возможно, мне просто не хватает подходящего поискового запроса.
Это возможно и требует трех изменений конфигурации:
Вы должны знать, что после настройки SSL bump, Squid создаст и выдаст самозаверяющий сертификат для каждого домена, для которого он настроен. Ваш клиент должен принять этот сертификат, чтобы передача состоялась. cURL может сделать это с помощью параметра --cacert (позволяющего принимать центры сертификации, чей открытый ключ указан в списке) или параметра -k (полностью отключает проверку SSL).
Кроме того, есть тонкая (но важная) разница в том, как работают две команды cURL, которые вы разместили выше. Первый заставит cURL открыть соединение, как если бы он разговаривал с прокси, т. Е. Открыть порт, выдать инструкцию «CONNECT», затем дождаться подтверждения SSL, а затем начать разговор по HTTP. Второй вызов заставит cURL открыть соединение и сразу же попытаться установить соединение SSL. В этом случае хост (на котором запущен Squid) должен выяснить, к какому хосту подключиться, обычно из части SNI рукопожатия. Squid может это сделать, но вам нужно настроить его с помощью https_port прозрачный заявление. Я бы порекомендовал сделать это с помощью первого метода, если вы можете, так как он требует меньше настроек на стороне Squid и дает понять на стороне клиента, что задействован прокси.